[00:02] <pcjc2> I've got 945GM here, and haven't seen it... although have seen a few lockups resuming from suspend. (Which I'd attributed to doing testing on new driver patches)
[00:12] <bdmurray> pcjc2: I tried it with glxgears running and had no problem
[00:12] <bdmurray> However, suspend is tough to test on my system as I can only do it 1x
[00:15] <pcjc2> I'm sure this X11 testing is doing no favours for my HDD's power off retract count
[00:16] <pcjc2> (they don't like being hard-powered off too many times)
[00:17] <bdmurray> You can't even use sysrq?
[00:18] <pcjc2> is that built in by default on Gutsy kernels?
[00:18] <pcjc2> I've never made it work on either of the laptops I've had
[00:19] <bdmurray> It works for me, just reaching all the keys is hard
[00:19] <pcjc2> Figured it might be because its not got a native Sysrq key... its FN + delete  (its been so long since I used it, I've forgotten what the magic key combo is)
[00:19] <bdmurray> Ctrl+Alt+SysRq then U for umount S for sync and B for boot
[00:19] <bdmurray> or really maybe B for reBoot
[00:19] <pcjc2> It won't work for most of the intel crashes anyhow...
[00:20] <pcjc2> the graphics chip physically hard locks the machine
[00:21] <pcjc2> when you poke a register which isn't enabled. It seems that many register writes are locked into a hardware state machine which is clocked of one of the various internal video clocks. If you program such a register with the clock off / unstable, it can hang the chip
[00:21] <pcjc2> ok, so the key combo works ;)
[00:24] <pcjc2> oops... thats one FN key away from Ctrl-alt-del
[00:25] <bryce> heh
[00:31] <pcjc2> Bryce: Does opengl play nice with compiz in general?
[00:32] <pcjc2> A screenshot running glxgears... http://www2.eng.cam.ac.uk/~pcjc2/Screenshot.png
[00:32] <bryce> pcjc2: yes it should
[00:32] <bryce> I think many bugs harbor there tho
[00:32] <pcjc2> it doesn't "expose" (I know that's not technically what it does) the window underneath
[00:32] <pcjc2> so if I drag the GL window around, it leaves prints
[00:33] <pcjc2> I'm trying to go back to basics on the 855 bug, and understand how windows get from applications to the screen with compiz
[00:34] <pcjc2> Rendering via GL textures, so does a GL bug mean a compiz bug?
[00:34] <bryce> I don't know enough about compiz internals to say, but it seems that there's not a 1:1 relationship there
[00:35] <pcjc2> I started to read up about how it works, and got lost very quickly
[00:35] <bryce> Amaranth and mvo are good contact points for it
[00:36] <pcjc2> its bad enough with the one physical intel chip,  AGP drivers for the bridge device, DRM drivers, X11 graphics drivers, Mesa DRI Libraries .... framebuffer drivers... 
[00:36] <bryce> yeah it's another area where I need better education.  Since mvo, Amaranth and others seemed to have it under control, I ended up mostly focusing on other areas of X.
[00:37] <bryce> but we have a number of underlying issues that need solving at the X level
[00:37] <bryce> yup
[00:37] <pcjc2> Gutsy is going to be a bad trip for people with Intel hardware unless some fixes can get backported
[00:38] <pcjc2> Hopefully (ever the optimist) the newer Xorg and drivers in Hardy will be more stable
[00:39] <bryce> yeah, I'm a bit worried about this too
[00:40] <bryce> I think we should shoot for getting a fixed up new -intel out in -updates
[00:40] <pcjc2> Jesse Barnes was going to read up some 855 docs for me.. but I've not heard back
[00:41] <pcjc2> On a personal note, I'm annoyed.. I've not used compiz until recently, and I discovered the electronic cad software I'm a contributor for (gEDA) really really breaks redrawing with compiz
[00:41] <pcjc2> (gEDA has a rubbish "canvas", and I'm _trying_ to fix it, but still)
[00:44] <bryce> you might want to follow up with Jesse again in a few days; he is great at answering questions but I think he has many distractions so doesn't always follow up on things
[00:45] <pcjc2> I'm keen to get hands on some 855 hardware, I'll keep asking around if anyone has any
[00:45] <bryce> pcjc2: one thing I think we should do is compile a listing of the worst -intel bugs, perhaps with commentary about the seriousness of the issue and/or what's needed to fix them
[00:46] <bryce> I talked with shuttleworth about -intel and he said we have good high-up connections with Intel, and they really want to make their hardware solid with Ubuntu, so I think if we got a good way to summarize the main issues we need help with, I might be able to work on it from a top-down direction in Intel
[00:46] <pcjc2> sounds good
[00:46] <pcjc2> Keith Packard has been fairly helpful answer questions
[00:47] <pcjc2> he even told me he's "working on" getting some docs which mortals without NDA can have
[00:47]  * bryce nods
[00:48] <jcristau> he's been saying that for a while :)
[00:48] <bryce> he's been working on that for quite some time though; I don't know how soon we can expect to see them
[00:48] <pcjc2> Reading between the lines
[00:49] <pcjc2> KP: "
[00:49] <pcjc2> We don't have any documentation available for publication at this point,
[00:49] <pcjc2> although I am trying to make this happen."
[00:49] <pcjc2> The documentation details too many bugs / workarounds / technical details we don't want to release for scrutiny. I'm fighting internal politics"
[00:49] <pcjc2> (The latter being my reading of the former)
[00:50] <bryce> mm, I doubt it's that
[00:50] <jcristau> i'm sure internal politics are part of it :)
[00:51] <bryce> no I mean, I doubt it's that the docs describe too many bugs / workarounds
[00:51] <pcjc2> Its kindof come to my realisation that graphics drivers make or break the product
[00:51] <bryce> certainly internal politics can be expected here; I think he's said as much
[00:52] <bryce> but I think it's more about worry about exposing "crown jewels" or opening the company to litigation, enabling competitors, etc.
[00:52] <pcjc2> I've found some datasheets they do publish very very useful for debugging (e.g. this cruddy HP laptop BIOS)
[00:52] <bryce> ultimately I suspect the issue boils down to trying to identify a tangible benefit to the company, to offset the risks 
[00:53] <pcjc2> I guess
[00:53] <pcjc2> I wonder how hard it is to get an NDA... (or whether its sensible)
[00:53] <bryce> ATI put out their stuff not because of goodwill or because they valued the community, but rather because if they hadn't, they were worried they'd lose some of their big corporate/government customers that were demanding availability of open source drivers in their bid requirements
[00:54] <bryce> (ATI/AMD was very clear on this point at XDS)
[00:56] <pcjc2> All companies are in it for the money
[00:56] <pcjc2> Even Canonical presumably has to make some ;)
[00:57] <pcjc2> (Dumb question... where are Canonical based (globally?)
[00:58] <bryce> UK basically
[00:58] <bryce> employees are scattered hither and thither.  I'm in Portland Oregon
[00:58] <pcjc2> I thought UK, but didn't know why
[00:59] <bryce> the main offices and the data center are there in London
[00:59] <bryce> most of management is in england.
[00:59] <bryce> the official business address is Isle of Man
[00:59] <pcjc2> tax reasons probably ;)
[00:59]  * bryce nods
[01:00] <pcjc2> I wonder if anyone has any 855 based hardware sitting available for testing (or do Canonical not have "central" hardware available for testing
[01:00] <bryce> canonical is for profit, but the business model centers around service rather than product sales
[01:00] <pcjc2> seems eminently sensible... shame we're all SuSE at the University
[01:00] <bryce> if you can do the testing remotely, we can probably get you hooked up with a machien with 855 in it
[01:01] <pcjc2> would much rather not have to package two sets of all the electronics packages we do!
[01:01] <bryce> which uni?
[01:01] <pcjc2> I'll keep it in mind.. although really, I'd be wanting to watch the screen and poke with GDB
[01:01] <pcjc2> Cambridge, (sorry, assumed you'd see from my email address)
[01:02] <bryce> well, tell you what - Chris Jones, who reported bug 13311, is one of Canonical's system administrators
[01:02] <ubotu> Launchpad bug 13311 in gftp "FTBFS: compile errors" [High,Fix released] https://launchpad.net/bugs/13311
[01:02] <pcjc2> I'm a 2nd yr Electronic Engineering student
[01:02] <bryce> he would be the key guy to get you access to an 855 machine, particularly if you would be working to get a fix for that bug
[01:02] <bryce> ahh awesome
[01:03] <pcjc2> I chat to Matthew Garrett often (usually when I find a bug... its almost always some area he knows about ;), althoug 
[01:03] <pcjc2> h we've never met
[01:03] <bryce> cambridge england or mass?
[01:04] <bryce> oh duh, nevermind :-)
[01:04] <bryce> I was at cambridge a few weeks ago myself for XDS
[01:04] <pcjc2> (England's same as Garrett). I'm a 2nd year PhD student working on marine renewables.. and secretly wondering if a job in programming would be better
[01:04] <bryce> beautiful town
[01:04] <pcjc2> I was kicking myself that I missed that. Saw the info on the xorg page, then saw it had already passed
[01:04] <bryce> yeah he's a huge resource
[01:05] <bryce> Colin Watson (my supervisor) is also in the Cambridge area
[01:05] <pcjc2> so Canonical is quite distributed ;)
[01:06] <pcjc2> How did you come to Canonical? (If you're the same Bryce... you founded Inkscape?)
[01:06] <bryce> yup, that's I
[01:07] <pcjc2> cool (I'm not artistic, but Inkscape is a tool I keep handy for vector graphics)
[01:07] <bryce> I used to work for a company called OSDL in Portland, doing kernel and nfsv4 testing, and working on Inkscape and tinkering with X/Cairo on the side
[01:07] <bryce> Kees Cook and Brian Murray also worked there with me
[01:07] <pcjc2> Do you do the VNC packages as part of X in Ubuntu?
[01:07] <bryce> Kees was in IT there, but was much more interested in security work, and he was absolutely enamoured with ubuntu (brian and I were into gentoo at the time)
[01:07] <pcjc2> That was my first dive into the X code, trying to fix some horrid bugs in that. RealVNC were very unhelpful
[01:08] <bryce> so when a security position opened with canonical he went for it
[01:08] <bryce> I heard such good things that I converted to ubuntu as well, liked it, and also followed him over to Canonical
[01:08] <bryce> I haven't touched any of the VNC stuff myself
[01:09] <bryce> it's possible that's an area I need to get into, but haven't had any pulls to work on it so far
[01:09] <pcjc2> I wanted to setup thin clienting nicely, and got looking at the GDM work done by various people
[01:10] <pcjc2> Either using VNC + some extensions (hacks) to allow re-negotiation and hot swapping of the server after authentication..
[01:11] <pcjc2> hit lots of VNC bugs (mostly all solved, or worked around now), I looked at XDMX and various X forwarding (but got stuck with XLib insisting on aborting if the client disconnects uncleanly)
[01:12] <pcjc2> XCB was mentioned as a possible way around it, but in the end.. no time.
[01:14]  * bryce nods
[01:16] <bryce> hmm, when I was at OSDL we had a nice collection remotely accessible test machines that OS devs could log into and do stuff.  I wonder how hard it'd be for me to recreate that.
[01:18] <pcjc2> would have to have gutsy like environment
[01:18] <pcjc2> and a remote poking switch for when the GPU locks up
[01:19] <pcjc2> Unfortunately, its not really clear how to test this most effectivey... the machines are usable when they corrupt the display - just you have to guess where things are.
[01:19] <bryce> yeah, we had remotely addressable power control bars that worked wonderfully for restarting after kernel lockups
[01:19] <bryce> also since they were servers we had good serial consoles for capturing oops and the like
[01:19] <bryce> but not X so much
[01:19] <pcjc2> So without a webcam pointing at the screen, its probably not all that useful
[01:20] <pcjc2> Also... if you get nasty timings to an LCD panel, it can destroy it
[01:20] <bryce> mmm, a webcam would be doable
[01:20] <pcjc2> many of the driver chips seem to have some protection in them, but I've managed to get this machine here into a state which I was very unhappy until I'd pulled the plug
[01:21] <pcjc2> (You get a creeping propogation of green across the LCD which seems more a manifestation of very bad drive signals to the LCD its self, rather than just display corruption).
[01:25] <pcjc2> Is Chris Jones based in London?
[01:26] <bryce> yeah i think so
[01:26] <pcjc2> ok, so if necessary, not too far away
[01:26] <pcjc2> I'm sure I'll be able to find some hardware
[01:26] <bryce> yup, hes in Catford Bridge, London
[01:26] <pcjc2> I already dug through a pile of old laptops here (mostly broken some way or other), and have been round obvious friends
[02:28] <pcjc2> night!
[03:16] <ubotu> New bug: #153782 in xorg (main) "[Gutsy] screen doesn't resume after suspend" [Undecided,New] https://launchpad.net/bugs/153782
[05:01] <ubotu> New bug: #153797 in linux-restricted-modules-2.6.22 (restricted) "Fails to resume when using Nvidia-glx or Nvidia-glx-new" [Undecided,New] https://launchpad.net/bugs/153797
[11:32] <ubotu> New bug: #153818 in xorg (main) "Visual Effects can not be enabled on Santa Rosa" [Medium,Incomplete] https://launchpad.net/bugs/153818
[13:10] <ubotu> New bug: #153873 in xserver-xorg-driver-savage (main) "Freeze on visuals in Rhythmbox with savage drivver" [Undecided,New] https://launchpad.net/bugs/153873
[14:17] <ubotu> New bug: #151439 in linux-restricted-modules-2.6.22 (restricted) "Constant "banding" and other visual artifacts in gusty on nvidia GeForce 4 MX" [Undecided,New] https://launchpad.net/bugs/151439
[16:16] <ubotu> New bug: #153936 in xserver-xorg-video-intel (main) "Bad screen size using external monitor" [Undecided,New] https://launchpad.net/bugs/153936
[17:16] <ubotu> New bug: #118808 in linux-restricted-modules-2.6.22 "Unable to reach C3/C4 states while wireless is up." [Medium,Confirmed] https://launchpad.net/bugs/118808
[17:23] <pcjc2> Question.... anyone know why the Intel X driver isn't appearing to see suspend events from ACPI?
[17:23] <pcjc2> It has a hook, but output I've added there doesn't print to the log
[17:35] <ubotu> New bug: #153971 in xserver-xorg-video-ati (main) "Black Screen: Radeon X1300, Gutsy, AMD64, and fglrx." [Undecided,New] https://launchpad.net/bugs/153971
[17:36] <pcjc2> never mind... I see those are only had via APM, we don't have hooks for suspend / resume with ACPI
[18:25] <ubotu> New bug: #153986 in xorg (main) "GL screensavers crash the X server" [Undecided,New] https://launchpad.net/bugs/153986
[19:05] <bryce> morning
[19:07] <tepsipakki> bryce: morning? you've slept well, eh? :)
[19:08] <bryce> yup.  was up late triaging bugs last night
[19:08] <bryce> and a little docs writing
[19:30] <ubotu> New bug: #154007 in xorg (main) "(bulletproofX) failsafe X doesn't work very well on my Thinkpad T61p laptop with an Nvidia chipset" [Undecided,New] https://launchpad.net/bugs/154007
[19:50] <tepsipakki> bryce: oh, didn't notice the post on the ml before
[19:50] <tepsipakki> I'll check it out later
[19:57] <bryce> thanks
[19:58] <bryce> I hope it's not so long that no one reads it...  maybe it could be condensed better
[20:20] <Q-FUNK> yippee!
[20:23] <bryce> heya
[20:24] <bryce> Q-FUNK: I don't know if you're on the ubuntu-x@ list, but I posted a new "Bug Research Guide" doc to it this morning.  Love to get some feedback on it.
[20:24] <Q-FUNK> ah, no, i'm not
[20:28] <Q-FUNK> hmm... is anybody here available for a short paying gig to upgrade -amd to sync with the current X core (including RandR 1.2)?
[20:30] <bryce> Have you thought about asking Alex Deucher?
[20:33] <Q-FUNK> you think he could be interested?
[20:42] <bryce> dunno, but it's possible
[20:43] <bryce> his day job is not X related, so I think he might like gigs to work on X stuff.  I think he's done it in the past
[20:43] <bryce> in any case, he and Jesse are the two with the most experience adding xrandr 1.2 support to drivers
[20:43] <bryce> and jesse probably can't do it since he's working for Intel
[20:44] <bryce> alex might prefer to wait until -ati 6.8 is out or something, but couldn't hurt to ask
[20:44] <bryce> heya tormod!
[20:47] <bryce> tormod, I don't remember if you're on ubuntu-x but I posted a first draft of a 'Bug Research Guide' doc.  Would love to get feedback.
[20:47] <bryce> I'm planning on doing some major update of X resources on our wiki.
[20:47] <bryce> we didn't have much about how to research bugs, which is why I started there.
[21:08] <tormod> hi bryce! yes I saw the posting but didn't read in detail.
[21:08] <bryce> ah, too long?
[21:08] <tormod> yes :)
[21:09] <tormod> I feel there's a need for a step-by-step guide for people submitting bugs.
[21:10] <bryce> I also have a "Reporting Bugs" section that precedes this one, but decided to post just this one for comments first, to avoid posting too much reading material at once
[21:10] <tormod> Like: we need to know what card: lspci -vvnn. Which driver (file right). log files. etc
[21:10]  * bryce nods
[21:11] <tormod> I guess people actually triaging have good debugging knowledge anyway. But of course documentation is always good.
[21:11] <bryce> I break it down by problem class.  i.e., bad resolution bugs need these files, crashes need these, bad dpi issues need these, video playback need ...
[21:11]  * tormod looks up that post
[21:12] <bryce> I'm thinking more about people who are new to triaging, to help them get up to speed
[21:12] <jcristau> for pretty much everything you need config and log anyway; hence the stuff in /usr/share/bug.
[21:12] <bryce> but I want to make sure I have the right info (and not too much of it, that makes their eyes just glaze over *grin*)
[21:12] <jcristau> hi, congrats on the release btw :)
[21:13] <bryce> heya jcristau, thanks
[21:13] <bryce> yeah I thought about setting up a bittorrent to help with the bandwidth, but I couldn't even download the .torrent!
[21:15] <tormod> bryce, yeah I found your Bug Research a little word-heavy. started reading and thought: this is just common sense. then I see there are good pieces in there. But will people read it? :)
[21:16] <tormod> I don't want to sound discouraging :) 
[21:18] <tormod> we really need a little check list for bug submitters, that pops up automatically when they file bugs on *xorg*
[21:19] <tormod> I am getting bored by asking the same questions when triaging bugs, even if I cut and paste.
[21:19] <tormod> launchpad should refuse bug reports without Xorg.0.log :)
[21:20]  * bryce nods
[21:27] <tepsipakki> launchpad really should tell the reporter to attach those files, or could it do it on behalf of the reporter (like bug-buddy does)?
[21:28] <bryce> many of our bugs come initially filed against ubuntu, and triagers move them to xorg, so that wouldn't help
[21:36] <tepsipakki> right
[21:46] <bryce> I've posted the list of required files/data I came up with
[21:48] <tepsipakki> looks good
[21:49] <tepsipakki> also, one of the first things upstream tends to ask people to test is disabling DRI
[21:49] <bryce> ok
[21:49] <tepsipakki> maybe that could be mentioned on the display corruption class?
[21:50] <bryce> or should I have a separate section (preliminary things to try out)?
[21:50] <tepsipakki> perhaps yes
[21:50] <bryce> I'll do both
[22:06] <tormod> bryce: I wrote a Bugs page for ati once, now outdated: https://wiki.ubuntu.com/Bugs/AtiDriver maybe there are some ideas
[22:07] <ubotu> New bug: #40667 in xserver-xorg-video-trident (main) "Doesn't correctly support dpms" [Low,Incomplete] https://launchpad.net/bugs/40667
[22:07] <ubotu> New bug: #46796 in xserver-xorg-video-trident (main) "Totem-xine uses 100% cpu" [Medium,Incomplete] https://launchpad.net/bugs/46796
[22:09] <tormod> suggestion re your new post: paste in lspci --vvnn|grep "VGA comp" and attach as file the output of lspci --vvnn
[22:11] <immoT-> Ubuntu gutsy xserver donesn't start (trident). No errors in log file.!
[22:12] <tepsipakki> immoT-: still no bug report ;)
[22:21] <tormod> http://wiki.debian.org/XStrikeForce is getting some nice documentation, for instance xrandr12 and debugging-server-crash. Maybe we should coordinate better the documentation between Debian and Ubuntu? Of course the launchpad and triaging stuff would be Ubuntu specific, but debugging and bug report contents would be the same.
[22:22] <immoT-> tepsipakki: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-trident/+bug/154069
[22:22] <ubotu> Launchpad bug 154069 in xserver-xorg-video-trident "Ubuntu freezing with toshiba laptop" [Undecided,New] 
[22:23] <tormod> I started contributing to Ubuntu docs because it was more anarchistic and easy to just do it in Ubuntu, but I have heard rumours that Debian is gonna be fun again?
[22:23] <tepsipakki> immoT-: you could attach xorg.conf and Xorg.0.log to that bug
[22:23] <tepsipakki> s/could/should/
[22:25] <immoT-> I can't use copypaste with lynx/commandline
[22:26] <tormod> there used to be a thing to use mouse and copy/paste in a text console - gpt (?)
[22:27] <tormod> anyway, you can attach files with lynx as far as I can remember.
[22:28] <immoT-> ok, trying tomorrow
[22:28] <tepsipakki> hm, I was just testing lynx
[22:29] <tepsipakki> I wonder if mail attachments are now added to the bug
[22:30] <ubotu> New bug: #154069 in xserver-xorg-video-trident (main) "Ubuntu freezing with toshiba laptop" [Undecided,Incomplete] https://launchpad.net/bugs/154069
[22:38] <bryce> tormod: ok I'll take a look
[22:39] <jcristau> tormod: debian? fun? that can't be true!
[22:39] <tepsipakki> :)
[22:40] <tormod> jcristau: yeah I was hoping you would comment on that :)
[22:40] <ubotu> New bug: #154046 in xorg (main) "black screen after upgrade to gutsy" [Undecided,New] https://launchpad.net/bugs/154046
[23:03] <ubotu> New bug: #153977 in xorg (main) "Unable to use external monitor on laptop" [Undecided,New] https://launchpad.net/bugs/153977
[23:12] <ubotu> New bug: #153952 in xserver-xorg-video-nv (main) "Gutsy boot failure" [Undecided,New] https://launchpad.net/bugs/153952
[23:21] <tormod> good night