[01:19] <federico1> bryce: pingety ping
[01:19] <federico1> bryce: sorry if I sound like a broken record... do you remember that bug in the intel driver where it said that VGA was connected when it actually isn't?
[01:23] <bryce> hi federico1
[01:23] <bryce> uhh, vaguely
[01:24] <federico1> I thought you had a patch?
[01:24] <federico1> s/you/ubuntu
[01:25] <bryce> lemme check
[01:25] <bryce> 108_dont_disable_vga_centering_bit.patch ?
[01:26] <federico1> hmm
[01:26] <bryce> commit 3aa8591abfbe8db0f13912910c850fdd748808df
[01:26] <federico1> one sec, let me check
[01:26] <bryce> not sure that's it, that's for bug #17235
[01:26] <bryce> silly ubottu
[01:27] <bryce> for ubottu, bug #324913
[01:28] <federico1> the b.f.o doesn't look like it
[01:28] <federico1> I remember that patch being way bigger
[01:29] <bryce> hmm, don't see any other patches relevant to that, can you give me some more context to jog my memory?
[01:29] <federico1> I have this url in my journal - http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/i830_quirks.c
[01:29] <federico1> or maybe the patch was a quirk for a certain model?
[01:30] <bryce> oh that could be
[01:30] <federico1> we had a problem where you boot with no external displays connected, and gnome-panel appears at 1024x768 while your LCD is in fact much bigger
[01:30] <federico1> it happened because the driver lied about VGA being connected, and defaulted to 1024x768 --- then, the panel was stupid and assummed that the first output was the primary display
[01:30] <bryce> did xrandr show a phantom output in that case?
[01:31] <bryce> yep, that's not an uncommon issue
[01:31] <bryce> https://wiki.ubuntu.com/X/Quirks
[01:31] <federico1> bryce: yeah, it showed an output that wasn't in fact there
[01:32] <bryce> that's usually more common with phantom s-video or lvds outputs
[01:33] <bryce> federico1: generally the procedure is to have the user verify that by setting Option "Ignore" on the output, that it makes the issue go away
[01:33] <bryce> if it does, then upstream can (usually) quirk it
[01:33] <federico1> it's probably quirkable for some cards
[01:33] <federico1> although I remember keithp or anholt saying that this was a race condition when initializing the driver
[01:34] <bryce> mm, there is a quirk_ignore_crt() available
[01:34] <federico1> maybe I should ask them :)
[01:34] <bryce> Sony VGC-LT71DB has no VGA output (bug #17395) 
[01:34] <bryce> that's the only hw with that quirk currently
[01:35] <bryce> yep, best to ask one of them, or jesse
[01:35] <federico1> which jesse?
[01:36] <federico1> yeah, it looks a lot like that bug
[01:37] <bryce> barnes
[01:37] <federico1> bryce: thanks
[01:37] <bryce> sure thing
[01:37] <federico1> oh, I don't know him :)
[01:37] <federico1> so
[01:37] <federico1> I'm talking to the fedora guys, trying coordinate some RANDR love
[01:37] <federico1> I've been doing a lot of randr stuff for opensuse
[01:37] <federico1> the gnome stack is pretty much okay except for some panel problems, and probably some gdm ones
[01:38] <federico1> I have three or four main areas of bugs:
[01:38] <federico1> - panel
[01:38] <federico1> - intel driver
[01:38] <federico1> - hooking to signals from gnome-power-manager (re-detect displays on unsuspend) and something about docking stations (re-detect on dock/undock, figure out what people actually do there)
[01:38] <federico1> so if we could split up the work...
[01:41] <bryce> there's also a set of bugs that seem to be particular to randrwrap in gnome-display-properties, i.e. that can't be reproduced using just the xrandr cmdline tool
[01:42] <bryce> I find those frustrating, because they're ambiguous who to upstream them to
[01:42] <bryce> do you know if the fedora guys had special plans for working on these bugs?
[01:44] <federico1> the randrwrap ones?
[01:44] <bryce> well, any of the above, but yeah the randrwrap ones in particular
[01:44] <federico1> I've been hacking on randrwrap - don't really know what soeren is doing these days
[01:45] <federico1> so ping me about those
[01:45] <bryce> ok
[01:45] <bryce> lately esp. this week I've been focusing mostly on -ati bugs
[01:45] <federico1> about the other bugs, I'm discussing things with mclasen in #fedora-desktop
[01:45] <federico1> ooh
[01:45] <bryce> the next couple weeks I've planned to focus on xserver crash bugs, since we now have some good crash capturing tools in place with apport so are getting better auto-collected backtraces
[01:46] <federico1> bryce:  my fucking ATI driver will sometimes do a RANDR change, and freeze the displays.  I have to switch to a text VT and then back, and then it will be correct
[01:46] <bryce> mm, which version of -ati?
[01:47] <federico1> but a weird kind of freeze - you don't see the mouse pointer move, but if you move it, you see that some widgets highlight/spin/whatever
[01:47] <federico1> hmm, Xorg.0.log says:
[01:47] <federico1> Module radeon blah blah, module version = 4.3.0 - is that what you need?
[01:48] <bryce> hmm, I'd expect 6.9.xxx
[01:48] <federico1> one sec, I'll tell you the real version
[01:49] <bryce> anyway, I've not run across a bug report similar to that so far
[01:51] <federico1> 6.9.0 plus a few patches which are probably backports
[01:51]  * bryce nods
[01:51] <federico1> bryce: ok
[01:51] <federico1> hmm
[01:51] <bryce> what chip class?  lspci | grep VGA
[01:51] <federico1> what info would you need to diagnose this?
[01:52] <federico1> RV280 [Radeon 9200 SE]
[01:52] <bryce> ahh
[01:52] <bryce> lots of bugs on that one
[01:52] <federico1> so
[01:52] <federico1> normally I have VGA connected
[01:52] <federico1> when I plug a second monitor in the DVI and configure it to the *left* of the VGA one, and make it use a smaller resolution, I get that kind of freeze
[01:53] <bryce> there is a tool called radeontool you can get from git.freedesktop.org in airlied's stuff, which provides register dumps
[01:53] <federico1> I'm not yet sure if it's 100% reproducible, but happens often enough for me :)
[01:53] <bryce> with bugs like these, I would collect register dumps once from when you see the problem and once when you are nto seeing the problem, and then file a bug at freedesktop.org with that info, plus Xorg.0.log and lspci info
[01:54] <federico1> sweet
[01:54] <federico1> thanks, I'll do that
[01:55] <bryce> here's some rv280 / xrandr bugs we have:
[01:55] <bryce> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-
[01:55] <bryce> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/205085
[01:55] <bryce> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/291715
[01:55] <federico1> oh, yeah, compiz seems full of epic fail
[01:56] <bryce> yeah none of those seems an exact match, but seems there is something screwy with the xrandr behavior on rv280
[01:56] <federico1> yeah
[01:57] <federico1> oh, I remembered - I also get funny output when rotating 90 degrees
[01:57] <federico1> anyway
[01:57] <federico1> hmm
[01:57] <federico1> I'll write a mail to you and interested people
[01:57] <federico1> what's your email again?
[01:57] <bryce> bryce@canonical.com
[01:58] <federico1> thanks
[01:58] <bryce> federico1: btw is your card AGP?  If it is, there's some quirking which sometimes helps
[01:58] <federico1> yeah
[01:58] <bryce>       Option "AGPMode" "2"
[01:58] <bryce> try 1, 2, 4, 8
[01:58] <bryce> _sometimes_ there is one that works better than others
[01:58] <federico1> will do
[01:59]  * federico1 sees todo.txt grow uncontrollably
[01:59] <bryce> if so, quirks can be added - see http://wiki.ubuntu.com/X/Quirks
[01:59] <bryce> heh, sorry :-)
[02:00] <bryce> getting back to the panel bugs, I don't have the todo.txt space to work on them myself, but they seem to be the most commonly reported problem so far.  
[02:01] <bryce> federico1: oh also at the last ubuntu developer sprint I collected a "projector sh!t list" of issues people were running into
[02:01] <bryce> cross driver, xserver, gnome panel, and capplet
[02:01] <federico1> url me :)
[02:01]  * bryce eyeballs the ratty sheet of paper in his briefcase
[02:02] <bryce> I'll have to type it up first.  I'll ping ya when I get that in
[02:02] <federico1> hehe, I have a similar list here - http://en.opensuse.org/GNOME/Multiscreen 
[02:02] <bryce> nice
[02:03] <bryce> yeah I'll review that and my list, maybe in sharing notes we can squish a few of the bugs 
[02:03] <federico1> oh, duh, I had a link to the intel bug I was asking you about right in that page - https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/152416
[02:03] <bryce> aha 
[02:04] <bryce> ok yeah that quirk patch went upstream already
[02:04] <federico1> bryce: make sure you have a b.n.c account, or our @#$% bugzilla won't show you bug dependencies.  Also, if you find a bug for which you don't have permission, it's probably a SLED bug - tell me and I'll make it visible (we have an annoyingly paranoid bugzilla team...)
[02:04] <bryce> ok cool
[02:04] <federico1> anyway
[02:04] <federico1> my clearinghouse is https://bugzilla.novell.com/show_bug.cgi?id=multiscreen-tracker
[08:44] <dholbach> hiya
[08:44] <dholbach> I have an interesting case of something weird in X going on :)
[08:45] <dholbach> in dmesg:
[08:45] <dholbach> [15560.738232] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0
[08:45] <dholbach> in /var/log/Xorg.0.log.old (had to restart X over SSH to un-black it)
[08:45] <dholbach> http://paste.ubuntu.com/120487/
[08:45] <dholbach> any idea?
[10:09] <mnemo> dholbach: EXA or UXA? and what chipset?
[10:29] <dholbach> VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
[10:30] <seb128> dholbach: what issue do you have?
[10:30] <dholbach> yes, EXA (didn't change from the default and it says something about it in the log
[10:30] <dholbach> seb128: 
[10:30] <dholbach>  I have an interesting case of something weird in X going on :)
[10:30] <dholbach>  in dmesg:
[10:30] <dholbach>  [15560.738232] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0
[10:30] <dholbach>  in /var/log/Xorg.0.log.old (had to restart X over SSH to un-black it)
[10:30] <dholbach>  http://paste.ubuntu.com/120487/
[10:30] <dholbach>  any idea?
[10:31] <seb128> hum, no, no idea
[10:31] <seb128> I've the same card on my laptop but no such issue
[10:31] <dholbach> it was the first time it happened to me
[10:32]  * dholbach tries pulling the plug again :)
[10:32] <dholbach> ok, worked this time :)
[10:33] <mnemo> dholbach: check the backtrace in xorg... if it's like an ioctl then probably the chip or hung... if it's a segv or something the stacktrace alone might be actionable for upstream
[10:34] <mnemo> i've seen the "vblank on disabled pipe" message before but on a machined that "worked"
[10:34] <mnemo> so I think you might have both the vblank warning and then some other thing as well that causes the crash
[10:34] <dholbach> mnemo: there was no backtrace - no segfault
[10:35] <mnemo> so xorg is inside the WaitForSomething() function??
[10:36] <mnemo> i mean check the backtrace in gdb (dont look for a stacktrace in xorg.log)
[10:37] <dholbach> ok
[15:01] <Ng> hmm, should I be using EXA or UXA on jaunty atm? (965)
[15:02] <Ng> I seem to be using the former and switching desktops isn't the fastest thing ever, it has to be said
[15:10] <seb128> exa works fine for me
[15:10] <seb128> uxa makes xorg crash on resume
[15:11] <Ng> well it feels a lot snappier now I don't have sunbird eating my CPU like there's no tomorrow
[15:12] <Ng> different to intrepid, but not really slow
[15:13] <tjaalton> Ng: bug 320813
[15:13] <tjaalton> I'll disable vblank again once I get home
[15:14] <Ng> aha
[15:15] <tjaalton> with uxa you get dri2 and hence no vblank
[15:15] <tjaalton> and mine crashes on resume also with exa
[15:15] <Ng> interesting. I've not yet done a suspend/resume cycle
[15:15] <Ng> bah why is ssh-agent running
[15:17] <Ng> vte feels a bunch faster, which rocks
[15:19] <Ng> so yeah, I have x-session-manager spawning ssh-agent and seahorse-agent - isn't seahorse supposed to be at the top?
[15:30] <seb128> Ng: echo $SSH_AUTH_SOCK
[15:39] <Ng> seb128: that's pointing at /tmp/keyring-blah/socket.ssh, but nothing appears to be connected to it
[15:39] <Ng> I did get a gnome style ssh password prompt the first time, but since then ssh has been prompting me in terminals
[15:40] <Ng> (this was all working with auto-unlocked keyrings in intrepid, but I've hit problems before when ssh-agent and seahorse-agent were both running, afair)
[18:53] <bryce> karmic koala
[18:54] <bryce> seb128: "uxa makes xorg crash on resume" has it crashed more than the one time?  
[18:54] <seb128> bryce: I tried several times during the sprint each time, I switched back to exa since but I can try again if you think that's fixed now
[18:55] <bryce> ok.  no, no reason to think it's fixed yet
[18:55] <seb128> what is this speed issue on intel every speaks about?
[18:55] <seb128> xorg doesn't feel slow on jaunty for me on my laptop which has an intel card
[18:56] <seb128> ie compiz animations are smooth, video plays correctly
[18:56] <bryce> yeah, performance has been ok for me as well, even just with EXA
[18:56] <bryce> but several people showed me their intel systems which were slow for desktop switching in compiz (which may be fixed now)
[18:57] <seb128> you mean some seconds hangs and high cpu usage?
[18:57] <seb128> some seconds or 1 second which seems long enough to watch
[18:57] <bryce> iirc some people were having performance problems even with compiz off.  don't remember if anyone showed me that specific case
[18:58] <james_w> not fixed yet, at least for me
[18:58] <seb128> what is the issue?
[18:58] <bryce> I had heard people were seeing on the order of seconds.  However all the examples I saw it was <1 sec between switches, but noticeably laggy
[18:58] <seb128> I had a very slow animation and high cpu usage issue
[18:58] <seb128> which I workarounded using 

[18:58] <seb128>     <device screen="0" driver="i965">
[18:58] <seb128>         <application name="Default">
[18:58] <seb128>             <option name="vblank_mode" value="0" />
[18:58] <seb128>         </application>
[18:58] <seb128>     </device>

[18:58] <seb128> drirc
[18:58] <seb128> tjaalton gave me that workaround I think
[18:59] <seb128> he said that was a patch dropped which will be added back no?
[18:59] <bryce> yep, that was the issue that I am wondering if it may be fixed now.  it required a kernel change, which timg had on his todo list
[18:59] <bryce> I'm uncertain if that patch will fix all the performance issues, or just this specific one
[18:59] <seb128> well, once that fixed speed is as good as intrepid for me
[18:59] <seb128> I'm wondering what are the other concerns
[18:59] <bryce> ok, good to know
[19:00] <seb128> I don't think we should switch to uxa if it's not tested for jaunty
[19:00] <seb128> we are trying to get some credibility back from users who think we are breaking too much between ubuntu version and quality is going down this cycle
[19:00] <bryce> er, who said we were considering uxa?
[19:00] <seb128> so better to stay on what is proved to be stable if we can
[19:01] <seb128> I was reading the mailing lists discussions
[19:01] <bryce> which list?
[19:01] <seb128> and it was not clear from me if we were considering exa performances as a blocker or not
[19:01] <crevette> "let's going back to intel driver 2.2.x"
[19:02] <crevette> :)
[19:02] <bryce> well, getting the exa performance issues solved is a high priority.  I think the testing done so far shows uxa is not ready for prime time.  I talked with upstream about this choice (jesse) and he agreed sticking to exa probably makes the most sense so far
[19:03] <seb128> "video card (intel) problems in jaunty" on ubuntu-devel-discuss
[19:03] <bryce> oh heh, I unsubbed from that list a while ago.  Too much angst ;-)
[19:04] <seb128> I tend to go through the title quickly and read some of the discussions just to know what the issues raised by users
[19:05] <bryce> anyway, I told everyone to help test uxa and report bugs upstream.  If the issues everyone reports get all solved, then I guess we can consider uxa, but it's too unstable so far
[19:06] <seb128> I think it's too late in a cycle we want to be stable do consider a such change now
[19:06] <seb128> better to stay on exa and try fix performances issues
[19:06] <bryce> heh, I see there's also a long thread on ctrl-alt-backspace
[19:06] <seb128> that's noise
[19:06] <seb128> I didn't read this one ;-)
[19:08] <bryce> yep, looks like a tedious discussion
[19:32] <tjaalton> bryce: hey, I'll disable intel-vblank again in mesa, once I get back home :)
[19:33] <tjaalton> I don't think there's enough time to get it stable for jaunty
[19:33] <bryce> ok
[19:33] <bryce> seb128: btw I could only find one post there on "video card (intel) problems in jaunty"
[19:34] <bryce> and it sounded mis-informed
[20:30] <seb128> bryce: right, there is only one question and one reply, I was just not sure how informed the discussion was about the plans for jaunty
[22:07] <adelie42> what package is X a member of? running ubuntu-minimal 8.10, installed xserver-xorg-core, xinit, and xauth but there is still no /usr/bin/X. any help?
[22:10] <adelie42> he he,  installing 'xorg'. i'll see if that fixes it till somebody responds
[22:17] <tjaalton> adelie42: xserver-xorg
[22:18] <adelie42> sweet, thanks