[00:00] <RAOF> bryce_: Yeah.  That's the bug report I'm wandering through.
[00:11] <albert231> fwiw, I got that same assert when I booted my PC without monitor attached
[00:12] <RAOF> albert231: Hm, interesting.  Evidence for my hypothesis!
[00:12] <RAOF> Got an Xorg.0.log for that case?
[00:12] <albert231> I have a stacktrace...
[00:12] <RAOF> Before I try deliberately breaking my X server? :)
[00:12] <RAOF> That's useful, but I'd also like the Xorg.0.log if you've got it.
[00:13] <RAOF> There's some debugging information earlier in startup that I'm interested in.
[00:13] <albert231> http://pastebin.com/SCaae1JX
[00:13] <albert231> Xorg log is in the trace
[00:13] <RAOF> Ta.
[00:14] <RAOF> Yeah.  In that case we also can't copy the fbcon.
[00:26] <RAOF> Ah, yeah.  There it is.  It makes no sense!  The scratch pixmap *is* initialised before uxa_realize_glyph_caches is called!
[01:02] <LLStarks> what releases have the same graphics stack and/or kernel as natty? fedora rawhide?
[01:03] <LLStarks> or rather maverick.
[01:05] <RAOF> Man, “set print pretty” should totally be the default.\
[01:11] <RAOF> Ok.  I'm obviously crazy.
[01:11] <RAOF> Alternatively, one of our patches is totally crazy.
[01:13] <LLStarks> how crazy?
[01:18] <RAOF> Crazy like an upstream fox, apparently.
[01:31] <RAOF> Ah, no.  Just subtly broken.
[01:37] <RAOF> Iiinteresting.  I can make it crash slightly later :)
[02:13] <LLStarks> xrender broken on fc14 too. guess this needs to go to upstream.
[02:14] <LLStarks> does everyone else have a working upstream, or does this seem limited to intel/945
[02:15] <RAOF> VW
[02:15] <RAOF> What was the test, again?
[02:19] <RAOF> Hah.  There it is.
[02:19] <RAOF> I win!
[02:20] <ScottK> The only way to win is not to play the game.
[02:21] <LLStarks> i lost the game
[02:22] <RAOF> No, I both played and one.  Your analysis is incorrect :P
[02:23] <RAOF> bryce_: Re: 109_dont_reconstruct_glyph_cache_on_rotate.patch - did you cherry-pick this in order to fix a known bug?  IIUC, that fixes a bug introduced in a commit that we don't have in our tree, and causes bug #718620
[02:23] <ubot4> Launchpad bug 718620 in xserver-xorg-video-intel (Ubuntu) "With HybridGraphics Xorg assert failure: X: ../../dix/pixmap.c:118: AllocatePixmap: Assertion `pScreen->totalPixmapSize > 0' failed. (affects: 19) (dups: 25) (heat: 200)" [High,In progress] https://launchpad.net/bugs/718620
[02:26] <LLStarks> i'm positive now. as of around a week ago, vsync has been broken with metacity, at least on intel.
[02:30] <bryce_> RAOF, it can probably be dropped
[02:30] <RAOF> I'll just check that it dropping it *actually* fixes that bug, but I think it's right.
[02:31] <RAOF> We could also cherry-pick a commit that one depends on.
[02:32] <bryce_> I had pulled it in hope that it'd resolve the font corruption issues that people reported right after updating the stack
[02:33] <bryce_> since it was a relatively recent upstream change after the -intel update it looked like a good candidate
[02:37] <LLStarks> is the font corruption in the same vein as the scrolling corruption?
[02:37] <LLStarks> because i've noticed both
[02:38] <RAOF> Still?
[02:40] <RAOF> bryce_: If you'd like to keep it, I know how to make it not crash :)
[02:43] <bryce_> LLStarks, I thought it might be, but it proved not to
[02:43] <bryce_> I'm scratching my head, but I seem to recall we had 3 different font corruption bugs at the time, and I don't remember if one of them went away after this patch or not
[02:43] <bryce_> (and it could have gone away for other reasons)
[02:44] <RAOF> I'll pull in the commit which'll fix the crash, then.
[02:44] <bryce_> RAOF, okie
[02:48] <bryce_> good find narrowing it to that patch
[03:04] <LLStarks> being -intel is suffering
[03:05]  * RAOF uses it for both his primary and secondary systems.  Although that's gen4.
[03:36] <RAOF> bryce_: Would you like to upload -intel 1ubuntu12?
[04:08] <RAOF> Anyone available to sponsor xserver-xorg-video-intel?  http://cooperteam.net/Packages
[05:14] <bryce_> RAOF, still need sponsoring?  I can do it
[05:14] <RAOF> bryce_: Luke's offered to do it, but I also decided to pull from Debian, too.  They've got useful changes.
[05:14] <bryce_> alrighty
[05:15] <bryce_> I pulled my old synthesizer out of my closet this evening and Dutch went absolutely apeshit over it
[05:15] <RAOF> Incidentally, can we start cherry-picking from upstream using git into the diff.gz?
[05:15] <RAOF> :)
[05:16]  * RAOF has a keyboard on order.  Should be fun!
[05:16] <bryce_> it's covered in buttons and makes noise and he can sit on it, what more can you ask for as a 1.5 yr old?
[05:16] <RAOF> Totally awesome!
[05:16] <bryce_> I don't favor that, but lets talk about it at UDS?
[05:16] <RAOF> Ok.
[05:21] <bryce_> one of the reasons for my hesitation is that we've had a few cases of non-X guys making changes outside version control, and I'm leery we could get into an even messier situation if patches are managed via version control.  bzr might be more workable on that count, but it has some troubles too
[05:22] <bryce_> I also am unsure what the workflow would be for testing disabling patches (which we do from time to time), would they need to be reverted?
[05:23] <RAOF> That's a good question.  That wouldn't work nicely.
[05:24] <RAOF> At least I don't think it would.
[05:24] <RAOF> How many times have we needed to revert an upstream cherry-pick, though?
[05:26] <RAOF> This would *only* be for cherry-picks from upstream git, and it's nice because (a) we seem to have rather a lot of them, and (b) they naturally go away when we update to a version which contains those commits.
[05:27] <bryce_> true, that's a good point.  there'd been a time (pre-PPA's) when we were carrying a lot more randomly sourced patches, and used to need people to test disabling them from time to time - which I don't think we could do as easily these days
[05:27] <bryce_> however with PPAs I find it's easier for me to just roll them a special package than to walk them through building packages ;-)
[05:28] <bryce_> and heck, half the time they never even bother testing the packages...
[05:30] <RAOF> And when walking others through patch disablement there's always the question of whether they've built the packages correctly…
[05:30] <bryce_> RAOF, anyway it's probably one of those things that once I've done it a few times I'll be more comfortable with it
[05:30] <RAOF> Yeah.
[05:31] <RAOF> It's what Debian's doing (and has been doing for a while, although they don't cherry-pick nearly as much as we do).
[05:31] <bryce_> I've done git cherrypick once or twice, and remember being quite impressed with it
[05:34] <bryce_> anyway, good uds topic.  I think if we switch to doing that we should do it at the start of a new release
[05:35] <bryce_> also, we probably should become more consistent about using vcs on all the packages
[05:36] <bryce_> (another something I've not fancied doing, but there's enough of us it makes sense)
[05:36] <RAOF> The ones that aren't already in git I tend to feel aren't in git because we're hoping they'll go away :)
[05:37] <bryce_> however I do think we have an issue in that using git imposes a barrier for ubuntu colleagues who could do bzr but aren't going to be as willing to do git
[05:38] <RAOF> That is a problem, yes.  Although, really, they can just do what they normally do and upload outside of git and we'll fold the changes in ourselves.
[05:38] <RAOF> That doesn't scale, but we don't really need it to :)
[05:45] <bryce_> RAOF, so yeah, even though I don't favor it, I'm open minded to the idea.  Sell me on it at UDS. :-)
[05:49] <tjaalton> ooh, git-cherrypicks.. interesting
[05:49] <tjaalton> need to get some breakfast first before reading the backlog :)
[05:54] <Sarvatt> can't say I'm a fan of the idea.. just a few days ago I was having to send our intel 2.12 patch series from maverick to a guy at intel, a bit easier to see our differences that way than know which commits on the branch were cherry picked and dig through the log full of packaging maintenance but I guess its just me :) we'd have to start tagging releases for sure
[05:58] <RAOF> Sarvatt: Was the intel guy interested in the things we cherry-picked?
[05:59] <RAOF> Ahem.  Let's save this for a nice, high-bandwidth discussion at UDS :)
[06:01] <bryce_> yep
[06:01] <bryce_> http://vignatti.wordpress.com/2011/02/28/x-census-for-1-10/
[06:02] <bryce_> http://people.freedesktop.org/~vignatti/xdevelopment/xorg_110_xserver-SHOWING-WHEREIS-CANONICAL.txt
[06:11]  * RAOF hopes to be more prominent in the 1.11 version of that.
[07:32] <bryce_> RAOF, I wonder how those stats would look if we included commits to the ubuntu git tree too ;-)
[08:31] <tjaalton> RAOF: how to solve the problem of wacom & git? ron keeps his own tree, but we should have a place to host the branch(es)
[08:31] <tjaalton> pkg-xorg isn't it
[08:50] <lag> Ah, just the people I'm looking for :D
[08:50] <lag> I'm trying to pull up a desktop on my u8500
[08:50] <lag> But having lack of success
[08:50] <lag> Would someone mind seeing if there's a problem here please? https://pastebin.linaro.org/37/
[08:54] <tjaalton> lag: no access
[08:54] <lag> tjaalton: Was that a question, or a statement? 
[08:54] <tjaalton> "You do not currently have access to the pastebin."
[08:54] <lag> tjaalton: Ah yes, I'll use another
[08:55] <lag> This should be better: http://paste.ubuntu.com/574353/
[08:57] <bryce_> fbdev, eh?
[08:57] <lag> bryce_: Hi Bryce 
[08:57] <lag> bryce_: Yes, is that wrong?
[08:58] <apw> lag what are your symtoms
[08:58] <lag> apw: Black screen
[08:58] <bryce_> ah, arm - Linux 2.6.31-608-imx51 armv7l Ubuntu 
[08:58] <lag> bryce_: That's wrong, where did you get that from?
[08:58] <apw> [    14.264] Build Operating System: Linux 2.6.31-608-imx51 armv7l Ubuntu                                                                                                                                                                                                                                                 
[08:58] <bryce_> lag, from your pastebin log
[08:59] <lag> Ah yes, just looked
[08:59] <bryce_> that's your build OS tho
[08:59] <lag> It's a generic rootfs that we use for ALL our ARM aboards
[08:59] <bryce_> 2.6.35-1000-u8500 #2 SMP PREEMPT Tue Mar 1 15:21:38 GMT 2011 armv7l  
[08:59] <bryce_> that's better, that's what you booted
[08:59] <lag> I'm using Linux version 2.6.35-1000-u8500
[08:59] <lag> Yes
[09:00] <bryce_> anyway, for black screen issues, Xorg.0.log hardly ever provides useful debug info
[09:00] <lag> bryce_: I'm new to this graphics mallarky - if you could point me in the right direction for decent debug ...
[09:01] <bryce_> usually the procedure for debugging black screen bugs is to capture a gpu register dump with it black, and another with it not black (e.g. any workaround you've found) and then folks in the know can compare registers to see what's gone wrong
[09:02] <bryce_> however I'm completely unfamiliar with debugging X issues on arm, so YMMV
[09:02] <bryce_> also, I have NFI how to get gpu register dumps with fbdev
[09:02] <lag> Hmmm
[09:02] <bryce_> but that's how debugging works for -ati, -intel, -nouveau, etc.
[09:02] <lag> I have proven graphics to work
[09:03] <lag> I have an application which throws some coloured blocks around
[09:03] <bryce_> this won't help you but is our stock debug page for this class of issue https://wiki.ubuntu.com/X/Troubleshooting/BlankScreen
[09:03] <tjaalton> X seems to be up, there's just nothing that draws on it?
[09:03] <lag> I'll take a look
[09:04] <lag> tjaalton: What needs to be running to draw on it?
[09:04] <tjaalton> lag: i dunno, is it a normal distro, ie. gdm should be running?
[09:05] <lag> root      1239  0.0  0.8  13640  2648 ?        Ssl  08:42   0:00 gdm-binary                                                                                                                                                                                                                                               
[09:05] <lag> root      1373  0.0  0.9  16060  2924 ?        Sl   08:42   0:00 /usr/lib/gdm/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1                                                                                                                                                                            
[09:05] <lag> root      1427  0.2  3.7  25720 12028 tty7     Ss+  08:42   0:03 /usr/bin/X :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-gxP3xX/database -nolisten tcp vt7                                                                                                                                                             
[09:05] <lag> root      1635  0.0  0.7  13860  2296 ?        Sl   08:42   0:00 /usr/lib/gdm/gdm-session-worker 
[09:08] <tjaalton> does the gdm logfile have something?
[09:09] <lag> tjaalton: Nothing new
[09:10] <lag> tjaalton: In fact, it's fairly identical 
[09:14] <tjaalton> lag: what about dmesg? it's fbdev playing tricks, so more likely a kernel problem aiui
[09:18] <lag> dmesg | grep -i fb
[09:18] <lag> Nothing
[09:19] <lag> I'm fairly sure /dev/fb0 is created by MCDE
[09:21] <lag> root@localhost:~# fuser -v /dev/fb0                                                                                         
[09:21] <lag>                      USER        PID ACCESS COMMAND
[09:21] <lag> /dev/fb0:            root       1473 f...m Xorg 
[09:21] <lag> So X is running on /dev/fb0 and gdm is also running
[09:22] <lag> What's in the middle?
[09:24] <tjaalton> do you see the bootsplash (plymouth)
[09:24] <tjaalton> while booting
[09:24] <lag> If I kill X, I can run this: http://paste.ubuntu.com/574364/
[09:25] <lag> And it displays moving blocks, so /dev/fb0 IS working
[09:25] <tjaalton> ok
[09:25] <lag> tjaalton: No, but we never to AFAIK
[09:25] <lag> s/to/do
[09:25] <tjaalton> right
[09:27] <tjaalton> you can hear the drums when gdm is loaded (dunno if the sounds is still used)
[09:28] <lag> Audio doesn't work
[09:28] <lag> But I get a console on the serial
[09:28] <tjaalton> ok
[09:31] <tjaalton> well, there's no pointer device according to the logfile, but that shouldn't matter
[09:40] <bryce_> lag, it seems your issue is non-obvious, perhaps the logical next action would be to file a bug report ('ubuntu-bug xorg')
[09:41] <bryce_> lag, also I suspect ultimately it's going to be a kernel drm issue, so may be worthwhile to speak to apw or other kernel team members about it
[09:41] <bryce_> tjaalton, any other suggestions for 'next action' on this bug?
[09:41]  * apw sticks his fingers in his ears
[09:41] <bryce_> apw, *grin*
[09:42] <tjaalton> bryce_: no, afaict X is running fine, just that nothing ends up on the screen for some reason
[09:42] <tjaalton> lag: by filing the bug we'd also see the full dmesg, in case there's something..
[09:42] <bryce_> tjaalton, any chance it's a phantom output or incorrect output issue?
[09:43] <lag> I've been speaking to my graphics expert
[09:43] <jcristau> what's in /proc/fb?
[09:43] <lag> He says that X expects a single buffered autorefreshed framebuffer
[09:43] <tjaalton> bryce_: could be
[09:43] <lag> And we have a doublebuffered fb0 that needs an explicit  "pan" in order to do a refresh
[09:44] <bryce_> lag, what's this fellow's name?
[09:45] <lag> He who must not be named 
[09:45] <bryce_> lol
[09:45] <lag> Do you want to chat with him?
[09:45] <bryce_> nah, just curious
[09:45] <lag> Robert Fecket 
[09:46] <lag> He's my Graphics Guru on the ST-Ericsson Landing Team
[09:46] <bryce_> ok cool
[09:47] <bryce_> lag, that sounds like something which might be particular to fbdev (of which I'm unfortunately not sufficiently experienced with to say much)
[09:47] <lag> https://wiki.linaro.org/EngineeringTeam#ST-Ericsson
[09:47] <lag> Robert says fbdev is X11, which he isn't fluent in
[09:48] <bryce_> hrm
[09:48] <bryce_> we need to gain someone either on our side or yours who knows fbdev inside and our
[09:48] <bryce_> out
[09:49] <lag> bryce_: It's not usually something we deal it, it will have to be a Ubuntuite 
[09:49] <lag> s/it/in
[09:49] <tjaalton> is the single/doublebufferness a hardware feature or something you can decide on kernel cmdline?
[09:49]  * lag checks
[09:50] <bryce_> lag, rubbing my magic 8-ball I predict it's something you'll be dealing with in the future ;-)
[09:50] <bryce_> lag, but seriously, fbdev is not a driver we tend to deal with much outside of arm
[09:50] <bryce_> but still, we'll try to help
[09:51] <lag> Thanks
[09:52] <bryce_> lag, on -intel and other drivers, we have tools that produce register dumps.  Could you ask Robert if he can find out if there are any tools for getting GPU dumps on this hardware?
[09:52] <lag> Sure
[09:52] <lag> In fact, I can do better than that
[09:52] <bryce_> thanks.  I *think* that is the direction debugging needs to go for this issue (unless it's something obvious I'm just missing).
[09:53] <tjaalton> lunch->
[09:53] <bryce_> yep, 2am for me.  bed->
[09:53] <apw> night night bryce_ 
[09:55] <lag> Ah, take care
[12:13] <RAOF> tjaalton: I'd guess we could just host a bzr branch for wacom on launchpad.  I'd be happy to do that, and bzr builddeb is pretty awesome.
[12:14] <RAOF> lag: Sounds like you might need something a little smarter than fbdev?  The other arm guys seem to take fbdev and add a little sauce to bend it to their will (omapfb, for example).
[12:50] <tjaalton> hm, so bzr is said to be easier, but bzr-git has no manpages
[13:39] <lag> RAOF apw tjaalton bryce_: Cracked it :D
[13:39] <apw> lag, and?
[13:39] <lag> -# CONFIG_DISPLAY_GENERIC_DSI_PRIMARY_AUTO_SYNC is not set
[13:39] <lag> +CONFIG_DISPLAY_GENERIC_DSI_PRIMARY_AUTO_SYNC=y
[13:39] <tjaalton> ha
[13:39] <apw> heh
[13:40] <lag> Apparently turning auto_sync off will dramatically reduce battery life and performance, but I have a desktop!
[13:41] <apw> well you turned it on, so you are good no?
[13:41] <lag> I'm happy
[14:04] <tseliot> cnd: do you know what can be causing the synaptics kernel driver to pass x coordinates = 8176 after touching  the right area of the touchpad (not only the right edge)? I noticed this change when upgrading from Hardy to Lucid. BTW the x-axis range is 1472 - 5472
[14:04] <cnd> tseliot, no idea
[14:05] <tseliot> cnd: do you know someone who might know what's going on?
[14:05] <cnd> there's a few people on linux-input
[14:06] <cnd> but I think you'd probably need to do some debugging
[14:06] <tseliot> cnd: that wouldn't be a problem
[14:11] <johanbr_> What's the current situation with Nouveau and 3d in Natty? Default, possible with bits from PPA, or not at all?
[14:13] <tjaalton> possible with libgl1-mesa-dri-experimental, but unsupported
[14:20] <johanbr_> ahh, alright. thank you!
[16:46] <ara> Hello all!
[16:47] <ara> I know that there is a bug affecting Lucid that prevents installation in headless desktops 
[16:47] <ara> anyone remembers the bug #?
[16:47] <ara> thanks!
[16:51] <tjaalton> no idea, can't seem to find it either
[17:12] <bryce_> ara, I fixed it earlier this week, it ended up being a bug in ubiquity, not in X
[17:12] <bryce_> ara, but #714829
[17:13] <tjaalton> bryce_: that was on natty
[17:13] <tjaalton> this apparently still in lucid
[17:15] <ara> bryce_, that's not the bug I am looking for. The one I am looking for is one in Lucid that makes X freeze during the installation if there is no monitor attached to the desktop
[17:19] <bryce_> tjaalton, ah didn't read close enough
[17:19] <bryce_> yeah dunno that one
[21:58] <RAOF> tjaalton: Hm.  I've never noticed that bzr-git doesn't have any manpages, mainly because (a) it's transparent, and (b) bzr help $FOO is how 
[21:58] <RAOF> I find bzr help :)
[21:59] <RAOF> ara was thinking of the bug where X would refuse to start with “no screens found”, right?
[22:48] <LLStarks> bryce_, i'm sending xrender bug upstream. should i file against first known affected version of -intel?
[22:52] <bryce_> LLStarks, probably doesn't matter but I'd file against the most recently tested version
[22:52] <bryce_> or just leave it blank
[22:53] <RAOF> They'll be more interested in the most recently tested version.  If you know the *first* affected version, then there's likely bisection to be done, too.
[22:59] <LLStarks> well, regression window is 2.9.1-2.12
[23:13] <bryce_> man, going through bug reports is such a slog
[23:35] <Milos_SD> Hi
[23:35] <Milos_SD> Is there a way to get XServer 1.10 on Maverick?
[23:36] <RAOF> It might be in xorg-edgers?
[23:37] <Milos_SD> RAOF, it is not. Only 1.9.2 ... 1.10 is for Natty :(
[23:37] <RAOF> Any particular reason you want 1.10?
[23:37] <Milos_SD> no :)
[23:38] <RAOF> :)
[23:40] <Milos_SD> I just want latest and gratest :D
[23:40] <LLStarks> what package holds xorg-macros?
[23:41] <LLStarks> nvm
[23:42] <bryce_> Milos_SD, the amount of user-visible changes in 1.10 compared with 1.9 is not huge, maybe not compelling enough to trouble with it
[23:42] <bryce_> oops just missed him
[23:42] <bryce_> was going to suggest just running natty ;-)
[23:44] <LLStarks> does rendercheck automatically log?
[23:47] <bryce_> dunno
[23:54] <bryce_> LLStarks, thanks for pushing the bug report upstream
[23:54]  * bryce_ is way behind on getting bug reports upstreamed