| Sarvatt | the only thing matching ID_INPUT_TABLET is 69-xserver-xorg-input-wacom.rules | 00:01 |
|---|---|---|
| === cpplogger is now known as apachelogger | ||
| Sarvatt | http://sarvatt.com/downloads/patches/xserver-xorg-input-evdev_2.3.2-3ubuntu2.debdiff | 01:17 |
| Sarvatt | added a match for ID_INPUT_TABLET to the udev rules to have it load evdev by default, seems we missed that | 01:18 |
| bryceh | Sarvatt, uploaded | 01:29 |
| bryceh | hmm, I wonder if we've screwed up the -evdev package though. I don't see a .orig.tgz | 01:30 |
| bryceh | tjaalton, could you look to see if the -evdev merge was done correctly? | 01:31 |
| bryceh | http://packages.ubuntu.com/lucid/xserver-xorg-input-evdev - not seeing a .orig here either | 01:32 |
| Sarvatt | hmm yeah what happened there | 01:34 |
| Sarvatt | 8753eea10df08b960237f38bd2251846 377170 xserver-xorg-input-evdev_2.3.2.orig.tar.gz | 01:34 |
| Sarvatt | 1c9aa314a9dc8dd2a93389d27e6feff7 20437 xserver-xorg-input-evdev_2.3.2-3ubuntu1.diff.gz | 01:34 |
| Sarvatt | in the dsc for the 2.3.2-3ubuntu1 i sent ya a debdiff for | 01:34 |
| Sarvatt | oh dang ya already pushed it to git, was about to do that :D | 01:36 |
| bryceh | heh, yeah one of the rare instances I actually remembered to push ;-) | 01:39 |
| bryceh | Sarvatt, btw looks like we're in freeze; the upload is blocked for archive admin review | 01:43 |
| * bryceh bumps up the upper limit on http://www2.bryceharrington.org:8080/X/Graphs/totals.svg :-( | 01:44 | |
| Sarvatt | ahh yeah sorry, funny because the last evdev you sponsored for me was during a3 freeze also :) | 01:44 |
| bryceh | heh | 01:44 |
| bryceh | well, whatever went wrong with the package, we can probably fix next time we do a merge | 01:44 |
| bryceh | I've a feeling that at the least we're going to be pulling a git snapshot of -evdev before we're through | 01:44 |
| bryceh | heh, bumping up the bounds makes the graph look less scary now | 01:45 |
| Sarvatt | YAY! | 01:59 |
| Sarvatt | - Fixed a bug that caused the X server to crash when rendering occurred while the X server was not on the active VT. | 01:59 |
| Sarvatt | thats my exact resume hang problem and BUGabundo's VT switching problem | 01:59 |
| Sarvatt | in nvidia 195.36.15 | 01:59 |
| Sarvatt | http://paste.ubuntu.com/395913/ | 02:01 |
| Sarvatt | we can close out nvidia-graphics-drivers bugs with backtraces like that once its updated | 02:01 |
| bryceh | awesome | 02:06 |
| bryceh | Sarvatt, that's a pending change in the nvidia driver? | 02:06 |
| bryceh | Sarvatt, do you have a bug # for this? | 02:06 |
| Sarvatt | https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/534755 for one, was starting to go through the list to find more now and adding that to the title | 02:07 |
| ubottu | Launchpad bug 534755 in nvidia-graphics-drivers "(Needs 195.36.15) gdm/session killed when jumping to TTY" [Undecided,New] | 02:07 |
| Sarvatt | yeah its a just released blob update - http://www.nvnews.net/vbulletin/showthread.php?t=148947 | 02:07 |
| bryceh | oh hey, meant to ask if you had done that script to search Xorg.0.log files? It'd be handy for this | 02:07 |
| bryceh | Sarvatt, ^ | 02:08 |
| Sarvatt | afraid not :( | 02:08 |
| bjsnider | there is no 195.36.15 | 02:10 |
| Sarvatt | new one https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/534754 | 02:11 |
| ubottu | Launchpad bug 534754 in nvidia-graphics-drivers "(Needs 195.36.15) X crashes during suspend/resume" [Undecided,New] | 02:11 |
| Sarvatt | i just linked the nvnews post and the blobs are on the ftp bjsnider | 02:12 |
| bjsnider | does it build without a patch on the .33 kernel? | 02:13 |
| Sarvatt | no idea but we have a .32 anyway :D | 02:16 |
| bjsnider | some crazy people run the .33 kernel | 02:16 |
| Sarvatt | finding lots more with this same backtrace, gotta dig through a ton of logs to find it though.. its in like gdmlog3.txt for some people | 02:16 |
| bjsnider | they never put "improved compatibility with recent kernels" in their changelogs anymore | 02:26 |
| bryceh | Sarvatt, are you marking them as dupes as you find them? | 02:33 |
| superm1 | Sarvatt, they won't be updated unless something ships with 10.04 that needs them | 03:11 |
| superm1 | Sarvatt, i was really hoping to make sure things worked OOTB with the open driver too like they did in karmic | 03:12 |
| superm1 | it was nice that people were able to boot a karmic usb stick and have a working touchscreen | 03:12 |
| bjsnider | superm1, if dkms fails and leaves an exit code, is there a way to investigate for further information? | 03:14 |
| superm1 | bjsnider, fails during what? if it was during a build, it should generate an apport report | 03:14 |
| bjsnider | during a build. it said exit code 6 | 03:15 |
| bjsnider | but i couldn't find a useful log | 03:15 |
| superm1 | make.log should have hopefully been useful | 03:16 |
| bjsnider | where's that stored? | 03:16 |
| superm1 | it should have come in it's own key in the apport report | 03:16 |
| superm1 | or /var/lib/dkms/module/version/build/ etc | 03:16 |
| bjsnider | i just wish the failure message was a bit more specific. in this case, it was trying to apply a patch that wasn't appropriate. if it has just mentioned that it would have saved a bit of time | 03:17 |
| Sarvatt | superm1: yeah I completely understand, it's hard to mess with those things when you dont have any devices that work the same way though. bryce just sponsored an evdev upload that lets evdev work for tablet devices (what yours is showing up as, not a touchscreen), it would help alot if you could attach an Xorg.0.log to that bug after installing that and moving 69-xserver-xorg-input-wacom.rules out of the way | 03:19 |
| Sarvatt | err, archive is frozen actually so it'd be a few days | 03:20 |
| superm1 | doh | 03:20 |
| superm1 | okay :) | 03:20 |
| Sarvatt | ENV{ID_INPUT_TABLET}=="?*", ENV{x11_driver}="evdev" | 03:20 |
| Sarvatt | adding that line in /lib/udev/rules.d/65-xorg-evdev.rules | 03:20 |
| Sarvatt | (remove evtouch too) | 03:21 |
| Sarvatt | or just move 69-touchscreen.rules out of the way | 03:21 |
| Sarvatt | wacom udev rules need to be adjusted a bit to not claim all tablet devices and that fix isnt in yet, thats why i was saying make sure 69-xserver-xorg-input-wacom.rules isnt there | 03:22 |
| * Sarvatt needs to join ubuntu-bugcontrol | 03:39 | |
| RAOF | Perhaps there should be an X package set? | 03:42 |
| Sarvatt | hmm, looks like the glxinfo callout in the apport hooks is creating new bug reports about glxinfo crashing :D | 03:58 |
| RAOF | Yay! | 03:58 |
| Sarvatt | when run outside of X its trying to glxinfo to attach the info? | 03:58 |
| RAOF | Oh, that'll be people with half-installed nvidia drivers, I'll wager. | 03:58 |
| Sarvatt | yeah exactly what i'm looking at, been working on nvidia-graphics-drivers bugs the past few hours | 03:59 |
| Sarvatt | nvidia xorg.conf, no nvidia kernel module and it fails to start X yet its trying to attach glxinfo output | 04:00 |
| Sarvatt | https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/532425 | 04:01 |
| ubottu | Launchpad bug 532425 in nvidia-graphics-drivers "glxinfo crashed with SIGSEGV in __libc_start_main()" [Undecided,New] | 04:01 |
| RAOF | Heh. | 04:01 |
| RAOF | Yeah, there it is: glXQueryExtensionsString. glxinfo is quite happy to run outside of X; it'll just bail saying it can't find a display. | 04:03 |
| Sarvatt | apport collected glxinfo.txt contents - Error: command ['glxinfo'] failed with exit code -11 :D | 04:07 |
| Sarvatt | gnome-screensaver-gl-helper sure does hate the blob | 04:27 |
| libv | since you guys are into packaging more than into raw development; check the mesa-dri-* trees out in http://cgit.freedesktop.org/~libv/ | 04:44 |
| tjaalton | Sarvatt, bryceh: yeah looks like the new evdev upload made it a native package :) | 05:08 |
| tjaalton | so probably get that dropped from the queue, or just reupload then non-native version | 05:19 |
| tjaalton | *the | 05:19 |
| tjaalton | bryceh: oh, so the old -evdev was busted, but if the new upload went through fine it should correct itself | 07:06 |
| tjaalton | though I can't get to the lp page | 07:06 |
| tjaalton | oopses | 07:06 |
| === rye is now known as rye_ | ||
| === rye_ is now known as rye__ | ||
| === rye__ is now known as rtgz | ||
| === rtgz is now known as rye | ||
| === |thade| is now known as Alexia_Death_ | ||
| bryceh | Sarvatt, I had put in a change a month or so ago to check for DISPLAY before running glxinfo | 08:51 |
| bryceh | Sarvatt, so if the bug report(s) in question pre-date that, dont' worry about it | 08:51 |
| bryceh | if they're more recent, then that would be interestingly weird | 08:51 |
| bryceh | hey, good news everybody, I have a new graph! | 08:52 |
| bryceh | http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid.svg | 08:52 |
| tjaalton | less disappointing one than totals? | 08:52 |
| bryceh | indeed! | 08:52 |
| bryceh | yeah this limits to just X bugs tagged 'lucid' | 08:53 |
| tjaalton | oh that's almost readable :) | 08:53 |
| bryceh | a much more reasonable 300 bugs | 08:53 |
| bryceh | and really, *this* is the graph we should be looking at. It's the ones we know are relevant right now | 08:53 |
| tjaalton | yep | 08:54 |
| apw | we are finding that i915 powersave is an issue for some cards when turned on with drm 2.6.33 ... i hear you guys may know about it, and may be able to tell me which ones are known good and which bad | 14:12 |
| apw | Sarvatt, bryceh, RAOF ^^ | 14:17 |
| johanbr | hmm... with the latest nouveau bits from the ppa, the boot hangs at the plymouth splash screen, just before switching to gdm | 15:13 |
| johanbr | booting without splash works | 15:13 |
| rye | johanbr, hm, from ppa? In my case I get that even in stock lucid | 15:22 |
| johanbr | rye, oh... might be something in the main archive that's botched, then | 15:23 |
| tjaalton | it's called plymouth | 15:25 |
| tjaalton | file a bug against it | 15:26 |
| tjaalton | but there should be no need ot use any ppa's anymore aiui | 15:26 |
| tjaalton | s/ot/to/ | 15:26 |
| === seb128_ is now known as seb128 | ||
| === matteo` is now known as matteo | ||
| === Sinnerman is now known as Cobalt | ||
| === matteo` is now known as matteo | ||
| Sarvatt | ok ok I'm here for a good chunk of time today until after the meeting, knocked out my afternoon jobs early. | 16:30 |
| Sarvatt | apw: do you want PCI IDs or are generations ok? 915 and 945 variants are affected, I would add 8xx series as well to be on the safe side but I have not seen direct reports that they need it yet | 16:32 |
| Sarvatt | thats regarding powersave=0 | 16:33 |
| apw | Sarvatt, ok thanks so 945 and below are all bust yes? | 16:34 |
| Sarvatt | https://bugs.freedesktop.org/show_bug.cgi?id=26266 is the bug I was following about it, I still have the problem on my machine | 16:34 |
| ubottu | Freedesktop bug 26266 in Driver/intel "[945] Screen lockup some time after wakeup from standby (to ram)" [Critical,Assigned] | 16:34 |
| rye | tjaalton, the same plymouth worked on my intel-based netbook... but failed with -radeon and -nouveau | 16:35 |
| Sarvatt | apw: the method you are using to determine module options, is it overrideable? | 16:36 |
| Sarvatt | yeah <= 945 for sure right now | 16:36 |
| apw | Sarvatt, i only have modeset at the moment but yes thats changing the default of you haven't set it on the command line, so we can override it to test | 16:36 |
| Sarvatt | like if I have a blacklisted chipset for the powersave option, can i still load it with powersave=1 to force it on? | 16:37 |
| apw | i will be planning to do that if at all possible | 16:37 |
| Sarvatt | ah nice, was just worried about that | 16:37 |
| Sarvatt | to be honest the powersave module option is an incredibly small amount of power savings on my 945 netbook anyway, I can't tell a difference in powertop because the low is ~6.9 watts either way | 16:41 |
| apw | Sarvatt, is g45 > or < i945 | 16:44 |
| Sarvatt | > | 16:44 |
| apw | Sarvatt, perhaps to put it a better way, is the list in pciidlist in i915 in order | 16:44 |
| Sarvatt | hmm doesn't look like it, one sec i'll try to put together a list | 16:45 |
| apw | Sarvatt, can i also assume that UMS is handling any powersaving (or more likely not doing it) | 16:46 |
| Sarvatt | apw: honestly I'm not 100% on that, but I believe that is a correct assumption | 16:56 |
| apw | lets hope so :) | 16:56 |
| Sarvatt | asking over in the intel channel | 16:57 |
| Sarvatt | apw: drivers/gpu/drm/i915/i915_drv.c has a sorted pci id list | 17:00 |
| apw | Sarvatt, ahh that was the one i was quoting :) | 17:01 |
| Sarvatt | oh sorry about that! was looking at the modinfo list which was out of order | 17:02 |
| Sarvatt | 27ae would be the last yeah | 17:02 |
| Sarvatt | hmm | 17:07 |
| Sarvatt | the problem seems to be in framebuffer compression for sure on my machine, the only relevant ones on that list with .has_fbc=1 are | 17:08 |
| Sarvatt | INTEL_VGA_DEVICE(0x2592, &intel_i915gm_info), | 17:09 |
| Sarvatt | INTEL_VGA_DEVICE(0x27a2, &intel_i945gm_info), | 17:09 |
| Sarvatt | INTEL_VGA_DEVICE(0x27ae, &intel_i945gm_info), | 17:09 |
| Sarvatt | ah apw I knew there was a launchpad bug - https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/492392 | 17:15 |
| ubottu | Launchpad bug 492392 in linux "[lucid, intel] After suspend, flickering screen and then blank screen." [Medium,Fix released] | 17:15 |
| Sarvatt | weird, would anyone mind moving this to mesa? I can't. https://bugs.edge.launchpad.net/xorg-server/+bug/539373 | 17:29 |
| ubottu | Launchpad bug 539373 in xorg-server "[Mesa] Selection in blender does not work with r600" [Undecided,New] | 17:29 |
| Sarvatt | nevermind, worked it out | 17:33 |
| === yofel_ is now known as yofel | ||
| === radoe_ is now known as radoe | ||
| Sarvatt | meeting in 20 minutes right? :) | 19:39 |
| bryceh | yep | 19:40 |
| === jpetersen_ is now known as jpetersen | ||
| pitti | o/ | 20:01 |
| bryceh | heya | 20:01 |
| bryceh | pitti, rick says he's going to be a bit late | 20:02 |
| Sarvatt | heyo! | 20:02 |
| bryceh | hi Sarvatt | 20:02 |
| bryceh | RAOF, tseliot? | 20:02 |
| RAOF | Good (somewhat early) morning :) | 20:02 |
| Sarvatt | morning RAOF :) | 20:02 |
| * RAOF is just reading #ubuntu-kernel backscroll | 20:03 | |
| jpetersen | hey | 20:03 |
| bryceh | RAOF, sorry to get you out of bed early, and sorry to tseliot for staying up late | 20:03 |
| bryceh | hi jpetersen! well met | 20:03 |
| bryceh | let's go ahead and get started | 20:03 |
| tjaalton | howdy | 20:03 |
| bryceh | heya tjaalton | 20:04 |
| bryceh | the main purpose of this meeting is to get more manpower organized around X stabilization | 20:04 |
| bryceh | the motivator for this is that we've gotten tasked to make some progress with multitouch, and that's going to tie up some manpower which otherwise would be going to stabilization work | 20:04 |
| bryceh | (namely me) | 20:05 |
| bryceh | So we need your help to ensure we maintain good level of manpower on X stabilization in general | 20:05 |
| tseliot | hey | 20:05 |
| bryceh | I know this impacts projects you guys have been working on, so double thank-you for your flexibility, it's really appreciated | 20:05 |
| bryceh | in this meeting, I want to focus mainly on the non-multitouch aspects, but if anyone is particularly interested in working on that let me know; we can move tasks around pretty fluidly where there's interest | 20:06 |
| bryceh | before I go further... any comments or questions? | 20:07 |
| pitti | I have one wrt. multitouch, but let's do that at the end | 20:07 |
| bryceh | ok | 20:07 |
| Sarvatt | I wrote down quite a lot of bug related questions/issues I came up with while spending the whole afternoon focusing on bug work, not sure when to bring them up :) | 20:07 |
| pitti | and get to the main purpose first | 20:07 |
| bryceh | Sarvatt, excellent. Let's cover some of the high level stuff and then get into specific problems/bugs/needs | 20:08 |
| * Sarvatt nods. | 20:08 | |
| bryceh | (for reference, here's the multitouch blueprint listing the work items we've identified so far: https://wiki.ubuntu.com/X/Blueprints/Multitouch) | 20:08 |
| bryceh | I sketched out a todo list for X stabilization, most of you have seen this: | 20:08 |
| bryceh | https://wiki.ubuntu.com/X/Projects | 20:09 |
| bryceh | hopefully that doesn't look too intimidating... I tried to slice and dice the work down into chunks that would be more manageable | 20:09 |
| bryceh | one strategy I try to use for tackling this stuff is to try and get bugs filed upstream, and get their help solving them | 20:10 |
| pitti | (those canned bug searches are awesome!) | 20:11 |
| bryceh | this is effective since they're a lot smarter than me, and can come up with better solutions than I can most of the time | 20:11 |
| Sarvatt | I've asked my main question about it before but just want to be sure, n-trig seems to be the targetted device for multitouch support at the moment? That is the only device I'm aware of that looks even somewhat feasable to bring multitouch support for into lucid and there are quite alot of issues with it that I'm sketchy about. | 20:11 |
| bryceh | so then my job is to just make sure the bug report isn't completely insane, and that it's been reasonably well tested and characterized, and then just cut and paste into bugzilla | 20:11 |
| bryceh | Sarvatt, yes n-trig is the main focus | 20:12 |
| Sarvatt | there are 3 versions of the n-trig touchscreens that I know of, one supports single touch and stylus, one supports multitouch and the newest one can support both | 20:12 |
| Sarvatt | but each requires different firmware to be loaded | 20:12 |
| tseliot | right | 20:12 |
| Sarvatt | and the firmware appears to come from the windows drivers | 20:12 |
| bryceh | wb rickspencer3 | 20:13 |
| bryceh | Sarvatt, good questions, let's chat more about MT later | 20:14 |
| Sarvatt | ahh sorry about that, thought the topic was MT before I went rambling :) | 20:15 |
| bryceh | no prob | 20:15 |
| bryceh | so you can see in the list I roughly divided the tasks into three buckets. | 20:15 |
| bryceh | the first group I think we must get done, the second should get done, and the third would be nice to have done | 20:16 |
| rickspencer3 | this meeting shouldn't be about MT, it should be about everything *but* MT | 20:16 |
| rickspencer3 | ;) | 20:16 |
| bryceh | In general I think X is in fair shape, but we have a HUGE backlog of bug reports | 20:17 |
| bryceh | we spent a lot of time in the cycle doing blueprint work and bringing in a lot of new features | 20:17 |
| bryceh | the fear is that many of these new features have new bugs as well | 20:17 |
| rickspencer3 | bryceh, is this a fair time to introduce jpetersen | 20:18 |
| bryceh | please do! | 20:18 |
| rickspencer3 | (excuse the interruption) | 20:18 |
| pitti | Sarvatt: while you are editing the wiki, can you please fix the "radeon bugs" link to be -ati, not -radeon? | 20:18 |
| rickspencer3 | so, jpetersen has been working on Indicatory stuff | 20:18 |
| pitti | Sarvatt: (just tried it, but you have the lock) | 20:18 |
| rickspencer3 | but I've asked him to join us here so that he could spend the rest of his 2 (maybe more) weeks helping lighten the load for xorg stuff | 20:19 |
| rickspencer3 | maybe he'll work directly on xorg stuff, or maybe he'll take over other work so other people can do that | 20:19 |
| rickspencer3 | jpetersen comes highly recommend by jono and jcastro | 20:19 |
| Sarvatt | sure thing, was adding my name to a few tasks, done | 20:19 |
| rickspencer3 | so, welcome! | 20:19 |
| bryceh | jpetersen, welcome aboard! | 20:19 |
| jpetersen | thanks :) | 20:19 |
| tseliot | welcome :-) | 20:20 |
| Sarvatt | nice to meet you jpetersen :) | 20:20 |
| RAOF | Welcome | 20:20 |
| bryceh | jpetersen, can you give us some background about what level of debugging work you've done? | 20:21 |
| bryceh | jpetersen, (just trying to get a feel for types of tasks you would be interested in or most effective at) | 20:23 |
| jpetersen | bryceh, ok before i worked for Ubuntu I worked on the application framework for Maemo 5 | 20:23 |
| jpetersen | bryceh, we worked on a clutter based window manager and we had to work together with the X team there for bug fixes | 20:24 |
| bryceh | ok great | 20:26 |
| bryceh | RAOF, tseliot, I know you've been busy on some non-X work, how much time do you think you'll have going forward, and are there particular things you'd like to focus on? | 20:27 |
| bryceh | also, any input regarding how you think we should attack the stabilization work for X overall? | 20:28 |
| bryceh | Sarvatt and tjaalton, interested in your input as well | 20:29 |
| bryceh | also, what do you guys think of this approach of placing the main focus on pushing bug reports upstream? I know it's a lot of effort but I've found it tends to work reliably | 20:30 |
| pitti | RAOF: would you be interesting in shepherding the nouveau bugs, since you've been working on them already and they certainly need particular attention? | 20:30 |
| RAOF | I'm obviously happy to pick up the -nouveau tasks. | 20:30 |
| tseliot | bryceh: I handed the 16 colours support for plymouth to Keybuk but I took some new bugs which are both gnome and synaptics related (g-s-d), in addition to my work on kdm. Then of course I have some more work on mesa and nvidia and some other stuff. Let me have a look at your list | 20:31 |
| pitti | bryceh: I won't have too much time left, but I could give a hand with -evdev bugs, since I'm reasonably familiar with the input layer and how X handles them | 20:32 |
| tjaalton | bryceh: the merges are easy and not a lot of work. working on getting a (more) stable wacom snapshot might take more time | 20:32 |
| bryceh | pitti, great thanks | 20:32 |
| tseliot | bryceh: I guess "going through all of the -nvidia bug reports" is something I'll have to do sooner or later and there are a few things on my radar already | 20:32 |
| RAOF | didirocks is doing well with UNE, and f-spot's pretty much done. I will be able to dedicate lots of time. | 20:32 |
| tjaalton | tseliot: good luck :) | 20:33 |
| tseliot | heh, thanks, I'll need it | 20:33 |
| pitti | bryceh: hah, bug 537801 is exactly my taste ;) | 20:33 |
| ubottu | Launchpad bug 537801 in xserver-xorg-input-evdev "Touchscreen doesn't work after karmic->lucid upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/537801 | 20:33 |
| bryceh | tseliot, ok. I have wondered if scripts could help... like detect if they manually installed nvidia and close the bug with a suitable apology | 20:33 |
| bjsnider | tseliot, are you planning on packaging the new nvidia blob that was released last night? | 20:33 |
| bryceh | RAOF, I was also thinking you might be interested in taking the xserver bugs, since a lot of random stuff ends up there and it would give you a good breadth of X work, that might help get you up to speed for next cycle | 20:34 |
| tseliot | bryceh: can you send me a bunch of scripts that I could use as an example, please? | 20:34 |
| bryceh | RAOF, there tend to be a lot of gdb backtraces filed into xorg-server, and those tend to be pretty straightforward to debug | 20:35 |
| tseliot | bjsnider: I didn't know about that but I was waiting for it | 20:35 |
| bryceh | tseliot, sure can do | 20:35 |
| tseliot | thanks | 20:35 |
| RAOF | bryceh: That sounds like a good idea. I was going to suggest that I take the -intel tasks, too, unless someone else wants them. | 20:35 |
| bryceh | RAOF, ok great, yeah that's a big one, but Sarvat and Geir help a lot there too | 20:36 |
| bryceh | oh btw | 20:36 |
| bryceh | to get a visualization on how the bug situation looks I did a graph: | 20:36 |
| bryceh | http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid.svg | 20:36 |
| Guest26447 | btw, I'm Geir Ove (just joined after coming home)... I'm an IRC-analphabet, hence the nick... | 20:36 |
| bryceh | it looks like between nvidia and intel, that's like half the bugs almost | 20:36 |
| bryceh | Guest26447, heya! | 20:36 |
| tseliot | yes, that's a lot | 20:37 |
| bryceh | I think I can take -ati | 20:37 |
| pitti | bryceh: is that because intel is really that bad still, or just because we have the freeze detection on intel, and not on other drivers? | 20:37 |
| bryceh | pitti, a combination of both | 20:37 |
| Guest26447 | Freeze detection should amount to 50-60 bugs currently... | 20:37 |
| RAOF | Which would be about half those intel bugs. | 20:38 |
| Sarvatt | I don't even know where to start, but I put my list of concerns here - http://sarvatt.com/downloads/issues.txt | 20:38 |
| bryceh | Sarvatt, yeah it's a good point that we need ways to force into failsafex or other debugging modes | 20:38 |
| bryceh | moving to KMS seems to have obsoleted a lot of our traditional debugging techniques | 20:39 |
| bryceh | and doesn't appear to give us replacement techniques... although maybe we just need to poke around more | 20:39 |
| bryceh | Sarvatt, regarding trigger happy freeze detection, you may be right. I was hoping to get upstream to clue us in better but no word so far. | 20:40 |
| RAOF | For modelines we should be able to add them with xrandr, although that's wildly inconvenient compared with xorg.conf. | 20:40 |
| bryceh | I think if we start pushing the Intel bugs upstream they'll push back if the bugs are invalid, and we can adjust tools from there | 20:41 |
| bryceh | RAOF, yeah | 20:41 |
| Guest26447 | About -intel freeze trigger happiness: I looked a bit on the code during a train ride on the weekend, and there seems to be two ways to trigger the error handler with the udev event: one if the GPU is hung and otherwise if any other error is detected. | 20:42 |
| Guest26447 | The current title suggests only the GPU hung case. | 20:43 |
| bryceh | Guest26447, yeah I have it on my todo list to fix up the apport hook based on your latest suggestions, just haven't gotten to it yet | 20:43 |
| tseliot | Sarvatt: if you give me a bug number for the gnome-screensaver + nvidia GL bugs I can ask Nvidia about it | 20:43 |
| RAOF | Also on the subject of failsafes, we should get vesa to fail to load when KMS is active; for me, it badly-programs the hardware and I get a “bloom” on my lvds. | 20:44 |
| Guest26447 | bryceh, hold it off a little bit, since I have found out some more since last time... Sorry this is so incremental... | 20:44 |
| bryceh | ok | 20:44 |
| bryceh | Guest26447, I like incremental actually ;-) | 20:44 |
| bryceh | RAOF, yeah I've seen that too | 20:44 |
| Guest26447 | bryceh, I'll put together another incremental email soon.... | 20:44 |
| RAOF | I've got a bug report on LP & bugzilla about that. If push comes to shove, that *should* be an easy patch to write myself. | 20:45 |
| bryceh | ok, if anyone needs sponsoring, tseliot, tjaalton and myself are all core-dev so can push patches | 20:46 |
| Sarvatt | I have xforcevesa working by adding it to initramfs-tools, and adding a check for xforcevesa to the gdm init scrit and doing an exit 1 if it's there which starts failsafe. Can anyone think of a better way to do it? | 20:46 |
| tseliot | bryceh: absolutely | 20:47 |
| bryceh | RAOF, tseliot, do you think it would be better to have jpetersen help you with some of your other tasks to free you for more X work, or shall we turn jpetersen loose on doing X bug upstreaming? | 20:47 |
| Sarvatt | I can't seem to get the blacklist to stick, it eventually loads things later when plymouth kicks in | 20:47 |
| bryceh | jpetersen, or would you be interested in tackling X debugging directly? (e.g. are you familiar with gdb and/or X internals at all?) | 20:47 |
| jpetersen | i am familiar with gdb and some X internals | 20:48 |
| RAOF | jpetersen: If you've worked on a clutter-based window manager before, you'd perhaps like to tackle some of the UNE tasks? That's all clutter & clutk. | 20:48 |
| superm1 | Sarvatt, it's currently living in casper, so if you find a better place, make sure to remove it from casper too | 20:49 |
| tseliot | bryceh: I would like to take care of those bugs personally, so maybe he can focus on upstreaming or on whatever he prefers | 20:49 |
| jpetersen | RAOF, I could do that | 20:50 |
| RAOF | jpetersen: https://wiki.ubuntu.com/UNE/lucid-bugs is a nice list of UNE tasks, if you want a browse. | 20:50 |
| Sarvatt | superm1: hmm just looked and that casper hook will blow up horribly if KMS is in use | 20:51 |
| superm1 | Sarvatt, well it only emulates what the old xforcevesa used to do, and i've only tested it on nvidia hardware personally | 20:51 |
| bryceh | jpetersen, what type(s) of video cards do you have on hand? | 20:51 |
| superm1 | Sarvatt, so by all means, move the logic elsewhere that is more KMS aware :) | 20:52 |
| jpetersen | bryceh, just some different intel cards | 20:56 |
| bryceh | Sarvatt, getting back to your list... ATI> on my todo list to merge 192, I'll look at those bug reports. synaptics> TBH everyone gripes about the default settings no matter how they're set, but yeah would be nice to hammer some of that out | 20:56 |
| bryceh | jpetersen, ok, if you have time outside the UNE work, perhaps you can help RAOF with triaging the -intel bugs | 20:57 |
| jpetersen | bryceh, yes I think I can do that | 20:57 |
| bryceh | jpetersen, we've got a tutorial on how to triage X bugs at https://wiki.ubuntu.com/X/Triaging | 20:57 |
| RAOF | jpetersen: Great, thanks! | 20:57 |
| bryceh | I think that explains most of what you need to know. There's also a lot more info under wiki.ubuntu.com/X | 20:58 |
| bryceh | ok, we're at the hour, but I think we have a good plan in place now | 20:58 |
| jpetersen | thanks I will look at that pages | 20:59 |
| bryceh | I'll write up the results of this meeting, thanks everyone for volunteering, I think we mostly have everything covered now | 20:59 |
| bryceh | rickspencer3, any final words? | 20:59 |
| bryceh | pitti, or thoughts from you? | 20:59 |
| rickspencer3 | make it so? | 20:59 |
| pitti | bryceh: ohe question, how far does the MT support go? just making drivers available? because I don't think we have any application right now which would actually make use of those? | 20:59 |
| pitti | bryceh: (not meeting related, it's the Q that I announced at the beginning) | 21:00 |
| pitti | bryceh: thanks a lot for organizing this | 21:00 |
| bryceh | pitti, just drivers. Purely low level hardware-specific enablement work | 21:00 |
| bryceh | pitti, anything beyond that is gravy (and probably out of scope) | 21:00 |
| tseliot | I think OEM will take care of the rest | 21:00 |
| pitti | bryceh: so that it's "there" for developers/OEMs to play around with, but we don't have a commitment to making GNOME multitouch-capable or so? :-) | 21:00 |
| bryceh | pitti, exactly | 21:00 |
| pitti | bryceh: *phew* :) | 21:01 |
| bryceh | well, maybe lucid+1 for that | 21:01 |
| tseliot | well, X developers would have to come to an agreement on multitouch first ;) | 21:01 |
| bryceh | alright thanks everyone! expect a summary email within a few hours, and I'm open to questions whenever | 21:02 |
| tjaalton | don't think there are toolkit support planned yet | 21:02 |
| pitti | like, how to represent it in an Xevent? | 21:02 |
| tjaalton | s/are/is/ | 21:02 |
| tseliot | there are some patches for clutter and gtk+ | 21:02 |
| tjaalton | well, that still doesn't sound like a plan :) | 21:05 |
| tseliot | tjaalton: because it's not ;) | 21:06 |
| bryceh | Sarvatt, RAOF, regarding the glxinfo crashes in apport, yeah I think just checking for DISPLAY is insufficient. We need something else to test to see if GLX is available | 21:09 |
| bryceh | or alternatively, patch glxinfo to check itself, and to exit with an error code instead of crashing in such a case | 21:09 |
| RAOF | Can we simply suppress error reports from glxinfo crashing in the apport hook? | 21:10 |
| RAOF | Because catching all possible crashes sounds hard :) | 21:11 |
| bryceh | RAOF, yeah if we can detect it | 21:11 |
| bryceh | or even just drop glxinfo entirely | 21:11 |
| bryceh | I think the number of cases where we actually need the info is quite tiny | 21:12 |
| bryceh | like, certain types of mesa bugs | 21:12 |
| bryceh | although this feels a bit like sweeping the issue under the carpet ;-) | 21:12 |
| RAOF | The information the glxinfo crashes when you try to run it seems like an important data point to have on the bug. | 21:13 |
| bryceh | true | 21:13 |
| Sarvatt | pitti: on the n-trig multitouch side it just goes through wacom and supports hardcoded multi finger gestures like 2 finger tapping for right click and 2 finger scrolling with no way to have multiple pointers (per finger) or let applications detect do things with the multi finger stuff.. its basically just like a touchpad, nothing exciting :) | 21:14 |
| pitti | Sarvatt: I just wasn't aware that events (linux input and X) can have a list of coordinates | 21:20 |
| Sarvatt | wacom handles it internally, checks if theres multiple fingers in use and enters gesture mode if so, stops the cursor and waits for the second finger to be lifted to process it as an event based off of filters. multitouch is just a single cursor and a new button event to X with that | 21:35 |
| Sarvatt | synaptics does the same thing for 2 finger scrolling and stuff | 21:40 |
| bryceh | pitti, I think some of this may be new with the mpx stuff | 21:43 |
| bryceh | RAOF, btw keybuk was asking about whether the lbm_nouveau name support is still needed | 21:51 |
| bryceh | or can we drop the patches that added that | 21:51 |
| RAOF | We can drop them; we'll just need to pull patched versions of all those packages into xorg-edgers & the testing PPA. | 21:52 |
| RAOF | It would be a bit easier for the PPAs if we didn't drop them, but they're not needed for Lucid. | 21:53 |
| bryceh | RAOF, ok can you follow up with keybuk about that when you get a chance. Or toss debdiffs at me again and I can sponsor | 22:00 |
| bryceh | it doesn't matter to me whether we keep the patches or not but he might have a stronger preference | 22:00 |
| RAOF | I will. | 22:00 |
| Sarvatt | RAOFL: I already did a task you put your name on on the wiki (didn't see it until after) hope ya dont mind :) | 22:23 |
| RAOF | Sarvatt: You're welcome :) | 22:23 |
| Sarvatt | hmm I like the name RAOFL :) | 22:24 |
| Sarvatt | so..many..plymouth...bugs... | 22:48 |
| Sarvatt | filed against driver packages | 22:48 |
| RAOF | Pylmouth has not been a smooth ride. | 22:51 |
| Sarvatt | bryceh: how often is http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid.svg updated? | 23:03 |
| bryceh | daily I think, let me check | 23:05 |
| bryceh | hourly | 23:05 |
| bryceh | 40 min after the hour | 23:05 |
| bryceh | well, there's actually two scripts | 23:06 |
| Sarvatt | ugh, depressing to spend 7 hours straight clearing things out and its going up :) | 23:06 |
| bryceh | tell me about it | 23:06 |
| Sarvatt | was doing alot of nvidia-graphics-drivers-180 ones this morning though and those arent on there | 23:06 |
| bryceh | I think getting a handle on the intel freezes is probably key | 23:07 |
| bryceh | Sarvatt, you mean ones that weren't tagged 'lucid'? yeah those won't be included here | 23:07 |
| bjsnider | Sarvatt, were those legitimate bugs or support requests? | 23:09 |
| Sarvatt | i'm making sure theres no nvidia-graphics-drivers-180 bugs tagged lucid so yeah :) | 23:09 |
| Sarvatt | and likewise for nvidia-graphics-drivers bugs tagged karmic, looked like KDE people used it as a catchall target for blob problems | 23:10 |
| Sarvatt | bjsnider: look at the latest nvidia-graphics-drivers bug and you tell me for example https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/539351 | 23:12 |
| Sarvatt | :D | 23:12 |
| ubottu | Ubuntu bug 539351 in nvidia-graphics-drivers "[amd64][nv8600gt] karmic/lucid nvidia proprietary cause system crash when xserver-xorg starts" [Undecided,New] | 23:12 |
| bjsnider | that's a support request | 23:13 |
| bjsnider | his hardware is no doubt broken | 23:13 |
| bjsnider | anyway, he should be complaining to nvidia | 23:14 |
| bryceh | Sarvatt, yeah X was being used as a catchall in general a lot more than it should when I started | 23:14 |
| bjsnider | ubuntu does a poor job telling people where to go to file bugs on the nvidia driver | 23:14 |
| Sarvatt | anything with a title like package nvidia-185-kernel-source 185.18.36-0ubuntu9 failed to install/upgrade is pretty much guaranteed to be a PPA package upgrade issue | 23:15 |
| bryceh | bjsnider, open to suggestions | 23:15 |
| RAOF | bjsnider: I'm not really aware of a better place. | 23:15 |
| bjsnider | bryceh, i knew you'd say that | 23:15 |
| bjsnider | i have the info in my ppa description, if anybody reads it | 23:16 |
| bryceh | bjsnider, in fact we're pretty clear in Jockey to say "This is a binary-only driver that we can't really support since it's closed source" or some such | 23:16 |
| Sarvatt | I dont know what to do with the ones with titles like Xorg crashed with SIGSEGV in _nv001644X() | 23:16 |
| bryceh | people appear to ignore that and file lots of bug reports to us anyway | 23:16 |
| Sarvatt | (and there's *alot*) | 23:16 |
| Sarvatt | thats basically wontfix | 23:16 |
| bjsnider | yeah but do you say "go to nvforums.com/... blah blah" | 23:16 |
| bryceh | bjsnider, I guess we could, is that a feasible out? | 23:17 |
| jcristau | bjsnider: is there any point in saying that? | 23:17 |
| bryceh | or is it just the equivalent of saying "go away!" | 23:17 |
| bjsnider | there's a specific page that nvidia has put up explaining exactly how to file a bug with them | 23:17 |
| bjsnider | jcristau, not sure what you're getting at. you mean nvidia won't care if a bug is filed? | 23:18 |
| bjsnider | or users won't care? | 23:18 |
| bjsnider | Sarvatt, all of those bugs would be nvidia-specific issues right? | 23:18 |
| bryceh | Sarvatt, pretty much any crash that is isolated to -nvidia code like that is going to need to go to nvidia since we don't have the source code. I think scripting something to auto-close those with a pointer to nvidia (or the forums as bjsnider suggests) would be entirely appropriate | 23:19 |
| Sarvatt | yeah like https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180/+bug/532580 for example | 23:19 |
| ubottu | Ubuntu bug 532580 in nvidia-graphics-drivers-180 "Xorg crashed with SIGSEGV in _nv001646X()" [Undecided,Confirmed] | 23:19 |
| jcristau | bjsnider: the former | 23:20 |
| bjsnider | jcristau, cynical | 23:21 |
| bryceh | Sarvatt, we have code to automatically detect nvidia crashes and file them to nvidia-graphics-drivers. That code could be enhanced to also examine the backtrace and kick out ones that look non-viable | 23:21 |
| bjsnider | this is what my ppa description says: If you have a display bug in the Nvidia driver, please report bugs in the nvforums site here: http://www.nvnews.net/vbulletin/forumdisplay.php?s&forumid=14 | 23:21 |
| jcristau | bjsnider: maybe. but wrong? | 23:21 |
| bjsnider | i think they fix the bugs they have the manpower to fix, especially if they impact revenue customers | 23:22 |
| superm1 | is the nvidia bug report script ran during an apport capture for an nvidia crash? | 23:22 |
| jcristau | bjsnider: right, that makes sense | 23:22 |
| bryceh | superm1, no not from the apport crash hook | 23:22 |
| superm1 | if not, then perhaps add that and then in your auto close you can tell people to use that to file their bug with nvidia since there is nothing ubu developers can do | 23:22 |
| bryceh | hmm, or even just launch it directly for them | 23:23 |
| superm1 | yeah that's what i mean | 23:23 |
| superm1 | launch it for them to capture everything nv would have wanted in a bug report | 23:23 |
| bjsnider | then hope they don't waste time reporting it on launchpad | 23:23 |
| Sarvatt | bryceh: what bug status is appropriate is what I'm wondering, I can't set wontfix but I can start tagging bugs in a way you can pick up later if you want | 23:23 |
| superm1 | well if they do, then your autocloser would do justice in explaining what they can do | 23:24 |
| bryceh | Sarvatt, oh yeah you need to join the ubuntu-bugs or whatever team to get rights for setting wontfix | 23:25 |
| bryceh | bdmurray, could you hook Sarvatt up with joining the bugs team so he can wontfix stuff as needed? | 23:25 |
| Sarvatt | I think allowing the bug, tagging it a special way and running a script over it later would be the way to go so they can have the relevant info collected for them if they do want to report it | 23:27 |
| bjsnider | but how would apport know when to run the nvidia crash report and when the bug has to do with the ubuntu packaging scripts? | 23:27 |
| superm1 | bjsnider, well maybe just run the nvidia crash report tool every time when filing an nv bug? | 23:29 |
| Sarvatt | it would be alot more fine grained than that, I wasnt suggesting closing *all* blob bugs just ones obviously the blob's fault like Xorg crashed with SIGSEGV in _nv001646X() | 23:29 |
| Sarvatt | or were you guys talking about closing out all blob bugs? | 23:29 |
| bryceh | probably we're talking about several overlapping things | 23:30 |
| bjsnider | superm1, maybe there's some way to make apport intelligent enough to say "this is probably not a bug ubuntu can fix. please report it to..." | 23:30 |
| bdmurray | bryceh: sure if you are vouching for him | 23:30 |
| Sarvatt | a good portion of them are actually relevant | 23:30 |
| bryceh | bdmurray, I vouch for Sarvatt | 23:30 |
| bjsnider | Sarvatt, i asked earlier how many of these nvidia bugs are real bugs and how many are support requests or nvidia bugs | 23:31 |
| bryceh | bjsnider, don't think we have that data, but you're right a good chunk are really support requests | 23:32 |
| bryceh | but the trick is how to distinguish them | 23:32 |
| Sarvatt | support request ones would have to be manually identified for sure | 23:32 |
| Sarvatt | oh, there's always the convert to a question option I totally missed somehow... | 23:33 |
| bryceh | bdmurray, do you need Sarvatt to poke a button somewhere? | 23:34 |
| bjsnider | too bad there's no way to just click a button and have all of the nvidia ones closed and sent on to nvidia | 23:34 |
| bryceh | one thing I've pondered is if we could detect if the user had manually installed -nvidia from the web | 23:34 |
| bryceh | if so, those could be closed en bulke with some pointer to an nvidia installation guide | 23:35 |
| bryceh | bjsnider, we can do arsenal scripts to some degree, so long as there are ways to programmatically determine what bugs to apply the rules to | 23:36 |
| bryceh | usually the hard part is actually doing the cut-and-paste into the foreign bug tracker | 23:36 |
| bjsnider | well, for example a pattern like _nv001646X() is obviously an nvidia bug | 23:36 |
| bryceh | right | 23:36 |
| bjsnider | nvidia could possibly be some help here | 23:37 |
| bdmurray | bryceh: nope he's all set | 23:37 |
| bjsnider | they could provide common patterns | 23:37 |
| bryceh | bdmurray, excellent thanks! | 23:37 |
| Sarvatt | bdmurray and bryceh: thank you *very* much for that :) | 23:38 |
| bryceh | Sarvatt, you are now beknighted with the wontfix wand | 23:38 |
| bryceh | I think this means you can also set priorities on bugs, and see private bugs | 23:38 |
| Sarvatt | bryceh: https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/509117 -- which side of that bug do you want to focus on? | 23:38 |
| ubottu | Ubuntu bug 509117 in nvidia-graphics-drivers "when kernel module fails to build Xorg crashes with SIGSEGV in CloseWellKnownConnections ()" [Critical,Triaged] | 23:38 |
| Sarvatt | the problem in the description is fixed | 23:38 |
| Sarvatt | \they still won't get X up with a nvidia xorg.conf and a kernel module failed to build, but it wont segfault anymore :) | 23:39 |
| bdmurray | bryceh, Sarvatt: yes priority and private apport crashes | 23:39 |
| bryceh | I'd consider it closed at this point | 23:39 |
| bryceh | I think we have bug reports already open against jockey and other things to DTRT in these cases | 23:39 |
| bryceh | you could doublecheck the jockey bug reports tho just to make sure we're covered | 23:40 |
| bryceh | the idea is that if the kernel module fails to build, tell the user and don't configure the system to try to use nvidia | 23:41 |
| Sarvatt | dang, now I wish I could set priority 8 hours ago when I started this bug rampage :) | 23:41 |
| superm1 | and there is automatically another report filed about it failing to build too from DKMS | 23:44 |
| bryceh | right | 23:45 |
| bryceh | Sarvatt, so any 'dkms failed to build' that are older than a few months can probably be closed | 23:46 |
| Sarvatt | i'm using https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/492392 as the master bug for freeze after suspend hangs with intel incase it helps, if its 915 or 945 and they say it hangs with a black screen a few minutes after resume its pretty much guaranteed to be that | 23:47 |
| ubottu | Ubuntu bug 492392 in linux "[lucid, intel] After suspend, flickering screen and then blank screen." [Medium,Confirmed] | 23:47 |
| Sarvatt | I meant to bring this up during the meeting, but maybe we should start a wiki page where we can collaborate on symptoms and list the bugs to dupe things to | 23:48 |
| Sarvatt | i work my way from the newest to the oldest bugs so i dont dupe much until I find the first report of it, and that usually doesn't happen because there's hundreds to go through :D | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
