#ubuntu-x 2006-07-19
<rodarvus> guys, as you might (or not :) ) know, I'm working on X.Org 7.1 packages, currently
<Mithrandir> you're basing those off the 7.1 packages in Debian?
<rodarvus> Debian has *very* little done, until now, and gravity will be away for the next two weeks (and has no plans to touch X.Org 7.1 until then)
<Mithrandir> hmm, ok.
<rodarvus> so, yes, I'm basing on their work
<rodarvus> but very little has been done
<rodarvus> I was wondering if it makes sense to try to collaborate with them right now - meaning contacting someone at XSF, and try to push our packages directly to experimental
<rodarvus> and sync them into ubuntu, from there
<rodarvus> (this is question #1)
<Kamion> political advice: don't talk about it as "pushing our packages"
<rodarvus> also, I noted that many of the packages that are "part" of X.Org 7.1 are already outdated - for example, libx11 (for 7.1) is 1.0.1 - current version is 1.0.3
<Kamion> also, there are still differences, so presumably the versions in experimental would have to be based on existing Debian packaging, not on existing Ubuntu packaging
<rodarvus> do you think it is a problem for us to go directly to 1.0.3? (and be "newer" than 7.1 in some packages)
<rodarvus> the same operation would happen in many other packages too
<Kamion> that's not to say collaboration doesn't make sense of course - I think it does, if possible
<Kamion> rodarvus: case-by-case, I'd say
<Kamion> depends on what's in 1.0.3
<rodarvus> *nods*, I agree its a case-by-case
<rodarvus> Kamion: also, thanks for the advice on collaboration with Debian :)
<Kamion> I wouldn't expect it to be intrinsically a problem to go to newer versions, if the changes are reasonable and not API/ABI-complex
<rodarvus> dangerous territory :P
<Mithrandir> I'd be very scared if Xorg broke the libX11 ABI.
<Kamion> http://gitweb.freedesktop.org/?p=xorg-lib-libX11;a=log;h=99c711707ad08e1396e123b1c7df687c560a489a shows at least some security fixes between 1.0.1 and 1.0.3
<fabbione> same soname
<fabbione> no abi breakage
<Kamion> also one or two changes that might require packaging tweaks
<Kamion> (the i18n datadir/libdir stuff)
<fabbione> you need to make sure to pull in the proper headers to build libx11
<fabbione> otherwise it's not going to build
<rodarvus> fabbione: right, I plan to build all new x11proto before
<fabbione> ok
<rodarvus> before building the rest, I mean
<rodarvus> anyhow, I'll do it, then - thanks for the advice, guys!
<rodarvus> I'd also like to consider helping XSF directly in the future, but I figure it won't be very likely to happen *right now*, due to time constraints
<Kamion> I suspect that collaborating with XSF on this pretty much equates to helping them directly
<Kamion> since it won't be a matter of "commit Ubuntu packaging to SVN"
<rodarvus> exactly
#ubuntu-x 2006-07-21
* Starting logfile irclogs/ubuntu-x.log
<rodarvus> libxpm, libdmx, libxdamage, libxdmu built successfully
<rodarvus> libxaw uploaded
<rodarvus> hopefully dependency hell will be solved RSN
<rodarvus> libxrender uploaded
<rodarvus> libxevie uploaded
<rodarvus> libxi uploaded
<rodarvus> libxres uploaded
<rodarvus> libxcursor & libxrandr are ready to be uploaded, but blocked on libxrender publish
<rodarvus> libxcursor uploaded
<rodarvus> libxrandr uploaded
<rodarvus> libxvmc uploaded
<rodarvus> libxkbfile uploaded
<rodarvus> libxxf86dga uploaded
<rodarvus> libxxf86misc uploaded
<rodarvus> libxxf86vm uploaded
<rodarvus> ok, by now, all X.Org libraries are either built/published, or at least uploaded (with exception of libxkbui, which depends on libxkbfile to be published)
<rodarvus> hopefully later today I'll return and work some more on xorg-server (if it has no other dependencies, of course)
<rodarvus> after that, comes mesa, drivers, apps and any packages I might have left abandoned
<rodarvus> family time now, I'll be back later
#ubuntu-x 2007-07-16
<ubotu> New bug: #54202 in xorg (main) "xorg 7 dissables capture - ATI Radeon 7500 RV200 QW - WARNING ! Radeon memory controller is misconfigured, disabling capture" [Undecided,New]  https://launchpad.net/bugs/54202
<ubotu> New bug: #126362 in xorg (main) "Xorg crashes when working with large images" [Undecided,New]  https://launchpad.net/bugs/126362
<ubotu> New bug: #126425 in xorg-server "[Fixed]  Intel driver (using EXA) crashes system when starting compiz" [Undecided,New]  https://launchpad.net/bugs/126425
#ubuntu-x 2007-07-17
* Starting logfile irclogs/ubuntu-x.log
<ubotu> New bug: #109824 in xorg-server (main) "fixed css scrolling bug in firefox while using compiz" [Medium,Confirmed]  https://launchpad.net/bugs/109824
<ubotu> New bug: #108527 in xserver-xorg-video-ati "desktop-effects enabled sometime freeze computer" [Undecided,New]  https://launchpad.net/bugs/108527
<ubotu> New bug: #109359 in compiz (main) "No video image when desktop effect are active (dup-of: 122979)" [Undecided,New]  https://launchpad.net/bugs/109359
<ubotu> New bug: #124002 in compiz (main) "trouble with totem on ibm thinkpad r51 (Radeon Mobility M7 LW ) mplayer work fine (dup-of: 122979)" [Medium,New]  https://launchpad.net/bugs/124002
<ubotu> New bug: #125693 in compiz (main) "After installing desktop effects, totem dosen't display (dup-of: 122979)" [Undecided,New]  https://launchpad.net/bugs/125693
<ubotu> New bug: #126561 in xorg (main) "displayconfig-gtk crashes doesn't work at all" [Undecided,New]  https://launchpad.net/bugs/126561
* Starting logfile irclogs/ubuntu-x.log
#ubuntu-x 2007-07-18
* Starting logfile irclogs/ubuntu-x.log
<ubotu> New bug: #126748 in xserver-xorg-video-nv (main) "Occasional color map corruption with GeForce 6150" [Undecided,New]  https://launchpad.net/bugs/126748
<ubotu> New bug: #37472 in linux-source-2.6.15 (main) "the keyboard don't work perfectly on laptops acer travelmate 2300 series with Dapper (dup-of: 39315)" [High,Incomplete]  https://launchpad.net/bugs/37472
<ubotu> New bug: #119465 in xorg (main) "ati radeon cards won't work" [Undecided,New]  https://launchpad.net/bugs/119465
<ubotu> New bug: #123266 in xorg (main) "[gutsy]  AGP not available, amd64_agp, drm" [Undecided,New]  https://launchpad.net/bugs/123266
<ubotu> New bug: #123885 in xorg (main) "failed to start Ubuntu 7.10 Tribe 2 (radeon x800 xl pcie)" [Undecided,New]  https://launchpad.net/bugs/123885
<ubotu> New bug: #126820 in xorg-server (main) "Xorg crashed with SIGSEGV in xf86XVRegetVideo" [Undecided,New]  https://launchpad.net/bugs/126820
<ubotu> New bug: #119585 in xorg (main) ""out of range" message on monitor" [Undecided,Incomplete]  https://launchpad.net/bugs/119585
<ubotu> New bug: #125902 in xorg (main) "X server crashed while gnome-session was checking for texture_from_pixmap support under VMWare" [Undecided,New]  https://launchpad.net/bugs/125902
<ubotu> New bug: #126843 in xserver-xorg-driver-ati (main) "ATI Radeon 7200 + OpenGL Lockup with Gutsy Gibbon Tribe 2" [Undecided,New]  https://launchpad.net/bugs/126843
<ubotu> New bug: #119357 in xorg (main) "[ gutsy ]  applications use wrong screen resolution" [Undecided,Incomplete]  https://launchpad.net/bugs/119357
<ubotu> New bug: #126867 in xserver-xorg-video-savage (main) "please sync xserver-xorg-video-savage 2.1.2-6 from Debian unstable" [Undecided,New]  https://launchpad.net/bugs/126867
#ubuntu-x 2007-07-19
<ubotu> New bug: #119246 in xorg (main) "No working graphics after installation, thinkpad z61m" [Undecided,Incomplete]  https://launchpad.net/bugs/119246
<ubotu> New bug: #120420 in xorg (main) "Tilde not working on iMac in UK (Feisty)" [Undecided,New]  https://launchpad.net/bugs/120420
<ubotu> New bug: #126897 in xserver-xorg-input-mouse (main) "IBM ScrollPoint mouse scrolls vertically VERY fast and has no horizontal scrolling" [Undecided,New]  https://launchpad.net/bugs/126897
<ubotu> New bug: #51056 in linux-restricted-modules-2.6.17 (restricted) "DVB firmware USB drivers" [Undecided,Fix committed]  https://launchpad.net/bugs/51056
<ubotu> New bug: #127005 in xserver-xorg-video-i810 (main) "my xserver crashed after unsuspend" [Undecided,New]  https://launchpad.net/bugs/127005
<ubotu> New bug: #36875 in xserver-xorg-video-ati (main) "ATI mobility radeon x700 doesn't work. (dup-of: 37116)" [Medium,Incomplete]  https://launchpad.net/bugs/36875
<ubotu> New bug: #99114 in xorg (main) "System reboots on heavy 3D activity (i810 + Intel 82G965 + Compiz)" [Undecided,New]  https://launchpad.net/bugs/99114
#ubuntu-x 2007-07-20
<ubotu> New bug: #127096 in xrandr (main) "nvidia through DVI screen resolution incorrectly detected as 1024x768 on a HP F1905B LCD monitor" [Undecided,New]  https://launchpad.net/bugs/127096
<ubotu> New bug: #127101 in xorg-server (main) "laptop hangs, last message is "XAA: Evicting pixmaps"" [Undecided,New]  https://launchpad.net/bugs/127101
* Starting logfile irclogs/ubuntu-x.log
<ubotu> New bug: #127252 in xorg (main) "DRI graphics drivers causes too many wakeups" [Undecided,New]  https://launchpad.net/bugs/127252
#ubuntu-x 2007-07-21
<ubotu> New bug: #122591 in xorg (main) "Intel 945 Express 1680x1050 resolution on external monitor" [Undecided,New]  https://launchpad.net/bugs/122591
<ubotu> New bug: #127302 in xserver-xorg-video-intel (main) "Intel G945 vidio driver don't support the "direct rendering" on Gutsy " [Undecided,New]  https://launchpad.net/bugs/127302
<ubotu> New bug: #127343 in Ubuntu "Problem running Ubuntu 7.04 with VIA VN896 Chrome9 IGP Graphic Card" [Undecided,New]  https://launchpad.net/bugs/127343
<ubotu> New bug: #127368 in xorg (main) "Ubuntu won't install on Dell 1420n" [Undecided,New]  https://launchpad.net/bugs/127368
<ubotu> New bug: #127369 in xorg (main) "Stuck on blank screen after login with nvidia driver on ubuntu gutsy tribe 3" [Undecided,New]  https://launchpad.net/bugs/127369
<ubotu> New bug: #127382 in xserver-xorg-input-evdev (main) "EVDEV driver makes my mouse mad" [Undecided,New]  https://launchpad.net/bugs/127382
<ubotu> New bug: #127428 in xserver-xorg-video-unichrome (universe) "very inaccurate package description" [Undecided,New]  https://launchpad.net/bugs/127428
#ubuntu-x 2007-07-22
<ubotu> New bug: #127529 in xorg (main) "nv driver - widescreen not recoginzed  Asus A8Jn" [Undecided,New]  https://launchpad.net/bugs/127529
#ubuntu-x 2008-07-14
<bryce_> morning!
#ubuntu-x 2008-07-15
<jcristau> bryce_: hi. any chance you can try the patch i attached to fdo bug 16674? it fixed vesa/randr here
<ubottu> Launchpad bug 16674 in ubuntu "In Breezy, the keybard is set to qwerty in virtual terminals (dup-of: 16364)" [Medium,Invalid] https://launchpad.net/bugs/16674
<ubottu> Launchpad bug 16364 in console-common "boottime.kmap.gz is not loaded at boot : problem with install-keymap and/or loadkeys" [Critical,Fix released] https://launchpad.net/bugs/16364
<bryce_> jcristau: I can package it up for matt to test; unfortunately I'm on travel in London this week and don't have access to my test gear
<jcristau> ok
<bryce_> wow, such a simple fix
<jcristau> yeah. it turns out that (int) (mode->Clock * 1000.0 / mode->HTotal / mode->VTotal + 0.5) when mode->Clock, mode->HTotal and mode->VTotal are all 0 doesn't give such a meaningful refresh rate
<bryce_> ahh
<jcristau> spent a few hours trying to understand what was going wrong
<bryce_> much appreciated.  building server pkgs presently...
<bryce_> yeah I banged my head on gdk client-side for the better part of a day before I left
<jcristau> i figured it wasn't a client-side problem when i made a trivial app that just did XRRGetScreenResources()/XRRGetCrtcInfo()/XRRGetOutputInfo() and that returned crap
<bryce_> jcristau: ok posted to http://people.ubuntu.com/~bryce/Testing/xserver/ and asked mdz to give it a try
<crevette> hey bryce
<bryce_> heya crevette
<crevette> bryce_, I've a brand new thinkpad T61 with intel chip, and all is working great except cpu sticks to 100% cpu for intensive CPU 
<crevette> I blaming GPU because with the same hardware with Nvidia I didn't have issue
<crevette> is it a known issue
<crevette> ?
<bryce_> crevette: don't know
<mvo> bryce_: *cough* I just uploaded the new mesa from debian experimental to intrepid
<bryce_> mvo: great.  any effect on the bugs we're looking at?
<bryce_> jcristau: yes mdz confirmed that this patch fixes the issue
<jcristau> cool
<tormod> this looks wrong: 7.1~rc3-1~ppa1 Published in intrepid-release 2 hours ago
<bryce_> tormod: is that the mesa release?
<bryce_> mvo accidentally uploaded it earlier.  However I assume it failed to build?
<bryce_> in any case he's planning on putting a fixed up new mesa in
<mvo> bryce_: yes, my bad
<mvo> it fails to build
<mvo> never do more than one thing at a time ;)
<tormod> bryce_: the version looked a bit strange for a real upload :)
 * mvo blushes in shame
<tormod> glad to see a new mesa coming anyway!
<bryce_> mvo apologized profusely to us and will fix :-)
<bryce_> mvo, right no need to do the merge via git
<bryce_> mvo, our git page - https://wiki.ubuntu.com/X/GitUsage
<bryce_> only xorg and xorg-server require git
<bryce_> hmm, speaking of which I forgot to check in the fix for matt's bug
<tormod> mesa should be synced, right?
<jcristau> there's an ubuntu branch for mesa too
<jcristau> tormod: no
<tormod> the ubuntu branch is not up to date
<bryce_> jcristau: I believe timo created that for merge convenience, but isn't requiring it
<tormod> the build failure indicates it can not be synced I guess...
<jcristau> a bit weird to have a branch there if it's not going to be used
<bryce_> tormod: it needs to be merged
 * mvo is working on it now
<jcristau> bryce_: hmm, there's already a python binding for libxf86config, i thought
<bryce_> tjaalton: it looks like maybe your -0ubuntu2 change for xorg-server wasn't committed to git?  (or maybe I'm doing something wrong...)
<jcristau> right, no -0ubuntu2 in git
<tjaalton> damn, let me push (back again)
<bryce_> tjaalton: you'll need to merge my change I just uploaded (sorry)
<tjaalton> bryce_: no worries, my bad
<bryce_> summarizes current X in ubuntu:  http://www.phoronix.com/scan.php?page=article&item=ubuntu_810_xorg&num=1
<tjaalton> yeah, merging mesa using the git branch would be trivial
<mvo> tjaalton: could you please check if you can merge my (not yet uploaded changes) from http://people.ubuntu.com/~mvo/git/mesa.git/ ?
<mvo> tjaalton: my git-foo is very weak, so I would like to know if it actually works :)
<jcristau> mvo: i think you need to run git-update-server-info on the server for http:// git to work
<jcristau> mvo: and if you chmod +x hooks/post-update it should be done automatically
<mvo> jcristau: thanks, I thought I had done that, but it seems like it was not run for some reason. I ran it now manually
<mvo> jcristau: if you could test-merge it, that would be cool!
<tjaalton> mvo: ok I'll check it out
<mvo> tjaalton: its a really trivial merge (I hope :) 
<tjaalton> mvo: I bet it is :)
<tjaalton> fetching it.. gonna take a while
<jcristau> mvo: looks good. pulled and pushed back out.
 * mvo hugs jcristau
<mvo> thanks!
<tjaalton> jcristau: wow thanks, so I failed to push mesa too.. amazing
<tjaalton> my git fetch didn't finish after ~2h, so maybe this GPRS connection is not that suitable for development after all :P
<jcristau> heh
<tormod> we've got new mesa \o/
 * jcristau got it like *days* ago.. ;)
<tjaalton> the "old " one was quite rece tnt too, not quite rc1
<tormod> I think some people will be happy for the fixes, especially on intel
<jcristau> i965 compiz is still b0rked though
<tormod> is there an easy way to see the Ubuntu delta, short of waiting for patches.ubuntu.com
<tormod> ?
<tormod> and short of debdiffing src packages...
 * crevette wants to upgrade to intrepid
<jcristau> git diff debian-experimental..ubuntu
<tormod> jcristau: thanks, can't get easier I guess :)
#ubuntu-x 2008-07-16
<unggnu> hi all
<unggnu> I have read about the xorg-options-editor and wanted to ask if there will be a modeline generator shipped within?
<unggnu> the best would be a combination with a driver importer like displaconfig-gtk I guess. Maybe this part could be reused.
<unggnu> For faulty hardware of course. Would make things for the concerned much more easier I think. Btw. displayconfig-gtk seems to depend on Python too.
<jcristau> what's wrong with cvt and gtf?
<jcristau> other than 'omg a command-line tool'
<tseliot> ï»¿unggnu: we haven't planned to add a modeline generator since this tool won't be used to set the resolution
<unggnu> I thought it will be an advanced button for screen resolution?
<unggnu> jcristau: People love their Guis :)
<unggnu> It is if the monitor sends wrong data and the user is stick with low resolutions or hugh fonts thish could be fixed through adding modelines. And a driver importer or easy setup (add size, hsync and vsync) would things much more easier.
<jcristau> i think most people don't use 10-year old monitors so they don't need that anyway
<jcristau> but hey
<unggnu> jcristau: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/120619
<ubottu> Launchpad bug 120619 in xserver-xorg-video-intel "[Gutsy] invalid resolution detected resulting in BIG fonts on i915" [Undecided,Confirmed] 
<unggnu> I don't know, but it doesn't seem so rare
<unggnu> jcristau: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/191000
<ubottu> Launchpad bug 191000 in xserver-xorg-video-intel "[Hardy] X Server fails to start [845g] (dup-of: 194760)" [Unknown,Fix released] 
<ubottu> Launchpad bug 194760 in xorg-server "EDID fail" [High,Triaged] 
<jcristau> unggnu: i suspect most of those have been resolved by now
<unggnu> The second one 191000 can't be fixed without adding a modeline according to Upstream.
<jcristau> plus they don't need a modeline, they need correct size detected
<unggnu> I don't know, just though it would make things much more easier if someone has this problem. It is of course no must have
<jcristau> sure
<unggnu> Several people could fix their problem with displayconfig-gtk because of the modlines but as we know it could break easily X.
<unggnu> +e
<unggnu> Btw. isn't the display size saved in the modeline?
<jcristau> urgh. 1600x1024 doesn't make any sense
<tseliot> ï»¿unggnu: I'll think about adding this feature (since I'm the developer of ï»¿xorg-options-editor)
<bryce__> heya
<tseliot> ï»¿bryce__: hi
<unggnu__> re, sorry, had a connection problem :)
<bryce_> unggnu: no I think we want to get away from users generating modelines on their own
<unggnu__> It is just for the case where the correct resolutions aren't recognized. Hidden in the advanced tab or something like that
<bryce_> if they know what they're doing enough to generate one, then they probably have the aptitude to do it via command line via one of the tools jcristau suggests
<bryce_> to be honest I'd sort of prefer them to report these as bugs so we can get them fixed
<jcristau> unggnu: afaict 191000 doesn't need a modeline, just the PreferredMode option?
<unggnu__> Ok, but most people don't know how to do it and it doesn't look so great. I have always asked why Windows hasn't this resolution problems but I guess it is most likely because they use a monitor driver in most cases.
<bryce_> unggnu, this sort of falls into the category of the MonitorsOnlineDatabase spec (which I'm skeptical we even need anymore, but would fit in with that)
<bryce_> unggnu, right.  displayconfig-gtk had a tool for getting the modeline/resolution by parsing it out of the windows .inf files, which I think might be useful
<bryce_> esp. if coupled with a mechanism for sending the data back up (maybe via apport?)
<unggnu__> That was what I suggested except of the data backup.
<bryce_> ah, I thought you meant a modeline generator
<unggnu__> a generator with an import function :)
<bryce_> in any case, I'd like to keep it separate from tseliot's option editor, to keep things simple.  
<unggnu__> import is easier I guess but if there is no driver file add the data from the monitor handbook
<unggnu__> Ok, I just though a GUI would be great. Displayconfig-gtk is to risky imho.
<unggnu__> I mean no automatically modeline generator. If the resolution isn't recognized you could go to the advanced tab or something like that and generate/import one.
<bryce_> anyway, I think monitor configuration issues are reducing in frequency a lot, and I don't plan on investing time in gui tools for monitor config myself (I'd rather focus those energies on fixing the problem at its root), however if someone else were to write something which was adequately simple (and easy to maintain), and had provisions for getting the data upstream, I'd be open
<unggnu__> If someone come to the IRC channel my resolution is 800x600 or something like that you can lead him to the advanced function so he could try it. Btw. does the Vesa driver accept modelines?
<unggnu__> bryce_ Ok, sure.
<bryce_> I think I'd be more open to just an importer, than a generator/importer
<unggnu__> I personally never installed a monitor driver but it is possible that nearly every vendor has some on their homepage.
 * bryce_ nods
<bryce_> there's web pages out there to generate modelines, if people really wish to avoid cmdline tools
<unggnu__> Yeah, I tried it but it is not very easy imho.
<bryce_> I'll admit, I've never run into a bug where a modeline I generated with those web tools solved it.  Like jcristau points out, it usually ended up needing some server or driver option be set, or else some monitor quirk added to the xserver
<bryce_> so that's what made me think maybe just an options editor would be the best approach, and just have people file bugs so we can care for the rest.
<unggnu__> If I need a modeline to test I normally search for it :)
<bryce_> unggnu__: btw I just sat in on a presentation by the bug team about a new bug web report / graph thing they're working on:
<bryce_> http://people.ubuntu.com/~ogasawara/pkg-stats/openoffice.org.html
<bryce_> (that's a prototype)
<unggnu__> looks great
<unggnu__> But could make depressive ;)
<bryce_> hehe
<bryce_> btw, I don't know if you look at this one - https://bugs.launchpad.net/ubuntu/+upstreamreport
<bryce_> the last couple days I've been working on getting all the valid triaged bugs reported upstream for xserver-xorg-video-intel
<tseliot> bryce_: this is a list of the value types which xorg-options-editor should deal with (apart from '...'): http://pastebin.com/m3a979927
<bryce_> tseliot: ok
<tseliot> bryce_: is there anything we should ignore?
<bryce_> tseliot: how do you mean?
<bryce_> unggnu__: I've still got a few left to do, but two of the three columns are now green :-)
<tseliot> bryce_: here's the full XML with the options: http://pastebin.com/m40690da0
<unggnu__> No, didn't know this statistic page. Is there any Wiki/ link page for them?
<tseliot> bryce_: I mean, are there any options which we should not make available in the program?
<bryce_> unggnu__: I'd love to see the third column green (it must be hard to achieve, only gedit has it green), but it would be a great goal to work for with -intel
<bryce_> unggnu__: not sure, maybe from the QA page?  I learned of it at UDS, it's sort of experimental so not well advertised.
<bryce_> tseliot: hmm
<unggnu__> I am thinking about moving Bug 233787 upstream. It seems most likely that it is a pipe/output/quirk problem. I am asking for Force Pipe a and if it doesn't work I am going to move it upstream.
<ubottu> Launchpad bug 233787 in xserver-xorg-video-intel "No display with Intel x3100 965GM Express" [Undecided,Incomplete] https://launchpad.net/bugs/233787
<bryce_> tseliot: if it were me, I'd be lazy and just let them be freeform string entry, and if the user puts in something invalid, then they can deal with the breakage.  But you might be more kind than me.  :-)
<bryce_> unggnu__: excellent
<bryce_> tseliot: let me look more at it a minute
<tseliot> ï»¿bryce_: ok
<bryce_> tseliot: well, could we associate regexp's for each?
<bryce_> so we could specify { validator => '^\d+ \d+ \d+$', } { validator => '\d+\s*-\s*\d+' }
<tseliot> bryce_: ok, so that we can check the type of the components of each typed value?
<tseliot> decimal, string, etc.
<bryce_> yeah
<tseliot> ï»¿bryce_: how would we deal with time?
<bryce_> that'd probably be a sufficient sanity check to catch typos
<bryce_> what options need time?
<bryce_> ah blanktime
<tseliot> BlankTime, OffTime, SuspendTime, StandbyTime, etc
<bryce_> ok those are probably all measured in seconds, so it'd just be '^\d+$'
<tseliot> bryce_: seconds, minutes, etc. I can set the precision of floats in any case
<bryce_> or maybe '^(?:\d+|\d+\.\d+)$' or some such to permit fractional seconds, if it is allowed
<tseliot> bryce_: HandleSpecialKeys has a "when" type
<tseliot> what do we do with it?
<bryce_> oh looks like time is in minutes
<bryce_> but the regexp's would be the same
<bryce_> tseliot: that looks like it's an enum with three values possible
<bryce_> so a regexp for that would be /^(?:Always|Never|WhenNeeded)$/i
<tseliot> bryce_: ah, ok. So, when possible I should include the accepted values too. I might define these types in an XML file
<bryce_> sure, if you'd like
<bryce_> tseliot: I know python's regexp handling isn't as convenient as in perl, but if it were me, I'd do all the type specification and checking just using regexp's, and keep it simple
<bryce_> so for boolean, it'd be /^(?:1|0|true|false|yes|no)$/i or whatever
<tseliot> ï»¿bryce_: ok, good idea
 * pwnguin wishes we had something as popular as regex for more complicated languages
<pwnguin> antlr seems close
<unggnu__> tseliot: Do your program get the values and descriptions from the man page or do you enter them all in your program?
<tseliot> ï»¿unggnu__: it parser the man page
<tseliot> parses
<unggnu__> Ok, that is the best way to do I guess :)
<bryce_> tjaalton, jcristau: cjwatson noticed that the SECURITY module isn't getting loaded on xserver 1.5 in intrepid.  Has there been changes with that?  
<bryce_> looks like it's disabled in 1.5
<bryce_> hmm, seems to be an selinux change
<tseliot> ï»¿bryce_: the program should deal with these sections: device, screen, monitor, serverflags. Shall we keep serverlayout out?
<bryce_> I'd think so, unless the other sections won't work without it present
<tseliot> ok
#ubuntu-x 2008-07-17
<bryce_> jcristau, tjaalton:  I just got a response from intel that they're no longer going to support 81x any longer
<bryce_> http://bugs.freedesktop.org/show_bug.cgi?id=16729
<ubottu> Freedesktop bug 16729 in Driver/intel "[815]3D apps cause horizontal line corruption and freezes" [Major,New] 
<tseliot> bryce: what is the file that does the hardware detection when no driver is specified in the Device section of the xorg.conf?
<tseliot> ï»¿ bryce:  if no driver is specified I should detect which driver is loaded for the xorg-options editor
<bryce_> you'll need to parse that from the Xorg.0.log
<bryce_> I don't know of any reliable way to determine that otherwise
<bryce_> hm, or maybe you could look up the pci id in /usr/share/xserver-xorg/pci/
<tseliot> ï»¿bryce_: ok, thanks I'll look up the pci id then
<tjaalton> bryce_: bah, thypical
<tjaalton> -h
<bryce_> heya tjaalton
<tseliot> ï»¿bryce_: hardware detection works well now ;)
<bryce_> tseliot: nice
<jcristau> looking in /usr/share/xserver-xorg/pci/ is probably not future proof
<bryce_> tseliot: btw, I added a brief blurb about the status of -nvidia to https://wiki.ubuntu.com/X/Drivers .  When you get a chance it would be nice if you could flesh it out a bit more (not too detailed, but a paragraph or two would be sufficient, and links to more info would be great)
<tseliot> ï»¿bryce_: ok, I'll do it
<tseliot> ï»¿jcristau: what do you suggest then?
<jcristau> i don't know why you need that info for
<jcristau> also, what's with the BOMs
<tseliot> ï»¿jcristau: I'm writing xorg-options-editor and if no device section is available (or if the device section is available but the driver is not specified) I have to rely on xorg's autodetection
<jcristau> right
<tseliot> ï»¿BOMs???
<tseliot> and why isn't it future-proof?
<jcristau> yes, U+FEFF. there's one at the beginning of every one of your lines.
<jcristau> or, almost every one
<jcristau> it's not future proof because it'll probably go away at some point
<tseliot> jcristau: ï»¿U+FEFF??? I'm a bit confused by acronyms
<jcristau> it's an unicode codepoint
<jcristau> so whatever you use for irc is broken and puts that everywhere
<tseliot> I can't notice the problem here, using pidgin on Hardy
<tseliot> tjaalton reported a similar problem though
<tseliot> ï»¿bryce_: I have updated the wiki. I might do something more later
<bryce_> tseliot: excellent thanks
<bryce_> tseliot: http://www.phoronix.com/scan.php?page=article&item=xorg_driver_persistent&num=1
<tseliot> ï»¿bryce_: yes, I had also read the discussion in the X mailing list. When (or "if") they come to an agreement I can modify xorg-options-editor accordingly
<jcristau> err. maybe we haven't read the same discussion then. what more agreement do you need?
<tseliot> "To make it persistent, Dan Nicholson had chimed in asking whether GConf or HAL fdi should be used for storing these device property values."
<jcristau> and the answer was hal for system-wide defaults, gconf for user-specific, iirc?
<bryce_> tseliot: great, sounds good.  Since it sounds like an xserver 1.6 thing, I guess we can look into that for Intrepid+1
<tseliot> ï»¿bryce_: ok, I'll think about it when it's (almost) ready then
<BUGabundo> his Alberto Milone arround?
<BUGabundo> his = is lol
<mario_limonciell> tseliot, other than the fact that "debian has it", is there a reason that we have an init script for /etc/init.d/nvidia-kernel?
<mario_limonciell> i'm very surprised that something like this wouldn't be handled directly by the kernel module when loaded
<mario_limonciell> yeah actually it looks like it is done by the kernel module.  try stopping X, then "rm /dev/nvidia*" and then sudo X
<mario_limonciell> you'll see that those modules are created for you
<mario_limonciell> or devnodes i should say
<mario_limonciell> well i filed a bug for now, bug 249565
<ubottu> Launchpad bug 249565 in nvidia-graphics-drivers-96 "/etc/init.d/nvidia-kernel appears to be unnecessary" [Undecided,New] https://launchpad.net/bugs/249565
<tseliot> ï»¿mario_limonciell: thanks, I'll have a look at it later
<mario_limonciell> tseliot, i filed another bug about the init script for nvidia-glx too
<tseliot> link?
<mario_limonciell> tseliot, and it's existence makes me uneasy (in addition to the bug) since it just goes mucking around /usr/ like that
<mario_limonciell> but that's not what i filed the bug about
<mario_limonciell> sec
<mario_limonciell> https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-173/+bug/249566
<ubottu> Launchpad bug 249566 in nvidia-graphics-drivers-96 "/etc/init.d/nvidia-glx doesn't use LSB functions" [Undecided,New] 
<mario_limonciell> the reason i'm uneasy about that second init script existing, what if someone mounts /usr over NFS read only?  You can't assume that you are able to go and change things in there
<tseliot> ï»¿mario_limonciell: whatever it is (my connection seems to have some problem now) I will fix it. Don't worry ;)
<tseliot> mario_limonciell: what version and revision of the driver are you using?
<tseliot> I removed ï»¿/etc/init.d/nvidia-glx a few releases ago
<mario_limonciell> tseliot, then it must have come from dist-upgrading then
<mario_limonciell> let me purge all versions and do a fresher install
<tseliot> ï»¿mario_limonciell: ok
<mario_limonciell> tseliot, it wasn't around in hardy right?  so people who do hardy_>intrepid jump won't end up with it
<mario_limonciell> i probably just have it from an earlier use of your packages updated to a newer version
<mario_limonciell> tseliot, ah yeah neither of those appear to be present in the final ones :)
<mario_limonciell> you don't need /etc/default/nvidia-glx-### though anymore then either
<mario_limonciell> which is still present after i purged and reinstalled
<tseliot> ï»¿/etc/default/nvidia-glx-### ???
<tseliot> it's not in my packages
<mario_limonciell> i have an /etc/default/nvidia-glx-177 somehow?
<mario_limonciell> i purged all nvidia-* and reinstalled and saw it there
<mario_limonciell> i'll purge once more to ensure though
<tseliot> remove it manually
<tseliot> that was from TLS
<tseliot> which I removed
<mario_limonciell> no it definitely came in from nvidia-glx-177
<mario_limonciell> when i installed that
<mario_limonciell> it's in it's package listing (dpkg -L nvidia-glx-177)
<tseliot> which revision?
<tseliot> ubuntu5?
<mario_limonciell> ubuntu6
<tseliot> mario_limonciell: do a "dpkg --contents name_of_the_package" please
<tseliot> don't rely too much on dpkg -L
<mario_limonciell> http://paste.ubuntu.com/28113/
<mario_limonciell> yeah it's in there
<tseliot> ï»¿mario_limonciell: 173 is not affected though. Weird. Let me check the code
<tseliot> ï»¿mario_limonciell: there's no trace of such files in the rules, however I have noticed that I had left nvidia-glx-VER.default files in the debian folder of each driver apart from 173. I have removed such files and I'm rebuilding the packages
<mario_limonciell> ah 
<mario_limonciell> yeah that's most likely how it ended up there
<mario_limonciell> tseliot, i was thinking of something useful that you might consider putting into EnvyNG at some point
<tseliot> shoot
<mario_limonciell> the ability to grab the source of the nvidia-drivers-$LATEST, and for the user to provide the .run file from the nvidia website
<mario_limonciell> and let it spit out a package in case they aren't out and ready yet in backports etc
<mario_limonciell> so really it would just craft the orig.tar.gz from the run file and then bump the changelog and version inside the debian packaging temporarily
<tseliot> ï»¿mario_limonciell: I could do that but I don't think the other devs/motus would be extremely happy about this
<tseliot> since they wanted EnvyNG to install only packages from the official repos
<mario_limonciell> well i mean as long as it always used the source from the archive to build these newer packages
<mario_limonciell> it could be a temporarily solution
<mario_limonciell> think of it as the same model that is in the AMD drivers now
<mario_limonciell> that the source of the debian/ directory is contained and you get the same drivers if you install from AMD's website as you do if you install from the archive
<mario_limonciell> just since NVIDIA doesn't provide such a system, you fill the gap with envyng
<mario_limonciell> it's just an idea to think about at least
<tseliot> ï»¿mario_limonciell: I'm not saying that it's a bad idea. I would like to keep both users and devs happy, that's all.
<tseliot> I'll think about it
<mario_limonciell> tseliot, remember too that you'll never make all the devs happy.  it's a closed driver ;)
<tseliot> heh
<tseliot> mario_limonciell: it is also true that if a firm such as Dell needed this feature, I would give it more than a thought :-P
<mario_limonciell> haha
<mario_limonciell> well when we receive beta drivers from nvidia, it's easy enough to manually do these sorts of things
<tseliot> too bad ;)
<tseliot> ï»¿mario_limonciell: ok, problem solved with the packages. The files in /etc/default couldn't do anything bad but there was no need to keep them there.
<mario_limonciell> yeah
<mario_limonciell> well they were doing bad when i had init scripts sitting around still
<mario_limonciell> but since those are gone, they didn't do anything anymore
#ubuntu-x 2008-07-18
<pwnguin> oh this FAQ is hilarious
<pwnguin>  The fonts FontForge uses in its GUI are too small (too big) how do I change them?
<pwnguin>     The X server does not have a good idea about screen resolution, and when fontforge asks it, the answer is often wrong. The result is that ff may use fonts that are too small (potentially too big too, but no one has complained about that one yet). You can tell fontforge the true screen size by adding a line like
<pwnguin>         Gdraw.ScreenWidthInches: 14.7
<pwnguin>         Gdraw.ScreenWidthCentimeters: 37.3
<pwnguin>     to your ~/.Xdefaults file (The general mechanism is discussed on the X Resources page). If the GUI fonts are still too small you can lie about the screen size. If you claim the screen is smaller (in inches or centimeters) than it actually is, ff will use a bigger font. 
#ubuntu-x 2009-07-13
<Sarvatt_> doh! x11-server-utils 7.4+2 is already in karmic, was just those silly goobers using jaunty that had the problem.. no wonder i couldnt reproduce it :)
<ScottK> tseliot: I looked at your 112_add_movement_bottom_edge.patch and it doesn't apply cleanly to the Karmic package due to other code changes.  I was wondering if you'd be willing to update it for Karmic?
<tseliot> ScottK: I'm discussing upstream inclusion and I had to change that patch: http://bugs.freedesktop.org/show_bug.cgi?id=21613
<ubottu> Freedesktop bug 21613 in Input/synaptics "Property to make part of the touchpad insensitive to movements" [Enhancement,Assigned]
<tseliot> when the discussion is over, I'll port the patch to Karmic
<ScottK> tseliot: Great.  I'm very interested in seeing the 111 patch (made hardware specific) in Karmic too.
<tseliot> ScottK: I'll have to change that patch a bit but it shouldn't take long
<ScottK> tseliot: Thank you.  I think we are close to having very good in archive support for 10v in Karmic.
<tseliot> :-)
<jbarnes> bryce: do you file bugs upstream at fdo with a script?
<bryce> jbarnes, no
<jbarnes> oh well... was hoping it would be easy for you to change it to attach logs as text/plain
<jcristau> bugzilla should be smarter about this..
<jbarnes> yeah wish it was
<jbarnes> right now I get logs as text/x-log
<jbarnes> which makes ff open a new app
<bryce> yeah I could probably do better things if I had this scripted or something, but just havent figured out a good angle to do it
<bryce> launchpad often isn't too smart about attachment file types either
<jcristau> scripting bug forwarding sounds like a hard problem, given the amount of work needed to turn the average bug into something useful :/
<bryce> yup
<jbarnes> just need an AI
<bryce> jcristau, and then after doing all that work, upstream just marks it a dupe ;-)
<jcristau> yeah, that happens :)
<Sarvatt> ugggh got all this new stuff just to find out VDPAU sucks and cant handle subtitles (4TB of subtitled stuff on my HTPC), i should have gotten the 790GX motherboard instead of this 8200 one in that case
<bryce> that sucks
<Sarvatt> then again it seems nvidia is a little quicker about supporting newer kernels than fglrx :D
<bryce> yap
<RAOF> Could someone give the nouveau-kernel-source package in xorg-edgers/nouveau a bit of a review?  I'd like to push it to Universe, and there are a lot of packaging changes there; it'd be nice to have a second pair of eyes.
#ubuntu-x 2009-07-14
<RAOF> I'll push to lp:~xorg-edgers/nouveau/edgers-ppa-kernel-source, too.
<ripps> Sarvatt: you might want to try out coreavc and coreavc-for-linux. It's a codec that can use nvidia cuda to assist with decoding, it's much faster and more advanced than ffmpeg with h264, but it's not free and it requires installation through wine and then copying the codec and stuff to other dictories
<ripps> You'll probably have to patch and install software for it manually though, I think there's a patch for myth
<Sarvatt> it doesnt use the cuda libs right, i looked into that a few weeks ago
<Sarvatt> theres a seperate dll for the cuda acceleration in it that doesnt get used
<Sarvatt> i dont like myth at all, just threw vista (eww) back on it since i saw they added MPC-HC support to mediaportal that i've been using for years. cpu usage wasnt really a concern, the things plenty fast enough to play back the toughest interlaced 1080p 40mbit h264 stream i could find with ffmpeg though, coreavc was just at 40% cpu usage vs 70%. i'll just stick virtualbox on it again to run my irc bouncer and call it a day, its not like i
<Sarvatt>  ever see the OS on it :)
<Sarvatt> (~10% cpu usage with MPC-HC deinterlacing plus rendering the subtitles too)
<RAOF> bryce: Thanks for forwarding the intel bug.
<bryce> RAOF, np
<tseliot> ScottK: can you show me the output of dmesg | grep -i synaptics on your Dell mini 10v, please?
<ScottK> Sure
<ScottK> tseliot: [    6.993297] Synaptics Touchpad, model: 1, fw: 7.4, id: 0x1e0b1, caps: 0xd04711/0xa40000
<ScottK> [    7.080398] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input10
<tseliot> ScottK: perfect, thanks
<ScottK> Handy that I'm IRCing from it currently ....
<tseliot> heh
<apw> bryce, do we have any idea when ati support is expected in userspace?
<bryce> apw, hopefully soon; it should all be set up in xorg-edgers now for testing
<apw> excellent, so likely to make A4 ?
<bryce> I'd like to get it beat on a bit further to make sure everything's good to go
 * apw has an ati box which supports KMS so i'll try it out
<bryce> oh certainly by alpha-4
<bryce> yeah I probably should do a call for testing and re-do my testing with the latest stuff
<bryce> (been mostly focusing on -intel bugs lately)
<bryce> nice, ajaxy popups for setting status and importance in launchpad.
<superm1> ooo purdy indeed
#ubuntu-x 2009-07-15
<tanath> can anyone help me narrow down my graphics issue? i have graphical glitches that make it difficult to see anything
<tanath> came from a somewhat recent update. is a regression
<tanath> anyone? it's rather frustrating >_<
<RAOF> There we go.  Now with 2.6.31-compatible nouveau
<tseliot> tjaalton, jcristau: any ideas as to why X.org stops logging in Karmic? http://pastebin.ubuntu.com/218888/ 
<tseliot> and is there a way to restart logging?
<tseliot> if I create an xorg.conf with a Device section I can't reproduce the problem
<jcristau> tseliot: nothing in the gdm log?
<tseliot> I'll check that
<tormod> tseliot: it doesn't stop logging, it dies. check the gdm log also.
<tseliot> yes, I noticed that ;)
<tormod> yeah I though that would be hard to miss but since you asked :)
<Sarvatt> wow, good thing i didnt make your kernel last night tormod lol
<Sarvatt> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=drm-radeon-kms
<tormod> it's flooding
<Sarvatt> making it now, going to pull drm-next drm-fixes drm-radeon-kms and drm-intel-next into it so far at least :D
<tormod> sounds like a perfect edgy kernel :)
<Sarvatt> some time to go on vacation :)
<Sarvatt> i really should just make it off of the ubuntu kernel build system so we can upload it to a PPA...
<Sarvatt> hmm, pull everything into a branch off linus' tree, then cherry pick ubuntu sauce on top of it? i'm not sure how to manage it in git
<Sarvatt> imagine pulling in new stuff on top of ubuntu-karmic.git will screw up some of the sauce
<Sarvatt> too much to read up on now, i'll just use kernel-package again
<Sarvatt_> man, nouveau stinks :)
<Sarvatt_> Power usage (5 minute ACPI estimate) :  53.6 W (1.3 hours left)
<Sarvatt_> Power usage (5 minute ACPI estimate) :  69.5 W (1.0 hours left)
<Sarvatt_> LOL
<Sarvatt_> its like 15 with nvidia on this hp lappy.. wheres devicekit-backlight at? i miss brightness keys :D
<jcristau> it turns out using the power saving stuff from a card without any information about it is hard.  who would have thought.
<jcristau> :)
<Sarvatt_> well it sure isn't just powermizer missing at least, running it at full clock speed on the blob only shoots up around 21 watts 
<Sarvatt_> tormod: does your intel system you're testing the kernel on have ICH6 chipset?
<Sarvatt_> i want to start putting a patch back in to force it to SATA mode but dont want to screw your system up
<tormod> Sarvatt_: ICH6M Chipset, right on :)
<Sarvatt_> darn, would probably screw you up then
<Sarvatt_> http://sarvatt.com/downloads/patches/ich_force_ahci_mode.patch
<Sarvatt_> eww, segfault starting gedit..
<Sarvatt_> http://sarvatt.com/downloads/patches/ich_force_ahci_mode.patch
<tormod> Sarvatt_: I can check if it has any of the PCI IDs listed in that patch, but not now
<Sarvatt_> looking to see if theres a way to disable the quirks
<Sarvatt_> do you use an ide drive in it?
<Sarvatt_> eh i'll leave it out, other people were using it too no biggie.
<tormod> yes it has an ide drive
<Sarvatt_> ah yeah that patch will screw you up then
<tormod> do you know if the IDs in the patch are for the IDE controller or more probably the SATA AHCI controller? I am pretty sure this old machine does not have any sata controller
<Sarvatt_> they're odd, the pci id changes in ide or sata mode and that quirks it over into sata mode instead of ide
<Sarvatt_> hmm http://patchwork.kernel.org/patch/35295/
<Sarvatt_> he put my changes in there, not sure yet if this is going to fix it loading on non aspire ones though
<tormod> the "AO" check is still left out
<Sarvatt_> yeah looks like its still screwed up
<Sarvatt_> whats your acer's product tormod?
<aggie> hi
<aggie> uuuh I'm using ubuntu 9.04 it's beautifull as ever. But there's omething going on with my windows
<aggie> When I move them arround the have a delay
<aggie> like when you finish solitair in windows
<aggie> :)
<aggie> I have a Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset
<aggie> help!
<drvoodoo> hi, has anyone a solution for a very bad x-performance with kde4.2 and 4.3 and an ati mobility radeon 9000? have installed the radeon-driver from the x-updates ppas
<Ng> interesting situation in karmic atm
<Ng> KMS is so fast to bring the display back after suspend that X doesn't seem to have had time to bring the keyboard back
<Ng> I hear RH might have patches to help with this (so says Pete Graner)
<ScottK> My experience with KMS is my system won't boot at all, so you're at a level of refinement well beyond where I am.
<Ng> intel?
<ScottK> Yes.  I hear it'll be better after the next upload.
<Ng> ah right
<Ng> I've only used it so far on 965 and G45 and it's been kinda excellent on both
<ScottK> Mine is 945.
<RAOF> My G45 now actually drives the display correctly with the new kernel.
<ScottK> Maybe I'll give it another shot.
#ubuntu-x 2009-07-16
<Sarvatt> Ng are you using the 2.6.31-rc3 kernel?
<Ng> yup
<Sarvatt> input modules werent getting frozen on suspend and they were screwing up on resume beforee
<Sarvatt> why the heck is this high importance?!
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/399559
<ubottu> Ubuntu bug 399559 in xserver-xorg-video-ati "ATI Radeon Mobility KMS modeset=1 22% slower than vesa" [High,Incomplete]
<bryce> it could probably be reduced
<Ng> tjaalton did it an hour ago or so :)
<hyperair> isn't there something seriously wrong when any driver gets slower than vesa?
<hyperair> i mean all other drivers are supposed to have GPU-specific features which improve performance among other things, right?
<Sarvatt> i think the question is more, is there a card made in the past 10 years with a recent ddx that is faster than vesa at gtkperf?
<hyperair> O_o you mean vesa actually beats them all?
<hyperair> if that was the case then something should be done shouldn't there? like copying some code from vesa or something =\
<Sarvatt> how about, does gtkperf performance mean anything or is it glxgears for 2d? :D
<hyperair> ah. ._.
<Ng> glxgears isn't a useful test of anything, gtkperf tests the performance of rendering gtk widgets, which is something that desktops do do, right? :)
<Ng> it's just not something they do in tight loops
<jcristau> hyperair: if you accelerate some stuff, but not everything, you sometimes have fallbacks.  and falling back once in a while is enough to make performance worse than an all-software thing.
<hyperair> i see
<hyperair> that maketh much sense.
<Sarvatt> http://global.phoronix-test-suite.com/index.php?k=profile&u=robert-14462-8152-19051
<Sarvatt> yay my radio button speed is going down! :D
<apw> Sarvatt, do we expect xrandr to work with kms?
<Sarvatt> yep, not working for you?
<apw> not sure.  ran tremulous and it left me in 640x480
<apw> i uses xrandr to go to 1024x768
<apw> and once there i could not change again
<Sarvatt> intel or radeon?
<apw> intel
<Sarvatt> downloading it now to see if it happens to me
<apw> i guess i should try changing now, see if its a general issue or not
<Sarvatt> worked fine here, thats odd
<apw> hrm ...
<apw> yeah switching back and forth seems to work
<apw> apw@dm$ xrandr -q
<apw> xrandr: output LVDS1 cannot use rotation "normal" reflection "none"
<Sarvatt> i didnt do anything, just started it and it went to 640x480 then joined a game and quit and it went back to 1024x600
<apw> what does that mean?
<jcristau> i think it means the driver is confused
<jcristau> :)
<apw> i just ran extreme tux racer and on quit i am in some other mode, not the one i am meant to be in
<Sarvatt> robert@ubuntu-9{/opt/source/xorg-pkg-tools}:xrandr -q
<Sarvatt> xrandr: output LVDS1 cannot use rotation "normal" reflection "none"
<apw> and am getting that poop
<Sarvatt> dunno but I get it too! lol
<apw> and now i can't fix it
<apw> anything i can collect before i logout
<Sarvatt> apw: just apply the settings in display properties
<Sarvatt> resets it
<Sarvatt> i didnt change anything, just applied it and its working right again
<apw> ok HOW did it do it when xrandr cannot!
<Sarvatt> just hit another bug like that, xrandr command line tool wasnt in sync with the server changes
<Sarvatt> guess theres no reflection property in KMS and the game sets the value on exit and confuses xrandr?
 * Sarvatt has no idea
<apw> Sarvatt, must be something like that
<apw> Sarvatt, when i VT swtich back to X under KMS the screen comes back nice and fast, all there, and then X redraws it all and it all flashes nastily, is that nromal
<Sarvatt> i get that too, guess its normal
<Sarvatt> it used to be alot worse, VT>X would change modes in 1.6.0 even under KMS
<Solarion> any idea why karmic gdm just keeps cycling instead of actually coming up?
<bryce> Solarion, check your gdm logs
<fishor> hallo all, did any one has some problem with tadays intel driver on gm915 graphic? xorg on my latop goin to resart loop.  workaround is to install oder one.
<fishor> s/oder/older/
<jbarnes> Sarvatt: libdrm 2.4.12?
<Sarvatt> havent updated it because it was just a version bump with no changes since the last one. will do it in a bit, in the middle of setting up a pc now
<jbarnes> cool
<jbarnes> it has a big bo cache fix
<jbarnes> which should keep gem object usage waaaay lower than it is today
<Sarvatt> already got that commit in there
<Sarvatt> and its super nice!
<Sarvatt> 71MB gem_objects, 3 days uptime with compiz :D
<jbarnes> cool
<Sarvatt> phew, took 2.5 hours to set up a second stage debootstrap of arm karmic on my G1
<Sarvatt> beat qemu by 2 hours at least
<Sarvatt> now to compile pixman for no reason
<bryce> amazingly, I've almost made it through all the -intel bugs for the first time in a long long time
<bryce> just 15 bugs left to upstream
<jcristau> can i get a clone of Sarvatt for debian?
<Sarvatt> what do you mean? i doubt i packaged it right, i am still very new to things but heres the changelog https://edge.launchpad.net/~sarvatt/+archive/xorg-testing/+sourcepub/676434/+listing-archive-extra
<Sarvatt> dreading packaging all these changes for xserver master in the past few days :(
<Sarvatt> yuck, looks like it'll take another 2-3 hours to bring in the build deps for it :D
<jcristau> hehe
<Sarvatt> you're a monster bryce, thats so many bugs!
 * bryce wields broom of bug death
<Sarvatt> ugh, i dont even know where to start. inputproto libxi libX11 xextproto libXext fixesproto libXtst renderproto and still have to rebuild all video drivers except vesa intel and ati. whee! :)
<Sarvatt> server 1.6 branch is begging for me to come back to it :)
<Sarvatt> i should have just done this in a debian chroot, for some reason karmic is super slow unpacking things on arm
#ubuntu-x 2009-07-17
<Sarvatt> then again it was lenny that only takes 15 minutes compared to the 3 hours, would probably have the same slowdown on a newer debian if its in dpkg or something
<Sarvatt> oookay protos updated, will have to dig into the libs tomorrow.
<Sarvatt> whats x11proto in debian terms? dont tell me x11proto-x11proto
<Sarvatt> ahh x11proto-core
<jcristau> yup
<Sarvatt> doesnt look important, all the changes are for other platforms.. guess i can skip that one
<Sarvatt> ah heck missed that fixes had an epoch
<Sarvatt> hmm, i dont understand the whole xextproto/libxext change
<Sarvatt> guess i should be installing usr/include/X11/extensions/* in libxext-dev now, but looking at it it looks like they split up the xextproto headers into smaller files and install them through libxext now, so should I be not installing the headers in x11proto-xext?
<jcristau> there's 3 parts for each extension
<jcristau> the protocol constants, the protocol data structures, and the client side function prototypes and data structures
<jcristau> previously all of them were together in the same header, with ifdefs to avoid pulling in the client side stuff in the server
<jcristau> now peter separated it all up properly, and moved the client side stuff to libxext
<Sarvatt> http://sarvatt.com/downloads/headers.txt
<Sarvatt> ah so both should be installing usr/include/X11/extensions/ then?
<jcristau> yes
<jcristau> libxext-dev will need Replaces: x11proto-xext-dev (<< something), but that should be it
<Sarvatt> thanks a bunch for the clarification
<jcristau> np
<Sarvatt> hmm, dont see any versioned dependencies on libx11, that is one nasty package i might skip :)
<Sarvatt> bah thought so, [x11 >= 1.2.99.1] in evdev
<jcristau> libxi probably wants the new libx11
<Sarvatt> oops yeah i meant libxi, i saw whot's post about the cookie stuff
<Sarvatt> that nokia guy really wants to break non embedded platforms huh? :D
<Sarvatt> anyone else interested on working on xorg 7.5 packaging at all? i'll move this over to xorg-edgers team if so, it could use someone who actually knows what their doing giving it a once over because I have a feeling I'm being really sloppy about some things in regards to the control handling. i'm just packaging it for my own use where I know what needs to be done manually
<Sarvatt> hmm i think i'll look into extending auto-xorg-git to parse PKG_CHECK_MODULES in configure.ac to bump build depends automatically tomorrow
<Sarvatt> 003_recognize_glibc_2.3.2_locale_names.diff in libx11 is one _monster_ of a patch
<Sarvatt> 11/49 hunks failed, i'll have to go over it tomorrow
<FaberfoX> Hi guys, can someone point me on the right direction to get mesa 7.4.1 for jaunty? This is regarding launchpad #360319. Do I have to compile all of x to get that released fix?
<ubottu> Launchpad bug 360319 in xserver-xorg-video-intel "[GM45] memory leak causes system to run out of memory (UXA/EXA)" [High,Fix released] https://launchpad.net/bugs/360319
<Sarvatt> 2.7.1+exa should be fine, its uxa that needs the mesa fix and theres alot more needed besides mesa to have uxa stable in jaunty
<Sarvatt> more than would be possible to provide in jaunty-updates, karmic is the way to go if you want to use UXA. or you can use this PPA https://launchpad.net/~xorg-edgers/+archive/ppa
<Sarvatt> darnit, spent 3 hours refreshing 003_recognize_glibc_2.3.2_locale_names.diff but i got the offsets wrong
<Sarvatt> need some kind of patch cleanup tool or else i'll be screwing with the offsets for another hour lol
<FaberfoX> thanks Sarvatt, I'll try xorg-edgers first and then do a parallel karmic install, I tried karmic about a month ago and wasn't too happy, but in a month there's so much that changes
 * Duke` hope that the last xserver-xorg-video-intel works... :p
<tjaalton> Sarvatt_: I'll start updating the debian-experimental branches once I get back home a week and a half from now
<moxo> hi! I've installed a PPA for xorg some weeks ago. now my update manager wants to update X11. will my manually installed PPA get lost once I let the update manager update xorg?
<Sarvatt_> lol think I set a new record for being slow, i thought you were asking for a clone of pixman 0.15.17 for debian last night jcristau :)
<Sarvatt_> odd, libx11 took 8 minutes to build on lpia but its going on 40 minutes on i386
<Sarvatt_> ugh, hitting this problem now http://lists.x.org/archives/xorg/2009-July/046480.html
<Sarvatt_> libxext failed to build because it needs the headers that moved from inputproto to libxi, but libxi requires this newer libxext to build
<Sarvatt_> hmm wonder if i can add libxi (>= 1.2.99.1) to the build depends for libxext to get around it, i dont know if that will break something
<Sarvatt_> guess i can do that, then build the newer libxi, and then rebuild libxext again against the newer libxi
#ubuntu-x 2009-07-18
<Sarvatt> neat, r600/r700 dri in mesa now, time to update the build rules to add it
<Sarvatt> hope they fixed it to build when libdrm-radeon1 is around
<bryce> Sarvatt, kewl
<Sarvatt> i'm scared to reboot with all these changes in the past day :D https://edge.launchpad.net/~sarvatt/+archive/xorg-testing
 * Ng wonders if any other intel karmic users sometimes lose the animated/spinny busy pointer
<RAOF> Not I.
<Sarvatt> yep Ng :)
<Sarvatt> problems been around since january when i started using KMS here
<Ng> aha
<Ng> I should hunt for a bug then :)
<Sarvatt> http://lists.freedesktop.org/archives/intel-gfx/2009-May/002433.html
<Sarvatt> that patch works to get rid of it for the most part, but theres still the corruption interruptions of the animation that were there even without KMS
<Sarvatt> i stopped including it on edgers because it wasnt worth the time reenabling the patch system every build for such a minor cosmetic fix
<proppy> Hi, which version of mesa ships with http://sarvatt.com/downloads/xorg-edgers-0.16-i386.iso ?
#ubuntu-x 2009-07-19
<Ng> would we expect 32bit games to work on intel on 64bit?
<Ng> (wrt http://www.linuxgamepublishing.com/faq.php?id=35&#faq_4_3 question 4.3)
<Ng> hmm, possibly a lack of direct rendering across CPU architectures?
<tanath> can anyone help me troubleshoot graphical glitches?
<MT-> I confirmed a bug in the mouse pointer and would like to know what package it should be assigned to and what user if possible
<jander99> Hello. Would anyone be available to help me with a bug I'm triaging?
<micahg> anyone have a couple minutes to look at a weird bug?
<micahg> bug 129702
<ubottu> Launchpad bug 129702 in dmz-cursor-theme ""Loading" mouse pointer's hotspot is off" [Undecided,New] https://launchpad.net/bugs/129702
 * andresmujica takes  a seat
<micahg> we've been chatting about it in ubuntu-bugs
<micahg> and it seems to be more of an X issue, but we're not sure
<micahg> could one of the experts take a peek?
<MT-> kees: you available? :D
#ubuntu-x 2010-07-19
<bryceh> tjaalton, dunno
<tjaalton> bryceh: ah, some mistake then
<bjsnider> wonder when they're going to add some additional amd64 ppa builders
<bryceh> tjaalton, oh figured out, that was in my xchat scroll buffer on a laptop I hadn't used since UDS in belgium
<bryceh> tjaalton, you'd asked me something about BEL at the time
<tjaalton> bryceh: haha, okay :)
<ScottK> I'd appreciate feedback on getting the proposed fix for Bug #569879 in for 10.04.1.  It seems to solve the problem here.
<ubot4> Launchpad bug 569879 in xserver-xorg-video-intel (Ubuntu Lucid) (and 1 other project) "Non-admin user logout fails on Lucid (affects: 8) (heat: 56)" [High,Confirmed] https://launchpad.net/bugs/569879
<jcristau> sounds reasonable
<ScottK> bryceh: Any objections if I upload it for an SRU of xorg-server?
<RAOF> ScottK: Were you perhaps after me?
<ScottK> RAOF: I was, but I'd forgotten.  Sorry.
<RAOF> ScottK: I have no objections.
<ScottK> RAOF: Thanks.  I'll try to get that up in the next day or two.
<jcristau> maybe i should get that patch in 1.7-branch upstream
<Sarvatt> funny, I thought the same thing regarding that commit a few months ago :) https://edge.launchpad.net/~sarvatt/+archive/bugsbugsbugs/+packages
<Sarvatt> but it didn't fix the problem in the guy i was helping's case
<bryceh> ScottK, yeah coordinate thru raof
<RAOF> Sarvatt: How much do we still need the disable-pageflipping patch with 2.12 & 2.6.35-rc5?
<Sarvatt> i dont need it at all on 945 anymore at least
<RAOF> And all the upstream bugs mentioned in the patch seem to be closed, too.
<Darxus> What needs to be done to get the bug #541492 fixes into Lucid and Maverick?  
<ubot4> Launchpad bug 541492 in xserver-xorg-video-intel (Ubuntu Lucid) (and 2 other projects) "MASTER: [i845] GPU lockup (apport-crash) (Should KMS be blacklisted?) (affects: 78) (dups: 30) (heat: 523)" [High,Triaged] https://launchpad.net/bugs/541492
<alkisg> Hi, I'm having complete hangs (so no logs at all) on my nvidia 8600m based laptop, and I'd like to try some newer nvidia drivers to see if they fix the problem. Are they available in some ppa, or is my only option to install the drivers from their site?
<alkisg> Ah, I just found 256.35-0ubuntu2~xup2 in https://launchpad.net/~ubuntu-x-swat/+archive/x-updates, I guess I'll use those...
<tomus> Hello. I would like to upload python-pyopencl into Ubuntu, and this package depends on files contained in nvidia-common and nvidia-current-dev (build-dep).
<Sarvatt> will probably be tricky until nvidia-current-dev is split off into another package since the opencl stuff is installed to a nonstandard location with no .pc
<bjsnider> tomus, it depends on the opencl headers?
<tomus> Yes. I had to add parameter to ./configure pointing to /usr/linclude/nvidia-current to be able to build on Ubuntu, but it builds succesfully.
<tomus> There are maybe four lines of difference between Debian and Ubuntu files.
<bjsnider> i imagine the opencl headers will be in their own separate package at some point in the distant future
<tomus> OK. Good to know.
<tomus> For now few people ask me about creating Ubuntu package. I would like to create PPA on launchpad, experiment there a little and then ask someone to sponsor package. Is that OK?
<tomus> On #debian-ubuntu I was advised to fill sync request - is in neccessary?
<Sarvatt> you need to merge it instead of syncing since it needs ubuntu specific changes, #ubuntu-motu is the place to go about getting it into ubuntu
<tomus> Thanks for information.
#ubuntu-x 2010-07-20
<RAOF> Sarvatt: You here, dude?  Have you seen terrible performance on nvidia *and* nouveau recently?  Like really horrible cairo rendering speed and slowish text rendering?
<Vi0L0> hi, which xserver version will 10.10 use? :)
<Vi0L0> @ www i can see that 10.10 is now using xserver 1.8, but maybe there are chances for xserver 1.9? :)
<ginggs> hi - I'm looking for someone to open the lucid task on the following bug please?
<ginggs> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/553415
<ubot4> Launchpad bug 553415 in xorg-server (Ubuntu) (and 2 other projects) "mouse trapped in box for Open Motif (affects: 24) (dups: 3) (heat: 107)" [Undecided,Fix released]
<jcristau> why am i not surprised how much of a mess that bug is..
<jcristau> RAOF: ginggs was asking about bug 553415 for lucid, which apparently needs e7154e9375e6b624db01a787d9ec6c8cedc2eb81 from 1.7.6.901 cherry-picked
<ubot4> Launchpad bug 553415 in xorg-server (Ubuntu) (and 2 other projects) "mouse trapped in box for Open Motif (affects: 24) (dups: 3) (heat: 107)" [Undecided,Fix released] https://launchpad.net/bugs/553415
<RAOF> jcristau: Thanks.
<RAOF> Hm.  I think it actually wants 1c612acca8568fcdf9761d23f112adaf4d496f1b to be cherry-picked, as the original patch got reverted.
<jcristau> e7154e9375e6b624db01a787d9ec6c8cedc2eb81 is 1.7-branch's cherry-pick of 1c612acca8568fcdf9761d23f112adaf4d496f1b :)
<RAOF> Aah, ok.
<ginggs> I have another request too, if I may: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/589250
<ubot4> Launchpad bug 589250 in nvidia-graphics-drivers (Ubuntu) (and 1 other project) "Unable to resolve function glX... (affects: 2) (heat: 86)" [Undecided,New]
<ginggs> relating to the removal of /usr/lib/libGL.so.1 in lucid
<jcristau> that's not a request..
<ginggs> I work at a university and spend many hours trying to get commercial packages to work in Ubuntu
<jcristau> that's a bug in the software you're using
<ginggs> well my request is how to proceed with this
<RAOF> You can work around it by providing that symlink.
<RAOF> We can't provide that symlink without breaking other stuff.
<ginggs> yes, i realize the problem is the path is hard-coded in the application, but these are the kind of vendors whose standard answer is use RHEL or SLED or don't talk to us.
<ginggs> you have answered my question, thanks
<RAOF> It will be safe for you to add that symlink.
<ginggs> thanks RAOF and jcristau, i'm out of here
<Sarvatt> RAOF: nope, what kind of environment are you seeing it on? lucid+nouveau+xorg-edgers is fine
<ricotz> RAOF, Sarvatt, i think i can confirm this cairo slowness using docky with maverick+nouveau+xorg-edgers
<Sarvatt> how about without docky and without compositing?
<Sarvatt> oh i have metacity compositing on there
<ricotz> Sarvatt, what are you using to test the cairo "speed"? I just notice some bumpy transitions in docky
<Sarvatt> everyday use
<Sarvatt> my wife uses that laptop all the time and i'm always screwing with it, would have noticed it slow down
<ricotz> it isnt noticable in everyday use for me
<ricotz> inkscape seems to suffer a lot
<Sarvatt> RAOF: what's slow?
<Sarvatt> i was assuming he meant firefox and gtk stuff
<ricotz> Sarvatt, perhaps he meant gnome-do
<ricotz> i can confirm DO it is very slow
<seb128> ricotz, hey
<seb128> ricotz, didn't you have gnome-shell changes in your ppa to workaround libmozjs issues?
<seb128> ricotz, I've diffed the rules with maverick but it seems it has no workaround
<ricotz> seb128, hi, havent i gave you the patch in a pastebin
<ricotz> seb128, the patch is included in the tarball to workarround the need of an autoreconf
<seb128> ricotz, right, but I was busy and I didn't note it, and I'm wondering how it built in your ppa without those changes
<seb128> ricotz, oh ok
<seb128> I though it was a debian/rules change
<seb128> thanks
<ricotz> seb128, have you looked into gdkpixbuf2.0 and gtk+3.0 packaging?
<seb128> sort of
<ricotz> ok
<ricotz> seb128, what version of g-s do you want to package?
<ricotz> seb128, only 2.31.4 will work, 2.31.5 needs gtk3 and mutter compiled against gtk3
<RAOF> Sarvatt: Summon gnome-do, type anything.  Watch the animation take > 5 seconds before Do is responsive again.
<RAOF> Sarvatt: Also, text rendering in gnome-terminal.
<seb128> ricotz, what debian has, it's a direct sync
<RAOF> Sarvatt: maverick / {xorg-edgers,main archive} / 9300 GS
<seb128> ricotz, gdk-pixbuf
<seb128> ricotz, it's in the pkg-gnome svn
<seb128> work in progress though
<seb128> it needs extra changes
<RAOF> Sarvatt: Aaaaand it's time for beer.  Sorry!
<ricotz> seb128, can you give me a direct link to this gdk-pixbuf svn?
<seb128> robert_ancell is working on update gtk now
<Sarvatt> gnome-terminal is fine here, sounds like gnome-do is doing something bad with cairo
<seb128> ricotz, http://pkg-gnome.alioth.debian.org/svn.html
<ricotz> seb128, thanks
<seb128> ricotz, it's in desktop, experimental, gdk-pixbuf
<Sarvatt> well does it only happen with nvidia machines + gnome-do?
<seb128> http://svn.debian.org/viewsvn/pkg-gnome/desktop/experimental/gdk-pixbuf/
<seb128> ricotz, ^
 * Sarvatt doesn't use it
<ricotz> Sarvatt, might be the case, so it could be a nouveau/mesa problem
<ricotz> seb128, thanks, i will have a look
<Sarvatt> metacity compositing would rule out mesa at least, i can't steal the machine from the wife at the moment to test it :)
<Sarvatt> trying it out on intel now, lessee
<ricotz> Sarvatt, ok
<Sarvatt> instant on intel+edgers+maverick
<Sarvatt> any of you guys gotten a profile of it?
<Sarvatt> go figure oprofile is busted because of binutils yet again :)
<Sarvatt> it is spending most of its time in cairo though
<Sarvatt> crap updated that machine to the ia32-libs in edgers, is that still broken with flash?
<ricotz> Sarvatt, they should work 
<ricotz> are you going to update the mesa packaging to provide this "dri-experimental" package?
<Sarvatt> ah ok, wife's gonna complain otherwise :) btw if you want a sysprof that works to see where its spending its time on nouveau i've got one in here - https://edge.launchpad.net/~sarvatt/+archive/ppa
<Sarvatt> one day.. probably not until 7.9 branches
<ricotz> Sarvatt, flash stuff is working here without problems, didnt hear any comlains lately :P
<ricotz> complains*
<ricotz> ok
<Sarvatt> yeah it was lucid that had the problem though, i've got that machine on lucid so she doesn't have to go through the plymouth hell we're going through again because that put her off ubuntu last time :)
<ricotz> ok, so you might want to test it while you already installed it ;)
<Sarvatt> yay i love when 003_recognize_glibc_2.3.2_locale_names.diff in libx11 needs refreshing :)
<Sarvatt> any specific gnome-do plugins that you guys are using over stock to make it slow maybe?
<jcristau> Sarvatt: if somebody upstreams that patch i'll owe him a lot of beer
<Sarvatt> did some of it already get upstream? it seems a lot smaller than it used to be
<Sarvatt> luckily it was just the cvs tag purge, just had to remove 2 lines and adjust the first hunk
<Sarvatt> ricotz: any specific gnome-do plugins that you guys are using over stock to make it slow maybe?
<ricotz> Sarvatt, it is not related to any plugin, you can literally see the drawing of the svg icons
#ubuntu-x 2010-07-21
<bjsnider> how do you write the control file so that x264-102 forces out x264-xxx where xxx is less than 102?
<bjsnider> would Depends: libx264-102 (<< ${binary:Version}) do it?
<bjsnider> i mean conflicts, not depends
<jcristau> bjsnider: normally you don't do that.
<toabctl> i have a bamboo fun cth 661 which is not recognized with ubuntu maverick.
<toabctl> when i plugin, syslog says: Jul 21 12:34:19 zitrone kernel: [ 2009.316083] usb 3-1: new full speed USB device using uhci_hcd and address 5
<toabctl> i loaded the wacom kernel module (modprobe wacom). $ lsmod |grep wacom
<toabctl> wacom                  26204  0 
<toabctl> any ideas?
<tjaalton> is it a real wacom brand device, or an oem one?
<tjaalton> ah, so it's a pen&touch model, no support for it yet then
<bigon> In dmesg I get "You have old & broken userspace please consider updating mesa" under maverick, is that know or should I open a bug?
<jcristau> bigon: it's known
<bigon> I've just opened a bug :x
<RAOF> Anyone running Lucid on i386 with an intel GPU?
<RAOF> I'd like to check that https://edge.launchpad.net/~raof/+archive/aubergine/+packages works before pointing everyone with broken i855 at it for testing.
<ScottK> RAOF: I've got an i865 machine that is currently working not too bad.  As long as there's a clear path back to the current packages, I can test that.
<RAOF> Excellent.
<ScottK> RAOF: The xorg-server change we discussed is uploaded too.
<RAOF> I noticed.  Thanks.
<RAOF> So, the path back would be either (a) manually downgrade xserver-xorg-video-intel & libdrm*, or (b) use ppa-purge to do that automatically.
<ScottK> OK.  How urgent is this?
<ScottK> Is this aimed at 10.04.1?
<RAOF> It's not.
<RAOF> It won't hit 10.04.1; it's too big a change (basically grafting a whole new driver into -intel)
<RAOF> But it needs testing so that I can push for it to be merged to -intel mainline, so that it can work in Maverick.
<ScottK> OK.  So if I don't get to it until Friday, it's not critical?
<ScottK> I'm glad you aren't pushing it for 10.04.1.
<RAOF> It's not critical.
<ScottK> OK.  I'll try to carve out some time then.
<RAOF> Whenever you've got a lazy hour.
<RAOF> Thanks.
<kees> RAOF: turned out to be a bug in the recent debian merge.  the ubuntu udev rules was subtly more correct than the debian one.
<RAOF> kees: GAH!  I stared at that merge.
<RAOF> (At the time, not just now)
<jcristau> what's wrong with our udev rules? :)
<kees> RAOF: heh, me too.  I looked at the old udev rules and was all "oh, these are the same"  :P
<kees> jcristau: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589847
<ubot4> Debian bug 589847 in xf86-input-wacom "internal serial wacom devices ignored" [Normal,Open]
<RAOF> We might as well also grab the new 0.10.7 release.
<jcristau> oh, wacom.
<kees> jcristau: heh
<jcristau> not my fault then \o/
<RAOF> Yah.  One of the annoying non-xsfbs X packages :/
<RAOF> Is there a release schedule for mesa somewhere?
<jcristau> not that i know of
<RAOF> Apart from âquarterlyâ.
<Sarvatt> RAOF: can ya bring up the modular agp problem at the sprint if you get a chance? :)
<RAOF> Sarvatt: Yes!
<RAOF> I've already got vga16fb handled.
<Sarvatt> just in time for the switch away from vga16fb to vesafb huh? :)
<RAOF> No - currently vga16fb *and* veasafb is loading.
<Sarvatt> blacklisting vga16fb isthe first thing i do on all of my machines so i didn't notice :)
<RAOF> We've dropped the patch which made vga16fb fail to bind if there was already a framebuffer driver.
<RAOF> So now there's /dev/fb1 driven by vga16fb waiting for the unwary to trigger it.
<Sarvatt> probably should drop the patch making vga16fb load for all vga pci devices too from last december
<Sarvatt> darnit, ati stopped building oddly, it failed on amd64 on both maverick and lucid last upload, now this upload it only failed on maverick but on both i386+amd64. http://launchpadlibrarian.net/52240157/buildlog_ubuntu-maverick-i386.xserver-xorg-video-ati_1:6.13.99%2Bgit20100720.593eff29-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz
<RAOF> Sarvatt: Yup, that's what's going to happen - we'll drop the âbind to everythingâ patch.
<Sarvatt> oh bah i forgot to add x11proto-xinerama-dev to xserver-xorg-dev last time i updated it
<bryceh> RAOF, how's the sprint going so far?
<gtaylor> Hate to ask such a basic question, but does adding the stable ubuntu-x-swat and updating allow you to install Catalsyt 10.6 drivers from Jockey?
<gtaylor> Or the command line for that matter. Just not sure what version of the drivers ubuntu-x-swat stable is on.
<Sarvatt> yeah catalyst 10.6 is in there, but it'll require running aticonfig --initial after installing it
#ubuntu-x 2010-07-22
<bjsnider> Sarvatt, is the nvidia-current in x-updates the maverick one backported?
<Sarvatt> yep, same thing
<bjsnider> the newest version
<bjsnider> with the 32-bit compat stuff fixed
<RAOF> Sarvatt: GAH! Where's that agp bug, so I can scream at the kernel team?
<bryceh> RAOF, how's the sprint going so far?
<RAOF> bryceh: Pretty good - the arm guys want to pick my brains lots.
<bryceh> yeah
<RAOF> It's nice to be able to stroll down the hall and poke the kernel guys, too :)
<bryceh> are they still asking about how to implement 3D X drivers on top of their proprietary opengl es stacks?
<RAOF> They're working out precisely where the proprietary interface should be, yeah.
<bryceh> yeah
<RAOF> The existance of a blob seems pretty non-negotiable at this point.
<bryceh> I hope you have more luck with them than I did
<bryceh> it seemed they had gotten themselves into sort of an untenable position
<bryceh> they need a 3d-enabled framebuffer driver but want to do it atop proprietary hardware/firmware gles
<bryceh> and would like to achieve it without investing much manpower into development I guess
<bryceh> maybe the new non-profit entity will give them a better opportunity to achieve that
<RAOF> It looks like things may be moving forward.
<bryceh> ah good
<bryceh> RAOF, btw, I was working on those radeon/linux/mesa reports we had talked about at uds
<bryceh> still WIPish but - http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/all-radeon-bugs.html
<tjaalton> if the rest of the community has failed at that, I'm skeptical that RAOF would succeed ;)
<tjaalton> man, im slow
<bryceh> there are also intel and nouveau reports there, but less interesting.
<bryceh> I'm going to split them into 'lucid' and 'maverick' reports... does that work?
<RAOF> That would be good, yeah.
<bryceh> the maverick reports are going to be pretty much empty
<bryceh> but I figure those are the ones you care about.  The plus side is they'll be so short it'll be easy to clear them
<RAOF> :)
<tjaalton> (s/raof/any single person/)
<bryceh> problem is I'm having to depend on having the linux/mesa bugs tagged as 'radeon', 'nouveau', or 'intel', and it's not common that those tags get applied
<bryceh> but that's probably a solvable problem
<RAOF> I've talked to the kernel guys about that tagging.
<bryceh> so yeah, I'll set these reports up with that assumption, and if they're useful you can lobby for getting the driver tags applied where appropriate
<RAOF> Great.
<bryceh> I noticed for the kernel, the 'intel' tag is also used for some wireless drivers and so on, not just graphics
<bryceh> but it's pretty obvious
<RAOF> The kernel guys aren't applying that tag.
<bryceh> ok, it was only maybe 2-3 bugs, so perhaps just end users tagging them
<RAOF> It probably is, yeah.
<RAOF> We will be applying tags.  Until launchpad grows the ability to search by pciid :)
<Sarvatt> RAOF: looks like mesa 7.9 might not release until intel Q3 comes out..
<RAOF> :/
<Sarvatt> sometime in october most likely
<RAOF> AKA: too goddamned late.
<Sarvatt> yeah :(
<Sarvatt> well there will be RC's out before then, could just go with the latest RC
<Sarvatt> probably wont get an RC until september though when they merge in the new glsl2 stuff
<RAOF> Right.
<RAOF> I'm actually going to give a built of that to the DX guys, because they've had problems with the GLSL complier in the past.
<Sarvatt> i'll upload that for ya in a minute, its building
<RAOF> Sarvatt: You're doing that?  Awesomesauce.
<Sarvatt> well it'll have xorg-edgers mesa packaging not whats in ubuntu :(
<Sarvatt> no egl and stuff
<RAOF> Hm.
<Sarvatt> i've been holding off updating it since i dont have the cpu cycles to work out all the egl and gles changes, darn atom
<RAOF> Where's your auto-xorg stuff ending up?
<Sarvatt> uploaded it https://launchpad.net/~sarvatt/+archive/xorg-testing
<RAOF> I'll see how much they care about gles.
<Sarvatt> actually that builds against edgers
<Sarvatt> i'll put it in sarvatt/ppa
<BlackZ> Sarvatt: do you have some time to talk about ppa-purge ? 
<Sarvatt> what's up?
<BlackZ> Sarvatt: nothing, I'd like to do few questions - pm?
<BlackZ> I don't think this is the right channel 
<Sarvatt> bryceh: was anything happening with the ppa-purge merge request? BlackZ wants to put it in universe
<BlackZ> Sarvatt: merge? 
<BlackZ> do you mean in bzr? 
<Sarvatt> he was looking into renaming it rm-apt-repository and adding it to the package add-apt-repository is in
<BlackZ> Sarvatt: BTW I think we should really do it a native ubuntu package 
<BlackZ> but I'm not sure yet
<BlackZ> a thing is sure: we can't get it in debian directly, because debian does not support PPAs 
<Sarvatt> it already is, theres no - and no tarball?
<Sarvatt> doesn't make sense in debian at all
<BlackZ> Sarvatt: ok, so if you're confirming me that I will consider for do that a native ubuntu package in universe :) 
<BlackZ> Sarvatt: I don't think it should be native; if there's upstream it should not be native: in the native packages normally releases are done with an upload in the ubuntu archive
<RAOF> BlackZ: The correct question for native is âDoes this package make sense for anything but Ubunt(/Debian)â.  The answer for ppa-purge is ânoâ, so it should be native.
<BlackZ> RAOF: right 
<RAOF> So, it should be native.
<BlackZ> RAOF: sorry, I misunderstood some things related to the package 
<BlackZ> I checked and yes, it should be native
<bjsnider> tseliot, http://github.com/tseliot/nvidia-graphics-drivers/blob/master/debian/nvidia-current.dirs.in lines 3 and 8 are duplicates
<tseliot> bjsnider: good point
<vish> hmm , whats up with Bug #465868  ?  seems to have stalled after being assigned to lucid a2
<ubot4> Launchpad bug 465868 in checkbox (Ubuntu) "checkbox should not run on nvidia (was: appearing error message extension "RANDR" missing on display ":0.0".) (affects: 2) (heat: 15)" [Critical,Incomplete] https://launchpad.net/bugs/465868
#ubuntu-x 2010-07-23
<Sarvatt> this looks real promising - https://bugs.freedesktop.org/show_bug.cgi?id=26980#c25 :(
<ubot4> Freedesktop bug 26980 in Driver/nouveau "GT230M or GT218 with nouveau: X server hangs spontaneously" [Normal,New]
<hyperair> Sarvatt: mesa 7.9.0+git20100722.c686ee0f-0ubuntu0sarvatt~lucid has some rather interesting effects with compiz on. it seems that the windows just don't update.
<RAOF> hyperair: Yeah, and it has a tendency to crash X on radeon.
<hyperair> RAOF: ooh fun.
<RAOF> Although that's the same with 7.8.1.
<hyperair> heh
<Sarvatt> same here hyperair 
<Sarvatt> tried 723 yet?
<Sarvatt> 20100723 is fine here, guess it was the glx locking stuff
<hyperair> Sarvatt: hmm no i haven't.
#ubuntu-x 2010-07-24
<Sarvatt> darn, that guy that uploaded ppa-purge to universe versioned it goofy and it wont get upgraded
<Sarvatt> oh you silly launchpad.. Rejected:
<Sarvatt> mesa_7.9.0+git20100723.80b331c7-0ubuntu0sarvatt.dsc: Version older than that in the archive. 7.9.0+git20100723.80b331c7-0ubuntu0sarvatt <= 7.9.0+git20100723.2299ff4c-0ubuntu0sarvatt
<hyperair> Sarvatt: with 723, compiz doesn't even start.
<Sarvatt> hyperair: 0724 uploaded with a ton of glx fixes
<BlackZ> Sarvatt: I proposed the branch, did you see? 
<hyperair> Sarvatt: okay, i'll give that a go
<Sarvatt> yeah, only reason I haven't merged it yet is i'm not sure about the changelog, any reason you dropped all the versions and redid it as 0+bzr46 so it wont upgrade?
<Sarvatt> sorry i haven't replied yet, I just woke up
<BlackZ> Sarvatt: 0 because your currently version is 0.2.6; bzr46 is the bzr branch I worked on for do the ubuntu package; and 1 are my changes 
<BlackZ> Sarvatt: BTW yeah, I told you I proposed the branch in pm (11:43 am about) 
<BlackZ> (local time where I live) 
<Sarvatt> approved it, not sure if i need to merge it manually also or if it automatically merges eventually though. would you mind bumping the version to 0.2.7+bzrwhatever whenever its uploaded again so people with it currently installed get updated?
<Sarvatt> or even 1+bzr or something
<Sarvatt> ah it says what i need to do now
<BlackZ> Sarvatt: I could yes, but your currently version is 0.2.7 so you should give it a version number like 1.0.0 
<Sarvatt> repository upgrade so i can actually merge it is taking forever
<BlackZ> Sarvatt: as I told you, I put 0 becuase your currently version is 0.2.6; why do you think it will not get updated?
<Sarvatt> because 0+bzr46 < 0.2.6?
<BlackZ> Sarvatt: right, but if there will be a new release it will get updated (and I did my changes to the ubuntu package with a final .1) 
<Sarvatt> thanks for doing that BlackZ 
<Sarvatt> kees: achievements are the best idea EVER!
<Sarvatt> especially achievements for using annoying features people complain about like the button order changes so they actually give them a shot :)
<hyperair> Sarvatt: 0724 has the same issues 0722 had.
<Sarvatt> hyperair: yeah i noticed :(
<hyperair> =\
<Sarvatt> cant boot with compiz enabled
<Sarvatt> well gotta switch to a vt and switch to metacity
<Sarvatt> did 0723 work for you too or was I just crazy?
<kees> Sarvatt: \m/
<hyperair> Sarvatt: with 0723 compiz just refused to start.
<hyperair> sudo dpkg -i /var/cache/apt/archives/*7.9.0+git20100721.ec0e7b16-0ubuntu0sarvatt~lucid*
<hyperair> Sarvatt: ^^
<hyperair> that's what i did anyway =p
<Sarvatt> any idea which 0722 was busted? do you have both?
<Sarvatt> libgl1-mesa-glx_7.9.0+git20100722.c686ee0f-0ubuntu0sarvatt_i386.deb libgl1-mesa-glx_7.9.0+git20100722.ca3238f3-0ubuntu0sarvatt_i386.deb
<hyperair> no, i think i only had one.
<hyperair> yeah, only one.
<Sarvatt> both are busted
<Sarvatt> gonna say something in #dri-devel
<Sarvatt> incase someone responds when i'm not around and you want to try it :)
<hyperair> i think i'll wait for your packages. mesa takes forever to compile
<Sarvatt> hyperair: found it - https://bugs.freedesktop.org/show_bug.cgi?id=29225
<ubot4> Freedesktop bug 29225 in Drivers/DRI/i965 "[bisected] compiz could not be enabled on gnome desktop" [Major,New]
#ubuntu-x 2010-07-25
<Sarvatt> hyperair: compiz 0.9 works
<Sarvatt> with opengl compositing
<hyperair> Sarvatt: ?
<Sarvatt> hyperair: it might be one of the compiz 0.8.4 patches screwing things up
<hyperair> oh
<Sarvatt> with recent mesa I mean
<hyperair> i see.
<hyperair> might be, eh.
 * hyperair wonders if there are compiz 0.9 packages for lucid.
<Sarvatt> would explain why the people doing the changes who use fedora dont see the problem :)
<hyperair> ah i see.
<Sarvatt> try dropping 049-damage-report-non-empty.patch or  010-disable-child-window-clipping.patch
 * hyperair didn't compile compiz...
<Sarvatt> do you want the compiz 0.9 build script to do it from git?
<hyperair> eh..
<hyperair> that might be interesting, yes.
<Sarvatt> sarvatt.com/downloads/buildcompiz.sh
<Sarvatt> need libboost-serialization(whatever version lucid is using)
<hyperair> okay
<Sarvatt> i purged all compiz related packages too first
<Sarvatt> think i'll just install this to /usr while i'm at it
<Sarvatt> oh yeah probably want to change the -Os -march=native CFLAGS, I was just screwing around
<Sarvatt> hyperair: more specifically its the "Force fullscreen redraws (buffer swap) on repaint option in compiz that makes it work
<Sarvatt> probably works with 0.8.4 if you enable that too
<Sarvatt> in workarounds
<hyperair> hmm let's try that.
<hyperair> Sarvatt: there isn't such an option in compiz.
<hyperair> i mean in 0.8.4
<Sarvatt> hmm it might be somewhere else in 0.8.4
<hyperair> Sarvatt: is it force_glx_sync?
<Sarvatt> nope that doesn't even do anything because its always forcibly enabled in a patch even if its disabled in ccsm
<Sarvatt> force_swap_buffers is the option
<hyperair> heh okay
<hyperair> nope, doesn't exist.
<hyperair> i think it's new.
<Sarvatt> damn
<hyperair> well apart from that, i really wish there was an option to disable page flipping.
<hyperair> it's really hard to restart X without another computer to ssh in from
<Sarvatt> dont think its page flip related if you can still ssh in?
<hyperair> http://lists.fedoraproject.org/pipermail/devel/2010-May/135429.html <-- see scenario B.
<hyperair> no wait, it's more like X gets stuck.
 * hyperair sighs. what happened to the days when i could alt+sysrq+r followed by alt+f1 to force a vt-switch?
<hyperair> now that X has to willingly switch the VT, it's become so much harder to recover from hangs.
<vish> hyperair: hey! how was the bug jam event? [forgot to ask so long ;p ]
<hyperair> vish: i bored everyone halfway to death.
<vish> lol!
<hyperair> honestly, i have to wonder how bug jam events go elsewhere.
<vish> bugs _are_ boring ;)
<hyperair> yeah, it seemed pretty boring to me too >_>
<hyperair> and there was an audible groan + laughter when i proposed 5-a-day
<vish> hehe!
<hyperair> the next time i'm asked to do a jam, i'm rejecting all notions of doing a bug jam.
<hyperair> packaging jam sounds much more fun
<vish> hyperair: yeah , easier to stick to tasks you are familiar with ;)
 * hyperair nods
<fil1> hi, anyone has problems with xorg-edgers PPA and the last build of xorg (1.8.99.905) using nvidia-current? (10.10)
<fil1> I can only boot in low graphic mode.
<Sarvatt> nvidia binary drivers dont work with xserver 1.9
<Sarvatt> there's a note at the top of the xorg-edgers page about it
<fil1> ok thanks.
<fil1> soory
<DrHalan> hey
<DrHalan> i am using maverick and sometimes my leftclicks stop to work
<DrHalan> everything else works fine in x
#ubuntu-x 2011-07-18
<RAOF> So, how much do we care that it looks like mesa 7.12 will ship with only radeon, intel, and nouveau 3D drivers?
<bryceh> RAOF, what else do we support?
<RAOF> sis, unichrome, mga, savage, tdfx, r128
<RAOF> Well, for values of âsupportâ equal to âship DRI drivers for and sort of accept patches to fix thingsâ.
<bryceh> right, I meant, what do we actually put any time into supporting
<RAOF> Oh.  Intel, radeon, and nouveau :)
<RAOF> I presume that savage, at least, does something that people find useful because we're carrying a patch for it.
<tjaalton> tormod supports savage
<tjaalton> and has improved it upstream
<bryceh> we've got a fair number of openchromers, although dunno if that works with mesa/unichrome or not
<bryceh> if sis works with sisusb and some of the other virtual gfx stuff, it could be interesting
<tjaalton> RAOF: is there a thread about it on the list?
<RAOF> mid.gmane.org/4E208571.90805@vmware.com
<RAOF> http://mid.gmane.org/4E208571.90805@vmware.com
<RAOF> Is, I think, the operative mail; tormod will want to respond there (and to update savage to the new mesa API)
<tjaalton> ah right
<RAOF> Ah, mesa.  Because there's no onerous packaging task that can't be made more fiddly by needing to accomodate proprietary alternatives.
<charlie-tca> I have a bug awaiting a upload of x11-common, any idea when that might happen?
<charlie-tca> bug 804734 is holding up the Xubuntu images for oneiric
<ubot4> Launchpad bug 804734 in xorg (Ubuntu) "Please ship 60xdg_path-on-session like gdm (affects: 1) (heat: 16)" [High,Fix committed] https://launchpad.net/bugs/804734
<charlie-tca> bug 804734 is holding up the Xubuntu images for oneiric; any idea when the next upload for x11-common will be?
<ubot4> Launchpad bug 804734 in xorg (Ubuntu) "Please ship 60xdg_path-on-session like gdm (affects: 1) (heat: 16)" [High,Fix committed] https://launchpad.net/bugs/804734
<charlie-tca> bug 804734 is holding up the Xubuntu images for oneiric; any idea when the next upload for x11-common will be?
<ubot4> Launchpad bug 804734 in xorg (Ubuntu) "Please ship 60xdg_path-on-session like gdm (affects: 1) (heat: 16)" [High,Fix committed] https://launchpad.net/bugs/804734
<tjaalton> we heard you
<tjaalton> though i'm on vacation and don't have the sshkey handy to push the release, so can't help
<charlie-tca> Hard to tell if anyone heard it if no one responds in 4 hours, really. Thanks for at least acknowledging it.
<tjaalton> bryceh: around? ^^
<bryceh> tjaalton, yes just got back from doctors.  What's up?
<tjaalton> bryceh: the bug charlie-tca mentioned, maybe you could upload current git to oneiric, my laptop installation has issues, and the screen host doesn't have the ssh key it seems :)
<bryceh> tjaalton, can do
<bryceh> tjaalton, has it been tested (does it need testing?)
<tjaalton> bryceh: great, thanks. no it's simple, dunno if there are other changes staged
<bryceh> xorg (1:7.6+7ubuntu2) UNRELEASED; urgency=low
<bryceh>   * add debian/local/Xsession.d/60x11-common_xdg_path to set
<bryceh>     xdg path depending on the selected session    
<bryceh>     (compatible with lightdm, gdm and kdm now) (LP: #804734)
<bryceh>  -- Didier Roche <didrocks@ubuntu.com>  Wed, 06 Jul 2011 09:39:17 +0200
<bryceh> that's the candidate?
<bryceh> yup looks like
<tjaalton> yes
<charlie-tca> Thank you, tjaalton and bryceh 
<bryceh> tjaalton, charlie-tca: uploaded
<bryceh> hmm
<bryceh> $ git push origin ubuntu
<bryceh> Counting objects: 7, done.
<bryceh> Delta compression using up to 8 threads.
<bryceh> Compressing objects: 100% (4/4), done.
<bryceh> Writing objects: 100% (4/4), 455 bytes, done.
<bryceh> Total 4 (delta 2), reused 0 (delta 0)
<bryceh> error: unable to create temporary sha1 filename ./objects/52: Read-only file system
<bryceh> fatal: failed to write object
<bryceh> error: unpack failed: unpack-objects abnormal exit
<bryceh> To ssh://bryce-guest@alioth.debian.org/git/pkg-xorg/debian/xorg.git
<bryceh>  ! [remote rejected] ubuntu -> ubuntu (n/a (unpacker error))
<ubot4> bryceh: Error: I am only a bot, please don't think I'm intelligent :)
<bryceh> error: failed to push some refs to 'ssh://bryce-guest@alioth.debian.org/git/pkg-xorg/debian/xorg.git'
<tjaalton> change the hostname to git.d.o on .git/config
<tjaalton> and try again
<bryceh> tjaalton, thanks that did it
<tjaalton> niice
<tjaalton> fallout of the alioth upgrade
<bryceh> I'm surprised they didn't do some virtual host redirecting or something to make the transition smoother
<bryceh> heh, git has such cryptic error messages sometimes.  but easy enough to fix, thanks.
<tjaalton> kibi had a blog post about that, with hints to do it on the client
<tjaalton> but i've just changed the configs, easy enough
<bryceh> tjaalton, push your -synaptics changes
<bryceh> oh you probably can't.  well, put it on your todo list for when you get back
<bryceh> tjaalton, you got mad last time I fixed it for you so not gonna do it now ;-)
<bryceh> eh, crazy how many bug reports aren't at all actionable by us
#ubuntu-x 2011-07-19
<RAOF> SYMBOLLLLLLLLLLS!
<RAOF> (Sung to the tune of KAAAAAAAAAAAAHN!)
<bryceh> RAOF, bug 812665 seems to be due to some symlink of /usr/share/doc/xorg
<ubot4> Launchpad bug 812665 in xorg (Ubuntu) "package xorg 1:7.6 7ubuntu1 failed to install/upgrade: trying to overwrite '/usr/share/doc/xorg', which is also in package xserver-xorg 1:7.6 7ubuntu2 (affects: 18) (dups: 13) (heat: 112)" [Undecided,New] https://launchpad.net/bugs/812665
<RAOF> bryceh: Ah.  I saw than on this morning's upgrade, but Jason didn't.
<RAOF> So I wasn't sure it wasn't a local issue.
<bryceh> yeah I noticed my graph spiked with a bunch of reports against xorg
<bryceh> looks like a stealth bug...  doesn't crop up after you upload it, only on the upload after that ;-)
<RAOF> Yay!
<bryceh> which may be why debian hasn't hit it - they haven't updated yet
<RAOF> Do you know what's wrong, or would you like me to wrangle it?
 * RAOF wonders whether his git pull is going to finish at some point.
<bryceh> looking
<bryceh> one nice thing though is I can see from the spread of bug reports, that some people still aren't getting xdiagnose installed for some reason
<bryceh> but when they do have it, at least the apport hooks are working properly
<RAOF> Yay!
<bryceh> 01dde16f91fc8e797c71bd40b9217fd5fb8d265d
<RAOF> That doesn't quite explain it, though?
<bryceh> yeah there's more commits
<bryceh> 1ace9ac414f8b58d11cec396e65cea6e1be3ebc1
<bryceh> 01dde16f91fc8e797c71bd40b9217fd5fb8d265d
<bryceh> cb28b49ff28e7f9e499c54ead75615fc5a191a51
<bryceh> 69913b837e4f09699dadb4c9df8e4dffbdd011c6
<bryceh> but I think some sort of transition/conflicts is needed or something
<RAOF> Ooooh, sneaky!
<RAOF> I think it's the space-saving auto-doc linker that's breaking things.
<bryceh> maybe something needs added in xserver-xorg.postrm.in?
<bryceh> bbiab; hear a little man calling for a dada
<RAOF> Go go!
<bryceh> space-saving auto-doc linker ?
<bryceh> oh the deep pitti magic?
<RAOF> Yes.
<bryceh> that's a better explanation why debian doesn't have the bug...  ok, since I'm well outside eod would you mind following up with him to find a solution?
<RAOF> Doing so right now in -desktop :{
<RAOF> :)
<RAOF> Have fun being dad!
<bryceh> boy, I tell you now that he can get out of his crib himself it ups the stakes quite a bit
<tjaalton> bryceh: not mad, just grumpy :) and now it seems i've no reason to get grumpy in the future, if i keep forgetting to push the changes myself, meh
<tjaalton> i'll check my laptop if it has the tree
<bryceh> tjaalton, also the xorg push from this morning broke stuff
<tjaalton> great
<bryceh> actually, wasn't that push's fault, but the one before
<bryceh> or something... pitti and raof debugging it on ubuntu-desktop presently
<tjaalton> yeah i noticed
<RAOF> tjaalton: git blames you for this, by the way :P
<tjaalton> RAOF: of course it does :)
<RAOF> But 2007-you.
<tjaalton> oh?
<RAOF> In 2007 you added some foo to symlink the doc directories to x11-common.  Now, xserver-xorg wants to ship files in /usr/share/doc/xorgâ¦
<tjaalton> I did that? sounds weird, but won't argue until i get to see the history myself :)
<RAOF> My thinking is that we let pkgbinarymangler handle the doc symlinking and drop that diff from Debian.  After the next LTS, 'cause we need to remove those symlinks in preinst.
<RAOF> + -- Timo Aaltonen <tepsipakki@ubuntu.com>  Sun, 28 Oct 2007 13:36:40 -0400 in 4ad13bf6 :)
<tjaalton> maybe i just sponsored it
<RAOF> It's entirely possible.
<tjaalton> ton of changes that day, probably just moving them to git from the previous version
<tjaalton> bryceh: doesn't look like my laptop has the current synaptics branch, so either wait two weeks or "break" it now :P
<tjaalton> and iMve no idea how to make my phone work as a bluetooth modem, it used to work at some point
<bryceh> tjaalton, ok; I ended up not having anything to upload at the moment anyway
<tjaalton> *i've
<tjaalton> bryceh: ah, ok
<bryceh> tjaalton, looked like it only needed s/UNRELEASED/oneiric/
<RAOF> If you're trying it on oneiric, good luck!  Bluetooth is entirely borked for me.
<tjaalton> yeah, meh
<bryceh> tjaalton, I figure we gotta rule out chase's MT patches now before upstreaming input bugs, so I rolled up a ppa omitting those for folks to test.  we'll see how that goes.
<tjaalton> RAOF: indeed, natty was equally broken for me
<RAOF> Whereas natty worked wonderfully for me.
<tjaalton> bryceh: nice
<RAOF> For both the magic touchpad, and bluetooth pairing with my phone.
<tjaalton> nice, gnome-shell hung while trying to pair them
<tjaalton> unity does't start
<tjaalton> oh it does
<tjaalton> ha, 'apt-get install bluetooth-dun' on my phone, and now it works :)
<RAOF> On your phone?  What is this, an N900? :)
<tjaalton> yep
<tjaalton> doesn't do DUN ootb, which was a bit of a surprise
<bryceh> http://www.bryceharrington.org/Arsenal/Reports/ubuntu-x-swat/totals-oneiric-workqueue.svg
<bryceh> thinking about all the bugs lacking apport information because xdiagnose wasn't installed...
<jcristau> kees: did you have any other pending X patches?
<jcristau> ah, the Xlib stuff.
<bryceh> I'm wondering if either xdiagnose needs to be a depends, or if the reporters simply hadn't upgraded since xdiagnose entered main.
<jcristau> but looks like that's being handled
<kees> jcristau: yeah, I need to address the issues with that
<kees> jcristau: I had an xhost change too that hasn't been committed, I don't think.
<jcristau> right, just found that one
<kees> (I had 3 patches: xclipboard, xhost, and the macro fix-up)
<jcristau> To git.freedesktop.org:/git/xorg/app/xhost
<jcristau>    29215ba..24685cf  master -> master
<mpoirier> All, I have a snowball board booting ubuntu and the graphics comes up with max resolution and color depth.  But i know for a fact the driver isn't reading the EDID. 
<mpoirier> How can X figure out the perfect graphic settings ?
<bryceh> mpoirier, more info plz
<mpoirier> I'd like to but I'm very green when it comes to graphics.
<mpoirier> I guess hte real question would be, how does X figure the best settings when booting ?
<jcristau> it asks the monitor
<mpoirier> doesn't rely on the kernel for that ?
<jcristau> depends.
<mpoirier> ok, that's interesting. pls expand.
<bryceh> mpoirier, probably best if you hit google
<jcristau> on kms that asking goes through the kernel
<mpoirier> and what's the non-kernel way ?
<jcristau> hw poking
<mpoirier> jcristau: you mean trail and error ?
<jcristau> no
<jcristau> essentially the same thing as the kms case except you're doing it in the userspace X driver instead
<mpoirier> humm... then it's must be using an i2c bus to read the edid.
<mpoirier> jcristau: is this something you can confirm ?
<jcristau> in many cases, yes.
<mpoirier> is there another way ?
<mpoirier> I'm insisting 'cause I know i2c0 is not configured and proven to be dead.
<mpoirier> i2c0 is the bus hooked to the hdmi controller.
<jcristau> on a laptop you can probe the bios instead
<jcristau> for hdmi probably not so much
<mpoirier> and this board is running uboot.
<jcristau> but i'm pretty sure edid is mandatory on hdmi, so..
<mpoirier> ok, something somewhere is happening for sure...
<jcristau> anyway.  read your driver's code?
<mpoirier> I have :o)
<mpoirier> and the ioctl returning fix and variable monitor info return bogus values.
<mpoirier> you've help me a lot.
<mpoirier> I don't think you can do more.
<mpoirier> jcristau: thanks for your time.
#ubuntu-x 2011-07-20
<RAOF> bryceh: I've just got a backtrace from the xorg apport hook: http://paste.ubuntu.com/647730/
<RAOF> Are you aware of this?
<bryceh> no hadn't seen it
<bryceh> thanks
<bryceh> fixed
<bryceh> RAOF, push git on xorg
<RAOF> Bah.  Done.
<bryceh> thanks
<bryceh> ok, I'm going to work on xdiagnose a bit more but am done fussing with X bugs for today.
<bryceh> RAOF, the queue's knocked down a bunch, but here's what's left:  http://www.bryceharrington.org/Arsenal/Reports/ubuntu-x-swat/workqueue-oneiric.html
<RAOF> That's looking pretty healthy for the moment!
<bryceh> keep in mind that list doesn't include bugs we've set as incomplete and are waiting on people to respond on
<bryceh> that's just ones that you and I need to do something
<bryceh> but yeah, even the "all bugs reported" status look ok:  http://www.bryceharrington.org/Arsenal/Reports/ubuntu-x-swat/totals-oneiric.svg
<bryceh> of course I worry that the bug you found in the apport hook might have been preventing people from filing bugs....
<bryceh> http://www.bryceharrington.org/Arsenal/Reports/ubuntu-x-swat/totals-oneiric-workqueue.svg
<RAOF> Look at that!  We fixed all the bugs just in time last cycle :)
<bryceh> something like that ;-)
<bryceh> we're definitely doing better than last cycle
<bryceh> last time we started at 0 and did pretty well
<bryceh> this time we started with 20 bugs, that I pulled forward from natty, and we're back down to 20 today
<RAOF> Man, it'll be good to have the vblank-when-disabling-outputs kernel in natty-updates; I'd guess at least one commenter on slangasek's -intel GPU hang bug is hitting that.
<bryceh> yeah
<bryceh> RAOF, you might also look at whether some of the mesa gpu fixes would be worth putting into natty's mesa as sru's
<RAOF> Yeah.  If they apply ;)
<apw> RAOF, i see that the testing results on bug #753994 are good, but i also see keith asking for updates (to comments)
<ubot4> Launchpad bug 753994 in linux (Ubuntu Oneiric) (and 2 other projects) "[arrandale] Display is slanted when using 1360x768 resolution (affects: 1) (heat: 8)" [Medium,Confirmed] https://launchpad.net/bugs/753994
<RAOF> apw: Yeah.  I presume that's why I couldn't find it in any upstream kernel tree.
<apw> RAOF, i see no response from the submitter updating it unless they also updated the title
<RAOF> apw: I haven't seen any response, either; I don't think that's an artefact of title updating.
<RAOF> I guess I'll send a Tested-By: reply and see if ajax wants to address the comments.
<diverse_izzue> bryceh, ping
<apw> RAOF, good idea
<RAOF> Which is exactly what I've done :)
<RAOF> diverse_izzue: It's probably a bit late for bryceh.  Can I help you?
<apw> RAOF, heh ... as it sounds like its just comment updates that doesn't preclude us from starting the SRU process
<apw> cirtainly if there is no response 'soon'
<RAOF> apw: You'd need to pull it into the current kernel first! :P
<apw> RAOF, heh yeah, well frankly thats the norm as the devel kernel is always off from mainline too these days
<diverse_izzue> ROAF, I don't know his time zone. I reported this bug (811640), and he responded by asking me to install a PPA (ppa:bryce/melon). However the xorg-server in that PPA is not new enough to supersede what's in oneiric, so I'm not sure that PPA will do what he intended.
<diverse_izzue> RAOF, the above is for you, but is misspelled your name :-)
<RAOF> Yeah.  I was just looking at the bug.  So, you *could* install those packages manually, and they should work (until you next update, at which point they'll be upgraded to the newer oneiric versions).  Or you could wait for tomorrow when bryceh will hopefully have oneiric packages in that PPA :)
<diverse_izzue> RAOF, they are oneiric packages, but i think there was just an xorg update pushed to oneiric, which is why the ppa ones are already not new enough.
<RAOF> Ah.  That's right, I stopped upgrades from dying.
<diverse_izzue> RAOF, don't understand
<RAOF> I updated the xorg package yesterday to fix an upgrade bug.
<diverse_izzue> is there a way to give a ppa a higher priority than the main repos?
<RAOF> There is, but you probably don't want that.  Just do an âaptitude install xserver-xorg-core=$THE_VERSION_IN_THAT_PPAâ, and then don't update before rebooting ;)
<diverse_izzue> oh, ok, and will that automatically pull the right versions of other stuff built from that source package?
<RAOF> To satisfy dependencies, yeah.
<diverse_izzue> RAOF, thanks for the help, will now try
<jibel> bryceh, latest xdiagnose introduced bug 813367
<ubot4> Launchpad bug 813367 in xdiagnose (Ubuntu) "xorg apport hook fails with TypeError: list indices must be integers, not list (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/813367
<albert23> Ah, sna also wants "shm: Replace open-coded version of GetScratchPixmapHeader". Now I understand the sna comments in the desktop meeting :-)
<bjsnider> ricotz, you're now starting to package gnome-shell extensions?
<ricotz> bjsnider, the package is available for 2 months ;) -- actually cdbs started it
<bjsnider> last i read the gnome recommendation was not to package any of them
<ricotz> bjsnider, this doesnt sound useful, where do you read this?
<ricotz> some of them must be installed in /usr because of gsettings schemas which isnt recommended for end-users
<bryceh> jibel, thanks; investigating
<kees> say, I've noticed that my laptop sees i915 waking up 60 times a second... is there some way to diagnose this so I can get some battery life back/
<kees> (this is on natty btw)
<bryceh> kees, look in your logs for error messages, turn on more debugging messages, look at modinfo i915 for any tunables, re-test on oneiric kernel, and if all else fails contact jbarnes
<bryceh> kernel team might have more structured diagnostics; generally we punt power and suspend type issues over to them.
<tjaalton> kees: and disable the blinking cursor if it's on, also check if the panel clock displays seconds..
<kees> tjaalton: oooh, blinking cursor!
<kees> let me try that first...
<kees> tjaalton: hm, no change there
<tjaalton> kees: duh, should've helped
<kees> tjaalton: powertop still shows 60 wakeups a second :(
<kees> tjaalton: any idea how to debug this?
<jcristau> kees: running compiz?
<kees> jcristau: yeah. I don't remember it doing that before, though
<jcristau> maybe pageflip didn't work before
<kees> hmpf.
<tjaalton> kees: (sorry, got disconnected) it's probably some x client causing it, like compiz as jcristau suggested
 * kees waves goodbye to battery life
<albert23> or use unity-2d, that's low power
<kees> yeah
<bryceh> kees, newer powertop has some trace points for tracking things like this, and might give the pid of what client is being naughty
<bryceh> kees, 60 wakes/sec sounds like something using vblank events
<kees> bryceh: yeah, so it probably is compiz. I'm going relogin in here in a second...
<bryceh> kees, if you definitively narrow it to compiz; might check by disabling plugins.
<bryceh> er, might *also* check
<jcristau> letting the compositing manager synchronise updates with vblank is what this interrupt is all about, so i'm not surprised it shows up...
<bryceh> drm_vblank_event_delivered in /sys/kernel/debug/tracing/events/drm sounds like it might give the pid of what's getting the events
<jcristau> i suppose the interrupt could be disabled when there's nothing to draw though...
<bryceh> yeah
<jcristau> dunno if that's supposed to be implemented, i haven't been paying too much attention :)
<bryceh> or implemented but off due to bugs
<albert23> switching off sync to vblank in compiz, opengl plugin seems to work
<bryceh> albert23, gconf setting?
<albert23> ccsm
<bryceh> kees, ^
<bryceh> kees, also I don't know if you already looked but modinfo i915 shows tunables for fiddling rc6 (render c6 deep sleep) and fbc (framebuffer compression).
<bryceh> those probably won't affect the wakeup problem though.  rc6 sleep may give you some suspend power improvements if you have it turned off.
<bryceh> kees is quiet now; perhaps he ran out of power?  ;-)
<ricotz> bjsnider, i was hoping that tseliot uploaded the new nvidia blob to oneiric, but it didnt :\
<ricotz> he*
<bjsnider> ricotz, which, the 275.19 or the 280?
<ricotz> bjsnider, 275.19
<bjsnider> i can throw it into x-updates based on his most recent build scripts
<bjsnider> the source package is already there, which is the big deal with the blob. it's very large
<bryceh> tseliot's probably tied up with oem work or something.  I've not talked to him in some time
<bjsnider> i think oneiric users should be ont he 280 at this point because of the recent kernels/x-server support though right?
<bryceh> there's several oneiric packaging bugs with -nvidia if anyone wants to take a look.  look like simple path checking issues and such
<bjsnider> bryceh, he said he'd put it in there not long ago. he might have forgotten
<bryceh> bjsnider, sounds about right
<ricotz> as long there is no xserver 1.11 in oneiric using the stable 275.x should be the one
<ricotz> 280.x doesnt feel that stable for me currently 
<bjsnider> what's the xserver version in oneiric right now?
<ricotz> bjsnider, putting it it x-updates would be nice for now
<bryceh> oneiric has 1.10 and 275.09.07
<ricotz> i think 1.10.2
<bjsnider> when is 1.11 going in?
<bryceh> 1.10.2.902
<bryceh> 1.11 isn't going in for oneiric
<ricotz> is this final yet?`
<bryceh> yep
<ricotz> ok
<bjsnider> that's kind of conservative
<bryceh> well, 1.10.3 will be final
<bryceh> unless there's a 1.10.4 that looks important
<ricotz> or 1.10.4 ;)
<ricotz> :P
<bryceh> bjsnider, precisely
<bryceh> I don't know if 280 is going to make it into oneiric, but like I said sounds right for x-updates probably
<bryceh> but up to you guys; if you think it's unstable then perhaps wait.
<ricotz> no, 275 should go in x-updates
<bjsnider> it's marked beta
<bjsnider> does the 275 build with the oneiric kernel?
<ricotz> bjsnider, yes, it is already in the repos
<ricotz> they patched it for 3.0 awhile ago
<bryceh> like I said there's been some packaging bugs reported, but they seem to be corner cases
<ricotz> yeah, there are probably multiarch problems
<bjsnider> ricotz, the package is now available for amd64
<ricotz> bjsnider, thanks :)
#ubuntu-x 2011-07-21
<apw> RAOF, did anything occur with that 'diagonal black' bug ?  any progress on the patch making it into an acceptable form?
<ricotz> bjsnider, http://www.nvidia.com/object/linux-display-amd64-275.21-driver.html ;)
<mdeslaur> hmm...I think I have a regression with -intel in natty-proposed
<bryceh> mdeslaur, do tell
<bryceh> mdeslaur, and link me the bug#
<mdeslaur> yeah, I'm filling out the bug now, one sec
<mdeslaur> bryceh: bug 814325
<ubot4> Launchpad bug 814325 in xserver-xorg-video-intel (Ubuntu) "fuzzy and corrupted display with update in -proposed (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/814325
<mdeslaur> it's a weird problem I've never seen before
<mdeslaur> when I come out of the screensaver (blank screen), the whole screen is fuzzy, and unreadable, and is flickery
<bryceh> mdeslaur, have you checked if the issue goes away if you revert back to the 7.1 driver and restart X?
<mdeslaur> bryceh: I'll try and ssh in and give that a try next time...even the console screen becomes like that when it happens
<mdeslaur> oh, hrm
<bryceh> mdeslaur, the deb may still be in your /var/cache/apt/archives/
<mdeslaur> I'll download it right away for next time
<mdeslaur> but, since the virtual consoles are like that too, I don't know
<bryceh> mdeslaur, I would also like you to test booting an oneiric livecd on this machine at some point too, since we are including that patch in oneiric already.  If it's bugged too, we'll need to get going on that bug else you'll be unhappy when you upgrade
<bryceh> mdeslaur, the patch in question is a major "Give up on optimizing UXA" patch which seems to fix a wide array of corruption bugs a lot of people have reported (with some minor performance drop)
<mdeslaur> I can't reproduce it at will, unfortunately
<bryceh> mdeslaur, I'll be disappointed if it is indeed the cause of your problem, but am glad you tested it so we know before it got into the wild
<mdeslaur> I know the changes don't appear to have anything to do with the problem I'm having, but I've only had it since I installed the package in -proposed
<mdeslaur> unless it's a kernel issue
<bryceh> mdeslaur, how many times have you reproduced it (after reboots)?
<mdeslaur> it's happened 3 times in the last day
<mdeslaur> and each time, I've rebooted, as I haven't figured out what else to do
<mdeslaur> The screensaver probably has activated 30 times in the last day
<bryceh> mdeslaur, could you also post your current /var/log/dpkg.log to the bug?
<mdeslaur> sure, one sec
<mdeslaur> hmm...there was a kernel update two days ago also
<bryceh> mdeslaur, yeah kernel could be a suspect as well
<bryceh> esp. if you didn't reboot into it until yesterday
<mdeslaur> bryceh: yeah...hmm...which one would you recommend I revert first to see if it goes away?
<bryceh> mdeslaur, 6 to half dozen...  -intel I guess.  Would be nice to prove patch guilty or innocent so we can kick it from -proposed if needed
<RAOF> apw: My prod seems to have got the âdiagonal blackâ bug a Reviewed-By from ickle, but no actual upstream committage.
<mdeslaur> yeah, I'll revert -intel so I can quickly comment on the -proposed bug
<mdeslaur> bryceh: thanks
 * mdeslaur -> rebootr
<bryceh> RAOF, does your new SRU approval hat include MIR approval?  if so, perhaps you can bump #810217 forward?
<RAOF> bryceh: No, sadly :)
<bryceh> ah well
 * bryceh reshuffles wayland down a bit more in todo list
<RAOF> Yeah.
<RAOF> I should probably back out the wayland re-enablement and upload mesa rc2.  Or rc3, if that's really coming out Monday :)
#ubuntu-x 2011-07-22
<RAOF> Intruiging.  linux-image-3.0.0-6 fails to bring up the panel on the dell.\
<RAOF> Oh.  Because I somehow thought passing âvideo=LVDS-1:dâ to the kernel was a good idea.
<ricotz> bjsnider, hi i saw you updated the nvidida package :) -- but did you used the right files? http://de.download.nvidia.com/XFree86/Linux-x86_64/275.21/NVIDIA-Linux-x86_64-275.21-no-compat32.run and http://de.download.nvidia.com/XFree86/Linux-x86/275.21/NVIDIA-Linux-x86-275.21.run
<RAOF> i965: Apply a homebrew workaround for GPU hang in OGLC api-texcoord.  :)
<RAOF> Looks like 3.0.0-6 does *substantially* better on the dell 6420 - it's currently failing to fall over running glxgears, unity, and doing a full piglit suite.
<apw> RAOF, not helpful
<apw> RAOF, the fix seems sane enough, so i suspect we can take it if we have a clean patch
<RAOF> Is the patch currently sitting on the ML not clean enough?  It's like 2 lines.
<apw> RAOF, probabally, i was only holding off cause of the whining about comments
<scoundrel50a> hi, is there somebody around that can help with Ubuntu 11.04 problems, of no backlight.
<scoundrel50a> What I need is somebody on here got me to install the Oneiric RC1 kernel, I want to uninstall it, and install instead, the latest kernel of 11.04, to see if the backlight problem has been fixed.
<scoundrel50a> Can anybody help please?
<scoundrel50a> is anybody here?
<bjsnider> ricotz, yes, i messed that up. oh well, they'll just have to do without.
<ricotz> bjsnider, you should be able to delete the packages and reupload a new one after  a while
<ricotz> if might take a time until you can upload a new orig.tar
<bjsnider> yeah i think it's at least a week, and most of the changes were to nvidia-settings anyway
<ricotz> bjsnider, a week?
<ricotz> i think it is about 3 hours
<bjsnider> before source papckages are deleted?
<ricotz> yes
<bjsnider> i've already deleted everything, so i will wait a few hours and test your theory
<ricotz> alright
<bjsnider> i was more concerned last night with sending in the new nvidia-settings, but it had not been uploaded anywhere at that time. i haven't checked today
<ricotz> yeah, the packages are a bit hidden :\
<ricotz> bjsnider, http://de.download.nvidia.com/XFree86/nvidia-settings/nvidia-settings-275.21.tar.bz2
<bjsnider> why is everything on the german site first?
<ricotz> i dont know ;)
<ScottK> bryceh: It looks to me like x11-common recommending xdiagnose is causing gtk3 to get pulled onto the Kubuntu CD (where there is just no room).
<ScottK> Do you mind if I change that to suggests?
<ScottK> Then if there's room on other images they can seed it directly.
<bryceh> ScottK, sucky for kubuntu.  Oh well, I'll take care of it
<ScottK> bryceh: Thanks.
<bryceh> ScottK, how come you only notice it now?  it's been a recommends for a while
<ScottK> Because this is the first time I've started to care we're oversized.
<bryceh> ScottK, can you show me a log file that indicates gtk3 got pulled in?
<ScottK> bryceh: http://people.canonical.com/~ubuntu-archive/germinate-output/kubuntu.oneiric/desktop-common
<bryceh> ScottK, and do you know of any bug reports open about this issue?
<ScottK> bryceh: Nope.  Just found it.
<bryceh> ScottK, there you go, done.  no X diagnosing for kubuntu :-)
<ScottK> bryceh: Thanks.  I'll add it to the metapackage we use for the DVD so at least people that install it that way will have it.
#ubuntu-x 2011-07-23
<Sarvatt> new macbook air's are horribly broken under ubuntu, color me surprised :)
<Sarvatt> http://sarvatt.com/downloads/macbookair/
<bjsnider> if the underlying hardware is al intel i don't see why it would be borked
<afiestas> RAOF: ping
#ubuntu-x 2011-07-24
<shadeslayer> hi, i have a AMD Radeon HD 6400M Series graphics card and i installed the fglrx driver on Oneiric, and now i have a "AMD Unsupported hardware" watermark at the bottom left, but on natty the driver worked prefectly, any ideas how to fix this?
<shadeslayer> i also get this while installing fglrx : update-alternatives: warning: forcing reinstallation of alternative /usr/lib/x86_64-linux-gnu/mesa/ld.so.conf because link group x86_64-linux-gnu_gl_conf is broken.
<shadeslayer> any ideas?
<ricotz> bjsnider, hi, did you tried to reupload the nvidia driver yet?
<bjsnider> well
<bjsnider> the thing is
<bjsnider> once a source tarball has been uploaded another one by the same name can never be uploaded. so, even if i delete the packages it doesn't change that
<shadeslayer> is there a way i can report a bug against the xserver-xorg-video-ati package from the xorg edgers ppa?
<ricotz> bjsnider, hmm :\ , so you are waiting for the next version now ;)
<bjsnider> that's about the size of it
<bjsnider> i expect a stable 280 will be the one
<ricotz> yeah probably -- 280.11 seems to feel better than 280.04
<RAOF_> afiestas: Monday pong.
<afiestas> RAOF_: 00:37 pong
<afiestas> xD
<RAOF_> Mmm.  Refreshingly morning :)
<afiestas> I'm about to start the work on renewing the RandR support in KDE-Workspace
<afiestas> and I remembered that we talked about sharing a library to save configuration relating edid information to it
<RAOF_> Yeah, that's right.
<RAOF_> I've not actually *written* that library yet, though :)
<afiestas> but you're planning to?
<afiestas> if so, when ? for this cycle?
<RAOF_> It probably won't be this cycle.
<RAOF> What sort of makeover does the KDE RandR code need?  Will it be easy enough to factor out such code later?
#ubuntu-x 2012-07-16
<mlankhorst> feeling a bit sick, but good morning :)
<mlankhorst> can someone re-upload libdrm? I fixed the arm build failure
<seb128> mlankhorst, there?
<mlankhorst> yeah
<seb128> mlankhorst, hey
<mlankhorst> heya
<seb128> mlankhorst, https://bugs.launchpad.net/ubuntu/precise/+source/xorg-server/+bug/1021517 seems a regression in the recent precise SRU
<ubottu> Launchpad bug 1021517 in xorg-server (Ubuntu Precise) "Xorg-server crashes reproducible with GIMP usage" [High,Confirmed]
<seb128> which got pushed to -security as well
<mlankhorst> oh fun
<seb128> mlankhorst, can you or somebody else from here have a look soon?
<seb128> mlankhorst, comments mention it depends of the trackpad status (like they get it when doing fn-f8)
<seb128> see the most recent comments
<mlankhorst> yeah seems likely that it was from 10.3 update, bit weird it would only show now though
<seb128> mlankhorst, it doesn't only show now
<seb128> mlankhorst, we started the bug was filed on 2012-07-06
<seb128> ups
<seb128> -we started
<seb128> mlankhorst, I guess you guys didn't monitor the new bugs after the SRU?
<jcristau> no apport gdb trace or anything?
<mlankhorst> seb128: I guess those people didn't test -proposed, more likely
<seb128> jcristau, only https://launchpadlibrarian.net/109601036/XorgLogOld.txt :-(
<jcristau> yeah not quite as useful
<mlankhorst> I'll see if I can make a new shiny backtrace
<seb128> not sure why we don't get apport report for xorg, I guess the xserver handler block it
<jcristau> maybe with those binaries addr2line would work, but i'm not going to download that..
<mlankhorst> I'll create a new bt if I can reproduce
<mlankhorst> works here :\ bug is useless without backtrace
<mlankhorst> oh there we go
<seb128> mlankhorst, you got it?
<mlankhorst> seb128: hm nope, was a sigpipe which is valid
<mlankhorst> might be old xf86-input-synaptics
<seb128> mlankhorst, the bug got some pretty responsive users, you can perhaps give them hint to get the stacktrace?
<jcristau> the bug already has a pointer to https://wiki.ubuntu.com/X/Backtracing
<seb128> ok
<seb128> mlankhorst, jcristau: I get the bug here, let me try that
<mlankhorst> seb128: oh i just put some qs on the bug
<seb128> easy to get for me "gsettings set org.gnome.settings-daemon.peripherals.touchpad touchpad-enabled false"
<seb128> well I just gor an xorg segfault this way in a guest session
<mlankhorst> ok
<mlankhorst> riught that works
<seb128_> hum, something the kernel didn't like
<mlankhorst> seb128_: seems i can reproduce it, but I'm going to lay down now, not feeling so well
<seb128_> mlankhorst, ok
<seb128> hum, again
<seb128> mlankhorst, sorry I might have missed what you said, but get better!
<mlankhorst> seb128: its no problem to get the bt tomorrow, already had one
<seb128> mlankhorst, should we hand over that to bryceh or RAOF while you get better?
<mlankhorst> it's just something that got my throat quite good, should be over in a day I hope :)
<seb128> mlankhorst, jcristau: backtrace on https://bugs.launchpad.net/gimp/+bug/1021517/comments/58
<ubottu> Launchpad bug 1021517 in xorg-server (Ubuntu Precise) "Xorg-server crashes reproducible with GIMP usage" [High,Confirmed]
<seb128> bryceh, ^ when you are up, it's a segfault and seems a regression from the recent SRU,security update to precise
<mlankhorst> it was before the security update so definitely the dix changes in 10.4, maybe cnd would know from the backtrace
<mlankhorst> if not with a bit more work anyone could find out what's going wrong :)
<seb128> mlankhorst, right, it's likely 10.3
<seb128> cnd, ^
<cnd> I'll take a quick look
<seb128> cnd, thanks
<seb128> cnd, you can do that today? it's an xorg segfault regression easy to trigger which made it in a security update of the current lts, i.e not great to have, we should address it
<bryceh> heya
<seb128> bryceh, hey
<seb128> bryceh, how are you? happy monday :p
<bryceh> seb128, a bit invalid... threw out my back yesterday while wrestling my son into a pair of pants
<seb128> bryceh, :-(
<cnd> mlankhorst, seb128: interesting, it's obviously input related, but I have no idea
<cnd> mlankhorst, it was in the latest update?
<cnd> mlankhorst, when you said changes in 10.4, did you mean 11.4?
<cnd> oh wait, nm
<cnd> -0ubuntu10.4
<cnd> mlankhorst, the attached X log says -0ubuntu10.3
<cnd> I may be restating things we already know :0
<cnd> mlankhorst, seb128: so my initial thoughts are that I haven't heard of such a bug before based on upstream activity
<cnd> and we need to do some deep dive debugging to figure it out, unless we can find a specific commit or patch that affects things
<cnd> if you can figure out *what* is going wrong, I can help figure out how to fix it
<seb128> cnd, it's trivial to trigger for me, run gimp, create an image, turn touchpad off (that's my latitude e6410 laptop config)
<seb128> cnd, I'm happy to test versions but report timing makes it pretty likely the issue is in ubuntu10.3
<seb128> cnd, I turn off the pad with gsd by doing the gsettings command I put it comment #58
<seb128> cnd, let me know if I can be useful in debugging
<bryceh> seb128, have you tested 10.2 to verify that the bug isn't reproducible there?
<bryceh> actually, come to think of it I was just yesterday using gimp on a machine that has 10.2 loaded and it did not crash
<seb128> bryceh, yes, downgrading to xserver-xorg-core (2:1.11.4-0ubuntu10.2) fixes it
<seb128> ok, upgrading to 0ubuntu10.3 and the bug is back
<seb128> it segfault on first click in gimp after turning the touchpad off
<seb128> so
<seb128> bryceh, cnd, mlankhorst: we need an upload to fix that today or tomorrow, do you think debugging the issue and fixing is a reasonable way out or should we look at reverting the ubuntu10.3 changes?
<seb128> or do you want to look at fixing it for a bit and after $time go to fallback plan to revert?
<cnd> seb128, I'm sort of sprinting with the kernel team
<cnd> I didn't bring a second laptop
<cnd> so I can't today
<cnd> and I'm also not really *supposed* to be helping debug X stuff, since I have other day job stuff
<cnd> I know that mlankhorst is quite capable of that :)
<cnd> if he can't get to it for some reason, then I can try to step in
<cnd> seb128, I could probably reproduce it, but I can't debug it easily without a second machine at least
<cnd> that's the blocker for me for today
<cnd> but again, I need to focus on other work, and try to be a resource for determining a proper fix after the root cause has been identified
<cnd> seb128, it's that critical of an issue?
<cnd> seb128, we'd have to figure out what needs reverting first
<cnd> the specific patch or commit would help
<seb128> cnd, mlankhorst is unwell and went to bed
<seb128> cnd, well, it's "xorg segfault when using gimp" which got introduced in a SRU,security update in the LTS, so it's an high importance issue yes
<seb128> cnd, xorg closing might mean work and datas lost
<seb128> cnd, but if you are busy no worry, I'm trying to estimate our easier way out
<bryceh> seb128, the 10.3 change set introduces six patches which fix one bug, which is also a crasher.  Reverting seems feasible and maybe lowest risk solution.
<mdeslaur> but wasn't 10.3 to fix a regression introduced in 10.2? :)
<seb128> pick your least bad regression :p
<bryceh> mdeslaur, hrmm, well the 10.2 fix was to make touchpad work on macbookair
<mdeslaur> which was incomplete and causing xephyr to segfault
<seb128> well, xephyr to segfault is better than xorg to segfault
<mdeslaur> so, it's pick the least evil of regressions :)
<bryceh> mdeslaur, right what I mean is that if we rolled that back too, then we would get into a state where nothing is crashing, just that macbooks have broken touchpads
<mdeslaur> hrm, I agree, not ideal
<cnd> bryceh, seb128: the bug fixed by 10.3 is a much lesser evil than an X server crash
<bryceh> seb128, cnd if you'd like, I can take the action to revert the 10.3 and 10.2 changes
<seb128> ok, at this point it's easier "we believe the easier way out is to fix the bug and we give it a few hours"
<seb128> easier->either
<seb128> or "let's revert and give us time then to figure what is wrong"
<seb128> bryceh, what do you think?
<sbeattie> bryceh: well, if we revert one or both, we should probably revert from the -security pocket as well.
<bryceh> seb128, it looks to me like reverting the patches from 10.2 and 10.3 would be the way to go, until this is better understood.
<seb128> bryceh, great, can you get that done today and coordinate with sbeattie,mdeslaur to get the rollback in -security as well?
<bryceh> seb128, certainly
<seb128> bryceh, then mlankhorst and cnd can probably investigate the segfault tomorrow
<seb128> bryceh, thanks
<mlankhorst> cnd: ^
<mlankhorst> but yeah it's fine if it gets reverted for now
<bryceh> sbeattie, I'm thinking just comment out the patches in question rather than doing a literal rollback to 10.1... sound right?
<mlankhorst> sbeattie: the bug was filed before the security sru got released..
<sbeattie> bryceh: yes, that's fine.
<mlankhorst> so I don't thin kit had anything to do with it
<mlankhorst> I'm not going to object to a rollback for now though :)
<cnd> the bug would result in the touchpad doing wonky things if you have disable trackpad while typing and you use it a bit, and then it starts to act like extra touches are on the touchpad when more than one touch is used
<cnd> IIRC
<cnd> the bug can also occur just by doing suspend/resume cycles
<cnd> but it's stil not a crasher
<cnd> bryceh, I thought the 10.2 was ok?
<cnd> so just reverting the 10.3 changes would be good enough
<cnd> seb128, correct?
<cnd> btw, I have really terribly high latency here
<cnd> wifi is terrible
<seb128> cnd, right, 10.2 is correct (but it had a xephyr segfault issue)
<mlankhorst> seb128: not just xephyr
<mlankhorst> xorg-server under some conditions as well
<mlankhorst> it's mentioned in the changelog, but xephyr was the easiest way to trigger it (sorry really slow today)
<bryceh> cnd, right; 10.3 attempted to fix the regression caused by 10.2.  10.2 itself was an attempt to fix a touchpad activation issue.
<cnd> bryceh, I don't think I'll be much use today between the sprint, wifi instability, and lack of machines, so if you can take care of the revert please do
<mlankhorst> so yeah rollback to 10.1
<mlankhorst> + security fix
<bryceh> cnd, yep I'll take care of the revert
<mlankhorst> thanks bryceh :)
<cnd> ok
<bryceh> mlankhorst, 10.4 added 516-dix-dont-emulate-scroll-events-for-non-existing-axes.patch which I'm guessing we'd like to keep?
<mlankhorst> bryceh: I don't know, it should be in -proposed atm, not sure though if it is
<cnd> +1 :)
<mlankhorst> if not just comment it out again
<bryceh> ok
<mlankhorst> bryceh: I updated some drivers in xorg today btw to x1.13rc1
<mlankhorst> likely going to need to touch all of them
<mlankhorst> since xaa was removed
<bryceh> sbeattie, btw the security patch 509 probably should have been numbered 228.  The comments in debian/patches/series are confusing but generally 5xx we were using just for the input frankenserver bits
<bryceh> I'll fix the comments so this is clearer
<seb128> bryceh, btw do you know why apport doesn't trigger on xorg segfaults?
<seb128> bryceh, is that a known issue,being worked?
<bryceh> seb128, yes it's a known issue discussed at UDS.  I believe RAOF has the action item to work on it.
<seb128> bryceh, ok, thanks, I will check with him, if we had that we would probably have noticed that one earlier through errors.ubuntu.com
<bryceh> seb128, it's not that they're not being triggered, but that they trigger only in some cases
<seb128> bryceh, well, that gimp segfault doesn't trigger it
<seb128> it might turn out to be a good testcase ;-)
<bryceh> the xserver has it's own crash handling code, which we had to bypass to make it work with apport, and it's always been a bit flaky
<sbeattie> bryceh: ah, okay. kees was the one who handed it to me, so I'd assumed he'd gotten the numbering correct.
<sbeattie> bryceh: anyway, let me know and I can shepherd things through the -security pocket.
<bryceh> sbeattie, yeah no prob, it's our fault that the sections weren't labeled clearly
<bryceh> sbeattie, ok, 1.11.4-0ubuntu10.6 uploaded
<sbeattie> bryceh: thanks.
<kees> bryceh, sbeattie: oh, whoops. sorry about that patch numbering. I missed that note :(
#ubuntu-x 2012-07-17
<sbeattie> bryceh, cnd, and mlankhorst: I published bryceh's revert of the 10.2 and 10.3 through precise-security
<bryceh> thanks sbeattie 
<bryceh> sbeattie, hmm I just got a reject message back on 10.6
<bryceh> sbeattie, guessing it's because it went through -security so the -proposed one can be canceled?
<RAOF> mlankhorst: Hey, how much do you know about drm authentication stuff?
<mlankhorst> not much, X server handles most of it, why?
<mlankhorst> oh right it probably screws up on prime
<mlankhorst> for some reason it only works there if i set /dev/dri/* to 666 even if im a member of video
<RAOF> mlankhorst: More I mean âwhat stops me from flinking random numbers until I hit upon the framebuffer/other juicy buffers and then screen cap everyone else's session from my user's logged in session?â
<mlankhorst> erm a handle to a bo is mapped per file
<RAOF> But you can retrieve that bo from the global name, right?
<RAOF> Via such magic as nouveau_bo_wrap and such.
<mlankhorst> in prime?
<RAOF> In general.
<mlankhorst> doubt it, anyhow I think X is partly responsible for security as well
<RAOF> From talking with airlied it's tied up with drm master, but I can't see how that's actually implemented in drivers/gpu/drm/*
<mlankhorst> drm_gem probably
<RAOF> Yeah; it's all protected with DRM_AUTH.
<RAOF> But *everything's* got DRM_AUTH.
<RAOF> Hm. Unless dropping master revokes that auth; but then I don't think the X server or clients reauth on VT switch in, so I don't think that's it.
<mlankhorst> I'm not sure it would matter, if you get the fd you probably already have enough privilege 
<RAOF> But you can pass across fds.
<RAOF> mesa & X have different drm fds but share buffers.
<mlankhorst> not sure
<RAOF> Ok. At least that makes two of us :)
<mlankhorst> prime is simply fd passing though
<RAOF> My concern is with the system-compositor; it breaks some assumptions that may have been there providing security (the currently logged-in user is drm master, when you switch user they drop master, only the currently logged in user is in the active vt, etc)
<mlankhorst> so try to write an exploit to steal someone else's bo :-)
<RAOF> Ah. The experimentalist approach!
<RAOF> I prefer to start with the âask someone who knows what the hell is going onâ approach; it makes everything easier âº
<mlankhorst> oh with nouveau it's usually easier to start with RE'ing
<RAOF> Well I feel that the nouveau code could do with a clean up if the easiest way to understand it is to reverse-engineer the open source driver :)
<RAOF> And this (should be?) is in the common drm infrastructure, anyway.
<mlankhorst> RAOF: I don't mean RE'ing nouveau
<mlankhorst> the other implementation
<mlankhorst> you're the kind of person that sees 2 and 2 and thinks 2 right?
<RAOF> Right.
<mlankhorst> although sometimes RE'ing is hard, I tried to RE aaronp but he didn't manage to get me the answer whether nvidia supports y swizzling or not :(
<RAOF> Heh.
<RAOF> Ah. So, it seems the answer to âhow does drm auth prevent inactive users from snooping on the active user's buffersâ is âit doesn'tâ. Hurrah!
<sbeattie> bryceh: yeah, correct, I had them dump the one in the unaccepted proposed queue, since I'd already pushed it through -security (and by extension, -updates)
<mlankhorst> morning
<mlankhorst> RAOF: figures, I guess having access to the nodes means you can probably look at the screen too :-)
<RAOF> mlankhorst: You shouldn't, though.
<RAOF> *Particularly* when you're not actually active.
<mlankhorst> still beats nvidia in security, though
<RAOF> Well, yes. You get to screen-scrape other users, rather than escalate-to-root :)
<mlankhorst> upgrading everything to xorg 1.13 has proven to be a royal pain..
<mlankhorst> I guess with all the major ones done I should focus on bumping all input drivers first
<mlankhorst> RAOF: did we upload new libdrm yet?
<seb128> mlankhorst, hey, do you feel better today?
<mlankhorst> slightly :)
<mlankhorst> milk + honey helps a lot
<seb128> hehe
<seb128> mlankhorst, not sure if you saw by bryce did an upload reverting the previous SRUs fixes to workaround the segfault
<mlankhorst> not against the sickness but I can at least talk some again
<mlankhorst> yeah I saw
<mlankhorst> I'll put it on the blueprint to fix
<seb128> mlankhorst, it would still be good to debug the real issue and add those backs with the segfault fix, but it's less of an hurry with the revert in
<seb128> mlankhorst, thanks
<mlankhorst> wow ppa buildqueue is empty? Time to saturate it
<mlankhorst>  >:D
<mlankhorst> RAOF: tiem for.. https://launchpad.net/~mlankhorst/+archive/x-1.13
<mlankhorst> time*
<mlankhorst> how do I get arm enabled in my ppa though?
<mlankhorst> https://launchpad.net/ubuntu/quantal/+source/x11proto-randr/1.4.0+git20101207.0d32bb07-0ubuntu2 argh........ why call it 1.4.0 when it isn't O_O
<mlankhorst> RAOF: what should we do about binary driver breakage with x1.13?
<tjaalton> scr
<tjaalton> oops
<mlankhorst> yikes, seems my testing machine is dying
<mlankhorst> sata errors and mounting r/o is probably not good..
<ogra_> heh, xinerama is funny ... if i move glxgears around on a three hearded two cards multi screen xinerama setup, i get 
<ogra_> 8146 frames in 5.0 seconds = 1629.200 FPS
<ogra_> 579 frames in 5.0 seconds = 115.800 FPS
<ogra_> the latter is the low power card indeed ... 
<ogra_> if i play a game that actually spreads fullscreen across both cards/all monitors ... does xorg take an average value between the two cards or would i be capped to the lowest framerate ?
<mlankhorst> I didn't know xinerama did acceleration
<mlankhorst> capped to lowest most likely
<ogra_> well, i can play Xonotic with ~70fps at 5760x1080 ... 
<ogra_> (just tried)
<ogra_> (with effects set to ultra)
<ogra_> that somewhat looks like it uses an average or so 
<mlankhorst> nvidia drivers?
<ogra_> fglrx
<ogra_> sadly they drop randr and composite as soon as you switch on xinerama ... 
<mlankhorst> I didn't know it even supported xinerama, most of the time it will cause loss of all acceleration
<ogra_> well, given that radeon doesnt work at all in this config, i'm happy to at least have the fglrx stuff
<mlankhorst> ok input rebuilds, looks like 37 video drivers will need a version bump..
<mlankhorst> RAOF/bryceh: I doubt this can be automated, so could one of you maybe do it? I prepared nouveau, ati and cirrus in debian-experimental, so would just be a simple merge for those..
<mlankhorst> modesetting lacks any acceleration so it will work, I'll try uploading the rest to my ppa to see which works and which doesn't
<mlankhorst> oh right intel too
<mlankhorst> https://launchpad.net/~mlankhorst/+archive/x-1.13/+packages all those xserver-xorg-video-* need an update..
<Sarvatt> RAOF: here's the latest version of your out of tree stuff (with src/mesa/Makefile.am fixes added to fix i386 builds..) if it helps any http://bazaar.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools/view/head:/hooks/mesa-out-of-tree.patch
<Sarvatt> darn thing needs refreshing every day :)
<Sarvatt> saw you mention rebasing the patches the other day
<ricotz> Sarvatt, hey, you are still having fun with mesa :\
<Sarvatt> ricotz: yeah up to 6 commits that needed backporting to fix the build from this mornings checkout
<Sarvatt> hopefully this one works :)
<ricotz> hmm, aics it doesnt :\
<ricotz> 8.1~git20120717.f42e601c-0ubuntu0sarvatt5 
<Sarvatt> 6 is already uploaded
<ricotz> ok ;)
<Sarvatt> with http://cgit.freedesktop.org/mesa/mesa/commit/?id=bf484024b944a452e9022a1098313663e0028b29
<ricotz> you can upload a clean tarball too, just rename the version and tar.gz according to 8.1~git20120717.rX.f42e601c
<ricotz> i meant 8.1~git20120717.rX.xxxxxxxx
<Sarvatt> if this doesn't build either i will
<ricotz> i hope it works
<Sarvatt> ricotz: doesn't look promising http://tinderbox.x.org/builds/2012-07-17-0023/logs/libGL/#build
<Sarvatt> ..and it failed in gbm
<ricotz> Sarvatt, this looks fixes in master
<ricotz> http://cgit.freedesktop.org/mesa/mesa/commit/?id=2023bf996ed5c3797233b8d70670c28e15bdff75
<Sarvatt> yeah i'm doing a new tarball now
<Sarvatt> sucks the dev release gets +50 build score :)
<ricotz> quantal rules :P
<ricotz> \o/
<ricotz> Sarvatt, damn symbols, but is looks good
<Sarvatt> ricotz: ARGH :)
<ricotz> looks like an abi break
<mlankhorst> Sarvatt: if you had upload rights you could fixup the entire x1.13 stuff :-)
<Sarvatt> its not like we can upload it until the nvidia blob works :P
<Sarvatt> got a month or more
<mlankhorst> Sarvatt: true but have to update every single package that depends on video abi since rebuild won' t work with this big abi breakage
<mlankhorst> I will probably just upload the major ones to my repo for now
<mlankhorst> eg cirrus, vmware, ati, nouveau, modesetting, intel
<ricotz> mlankhorst, there are still some patch-rewrites needed too
<mlankhorst> ricotz: I uploaded xorg-server just fine though?
<ricotz> mlankhorst, i meant of the video drivers ;)
<ricotz> like for xserver-xorg-video-tdfx
<mlankhorst> oh sure
<ricotz> and most of them are broken due the xaa removal
<jcristau> are there still any users for the tdfx driver?
<ricotz> no idea
<Sarvatt> looks like its just tdfx broken against xserver 1.12 today, was a bunch more broken yesterday before the releases
<Sarvatt> ricotz: it probably builds fine against 1.13?
<ricotz> Sarvatt, upstream is fine, but the debian patches break it
<ricotz> https://launchpadlibrarian.net/110246017/buildlog_ubuntu-quantal-amd64.xserver-xorg-video-tdfx_1%3A1.4.4%2Bgit20120716.42706433-0ubuntu0ricotz_FAILEDTOBUILD.txt.gz
<ricotz> i might confused this with another package
<mlankhorst> Sarvatt: airlied updated all xorg driver upstreams and in most cases released a new version so it builds
<mlankhorst> bryceh/raof?
<bryceh> mlankhorst, what's up?
<bryceh> ah new drivers, yes may be worth resyncing
<mlankhorst> yeah the thing is with debian freeze it's hard to upload there first
<mlankhorst> so that means literally uploading every driver to ubuntu directly..
<bryceh> will debian be pulling them in at some point within the next month?
<mlankhorst> doubtful
<bryceh> I think, unless something's broken, there is not a rush to get them in; we'll need to poke all the drivers anyway if/when we pull in the newer xserver.
<bryceh> mlankhorst, maybe debian would be willing to pull the newer versions into experimental, and then we could sync from there?
<mlankhorst> bryceh: maybe, anyone here has the capability to upload to experimental?
<bryceh> mlankhorst, tjaalton might.
<mlankhorst> ok I' ll try him :)
<mlankhorst> don't know if he's back from vacation yet though
<RAOF> mlankhorst: The way we deal with binary driver breakage in 1.13 is an email to various lists saying âwe're about to break the binary drivers until we get a new set of blobsâ
#ubuntu-x 2012-07-18
<Sarvatt> hmm every icon that doesn't show up has a set of warnings like this in apitrace under newer mesa http://ubuntuone.com/7GDQiIb6yBkfzgm8fvX3WW
<DanaG> Say, how would one go about getting the xf86-video-modesetting driver in Ubuntu?
<DanaG> My microserver has an ASPEED remote management chip whose DDX won't do 1440x900 for the LCD that's attached to it... yet the KMS driver WILL do that resolution.
<DanaG> I tried fbdev, but it bails... can't mmap /dev/fb0, or something like that.
<Sarvatt> DanaG: dget -u -x https://launchpad.net/~xorg-edgers/+archive/ppa/+files/xserver-xorg-video-modesetting_0.4.0%2Bgit20120622.d9bb1847-0ubuntu0sarvatt~precise.dsc ; cd xserver-xorg-video-modesetting-0.4.0+git20120622.d9bb1847 ; debuild -uc -us -b ; sudo dpkg -i ../xserver-xorg-video-modesetting*.deb
<RAOF> Sarvatt: Too late! :)(
<RAOF> Sarvatt: Also, good morning :)
<Sarvatt> RAOF: morning, opposite side of the globe person :)
<mlankhorst> morning
<mlankhorst> to both you opposite side of the globe persons
<tjaalton> bryceh, mlankhorst: sorry, can't upload to debian yet. but it should be possible to first prepare the -exp branch and then ask if kibi/jcristau had time to upload them :)
<tjaalton> usually only the 'useful' drivers are uploade for new xserver testing though
<tjaalton> since they all would need to be reuploaded to unstable when the time is right
<RAOF> tjaalton: Were you the one who knows a guy behind Eclipse, the board game?
<tjaalton> RAOF: well, I've met him, but I know his wife better. but yes
<tjaalton> the artist, not Touko
<RAOF> Could you kindly tell him to get his arse into gear for the third printing? They didn't produce enough copies of the second printing to satisfy preorders, so I'm waiting until September/October :)
<tjaalton> haha :)
<tjaalton> ok I'll try to poke them. Actually better to ask the producer company I guess :)
<RAOF> Yeah :)
<tjaalton> hmm looks like it's in stock here
<tjaalton> Supernova too
<mlankhorst> tjaalton: yeah but I prepared most useful ones at this point now
<mlankhorst> libdrm to 2.4.37, ati to some git, nouveau didn't need a change but I dropped the patch for building with old drm, mesa untouched, cirrus, modesetting intel updated in exp
<tjaalton> looks like it :)
<mlankhorst> all input drivers just need a rebuild bump
<RAOF> bryceh: Oh, by the way, I've asked for a provisional MRE for mesa here: https://lists.ubuntu.com/archives/technical-board/2012-July/001352.html . If this goes well we should then go for a standing MRE for mesa. I've also pinged infinity for a normal SRU review of the mesa upload, but I suspect that the MRE will be the way to go.
<tjaalton> RAOF: oh wow
<RAOF> tjaalton: I think it's reasonable; we've got tools to be reasonably sure that we don't introduce regressions, and getting the bugfixes in new mesa would be shiny!
<RAOF> seb128: Gooood morning!
<seb128> oh, a RAOF! hey, how are you?
<tjaalton> RAOF: exactly
<RAOF> seb128: I'm pretty good. About to head off to pilates in ~10 minutes, though ;)
<RAOF> seb128: Hows about your fine self?
<seb128> RAOF, when the late european start showing up it's time to call it a day ;-)
<seb128> I don't say "european" because pitti and didrocks are probably there for some hours :p
<seb128> RAOF, I'm good thanks!
<RAOF> Yeah. Those crazy bastards have been busy ubuntu-driver-managering for hours!
<seb128> RAOF, how is the system compositor feedback so far? did you guys get some? I didn't manage to catch robert_ancell recently, he's too good at being off IRC at the end of the work day 
<RAOF> Haven't got a whole lot of feedback; got a bug from a system that was an unholy amalgam of the system-compositor PPA and xorg-edgers, though; that was fun.
<seb128> ahah
<seb128> I will try to install it today and see how it goes here
<RAOF> Although from some of the feedback it seems the setup is a bit more fragile than I thought; a reasonable number of people have reported pretty pink screens.
<seb128> I've been a bit limited in testing recently, my main box is still running precise since I'm working on 12.04.1
<RAOF> Fair enough.
<RAOF> Support our mesa MRE! :)
<RAOF> Of course, everything worksÂ¹ on my systems.
<seb128> do you have a system-compositor tag or something for those bugs?
<seb128> lol
<seb128> everything always work on your systems :p
<RAOF> Â¹ For values of âworksâ sufficiently broad. âº
<seb128> oh, applying for a MRE? fun ;-)
<RAOF> Yeah; mesa's useful enough, and we can test it well enough.
 * RAOF â pilates.
<seb128> RAOF, have fun!
<mlankhorst> ah well uploaded other video drivers too to my ppa now
<mlankhorst> oh it was airlied who upstreamed the copy fb patch :)
<jcristau> it only took 5 years
<ricotz> mlankhorst, hey :)
<mlankhorst> heya
<ricotz> mlankhorst, i saw you updated the ubuntu branch, is 1.13 already on track for quantal? i thought this wasnt settled yet
<mlankhorst> ricotz: rc1 is out, video abi is settled
<mlankhorst> prime otoh still needs love
<ricotz> mlankhorst, rc2 is out ;)
<ricotz> i just thought it wasnt decided yet wether to go with it
<mlankhorst> ricotz: maybe, I'm just racing to get the sync patches ready for 3.6..
<ricotz> mlankhorst, alright, thanks for "racing" though ;)
<mlankhorst> rebased my dmabufmgr patches now on top of the new dma fence, but waiting for api to be complete before I can actually do something with it. :-)
<mlankhorst> I'll upload Xorg 1.13 rc2 now
<mlankhorst> 31 drivers remaining...
<mlankhorst> This xserver driver updating is making me go insane
<mlankhorst> https://launchpad.net/~mlankhorst/+archive/x-1.13/+packages after a commit spree my sea of red is slowly becoming green :)
<mlankhorst> ricotz: halfway through now..
<mlankhorst> and x1.13rc2 failed on the smoke screen test ;)
<ricotz> mlankhorst, i see, oh, i have it in my ppa and running it
<mlankhorst> yeah I was just fixing all the trivial xserver-xorg-video ones
<mlankhorst> which probably killed off a few brain cells due to tedious reptition :)
<mlankhorst> ricotz_: do you use vanilla x though?
<ricotz> mlankhorst, no, the xedgers based system
<mlankhorst> ah
<ricotz> mlankhorst, ready to be copied if nvidia catches up
<mlankhorst> looks like mach64 fails to build, sigh
<ricotz> mlankhorst, yeah but only i386
<ricotz> mlankhorst, https://launchpad.net/~ricotz/+archive/unstable/+packages
<mlankhorst> ricotz: I know
<mlankhorst> it's not built on amd64 probably
<mlankhorst> fix is a 1liner though
<ricotz> sounds promising
<mlankhorst> $ cat debian/patches/01_fix_build.diff ..
<mlankhorst> -        ATISwitchMode(0, pScreenInfo->currentMode, 0);
<mlankhorst> +        ATISwitchMode(SWITCH_MODE_ARGS(pScreenInfo, pScreenInfo->currentMode));
 * mlankhorst makes a mental note to push the patch
<mlankhorst> not patient enough, pushed without testing :)
<ricotz> hehe ;)
<mlankhorst> oh looks like he already fixed it in the same way
<mlankhorst> to better help my sanity I'm going to declare EOD early and look at build failures later in the evening, bb :p
<mlankhorst> weird.. build timed out but if I try locally it works
<mlankhorst> and rebuild worked too, I'll just pretend that I didn't see it hang in launchpad earlier.
<RAOF> mlankhorst: You know about rebuild-all-drivers in xorg-pkg-tools, right? That's obviously not going to be useful here because you need to get upstream changes for all the non-input drivers, but next time, maybe! :)
#ubuntu-x 2012-07-19
<mlankhorst> RAOF: I was using that for input
<mlankhorst> but I can't automate video
<RAOF> Yeah, you need source changes for the new ABI.
<mlankhorst> and I automated as much as I could for those, but the git commands need to be done manually sadly
<mlankhorst> RAOF: could you upload ubuntu branch of libdrm again? it nukes libdrm-intel1 on arm (but that might need to be reinstated for plymouth, sigh!)
<RAOF> Yes, we do need libdrm-intel1 for plymouth, even on intel.
<RAOF> Ooooh, no!
<RAOF> slangasek has kindly stopped building plymouth against libdrm-intel on !x86.
<mlankhorst> indeedy
<RAOF> mlankhorst: Hm, the ubuntu branch doesn't contain the changelog for the current version in the archives?
<RAOF> Bah. Because I didn't push when I uploaded it for you. Sorry.
<RAOF> mlankhorst: I'll fix that up.
<mlankhorst> k :-)
<mlankhorst> in some of the cases with video drivers I even merged the ubuntu branch again if it wasn't too out of date
<RAOF> GAH! That's why it's always building against Xwayland. I've got the xwayland server installed system wide. DUH!
<mlankhorst> RAOF: or you could have my git problem :-)
<mlankhorst> but it seems to be solved now, evil git
<mlankhorst> turns out git lets you merge anything
<mlankhorst> ricotz: heh got tons of the repos done now, some are more broken than others though..
<mlankhorst> but looks like yesterday I handled most of the 'good', today will be 'bad', and 'ugly' I'll defer :)
<ricotz> mlankhorst, nice :)
<mlankhorst> RAOF: where is geode maintained? doesn't seem to be in X
<mlankhorst> last one for xserver-xorg-video-all
<ricotz> mlankhorst, http://cgit.freedesktop.org/xorg/driver/xf86-video-geode/ ?
<mlankhorst> no the debian git branch
<ricotz> mlankhorst, ah i see
<mlankhorst> and uploaded last one for xserver-xorg-video-all to work on amd64..
 * mlankhorst booze
<mlankhorst> ok wacom needs a bump, but other than that I can confirm that x1.13rc2 works, huzzah!
<mlankhorst> bryceh/raof: my ppa is complete for now :-)
<mlankhorst> bryceh: I pushed most of x 1.13 to my ppa :)
<bryceh> mlankhorst, excellent
<bryceh> mlankhorst, you might consider posting to the ubuntu-devel@ mailing list that the sru is available, to stir up some testers
<mlankhorst> i want arm build complete first, and geode is broken
<mlankhorst> so I'm tempted to release a new xorg too that kills geode
<mlankhorst> but where do I fill out the paperwork to get it removed from master unless people start to complain?
<mlankhorst> s/master/main/ too much git today/yesterday
<mlankhorst> sigh, I'll pretend I didn't see the valgrind complaints about intel_drv 2.20..
<mlankhorst> bryceh: since there are enough problems pinned to input drivers should I make -dbg packages for wacom, evdev and synaptics?
<mlankhorst> makes it easier on quick debugging if i dont have to rebuild first
<bryceh> mlankhorst, yes that's a good idea
<bryceh> mlankhorst, would probably make sense to get those changes into debian
<mlankhorst> bryceh: sure
 * mlankhorst has been doing nothing but updating debian first past few days
<mlankhorst> poor arm builder, still stuck on xorg-server :)
<tjaalton> we already have ddebs
<tjaalton> and wacom is essentially forked
<jcristau> bryceh: the blocker for getting mlankhorst's work into debian is somebody with both debian upload rights and some free time.
<mlankhorst> pretty much
<mlankhorst> tjaalton: the thing is ddebs don't work on ppa and it's still easier to just install a -dbg without needing to fish around on a wiki to figure out what you need to do to enable it..
<mlankhorst> tjaalton: don't underestimate the power of git-merge, I managed to merge 2 incompatible repos with it. :P
<tjaalton> mlankhorst: yep, forgot the ppa thing
<tjaalton> hehe
<mlankhorst> witness xserver-xorg-video-openchrome >:O
<tjaalton> i'll have a look later :)
<mlankhorst> that repo was using svn, but kibi did some extra thing to mess it up, still managed to convert it to the upstream git after a lot of messing around with git
<bryceh> mlankhorst, I see that xserver 1.12.99.902 is staged in git; what is the eta on getting that uploaded to quantal?
<mlankhorst> bryceh: really depends on how fast someone uploads everything required to debian
<bryceh> ok
<jcristau> hmm?  an upload to debian is a prerequisite?
<mlankhorst> shrug if not just upload everything tomorrow
<mlankhorst> but I' d need to update xorg to remove geode in that case
<bryceh> why removing geode?
<mlankhorst> hasn't been updated, doesn't build currently
<bryceh> mm
<mlankhorst> we might be able to re-add it later though if it's really needed
<bryceh> well, the maintainer had been pretty active with us in the past.  but I think the funding dried up
<bryceh> would be worth emailing the maintainer in any case
<mlankhorst> depending how much it's needed I could just fix up compiling myself
<mlankhorst> it's not that much work, just tedious
<mlankhorst> bryceh: anyhow if you feel like adding -dbg to synaptics, evdev, wacom you could probably just do a release now :)
<bryceh> mlankhorst, are the changes in git?
<mlankhorst> not yet, eod for me
<mlankhorst> bryceh: but if you want to do it :)
<bryceh> mlankhorst, nah, but I'd be happy to sponsor an upload if you wanted to do it
<mlankhorst> SURE
<mlankhorst> sure*
<bryceh> Sarvatt, you have some ubuntu-oneiric mesa changes not pushed to git... mind adding them?
<bryceh> Sarvatt, ok well I've pushed my changes anyway, maybe it doesn't matter they're not included in git, I don't see us updating the oneiric branch so often now.
<mlankhorst> he's a terrorist for not using git though, makes it so much easier for me if everything's just there..
 * mlankhorst glares at Sarvatt >:O
<bryceh> it's ok, he just fixed it
<Sarvatt> there was a reason at the time, SRU was up in the air if it would even be accepted for a month or two because it did so much
<Sarvatt> but yeah sorry about that, bonehead move :)
#ubuntu-x 2012-07-20
<mlankhorst> tjaalton: ping?
<mlankhorst> oh nm I'll just send you a pull request, always wanted to do one of those
<mlankhorst> RAOF: if you merge something please do it properly ;)
<mlankhorst> try git diff c44dd5f11702cfc07f828d7f4716dc9cb7d257d0...ubuntu in libdrm
<mlankhorst> tjaalton: I updated xf86-input-wacom in your tree
<mlankhorst> bryceh/RAOF: evdev done, wacom done, synaptics done, xserver-xorg-video-all (minus geode) done. Xorg server ready, let her rip?
<mlankhorst> I'll give the geode thing a shot first
<RAOF> mlankhorst: Yeah, that was actually deliberate.
<mlankhorst> RAOF: why?
<RAOF> Because 2.4.37-0ubuntu1 was a pre-sync from debian-experimental; it wasn't actually a merge, so it doesn't need the previous changelog entries.
<mlankhorst> ok
<RAOF> When we sync we drop all the previous Ubuntu changelogs, partially because they no longer accurately describe the lineage of the package, partially because it's easier. :)
<mlankhorst> shrug git-merge handles changelog entries for me automatically, but yeah
<RAOF> Oh, yeah. It does for me, too.
<mlankhorst> ok I'm just setting up my quantal-i386 changeroot again, I automated most of it now though
<mlankhorst> RAOF: you could start uploading xorg-server to -proposed though with a note to keep it there for a bit, then prepare xserver-xorg-input-*
<mlankhorst> for the video drivers, openchrome was updated to 0.3.0 but I couldn't find a binary package, and the real 0.3.0 name will conflict with openchrome from hardy so you need to change version probably
<mlankhorst> ati and cirrus are git snapshots since they didn't post a release that worked in time
<mlankhorst> and the rest of the *.orig.tar.gz I'll sell to you for a small price
<mlankhorst> :P
<jcristau> openchrome 0.3.0?
<jcristau> ah.
<jcristau> i was remembering the version wrong
<mlankhorst> apm ark ati chips cirrus dummy fbdev glide glint i128 i740 intel mach64 mga modesetting neomagic nouveau openchrome qxl r128 rendition s3 savage siliconmotion sis sisusb tdfx trident vesa
<mlankhorst> all the xorg video drivers that I had updated
<mlankhorst> geode is going to need another fix but doesn't seem to use version control
<mlankhorst> working on it though as soon as this apt-get dist-upgrade finishes
<mlankhorst> ok early eod for me, still working on fixing up geode source
<mlankhorst> will complete tomorrow :)
<RAOF> mlankhorst: You know tomorrow's Saturday, right? :)
<RAOF> mlankhorst: I'm trying my hand at robustifying the âget apport to catch Xserver crashesâ patch; I think I can do that before uploading 1.13 (ie: it'll be done Monday or Tuesday)
<RAOF> Now, sleep
<mlankhorst> RAOF: yeah just moving up this afternoon to play wtih a friend, and maybe visit him next week in afternoon :)
<bryceh> tjaalton (and mlankhorst), I've moved the question you added at the end of https://wiki.ubuntu.com/X/Blueprints/LtsPointUpdatesForXorg up into the body proper.  What you listed as upgrade paths looks proper to me (and leann says it fits with foundation's recollection of the upgrade plan).
<bryceh> apparently there's been some confusion about how we're going to handle the upgrades so hopefully this will help us nail things down.  Please take a look and make sure it's covering things correctly.
<mlankhorst> bryceh: I would really want to sru libdrm if possible
<mlankhorst> so that only packages pulled in by xorg would get updated
<mlankhorst> this would make it possible to nuke the entire X stack and move back to the old one if needed :)
<bryceh> mlankhorst, well good luck getting that by the sru admins...
<mlankhorst> bryceh: I know, but it would make Xorg so much easier
<bryceh> if there's specific patches in particular that would help, that might be doable.  but I don't know
<mlankhorst> bryceh: it's specifically that having the new version shouldn't break existing functionality, and would make switching between new Xorg and old easier by a multitude
<mlankhorst> same for libXrender, if things would mess up, apt-get remove .*lts-quantal could be made to work
<mlankhorst> without leaving a severely broken system
<mlankhorst> although maybe xrandr needs a different solution
<mlankhorst> I think it makes sense to define the backported X stack as xorg package + xorg-server-core + all drivers + mesa
<mlankhorst> and x11proto probably :)
<mlankhorst> but if we would do that, there's no creepy magic going on any more, it would just be a different set of xorg packages
<mlankhorst> just mesa+xorg+xorg-server-core+drivers under a different name
<mlankhorst> if things mess up, we could create a script that uninstalls all the renamed xorg packages, the original xorg package names, and reinstall the original packages without leaving the system in a creepy halfbroken state because of libdrm
<mlankhorst> that would also mean sru'ing the fix for plymouth on arm, but we should really aim for it :)
<bryceh> mlankhorst, have you talked with RAOF about this?  what's his take?
<mlankhorst> not sure yet
<mlankhorst> I'm gonna pester him, and after x1.13 is uploaded do another renamed x stack for testing, but this time only including the packages I want to update unrenamed, and the x stack itself renamed
<mlankhorst> to show you can switch between them without scary brokenness
<mlankhorst> or at least, when it does break but it would leave your system in a state where it can still boot :)
<jcristau> booting is overrated
<mlankhorst> I already had a problem where I uninstalled libdrm-renamed, but the old libdrm was overwritten by it
<jcristau> at which point no plymouth, and things get unhappy?
<mlankhorst> erm plymouth package is fine, it was just libdrm*.so.* missing
<mlankhorst> which plymouth didn't like very much
<jcristau> yeah that's what i meant by no plymouth
<jcristau> sorry
<mlankhorst> :)
<tjaalton> mlankhorst: oh you managed to update it, cool. the shared repo sometimes doesn't really work that well..
<tjaalton> should probably push it to kernel.u.c or such..
<tjaalton> bryceh: ok, thanks. I'll read it once it's nice and calm ;)
<mlankhorst> it's fine though
<tjaalton> great then, remember there were some issues with it earlier
<tjaalton> ooh new upstream
<tjaalton> 0.15 wasn't interesting
<tjaalton> bryceh: yeah it looks fine
 * bryceh nods
<tjaalton> did update the 12.04.0 x stack column to 'no update' though (instead of 'none' :)
<tjaalton> https://wiki.ubuntu.com/Kernel/Release/Rolling looks scary, for 14.04
#ubuntu-x 2013-07-15
<ricotz> Sarvatt, you are starting to like "criticial" ;)
<a5m0> i see a new intel driver, is this one memory leak free?
<Sarvatt> yeah it was just that 0708 one that was messed up
<Sarvatt> ricotz: i see medium is working out for you :)
<a5m0> awesome
<Sarvatt> queue time was pretty much the same there but no mozilla/webkit bomb going on
<ricotz> Sarvatt, yeah i am less invasive ;P
<ricotz> mozilla can jam up everything
<Sarvatt> mesa is realistically the only one i upload that needs the urgency bump i guess..
<Sarvatt> about to upload that btw
<ricotz> alright
#ubuntu-x 2013-07-16
<zzippy> Hi. Question. why isn't there a unity package anymore in x-staging PPA for raring?
<zzippy> using PPA breaks unity in raring. have to use raring-proposed unity ..
<mlankhorst> because the only reason the xorg-server package in raring still exists is so that you can ppa-purge it correctly :-)
<mlankhorst> if you want it + updates, move to saucy
<zzippy> mlankhorst: ok, but there are people out there not running a development version, they want 13.04 and X-server 1.14.x for using "optimus native" ;)
<zzippy> it's just unnecessary to break somebody's system.
<mlankhorst> that may be, but I didn't push the fixes to raring and I don't want to maintain it, so if you want the latest 1.14 upgrade to saucy
<mlankhorst> but nothing prevents you from making your own ppa with all the fixes from saucy, could even be automated with backportpackage..
<zzippy> ehrm, ok.
<ricotz> mlankhorst, hi :)
<mlankhorst> hey
<ricotz> mlankhorst, just curious will wine 1.6 land in saucy? 
<mlankhorst> ask yokozar
<ricotz> ok
<Sarvatt> hyperair: get ready for more bustage with edgers, intel guys saying it needs a 3.12 kernel over in #intel-gfx.... :)
<hyperair> D=
<hyperair> time to comment out the sources, i guess
<ricotz> tseliot, hi :), this might be interesting for you https://launchpadlibrarian.net/145023470/nvidia-graphics-drivers-304_304.88-0ubuntu5_304.88-0ubuntu5%2Bxedgers~saucy1.diff.gz
<tseliot> ricotz: oh, 3.11 already... thanks ;)
<tseliot> finally a small diff
<ricotz> tseliot, same for 325.08 so i guess this simple addition also works for 319.x
<tseliot> right
<ricotz> Sarvatt, uh, what needs 3.12 :\
<Sarvatt> [10:49:27] <jbarnes> just recently updated to the 2.21.12 version of the DDX from edgers
<Sarvatt> [10:49:35] <jbarnes> now I see all sorts of stale data getting blitted all over
<Sarvatt> [10:49:43] <jbarnes> esp in claws with the tooltip windows
<Sarvatt> [10:55:01] <jbarnes> I'm running a 3.9.0-rc3+ ish kernel
<Sarvatt> [10:55:08] <ickle> you'll need something like 3.12 to have all known breakage fixed
<Sarvatt> no problems here on 3.10 at least
<Sarvatt> but i havent rebooted into the latest updates :)
<ricotz> Sarvatt, oh, i noticed some small drawing issues, although running 3.11rc1
<maxb> Given that a normal Ubuntu installation does without an /etc/X11/xorg.conf these days, what is the recommended way to set a single "Device" option? ("SWCursor" in my case) ?
<Sarvatt> maxb: http://paste.ubuntu.com/5882371/ as xorg.conf
<maxb> thanks
<Sarvatt> just guessing its radeon
<maxb> It is a radeon card, I was just contemplating whether the Driver line needed to say "ati" or "radeon"
<Sarvatt> ah its "SWcursor" if case matters
#ubuntu-x 2013-07-17
<hyperair> Sarvatt: is webgl in chromium broken for you?
<Sarvatt> hyperair: it always has been.. :(
 * Sarvatt doesn't remember a time when he didnt see [421894.855653] chrome[27911]: segfault at 50 ip 00007f2e880f33e7 sp 00007fff1b4f1e70 error 4 in libdricore9.2.0-devel.so.1.0.0[7f2e88044000+3c0000]
<Sarvatt>  when loading google maps
<Sarvatt> well some things work but maps is screwed
<Sarvatt> new google maps is screwed on windows on the same machine too though :)
<Sarvatt> hyperair: does a gen4 intel even support es2.0?
<Sarvatt> i dont think ironlake (gen5) is even on the whitelist yet, check chrome://gpu/
<hyperair> Sarvatt: es? i don't think so.
<hyperair> Sarvatt: i recall trying to play tf2 on a core 2 duo machine
<Sarvatt> tf2 needs a sandybridge+ last i looked :(
<hyperair> and gen5 doesn't work either, i checked glxinfo on that machine.
<hyperair> yeah pretty much
<hyperair> i recall webgl working on chromium in the past, but it crashes out when i try to use it on this machine.
<Sarvatt> what site?
<hyperair> (i just moved from snb to ivb recently)
<hyperair> eh a lot of test webgl sites
<hyperair> http://get.webgl.org/
<hyperair> https://support.google.com/chrome/answer/2905826?p=ib_webgl&rd=1 <-- i get this
<hyperair> oh, segfault.
<hyperair> i just noticed a bunch of chromium-browser segfaults in dmesg
<Sarvatt> yeah thats what i get when i try using new google maps on 9.2, but stuff like http://www.chromeexperiments.com/webgl/ work on my ivybridge
<hyperair> #0  0x00007fbd63bc03e7 in _mesa_BindFramebuffer () from /usr/lib/x86_64-linux-gnu/libdricore9.2.0-devel.so.1
<hyperair> hmm.
<Sarvatt> got Hmm. While your browser seems to support WebGL, it is disabled or unavailable. If possible, please ensure that you are running the latest drivers for your video card.on get.webgl.org
<hyperair> oh that's the blacklist
<hyperair> overridable ;-)
<Sarvatt> right, get.webgl.org works after overriding
<Sarvatt> spinning cube
<hyperair> haha
<Sarvatt> 5 chrome segfaults in dmesg... :P
<hyperair> GpuProcessHostUIShim: The GPU process crashed!
<hyperair> plenty of segfaults for me too in ivb
<hyperair> mesa bug?
<Sarvatt> well they'll probably say its your fault for overriding the blacklist :P only 30 minutes to ppa-purge and try 9.1.4 with all these private ppas from purchases slowing it down..
 * hyperair whistles
<Sarvatt> 20 minutes for an apt-get update ftw
<hyperair> i don't know where my --ignore-gpu-blacklist comes from actually
<hyperair> hmm
<Sarvatt> set it in about:flags?
<hyperair> oh hmm, it seems to be /usr/bin
<hyperair> did i modify that?
<hyperair> local diversion of /usr/bin/chromium-browser to /usr/bin/chromium-browser.distrib
<hyperair> hohoho
<hyperair> oh nice, it doesn't segfault any more
<hyperair> ay
<hyperair> yay*
<darkxst> X won't start at boot on my system after todays update http://paste.ubuntu.com/5882962/
<darkxst> I'm just getting dropped to a VT, where startx does work
<mlankhorst> darkxst: it doesn't load nvidia_drv.so for some reason, any idea why?
<darkxst> mlankhorst, nope, no idea, particularly given it loads find with startx from a VT
<darkxst> s/find/fine/
<mlankhorst> find the difference in the log between working/broken then..
<darkxst> mlankhorst, this is only there in the working log -> http://paste.ubuntu.com/5883334/
<mlankhorst> darkxst: what if you add nvidia to /etc/modules ?
<darkxst> I will try shortly, can't reboot right now..
<darkxst> mlankhorst, so I rebooted and it decided to work again now
<darkxst> (without touching the modules file)
#ubuntu-x 2013-07-21
<Duke`> I often encounter corrupted pictures with firefox and intel driver (from xorg-edgers, of course)
<Duke`> http://img15.hostingpics.net/pics/852388corruptionintelfirefox.png
<Duke`> I have an i945GM and have seen this bug for months, now
<Duke`> since I was running linux 3.8, I tried linux 3.10 yesterday, but the bug remains
#ubuntu-x 2014-07-14
<Prf_Jakob> mlankhorst: It might be a bug, which version of ubuntu? And what does dmesg say?
<mlankhorst> utopic, nothing extraordinary in dmesg
<Prf_Jakob> Does it say it has 3D or not?
<mlankhorst> it says it doesn't
<Prf_Jakob> Hmm okay, what drivers does the host have? We have backlisted most of the foss drivers.
<mlankhorst> nouveau
<Prf_Jakob> Yeah that would probably explain it.
<mlankhorst> can I override it? developing with blob is a pain
<Prf_Jakob> Try to enable it in the app, and then look in the vmware.log, there should be a error message that mentions a flag.
<Prf_Jakob> I don't have it swapped into memory.
<mlankhorst> actually it doesn't seem to mention a flag in the message log
<Prf_Jakob> Dang it, I'll ask internally.
#ubuntu-x 2014-07-15
<Prf_Jakob> mlankhorst: add this line to the vmx file
<Prf_Jakob> mks.gl.allowBlacklistedDrivers = TRUE
<mlankhorst> ah k
<mlankhorst> awesome! thanks
<Prf_Jakob> *insert legal disclamer of not being supported*
<mlankhorst> I don't think my current config is supported anyway
<Prf_Jakob> right
<Prf_Jakob> "Last I heard, AMD was crashing, Intel kinda sorta works, I haven't tried nouveau."
<mlankhorst> breaks :p
<mlankhorst> [ 4268.987132] nouveau E[vmx-mks[26567]] push 0 buffer not in list
<mlankhorst> but that should be fixable
<mlankhorst> I have a hack for threaded opengl at least, this looks similar
<Prf_Jakob> right
#ubuntu-x 2014-07-16
<Sarvatt> ricotz: need to use origin/ubuntu for utopic to build, +1 is missing the fix
<Sarvatt> uploading the mesa fix now
<ricotz> Sarvatt, thanks!
#ubuntu-x 2014-07-17
<ricotz> mlankhorst, hi, please consider updating libxi -- this includes an additional post-release fix https://launchpad.net/~ricotz/+archive/ubuntu/testing/+sourcepub/4300601/+listing-archive-extra
<mlankhorst> hm
<jcristau> meh.  there'll be 1.7.4 in a couple of days.
<mlankhorst> ah no point then :p
<mlankhorst> been busy with xorg-server 1.16 transition in ubuntu
<ricotz> mlankhorst, alright
#ubuntu-x 2015-07-19
<tjaalton>   /away
<tjaalton> uh
<tjaalton>  /away
<tjaalton> ffs
#ubuntu-x 2016-07-21
<marun> hi i have problem with vulkan on intel HD4600
<marun> i enabled dri3
<marun> cat /usr/share/X11/xorg.conf.d/10-intel.conf  Section "Device"    Identifier  "Intel Graphics"    Driver      "intel"    Option      "DRI"    "3" EndSection
<tjaalton> noone cares about intel anymore, yakkety switched to modesetting
<tjaalton> and the vulkan ppa is dead
<tjaalton> mesa 12.0 with vulkan will arrive soon, i hope
<tjaalton> stuck in new queue
<tjaalton> for yakkety
<marun> is it good idea to use oibaf ppa? it has mesa 12
<marun> i was off trying oibaf ppa but it didn't work either
<marun> is there any hw setup that could run vulkan?
<tjaalton> why do you need it?
#ubuntu-x 2016-07-22
<lol768> Hi there, I'm interested as to when https://lists.x.org/archives/xorg-devel/2016-July/050321.html will become available in Ubuntu's X server package?
<lol768> Do I need to file a bug report even if upstream have already fixed this?
<lol768> VirtualBox is pretty much intermittently unusable with Ubuntu for me
<lol768> Or rather to reword: running Ubuntu inside VirtualBox is intermittently problematic for me to the extent that the guest OS becomes unusable
<tjaalton> lol768: is it in 1.18.4?
<lol768> I'm not entirely sure, I know the patch was accepted but I can't find a trace of any sort of commit in the VCS
<tjaalton> then it's not fixed upstream, until applied
<lol768> "This has now been fixed in the upstream X server"
<lol768> https://www.virtualbox.org/ticket/15511
<lol768> https://www.virtualbox.org/ticket/15511#comment:25
<tjaalton> yes and is in 1.18.4 so yakkety has it
<lol768> Right but that's not released yet
<lol768> will it be backported to Xenial?
<tjaalton> eventually
<tjaalton> there's another sru pending which will be handled first
#ubuntu-x 2017-07-17
<mamarley> ricotz: I uploaded new builds of 340.102 with 4.11 and 4.12 support to https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages.
#ubuntu-x 2017-07-18
<mdeslaur> Could someone take a look and help me figure out why this build is failing? https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+build/13101220
<tseliot> mdeslaur: FAIL: input
<tseliot> input: ../../test/input.c:1773: process_input_proc: Assertion `ev->any.type == ++last_evtype' failed.
<mdeslaur> tseliot: yeah, what's up with that?
<tseliot> mdeslaur: do you have access to test/test-suite.log ?
<mdeslaur> I don't, no
<mdeslaur> I'll have to find an armhf box
<tseliot> yes, that would help
<jcristau> tseliot: test-suite.log won't have anything more than the assertion message
<jcristau> (the test log is included in the build log, as we pass VERBOSE=1 to make check)
<tseliot> jcristau: good to know, thanks
<mamarley> ricotz: Did you see my message yesterday about adding kernel patches for 340.102 in https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages ?
<ricotz> mamarley, hi, hmm, I guess I missed it
<ricotz> mamarley, nice, although precise and yakkety are EOL
<ricotz> copied :)
#ubuntu-x 2018-07-17
<mamarley> ricotz: I've got 390.77. :)
<mamarley> This one improves compatibility with 4.18 (that DRM symbol doesn't have to be removed anymore), but it still has the GPL-only symbol issue.
<ricotz> mamarley, alright :)
<mamarley> ricotz: They are uploaded in https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages now, but it looks like the ARM queue is all backed up right now.
<ricotz> ok
#ubuntu-x 2018-07-20
<ricotz> mamarley, hi, which vulkan api does 396.45 report?
<mamarley> ricotz: "apiVersion     = 0x401046  (1.1.70)"
<mamarley> (I guess it goes without saying that 396.45 is ready in my staging PPA ;) )
<ricotz> mamarley, I see, I feared so, and yeah I saw ;)
<ricotz> 396.24.10 has way more recent vulkan support
<mamarley> :/
<mamarley> Yeah, to be honest, I was expecting a new major release.  Especially because 396.45 was already a couple of weeks past the "normal" schedule.
<ricotz> yeah, so I am torn about how to proceed with this update :\
#ubuntu-x 2020-07-15
<ricotz> tseliot_, hi, nvidia-graphics-drivers-450 needs to be enabled for i386 builds
#ubuntu-x 2020-07-16
<ricotz> tseliot_, the 450 bionic backport is missing the alternative dep on xserver-xorg-core-hwe-18.04
<tseliot_> ricotz, I'll fix that. It's also missing a library
<ricotz> thank you
<tseliot_> ricotz, 450 should be fixed now
<ricotz> tseliot_, thanks I guess adding xserver-xorg-core-hwe-20.04 would be reasonable too
<tseliot_> ricotz, if/when we can a new xserver
