#ubuntu-x 2007-01-15
<Ubugtu> New bug: #79347 in xserver-xorg-input-evdev (main) "Unresolved symbol "set_bit" in evdev_drv.so crashes X (fixed upstream)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79347
<Ubugtu> New bug: #78069 in xorg (main) "Installer hangs or slows down dramatically" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78069
<Ubugtu> New bug: #68075 in xserver-xorg-video-ati (main) "Unknown ATI Video Card (X1000-series)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/68075
<Ubugtu> New bug: #79403 in xorg-server (main) "Screen turns white when using beryl or desktop effects" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79403
<Ubugtu> New bug: #79452 in mesa (main) "libgl1_mesa_dri segmentation fault" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79452
#ubuntu-x 2007-01-16
<Ubugtu> New bug: #71763 in vnc (main) "Font problems (dup-of: 2066)" [Undecided,Needs info]  https://launchpad.net/bugs/71763
#ubuntu-x 2007-01-18
<Ubugtu> New bug: #80376 in xserver-xorg-video-i810 (main) "compiz crashes X on intel GMA x3000" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80376
<Ubugtu> New bug: #80413 in xorg (main) "intermittent X crashes with edgy" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80413
#ubuntu-x 2007-01-19
<Ubugtu> New bug: #80500 in xorg (main) "intel 965 G1 graphics controller blurs during feisty-desktop-i386 install" [Undecided,Needs info]  https://launchpad.net/bugs/80500
<Ubugtu> New bug: #80653 in xserver-xorg-video-sisusb (main) "SiS driver don't seems to work after upgrade" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80653
#ubuntu-x 2007-01-20
<Ubugtu> New bug: #80731 in xorg (main) "Xorg consuming too much memory in Edgy" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80731
<Ubugtu> New bug: #80763 in xorg (main) "Feisty Herd 2 LiveCD crashes with 3dfx video card" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80763
#ubuntu-x 2007-01-21
<Ubugtu> New bug: #80792 in xorg (main) "X fails to start, agpgart error" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80792
<Ubugtu> New bug: #80836 in xorg (main) "xorg crashes when evolution starts causing mail-notification display a popup" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80836
#ubuntu-x 2008-01-14
<Q-FUNK> especially since a lot of people already expect this to work in gutsy
<tjaalton> I guess the xresprobe bugs can be marked as wontfix now
<bryce> true
<bryce> I can take care of that tomorrow if you'd like
<Q-FUNK> hm?
<Q-FUNK> what about xresprobe?
<tjaalton> Q-FUNK: obsolete
<bryce> it's deprecated now
<Q-FUNK> replaced by?
<tjaalton> xserver autoconfiguration
<Q-FUNK> ah yes
<tjaalton> bryce: there are only 11 of them, no big deal :)
<tjaalton> I need more karma :)
<bryce> hehe
<bryce> ok go for it
<Q-FUNK> although this doesn't yet work for all drivers.  they need to be ported to randr 1.2 and upgraded to recent api.
<tjaalton> hmm no
<tjaalton> it doesn't depend on randr 1.2
<tjaalton> although there are some issues with vesa at least
<Q-FUNK> and with -amd
<Q-FUNK> siliconmotion also
<bryce> what issues?
<tjaalton> "no modes left" with vesa
<bryce> ah
<Q-FUNK> for DDC probing, bartman produced patches that should at least fix -amd.
<Q-FUNK> that sound familiar from other drivers too.
<Q-FUNK> IIRC someone reported that for -amd as well, on some hardware.
<tjaalton> trident is buggy too, it hangs in a loop
<tjaalton> but it's upstream now with a backtrace
<Q-FUNK> ah, btw, amd 2.7.7.5 is in debian now
<Q-FUNK> it introduces basic OLPC support
<tjaalton> ok, file a sync request again, and tell the bug #
<Q-FUNK> grmbl.  doesn't yet show in changelog server.
<tjaalton> there, 11 bugs closed
<Q-FUNK> #182781
<Q-FUNK> hmm
<Q-FUNK> this is in main, right?
<Q-FUNK> or is it still in universe?
<tjaalton> main
<ubotu> New bug: #182778 in xserver-xorg-video-openchrome (main) "Wrong resolution on Hardy Alpha 3" [Undecided,New] https://launchpad.net/bugs/182778
<tjaalton> heh, add openchrome to the list
<tjaalton> there are also a lot of reports about not being able to change the resolution on livecd
<tjaalton> which puzzles me
<bryce> hrm
<tjaalton> but that's an old issue
<bryce> "not change" as through xorg.conf, or via displayconfig-gtk
<bryce> ?
<tjaalton> xrandr or d-g
<bryce> odd
<tjaalton> yep
<tjaalton> maybe #u-installer could help, I'll ask
<ubotu> New bug: #182781 in xserver-xorg-video-amd (main) "Please sync xserver-xorg-video-amd 2.7.7.5-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/182781
<bryce> tjaalton: heh, we've triaged too many bugs.  bdmurray has skipped us in favor of openoffice for bug hug day this month
<tjaalton> :)
<bryce> looks like between xorg, xserver, and major drivers, we barely have a total of 100 untriaged bugs left ;-)
<bryce> actually probably more like 50
<tjaalton> xorg has maybe 6
<bryce> -nv has the most ironically
<tjaalton> heh, yeah
<tjaalton> I should go through them now that I have one..
<bryce> so I wonder what we do when we hit 0 New bugs :-)
<tjaalton> we try to fix those that are confirmed? :)
<bryce> maybe focus on getting everything filed upstream?
<bryce> hehe
<tjaalton> going through b.df.o is one
<bryce> I got one of my upstream reported bugs marked invalid because it was one of those bugs that a bunch of users had "me too"ed their issues onto, so I summarized and sent upstream
<bryce> however upstream seems to prefer each person's issue be a separate bug report
<tjaalton> as do we
<bryce> unfortunately I think launchpad lets us down a bit here, since it's set up to only allow one upstream bug report per bug
<bryce> hmm, I've not been so picky that people who have roughly the same issue, report it separately (sometimes)
<tjaalton> i've closed bugs where people have reported other issues than the original one, and asked them to file new bugs
<bryce> maybe I need to be more strict though.
<Ng> I'm going to be bugging you X guys again like I was with gutsy. resuming my laptop is causing graphical issues again ;)
<bryce> I suppose that's a good practice
<bryce> heya Ng
<bryce> heh, the membership of #ubuntu-x sure has grown since I started working here....
<tjaalton> bug 180409
<ubotu> Launchpad bug 180409 in linux-restricted-modules-2.6.24 "bugs in fglrx - blank screen - artifacts" [Undecided,Invalid] https://launchpad.net/bugs/180409
<Ng> hey bryce :)
<tjaalton> that's one good example of a messy bug report..
<tjaalton> hey Ng!
<Ng> tjaalton :)
<Ng> erk, this is more broken than I thought. scrolling in firefox => jumbled mess
<Ng> bryce: do you know if the fix from 133118 made it upstream?
<bryce> I was fairly sure it did
<Ng> I don't think it can be the same thing, because Im sans compiz atm and 2d stuff is broken
<tjaalton> Ng: switch to XAA, set 'Option "AccelMethod" "XAA"'
<Ng> tjaalton: I did that already to get the 2d acceptably fast ;)
<bryce> man, that's sad that I recognize bugs off their bug id#
<bryce> my memory really isn't this good normally
<Ng> hehe, well to be fair i did buy pretty much everyone pretty much all the time about it ;)
<bryce> I'm 99.999% certain the fix was taken upstream
<bryce> however, what upstream has done with it since then is anyone's guess
<bryce> I know they've done additional work on this area since then
<bryce> Ng: file another bug with the current state of the issue, ref the prev bug, and I'll follow it up
<Ng> ok, ta :)
<Ng> fwiw, http://mairukipa.tenshu.net/855gm-resume-broken.png is what I'm seeing
<bryce> don't understand...
<bryce> I see what looks like some image doubling or something?
<Ng> see how the network-manager icon shows all the trails from the spinning, as well as the latest state (LAN connection)
<bryce> mm, sort of...
<Ng> if I cover that icon it'll force it to redraw, but if I then connect to another network the trails will build up again until I next force it to completely redraw
<bryce> hmm
<Ng> so scrolling in firefox causes a bit of a mess ;)
<bryce> make sure to describe the situation really well (or include screencast)
<Ng> oki doki
<Ng> I'm going to have a quick trawl of bugs to see if I can find anything similar
<bryce> I'm sure we'll here, "Oh yeah, that's 100% fixed.  Just switch to TTM."
<Ng> heh
<Ng> these interregnum periods are a pita for distros ;)
<Ng> filed as bug #182791
<ubotu> Launchpad bug 182791 in xserver-xorg-video-intel "855GM resume problems" [Undecided,New] https://launchpad.net/bugs/182791
<bryce> thanks
<bryce> Ng, I've been lightly hammering on Intel to get the <= 855 issues sorted out for a while
<Ng> good :)
<Ng> there are a lot of such laptops still in use and when they work they work fantastically ime, but it is a bit of a shame to have to chase down weird bugs each release ;)
<bryce> I've got it on record that they want -i810 deprecated, and thus desire all issues that work in -i810 but not -intel to be resolved in -intel so we can deprecate -i810
<bryce> sort of circular there, but in a good way
<Ng> has i810 changed since gutsy? istr it hadn't changed there since feisty?
<bryce> no it hasn't
<Ng> mmkay, well I probably won't bother even testing that yet, it was never very good at resume anyway ;)
<bryce> upstream in fact has just symlinked -i810 to -intel
<Ng> I am going to quickly try EXA just in case, since that is at least the default the driver is choosing
<bryce> cool
<ubotu> New bug: #182791 in xserver-xorg-video-intel (main) "855GM resume problems" [Undecided,New] https://launchpad.net/bugs/182791
<Ng> heh, good work ubotu ;)
<Ng> wow, it's even worse with EXA
<Ng> it's almost impossible to get anything to render. at best I could see the background of gtk widgets, but absolutely no foregrounds or text
<Ng> heh, I found an (I think) unrelated 855gm bug on fd.o's bugzilla and the intel guys seem to be saying that they don't have such hardware to test on
<Ng> this is not encouraging ;)
<ubotu> New bug: #182802 in xserver-xorg-video-intel (main) "[hardy] Screen freeze on resume" [Undecided,New] https://launchpad.net/bugs/182802
<ubotu> New bug: #153122 in xserver-xorg-video-openchrome (main) "Fatal error while loading Xorg" [Undecided,Incomplete] https://launchpad.net/bugs/153122
<ubotu> New bug: #164342 in xserver-xorg-video-openchrome "Suspend broken" [Undecided,Incomplete] https://launchpad.net/bugs/164342
<ubotu> New bug: #178313 in xserver-xorg-video-via (main) "antspotlight screensaver hangs computer" [Undecided,Incomplete] https://launchpad.net/bugs/178313
<mvo> tjaalton: you mentioned in #179515 that the screensaver might kill X during a upgrade, do you know any details?
<mvo> tjaalton: I'm wondering what to do about it, sending a inhibit signal via dbus for gnome-screensaver would be a obvious (but not trivial as the release-upgrader does not have access to the session bus) solution, but that leaves xscreensaver and kde out 
<tjaalton> mvo: yeah :/
<tjaalton> mvo: no perfect solution there, but I don't know what else could have caused it
<mvo> tjaalton: ok, its at least a hint. I will try to reproduce it here with screensaver on and see what comes out of it
<tjaalton> mvo: it only happens if your driver is buggy with DRI
<mvo> tjaalton: so for every driver ;) ?
<tjaalton> hehe
<tjaalton> there's always the possibility, sure :)
<mvo> tjaalton: do you know more details?
<mvo> I mean, what exactly is causing it? the fact that libdrm/libGL changes while the screensaver is runing?
<mvo> some incompatibility between the drm/dri interfaces?
<tjaalton> well, GL screensavers tend to trigger bugs
<tjaalton> but if the stuff is already loaded in the memory it doesn't matter if the libs are updated
<mvo> meh, if its in dri, then I can not reproduce it in a VM :(
<tjaalton> no, it's just a scenario
<tjaalton> that X crashes when you upgrading
<tjaalton> and to minimize the possibility it would be wise to disable the screensaver
<mvo> its probably a good theory, because I have not seen it crash in a VM yet, but it seems to happen sometimes on real HW - I have seen some reports
<tjaalton> yeah, I bet there are dupes
<tjaalton> you can disable gnome-screensaver with gconf
<tjaalton> idle_activation_enabled
<mvo> I look into it, I need to come up with something that works for xubuntu and kubuntu as well 
<tjaalton> ok, cool
<ubotu> New bug: #182865 in xserver-xorg-video-intel (main) "Cannot switch to console after installing "xserver-xorg-video-intel 2:2.1.1-0ubuntu9.1"" [Undecided,New] https://launchpad.net/bugs/182865
<ubotu> New bug: #182878 in xorg (main) "[gutsy] gma 950 no TV-OUT in dispalyconfig" [Undecided,New] https://launchpad.net/bugs/182878
<ubotu> New bug: #182883 in xserver-xorg-video-intel (main) "dual screen support doesn't work" [Undecided,New] https://launchpad.net/bugs/182883
<ubotu> New bug: #182898 in xserver-xorg-video-intel (main) "erratic widescreen intel gma 3000" [Undecided,New] https://launchpad.net/bugs/182898
<Ng> not a good day for -intel and bugs ;o
<tjaalton> poor intel
<mvo_> bryce I may do a mesa upload within this week, is there anything planed? I need to patch it so that compiz can detect glx window
<bryce> mvo, it should be safe.  I don't have mesa uploads planned and don't think timo does either
<bryce> I'm going to do an xserver upload for Q-FUNK with some new patches, but that'll be for gutsy-proposed, not hardy
<bryce> tjaalton might have some other things planned
<mvo_> bryce ok, thanks. I'm currently in testing stage, but it looks promising so far and I don't want to interfere with the X team, especially since you use git now (not sure if you also use it for mesa)
<bryce> no we don't
<mvo_> good, thanks for this info
<Q-FUNK> bryce: aye, thanks for that
<Q-FUNK> let's see if it improves everyone's results 
<tjaalton> mvo_: please go ahead
<Q-FUNK> if it does, we can always come back to the Hardy patch before the release takes place
<bryce> Q-FUNK: I need to do some UME stuff (trying to get it booted on the test hw they've provided)
<Q-FUNK> ah ok
<Ng> tjaalton: hmm, don't you have an X40?
<tjaalton> Ng: nope, X61
<Ng> ah, doh
 * Q-FUNK is patiently waiting for his Dell D430 to be delivered.
<Ng> I noticed that my particular model doesn't have any pm-utils quirks, so figured that might be causing X to fail to resume, but I've tried what I think should be the matching options from the old acpi-support, which made absolutely no difference ;(
<tjaalton> you might want to ask mjg59 for some tips
<Ng> yeah
<tjaalton> or check thinkwiki
<tjaalton> bryce: mjg59 confirmed that SHMConfig is not an option for us (pun intended)
<tjaalton> so I closed the bug that asked for including it
<tjaalton> ps. comedy inc. rules :)
<Ng> tjaalton: it was a sad day when mjg59's x40 got ruined and he switched to an HP ;)
<tjaalton> aww
<tjaalton> that explains the recent blog post then ;)
<bryce> tjaalton: ah ok
<Q-FUNK> ah. vorlon pushed the new -amd into hardy
<bryce> ok, I'm done (stuck) on the ume stuff for the time being.  -amd time.
<jcristau> `
<Q-FUNK> heh
 * jcristau blames ssh
<jcristau> fwiw, #182252 is invalid. X is started with '-nolisten tcp' by default, so obviously inet connections don't work
<bryce> Q-FUNK, what are the bug ID('s) that are fixed with these two xserver patches?
<tjaalton> jcristau: good point, I'll close that one
<Q-FUNK> bryce: I'm not sure that there was a separate bug open for this freeze issue on some BIOS
<bryce> can you open one please?  In order to upload SRU candidates they require patches be tied to bug ID's in launchpad
<bryce> are these patches fixes for bug 140051?
<ubotu> Launchpad bug 140051 in xserver-xorg-video-amd "amd driver fails to autoconfigure" [High,Triaged] https://launchpad.net/bugs/140051
<Q-FUNK> yes and no
<bryce> hmm, maybe I'm asking the wrong question
<Q-FUNK> it prevents X from freezing at configure time, but doesn't directly resolve DDC failing with -amd yet
<bryce> hmm, maybe I don't understand this
<bryce> it sounds like these don't fix the issue, as there is another known issue that prevents it from working
<bryce> however it adds the risk of changing existing -amd user's systems (presuming there are -amd users able to use the current driver)
<bryce> wouldn't it be more appropriate to put this into hardy or a ppa if the purpose is simply to check if it breaks other -amd user's systems?
<Q-FUNK> it needs to go into hardy regardless, if it works, but testing via gutsy-proposed feels as the most harmless way of having a wide test range
<bryce> hmm
<Q-FUNK> well, -amd is essentially borken for too many people, thanks to the broken x86emu
<Q-FUNK> I'm stuck with Etch and a souped-up Feisty to they my thincans here, because of that
<Q-FUNK> they->test
<bryce> there could also be some risk for non -amd users, since it affects code that (I gather) is run by all xserver users, so want to be careful we're not pushing it too aggressively
<bryce> not that I don't trust that this is a good fix to have, but it feels like we're skipping over some intermediary testing steps
<bryce> hmm
<bryce> ok I'm building the xserver with the patches.  Let me go grab lunch and think of how we should do this.
<ubotu> New bug: #134951 in ubuntu "gutsy too high resolution (dup-of: 182778)" [Undecided,New] https://launchpad.net/bugs/134951
<Q-FUNK> bryce: I just made a call to the X list for people to test this as much as possible
<bryce> back
<bryce> the bus patch failed to apply
<bryce> Applying patch 146_x86emu-correct-bus-dev-fn.patch
<bryce> patching file hw/xfree86/int10/helper_exec.c
<bryce> Hunk #1 succeeded at 469 (offset -80 lines).
<bryce> Hunk #2 FAILED at 480.
<bryce> Hunk #3 FAILED at 494.
<bryce> patch: **** malformed patch at line 61: PCI_OFFSET(PciCfg1Addr) + offset);
<bryce> P
<bryce> checking other patch...
<bryce> Q-FUNK: I did think about this some.  What I'd like to do is before uploading to gutsy-proposed, to put up a deb and get a few people to test it on gutsy systems, to make sure it doesn't cause X to fail to start
<bryce> Q-FUNK: if we can get three thumbs up, I say let's stick it in gutsy-proposed 
<bryce> oops, the other patch also failed to apply
<Q-FUNK> :(
<Q-FUNK> let's ask bartman
<bryce> hang on, I am looking into it deeper
<bryce> I can usually fix up patches to apply, if they're not too intricate
<bryce> Q-FUNK: hmm, those patches appear to be against current xserver head.  Let me check them against xserver 1.4
<bryce> nope
<Q-FUNK> bryce: I just told Bart and Gadi about it
<jcristau> i'm not sure what patches these are, but if they're for a post-pciaccess server, then they might need porting
<bryce> ok, I'm trying to do the patches manually
<bryce> jcristau: ah that might be; yes they appear to deal with pci tags
<bryce> hmm, that might be more work than I have time for
<Q-FUNK> indeed
<Q-FUNK> never mind
<Q-FUNK> I'll ask bartman to rebase against 1.3 for the test
<ubotu> New bug: #182743 in xorg (main) "hardy xorg not detecting for compaq evo n410c" [Undecided,Confirmed] https://launchpad.net/bugs/182743
<bryce> Q-FUNK: ok cool
#ubuntu-x 2008-01-15
<ubotu> New bug: #183026 in xorg (main) "desktop cd fails to start gdm with hp nc6400 (widescreen, ati-based laptop)" [Undecided,New] https://launchpad.net/bugs/183026
<ubotu> New bug: #183032 in xorg (main) "Seems to be confusion about what is the resolution of my external screen" [Undecided,New] https://launchpad.net/bugs/183032
<ubotu> New bug: #183119 in xserver-xorg-input-evdev (main) "[Hardy] Cannot open input pEvdev for keyboard" [Undecided,New] https://launchpad.net/bugs/183119
<ubotu> New bug: #182622 in xserver-xorg-video-nv (main) "Xserver Crashes After Double click on icon in awn" [Undecided,Incomplete] https://launchpad.net/bugs/182622
<ubotu> New bug: #183192 in xserver-xorg-video-nv (main) "closing youtube flash video make Xorg CRASH" [Undecided,Incomplete] https://launchpad.net/bugs/183192
<ubotu> New bug: #183298 in xorg-server (main) "can not disable track pad" [Undecided,New] https://launchpad.net/bugs/183298
<tjaalton> mm, testing RAOF's nouveau packages, but the kernel module refuses to load
<tjaalton> ah, wrong drm.ko loaded
<tjaalton> blimey, it works
#ubuntu-x 2008-01-16
<ubotu> New bug: #183416 in xorg (main) "screen is enlarged very much when I enable my graphics card(NVDIA card)" [Undecided,Incomplete] https://launchpad.net/bugs/183416
<ubotu> New bug: #40659 in dmidecode (main) "[ia64] Can't get past "Configuring xserver-xorg"" [Medium,Confirmed] https://launchpad.net/bugs/40659
<Q-FUNK> re
<bryce> hey
<Q-FUNK> no wonder batman's patch would not apply:  it needs to apply after everyone else's patch is there :)
<bryce> heh
<Q-FUNK> I'm building myself a test package
<Q-FUNK> I'll try it with both -amd and the -siliconmotion on my laptop
<bryce> amazing how much time this friggin equipment takes to make it work
<bryce> can't believe I've put an entire week into ume, and I feel barely further along than a week ago
<Q-FUNK> indeed
<Q-FUNK> it almost feels like rocket science
<tjaalton> bryce: apparently there is a libdrm release coming up in the next few weeks
<tjaalton> bryce: which means that the TTM API is finished..
<tjaalton> RAOF has snapshot packages for libdrm, so I'll try to build the intel stuff against it
<bryce> tjaalton: amazing!
<bryce> kewl
<tjaalton> the diff against 2.3.0 is over 6MB :)
<tjaalton> but that includes the kernel drivers too, same for bsd
<bryce> tjaalton: I made some good progress on ume today.  Preliminary results show that the lockup is solved.  I'm hoping by the time i get up tomorrow we'll be close to done with it
<tjaalton> bryce: that was with poulsbo?
<bryce> yeah I bet.  The libdrm2 patch I was manhandling for ume was like 16,000 lines
<bryce> yup
<tjaalton> hehe
<tjaalton> so I tried RAOF's nouveau packages yesterday, and it worked quite well
<bryce> nice
<bryce> 3d stuff?
<tjaalton> obviously no 3D, and no VT
<tjaalton> :)
<bryce> oh
<tjaalton> it's flaky
<tjaalton> but the software rendering wasn't too bad
<bryce> ok, so worked quite well for certain definitions of quite well ;-) ;-)
<tjaalton> yeah
<tjaalton> the VT's not working is a known issue
<tjaalton> no DRI since there was no driver for it
<tjaalton> but according to the wiki it's known to be broken for most
<tjaalton> jcristau: RAOF also promised to co-maintain nouveau on git.d.o :)
<tjaalton> the package is derived from -nv, so it's close to the XSF standards
<bryce> I hate it when VT switching is broken.  makes debugging a pain
<tjaalton> yep
<bryce> ah really...  is it a superset of -nv yet?
<tjaalton> no, obfuscated parts are mostly rewritten, so it's a fork but has more functionality now
<tjaalton> so I'm not proposing to replace -nv with it, not for hardy anyway :)
<bryce> well, still good to heaer about the progress
<tjaalton> although it seems that there are serious issues with -nv where on some models you need the binary driver to "prime" the card"
<tjaalton> and nvidia is not going to fix that
<bryce> wow
<bryce> I didn't know about that
<bryce> wow that sucks
<tjaalton> I'm not sure how common that is
<bryce> maybe it's updating bios or something?
<tjaalton> possibly
<tjaalton> i'll dig up the bug on b.fd.o
<tjaalton> hmh, can't find it
<bryce> ah well
<bryce> might be good to note on our wiki somewhere
<tjaalton> but there was one where aaronp said that "there's nothing we can do about it right now" or similar
<bryce> oh btw, the bug I mentioned in that tagging greasemonkey script is fixed now
<tjaalton> oh, cool
<bryce> brian also added some tooltips to it (haven't checked that out yet)
<tjaalton> so are the ume guys switching to hardy now?
<tjaalton> and would that be an excuse for putting the new drm stuff in the kernel?-)
<bryce> they're shooting for hardy yes, but gutsy is a backup in case we can't get things like X to work on it
<bryce> unfortunately time is very short to prove it on hardy, which is why everyone's scrambling
<tjaalton> yep
<tjaalton> we'd get TTM with the drm, although that was declined at UDS
<bryce> it looks like they've accepted that they're going to be running non-stock ubuntu, with loads of PPA bobbins stuck ontop, so they're working to the assumption that they'll be carrying drm bits and pieces
<bryce> I'm sure they would love hearing new drm included in main ubuntu, but don't think they're expecting it
<bryce> it would be >awesome< to have TTM
<tjaalton> I'm not exactly sure what would break with it, since it's not like a requirement to use it
<bryce> yeah
<tjaalton> but intel surely is going for it
<bryce> mvo would be happy
<tjaalton> hehe
<tjaalton> so, I'll break my laptop now
<bryce> well, if nothing else, it'd be nice to stick it in a ppa for people 
<tjaalton> yeah
<bryce> I'm sure dell would snag it for their systems
<bryce> (assuming it doesn't eat kittens and make babies cry or something)
<mvo> bryce: looks like I missed the earlier bits of the conversation :) ? new intel drivers?
<tjaalton> mvo: libdrm release due "in a few weeks"
<bryce> mvo, with TTM
<tjaalton> which would include the new memory manager (TTM)
<mvo> oh, with ttm ?
<mvo> nice
<tjaalton> so I'll try to package the intel branch that uses it
<tjaalton> currently the performance with 965 is actually worse than with the old driver, but that's hopefully fixed soon
 * mvo nods
<mvo> will this branch do redirected direct rendering? 
<tjaalton> I mean with TTM, worse than the current driver with EXA (amazed that it's actually possible..)
<tjaalton> mvo: I think that's a separate issue
<tjaalton> although it would require TTM yes
<mvo> ok
<mvo> thanks
<bryce> tjaalton: I got another meeting with Intel about -intel bugs tomorrow, but I've been so busy with ume stuff I haven't put much thought into what to talk about.  Are there any issues you think would be worth bringing up with them?
<bryce> oh speaking of which, Rolla says "We expect it to be better on 965 in about 2 weeks.  If Jesse releases 2.2.1 before that, then 2.3 should include the major improvements."
<bryce> "2.3 will release around march. 2.2.1 should be released near this month's end."
<tjaalton> hmm
<tjaalton> is March too late?
<tjaalton> hmm
<bryce> hmm, we were putting in new -ati's up until the last moment before release
<tjaalton> yeah.. but it was gutsy :)
<bryce> true
<bryce> ok I'll bring that up.
<bryce> what else?
<tjaalton> so 2.3 will use TTM, and we should be able to keep the hardy version more uptodate even when it's released
<tjaalton> I just hope they'll be around when the bugs keep rolling in :)
<bryce> no kidding
<tjaalton> so _if_ we are able to use TTM for intel, we _could_ ship with 2.3
<bryce> are you certain 2.3 will require TTM?  I can ask to get clarification on that
<tjaalton> but otherwise it's 2.2.1 and back to XAA
<tjaalton> oh, no I'm not sure, but if it's not available then we still have the annoying bugs
 * bryce nods
<bryce> I'll ask for clarification on it
<bryce> TTM is wholey within libdrm?  No xserver components needed?
<tjaalton> I'll probably take a C course this semester, which should improve my debugging skills :)
<bryce> wholly
<bryce> cool
<tjaalton> AIUI yes
<tjaalton> the redirected direct rendering touches xserver
<tjaalton> but that's separate
<bryce> upstream would be very sad if we went back to XAA
<bryce> "the gfx team says:
<bryce> EXA should only be slower than XAA on 965 mostly.  Also, we're working
<bryce> fully on EXA and we're we are doing nothing else with XAA so it doesn't
<bryce> support other features we've added - thus reverting to XAA would leave
<bryce> you unsupported.
<bryce> "
<tjaalton> yeah :/
<tjaalton> carrot-and-stick
<bryce> I sort of don't like how they flip switch over to new features and (relatively) immediately drop support for the old version
<bryce> reminds me of the -i810/-intel switch
<tjaalton> true
<tjaalton> drm built with a couple of nouveau related warnings, nothing else
<bryce> tjaalton: are you experiencing bug 175774?  I also started noticing it recently.
<ubotu> Launchpad bug 175774 in xserver-xorg-video-intel "[hardy] Enabling "Normal" effects produces badly drawn window shadows." [Critical,Confirmed] https://launchpad.net/bugs/175774
<bryce> I assumed it was compiz' fault but see the bug has ended up with us
<bryce> ah nevermind, I see you've already commented on it
<tjaalton> yes, it's visible with EXA
<ubotu> New bug: #182489 in linux-restricted-modules-2.6.24 (restricted) "Atheros wireless (AR5006EG) not working on ASUS Eee PC" [Undecided,New] https://launchpad.net/bugs/182489
<Ng> the gfx team are wrong, EXA is slower on 855 too ;)
<tjaalton> heh
 * Ng been playing with pm-utils quirks and I can kind of get X back after a resume, but scrolling is still very broken when I do, so it's clearly not working properly somewhere. I'm trying to find out what the correct suspend quirks are for this hardware and I was wondering if I could reasonably try the intel driver from gutsy-proposed with the hardy Xorg
<tjaalton> sure, the current version is, but the TTM version is 40% slower on 965 than a non-TTM version of the driver
<Ng> ouch
<tjaalton> rest should apparently be fine
<tjaalton> ..with TTM
<mvo> Ng: contracts for terminator being in the repository!
<Ng> I'm also considering pestering Peter Clifton about it, since he was so awesome in tracking down the bug that stopped me suspending with the release gutsy -intel driver
<Ng> mvo: ta :D
<mvo> Ng: meh, make that congrats :)
 * mvo can't type
<Ng> I also need to find more brave x40 users :)
<mvo> Ng: dholbach comes to my mind
<Ng> mvo: ooh, interesting point :)
<bryce> night
<Ng> cya bryce :)
<tjaalton> night bryce, hopefully I'll have a working TTM setup by the time you wake up :)
<mvo> night bryce
<mvo> tjaalton: do you happen to know aobut the latest development with the redirected direct rendering? is it merged into some branch already?
<tjaalton> mvo: I know that cworth is working on it, but at least his personal trees haven't been updated in a while, so could be that they are now in a separate branch (of xserver etc)
<tjaalton> once I get this TTM crap working I'll have a closer look
<mvo> ok, thanks
<tjaalton> hmm strange.. emacs runs on a local display but not over ssh, fails with xcb_xlib_lock assertion
<tjaalton> and now it works
<tjaalton> puzzling
<ubotu> New bug: #4596 in xorg (main) "Xorg 6.8.2-77 has multiple issues/bugs" [Undecided,Fix committed] https://launchpad.net/bugs/4596
<sirex`> How can I submit new keyboard layout to Ubuntu?
<tjaalton> sirex`: please submit them upstream
<tjaalton> file a bug against xkeyboard-config on bugzilla.freedesktop.org
<sirex`> Ok, thans tjaalton.
<tjaalton> sirex`: then if it is approved and included in upstream we can add it to our package
<sirex`> tjaalton: can I sumbit a bug to bugs.launchpad.net?
<sirex`> I mean bug about new keyboard layout..
<tjaalton> yes, and then link to the upstream bug
<tjaalton> so we know when it's applied upstream
<sirex`> I filed bug: http://bugs.freedesktop.org/show_bug.cgi?id=14096
<ubotu> Freedesktop bug 14096 in General "New Lithuanian keyboard layout LEKP" [Normal,New] 
<tjaalton> ok, now file the same on lp.net, and link to the b.fd.o bug
<ubotu> New bug: #183511 in xkeyboard-config (main) "New keyboard layout â LEKP" [Undecided,New] https://launchpad.net/bugs/183511
<tjaalton> sirex`: ok, I can link the upstream bug to that
<tjaalton> done
<Ng> ooooh
<Ng> I just got a successful suspend/resume cycle
 * Ng tries again
<tjaalton> don't spoil it :)
<Ng> win!
<Ng> that's so weird, but somehow the new kernel seems to have fixed that
<Ng> I noticed pitti said his suspend worked with it
<Ng> now I need to hack the hal fdi's to set the quirks for this laptop
<Ng> and maybe try and whittle the list of required quirks down a bit
<Ng> but at least I can close out my bug
<seb128> see you later
<Q-FUNK> apparently, bartman's combined patch (port blacklist, pci listing, ubuntu changelog) on xserver-corg-core 1.3 (gutsy) has been verified to not introduce regressions when upgrading X under -intel.
<Q-FUNK> I'm testing now with nv and siliconmotion
<Q-FUNK> (and needless to say, with -amd too)
<Q-FUNK> bryce: maybe it's just me, but these tow patches make this nv driver feel snappier.
<bryce> :-)
<tjaalton> mesa head building.. I guess it'll take a while
<Q-FUNK> mesa /bin/jarjarbinks ?
<tjaalton> not quite as annoying to watch ;)
<Q-FUNK> ;)
<tjaalton> duh, failed
<tjaalton> at i915tex, the next one would've been i965
<tjaalton> the one _I_ need
<tjaalton> something for tomorrow then..
<tjaalton> ->
<bryce> heya tormod
<tormod> hi bryce!
<tormod> testing out the new Render support on radeon. Any idea I what I can test for? compiz?
<bryce> tjaalton: I finally managed to get a good backtrace of the poulsbo ume crash - it's a ioctl call to the kernel.  So, something appears to be broken in the kernel.
 * tormod is starting to hate {trackerd,updatedb,scrollkeeper-update}
<bryce> I may need to learn how to shut that off
<tormod> the killer is when I do a package update that calls scrollkeeper-in-hell-update and at the same time the cron job kicks in, and they starve each other :(
<Q-FUNK> how was it that I enable my PPA again?
<tormod> funny enough, it happens often on a slow machine, if you have the habit of updating just after booting.
<Q-FUNK> I have test packages of the patched server for gutsy and of the latest amd, also backported for gutsy.
<tormod> Q-FUNK: isn't that just a click on launchpad?
<Q-FUNK> seems enabled, but no idea how to upload to it
<tormod> Q-FUNK: dput
<tormod> where is the blacklist for compiz located?
<Q-FUNK> yes, but where to?
<Q-FUNK> ah. found
 * tormod thought he knew better than the blacklist...
#ubuntu-x 2008-01-17
<ubotu> New bug: #182038 in xserver-xorg-video-nv (universe) "Black rectangle instead of image in FF3/Hardy" [Undecided,Confirmed] https://launchpad.net/bugs/182038
<ubotu> New bug: #180525 in firefox-3.0 (universe) "firefox-3.0 libpr0n resizes images into works of abstract art (dup-of: 182038)" [Undecided,Incomplete] https://launchpad.net/bugs/180525
<tjaalton> bryce: nice, so it's off your back then :)
<tjaalton> jcristau: you not on #debian-x? RAOF would like to have access to pkg-xorg
<bryce> tjaalton: indeed
<mvo> bryce, tjaalton: it looks like a fix for http://bugzilla.gnome.org/show_bug.cgi?id=488264 was commited. can we try to cherry pick this into our tree?
<ubotu> Gnome bug 488264 in general "keybord grab problem under compiz" [Normal,Unconfirmed] 
<tjaalton> mvo: I noticed, it was discussed on #debian-x briefly
<mvo> aha, nice
<mvo> the patch looks simple enough
<tjaalton> very
<ubotu> New bug: #173367 in xserver-xorg-video-intel (main) "Xorg crashed with SIGSEGV" [Medium,Incomplete] https://launchpad.net/bugs/173367
<ubotu> New bug: #144551 in ubuntu "Upgrade to 2.6.22.14 - NVidia driver does not work (dup-of: 145621)" [Undecided,New] https://launchpad.net/bugs/144551
<ubotu> New bug: #183716 in xorg (main) "cpu load jumps to 40% when copying to usb-flash" [Undecided,New] https://launchpad.net/bugs/183716
<mvo> tjaalton: do you happen to know if changes to structs like __GLXscreen in the libglx extension modify the abi in a way that might cause problems with fglrx/nvidia?
<tjaalton> mvo: they ship their own AFAIK
<mvo> good, thanks
<ubotu> New bug: #183742 in xorg-server (main) "configuration problems" [Undecided,New] https://launchpad.net/bugs/183742
<tjaalton> bryce: check airlied's comments on #xorg-devel about intel. currently I can't even build the batchbuffer stuff, and even if I could it doesn't do anything useful since intel guys should push their fixes upstream (AIUI)
<tjaalton> so.. I'll do something else in the meantime :)
<tjaalton> like, work
<Q-FUNK> jcristau: at xorg-server (2:1.4-1) in debian.changelog,       x11proto-render-dev was bumped.  was this just to match the latest release or an absolute necessity?
<jcristau> Q-FUNK: it was because of 030dd885476b70c9054b6e4b50dfdbab12e73716 in renderproto. probably not absolutely necessary
<Q-FUNK> ok
<Q-FUNK> I was trying to backport the hard xorg into gutsy, to see if it might restore operation on my laptop with siliconmotion.  that build-dep bump made pbuilder barf. :)
<jcristau> getting an updated renderproto would be trivial anyway
<mvo_> insn't the latest fglrx supposed to have texture_from_pixmap?
<tjaalton> yes, but apparently it's broken somehow
<tjaalton> we don't have the latest version, btw
<tjaalton> because it's even more broken than 7.11 :)
<mvo_> aha, that explains it :)
<mvo_> meh, is that even possible ;) 
<tjaalton> yes, breaks widescreen modes
<tjaalton> "quality control - FAIL"
<mvo_> :)
<mvo_> ok, thanks for this info
<tjaalton> np
<ubotu> New bug: #183746 in xorg (main) "Hardy Heron Live CD boots but with incorrect graphics mode on Vaio PCG-SRX51P/B" [Undecided,New] https://launchpad.net/bugs/183746
<tjaalton> some failsafe mode.. everything else is running but I have metacity instead of compiz
<tjaalton> which is failsafe enough :P
<bryce> yay, ume issue solved
<bryce> http://bryceharrington.org/drupal/ume-psb-fix
<ubotu> New bug: #183873 in xserver-xorg-video-ati (main) "Unable to use xrandr for dual-head in hardy" [Undecided,New] https://launchpad.net/bugs/183873
<Q-FUNK> bryce: how do you like poulsbo, so far?
<bryce> my judgement is likely clouded from having the last 2 weeks consumed by a single bug in it, but I'm yet to see what the big deal is about it
<bryce> the 3D driver might make a difference
<tjaalton> I've built drm, mesa, xserver (& couple of libs) master, and intel-batchbuffer, and the damn thing doesn't work. some part is lacking the batchbuffer stuff :/
<tjaalton> intel_dri.so complains about some unknown symbol and fails
<tjaalton> video ABI has bumped to 4 btw
<bryce> hrm
<bryce> I only talked briefly with rolla yesterday, but we discussed falling back to XAA; she says it's understandable  we'd need to take that approach until things are working better
<tjaalton> yep
<Q-FUNK> bryce: ok.  that matches my assessment of the chipset.
<bryce> it's a tiny chip; maybe the attraction is that it works "okay" but is tons smaller and less power consuming than the equivalent normal gfx chip
<Q-FUNK> to me, the main quibble is that it's touted as "almost x86" except it really isn't
<bryce> I'm a bit disappointed how much customized cruft has built up around it
<bryce> makes working on it rather complicated
<Q-FUNK> well, people want either real x86 or somehting completely different.  since it's touted as "almost x86" people start by building the almost, as in with libgcc1
<ubotu> New bug: #182358 in compiz (main) "Compiz crashes my laptop (Intel T7200) Nvidia 7400 (dup-of: 145112)" [Undecided,New] https://launchpad.net/bugs/182358
<tjaalton> well, something positive; on resume LCD backlight is turned on with intel master
<tjaalton> before I had to change the vt to turn it on
<tjaalton> hmm, grammar errors, but you get the point ;)
<ubotu> New bug: #183893 in libxfont (main) "[Sync request] Sync libxfont (1:1.3.1-2) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/183893
<Q-FUNK> tjaalton: here, with siliconmotion, this fails completely since X 1.3. with 1.2, the console switching trick you describe worked.  with 1.1, I never needed it.  operation was spotless.
<tjaalton> see, that's progress :)
<Q-FUNK> after briefly testing with1.4 tonight, I notice thta it keeps on getting worse.  same x-x-video-siliconmotion source, different x core.
<Q-FUNK> lovely definition of progress.
<bryce> I'd think Q-FUNK hated X if I didn't know better ;-)
#ubuntu-x 2008-01-18
<bryce> tjaalton: do we have many bugs against -vesa?
<bryce> 12, hmm
<bryce> wow, the vesa driver is all in one .c file
<tjaalton> something like that
<bryce> 1873 lines
<tjaalton> ye
<tjaalton> s
<bryce> do you know if there's any development work needed for vesa?
<bryce> or is it intended to be kept "trivial"?
<tjaalton> well, there still seems to be some problems with getting valid modes for r5xx
<tjaalton> but that should be "fixed" when those use ati or radeonhd
<bryce> hmm
<tjaalton> bug 174434
<ubotu> Launchpad bug 174434 in xserver-xorg-video-vesa "[ATI X1300] Could not generate /etc/X11/xorg.conf.failsafe" [High,Confirmed] https://launchpad.net/bugs/174434
<tjaalton> the title is just a symptom
<bryce> oh yeah, I was just looking at that
<ubotu> New bug: #183961 in xorg-server (main) "X Window System error while starting easyeclipse 1.2.2.2" [Undecided,New] https://launchpad.net/bugs/183961
<bryce> btw, I passed on your comments about drm issues to intel; hopefully that stimulates getting some traction towards addressing the issues.
<bryce> wow, -intel is 33,000 lines, and -ati is over 80,000
<bryce> I would have suspected those numbers reversed
<bryce> huh, and -nv is 19,000
<bryce> -psb is 16,500, not too shabby
<ubotu> New bug: #183969 in xorg-server (main) "xserver-xorg-core update breaks VLC" [Undecided,New] https://launchpad.net/bugs/183969
<tjaalton> bryce: ok, cool
<bryce> tjaalton: do you know if anyone's tried getting triple head running with an intel on-board chip plus an ati dual-output card?
<tjaalton> never heard of such
<bryce> I'm thinking of throwing some coding energy (after inkscape 0.46 is in the bag) towards making that work, if someone hasn't beaten me to it
<bryce> I'm figuring intel and amd don't have a lot of incentive to make each other's products work together, so it's not likely to be something that gets fixed on its own
<tjaalton> I understood that it needs some plumbing before it can work
<bryce> I know it'd require ttm in order to stitch the screens together...  but what plumbing beyond that?
<tjaalton> well you said it :)
<bryce> heh, ok
<bryce> ttm + misc. bug fixes
<tjaalton> but maybe xrandr-1.3 had something to do with it IIRC
<bryce> tjaalton: https://bugs.launchpad.net/ubuntu/+bug/183969
<ubotu> Launchpad bug 183969 in xorg-server "xserver-xorg-core update breaks java apps" [High,Confirmed] 
<tjaalton> known
<tjaalton> oh
<tjaalton> sorry I thought that was hardy
<tjaalton> so the security updates broke that?
<bryce> hmm, is that what did it?
<tjaalton> only changes in .1
<bryce> weird, I'd numbered my release 12ubuntu9 iir
<bryce> c
<bryce> ohhhh
<bryce> I recognize those error messages; java must be using some out of bounds conditions or something
<bryce> rats
<bryce> tjaalton: sorry; this one looks to be my fault.  I'll sort it out tomorrow.
<tjaalton> oh :/
<tjaalton> I can do a merge for hardy
<tjaalton> debian has the patches already
<tjaalton> bryce: is there a typo or something?
<bryce> no idea
<bryce> but if there was an issue, I should have caught it when reviewing the patches for hardy
<tjaalton> ok
<bryce> kees did the uploads for gutsy iirc
<tjaalton> hmm
<tjaalton> actually.. are the X and java security issues dependant on each other?
<tjaalton> I mean does java need to be updated if the X is updated
<ubotu> New bug: #183993 in xorg-server (main) "Could not Start Eclipse Rich-Clients after latest xorg-server update (dup-of: 183969)" [Undecided,New] https://launchpad.net/bugs/183993
<ubotu> New bug: #183994 in xorg-server (main) "After security update to 2:1.3.0.0.dfsg-12ubuntu8.1 can't start Eclipse Europa (dup-of: 183969)" [Undecided,New] https://launchpad.net/bugs/183994
<ubotu> New bug: #183996 in xorg-server (main) "Eclipse SDK 3.2.2 (with aptana plugin) crashes after xserver-xorg-core update (dup-of: 183969)" [Undecided,New] https://launchpad.net/bugs/183996
<tjaalton> maybe not
<ubotu> New bug: #183986 in eclipse (universe) "Eclipse crashes after xserver-xorg-core update (dup-of: 183969)" [Undecided,New] https://launchpad.net/bugs/183986
<ubotu> New bug: #183987 in pgadmin3 (universe) "PGAdmin3 won't start after xorg-core upgrade (dup-of: 183969)" [Undecided,New] https://launchpad.net/bugs/183987
<Q-FUNK> ok, we have one confirmation that the patched xserver-xorg-core fixes -amd in bug #140051
<ubotu> Launchpad bug 140051 in xserver-xorg-video-amd "amd driver fails to autoconfigure" [High,Triaged] https://launchpad.net/bugs/140051
<jcristau> meh. http://bugs.debian.org/461410 so it's not just you...
<tjaalton> right :/
<ubotu> New bug: #183974 in xserver-xorg-input-keyboard (main) "KB language setting resets at reboot" [Undecided,New] https://launchpad.net/bugs/183974
<ubotu> New bug: #184004 in xorg (main) "Eclipse no longer works after upgrading to xserver-xorg-core-...-ubuntu8.1 (dup-of: 183969)" [Undecided,New] https://launchpad.net/bugs/184004
<jcristau> can i blame java anyway? :)
<tjaalton> hehe
<jcristau> i suspect it's the mit-shm patch, but i don't have any swt app here to easily test
<ubotu> New bug: #184003 in xorg-server (main) ""BadAlloc (insufficient resources for operation)" error when run amule or filezilla with xserver-xorg-core version 2:1.3.0.0.dfsg-12ubuntu8.1 (dup-of: 183969)" [Undecided,New] https://launchpad.net/bugs/184003
<tjaalton> hmmh? enabling exa made the problem go away for one reporter
<tjaalton> https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/183969/comments/17
<ubotu> Launchpad bug 183969 in xorg-server "xserver-xorg-core update breaks java apps" [Critical,Confirmed] 
<jcristau> these "me too" are soooo useful...
<tjaalton> very..
<jcristau> tjaalton: exa doesn't support shared pixmaps, maybe that makes the bug go away
<tjaalton> ah, makes sense
<jcristau> are you able to reproduce it?
<tjaalton> hmm, I'll try on my laptop (intel)
<jcristau> the crash, i mean
<ubotu> New bug: #184018 in xserver-xorg-video-intel (main) "no terminal/console screens with new proposed xserver-xorg-video-intel 9.1" [Undecided,New] https://launchpad.net/bugs/184018
<jcristau> i'd like to confirm it's the ProcShmCreatePixmap check
<tjaalton> hmm, I can't get anything useful out of vlc
<tjaalton> trying azureus
<tjaalton> duh, how do I get a backtrace from it? need to set a breakpoint?
<jcristau> getting the name of the failing request would be a start
<tjaalton> request_code 146?
<jcristau> xdpyinfo -ext MIT-SHM
<jcristau> should tell you the corresponding opcode
<tjaalton> opcode: 146, base event: 94, base error: 170
<jcristau> ok that's the one then
<jcristau> mailed xorg@. maybe i should have sent it to xorg_security too...
<tjaalton> cool
<ubotu> New bug: #184029 in xorg-server (main) "emacs22 icon blank after xserver-xorg-core 2:1.3.0.0.dfsg-12ubuntu8.1 update and Xfce" [Undecided,New] https://launchpad.net/bugs/184029
<jcristau> got confirmation from another reporter that disabling mit-shm works around the problem
<tjaalton> how to do that?
<jcristau> Option "MIT-SHM" "no" in the Extensions section
<tjaalton> ok, thanks
<ubotu> New bug: #184032 in ubuntu "VLC media player fails to start (dup-of: 183969)" [Undecided,New] https://launchpad.net/bugs/184032
<tjaalton> keep'em coming
<jcristau> tjaalton: got a report that amd64 isn't affected
<tjaalton> hmm, good to know
<jcristau> there's an if (sizeof(long) == 4) in the patch though :)
<jcristau> so that's not completely unexpected
<tjaalton> hehe
<ubotu> New bug: #184044 in eclipse (universe) "Eclipse won't start anymore (dup-of: 183969)" [Undecided,New] https://launchpad.net/bugs/184044
<ubotu> New bug: #184046 in ubuntu "Eclipse's crashing after X update (dup-of: 183969)" [Undecided,New] https://launchpad.net/bugs/184046
<tjaalton> "whee", new fglrx
<tjaalton> catalyst 8.1 aka 8.452
<Q-FUNK> anybody wants to try porting bartman's x86emu patches to 1.4 ?
<tjaalton> not me, at least not now :)
<tjaalton> need to go shopping
<tjaalton> jcristau: we've reverted the security updates...
<tjaalton> until it's fixed properly
<jcristau> tjaalton: all of them, or just that one patch?
<tjaalton> all of them, just to be sure
<jcristau> ok
<tjaalton> I was tempted to upload a version to hardy with just the one patch dropped
<tjaalton> but dropped them all anyway
<keescook> might be reasonable to do that for hardy -- just to test the others.
<tjaalton> keescook: well, I did it already. You can play with it if you like :)
<keescook> tjaalton: heh, okay.
<keescook> I don't understand why that chunk of code fails, though.  the tests _seem_ sane.
<tjaalton> I'll build it locally without that patch
<tjaalton> and put it on my laptop
<jcristau> would be nice if someone would add some debugf's in there to know which check is failing and why
<bryce> did the patches break on hardy as well?
<tjaalton> yes
<tjaalton> I tried it..
<bryce> hrm
<bryce> keescook: next week in London perhaps we could put some thoughts together about a regression test suite
 * tjaalton goes out, bbl
<bryce> tjaalton: thanks, cya
<keescook> bryce: yeah
<keescook> bryce: mostly we just need an extension exerciser.
<bryce> I suspect many bugs would be caught by just trying to start X, and take a screen cap, but others are more involved
<jcristau> i'd been using the patched version for a week without noticing anything fwiw
<keescook> bryce: well, I might have noticed had I tested on i386 -- I only used amd64 this time.  *sigh*
<jcristau> but then i don't use the apps that have been reported as broken by the update
<bryce> yeah I don't make a habit of testing java apps.  hmm
<keescook> I've suddenly grown a new habit.  ;)
<bryce> ;-)
<ubotu> New bug: #184000 in ubuntu "wxPython apps fail after xserver update (dup-of: 183969)" [Undecided,Incomplete] https://launchpad.net/bugs/184000
<ubotu> New bug: #184079 in xorg-server (main) "Update xserver-xorg-core broke Eclipse (dup-of: 183969)" [Undecided,New] https://launchpad.net/bugs/184079
<keescook> jcristau: what's the right way to report debug messages from an extension?
<Q-FUNK> bryce: hiya.  any chance bartman's patches could go into X 1.4?
<ubotu> New bug: #184078 in xorg (main) "keyboard stops working until logout" [Undecided,New] https://launchpad.net/bugs/184078
<bryce> hi Q-FUNK, not today (i'm busy getting ready for my flight out tomorrow).
<bryce> possibly next week, however I've learned it's quite tough trying to get packaging done at a conference
<jcristau> well, for debugging printf should work
<keescook> jcristau: okay, cool -- I wasn't sure if it shut down std fds
<jcristau> hrm
<jcristau> you're right
<jcristau> lrwx------ 1 root root 64 Jan 18 18:12 2 -> /dev/null
<bryce> Q-FUNK: if I have a chance today, and if the patches go in cleanly, I'll try to get to it later in the day
<jcristau> keescook: let me check
<Q-FUNK> bryce: lovely.  if they work, can you pass them over to jcristau for inclusion into Debian too?
<keescook> jcristau: I've found other mentions of fprintf(stderr, so I'll give that a quick spin
<jcristau> keescook: you can use ErrorF
<jcristau> (and #include "os.h", if needed)
<keescook> jcristau: okay, building now
<ubotu> New bug: #184085 in wacom-tools (main) "in xsetwacom, setting button2 also sets button1" [Undecided,Fix released] https://launchpad.net/bugs/184085
<mvo> what is the master bug for the xbork problem? I got some 403 errors that I would like to reassign there
<jcristau> mvo: 183969
<mvo> thanks jcristau
<ubotu> New bug: #184088 in xorg-server (main) "permission problem on .deb download from synaptic (dup-of: 183969)" [Undecided,New] https://launchpad.net/bugs/184088
<ubotu> New bug: #184094 in xorg (main) "broken input in wine/crossover after updating xorg" [Undecided,New] https://launchpad.net/bugs/184094
<bdmurray> I've written a bughelper clue file for 183969 using the string "serial 477 error_code 11 request_code 144".  Is that a reasonable string to use?
<jcristau> the serial number and request code will vary
<keescook> ProcShmCreatePixmap (size < width * height) size: 12288 width: 1536 height: 64
<bdmurray> What would be a better string to uniquely identify the bug then?
<jcristau> keescook: thanks
<keescook> jcristau: is there another channel that is better to follow along with debugging this issue?
<jcristau> 12288 is 1536*64/8
<keescook> size is coming from PixmapBytePad ...
<jcristau> #define PixmapBytePad(w, d) \ (PixmapWidthInPadUnits(w, d) << PixmapWidthPaddingInfo[d].padBytesLog2)
<keescook> yeah
<keescook> PixmapBytePad is returning 192... (which is smaller than width?!)
<jcristau> yeah it's width/8
<jcristau> i guess #xorg-devel would be the best place
<keescook> jcristau: what nick does Matthieu Herrb use?
<jcristau> i don't think he's on irc
<keescook> ah
<jcristau> and airlied seems offline too :/
<ubotu> New bug: #184082 in boinc (universe) "'boincmgr' received an X Window System error (dup-of: 183969)" [Undecided,New] https://launchpad.net/bugs/184082
<ubotu> New bug: #183922 in xorg (main) "Xorg crashes after using Microsoft Word 2003 in Wine." [Undecided,New] https://launchpad.net/bugs/183922
<ubotu> New bug: #184134 in xorg-server (main) "X.org security update broke Eclipse" [Undecided,New] https://launchpad.net/bugs/184134
<ubotu> New bug: #163642 in xorg (main) "Maximum choosable resolution is too low even with nvidia driver" [Undecided,Incomplete] https://launchpad.net/bugs/163642
<bryce> keescook: do you think that java error could show up in wine crashes?  The timing of #183922 seems suspicious.
<jcristau> bryce: that bug title says "Xorg crashes", not "app crashes"?
<bryce> ah ok
<ubotu> New bug: #184147 in xorg-server (main) "[Feisty] 403 Forbidden http://security.ubuntu.com/ubuntu/pool/main/x/xorg-server/xserver-xorg-core_1.2.0-3ubuntu8.1_i386.deb" [Undecided,New] https://launchpad.net/bugs/184147
<keescook> bryce: it does make me a give nervous -- his log shows the updated X server.  but as jcristau says, it's not the bug we're currently fixing.
<bryce> ok; I gave general directions for getting an X backtrace.  we'll see where it goes
<ubotu> New bug: #184151 in xorg-server (main) "amule fails to start" [Undecided,New] https://launchpad.net/bugs/184151
<jcristau> wow, your users really don't know to search for existing bugs
<bryce> welcome to our world ;-)
<bryce> actually it's quite tragic - when they *do* search for existing bugs, they invariably pick one that isn't actually the same bug
<jcristau> heh
<bryce> so I think we drop a lot of issues just because we have to focus on the original reporter's issue to the exclusion of the me-too-ers; we ask them to file separate bugs, but I don't know how often they actually do
<jcristau> i don't think there's another way
 * bryce nods
<jcristau> (of course, just when i think debian users are marginally better, i see a bug filed on amule for the same issue, and i get another on xserver-xorg-core)
<bryce> heh
<ubotu> New bug: #184169 in xorg-server (universe) "eclipse crashes on launching with a bad alloc" [Undecided,New] https://launchpad.net/bugs/184169
<tjaalton> I'll merge the xserver for hardy
<tjaalton> now that the fix is included in debian \o/
<jcristau> meh. clueless people ranting on lwn...
<tjaalton> jcristau: link?
<jcristau> http://lwn.net/Articles/265754/
<tjaalton> haha
<tjaalton> "once again"..
<tjaalton> he has a good memory
<tjaalton> it's been 1.5 years without any incident though ;)
<tjaalton> and this time really hurt all the distros
<jcristau> well there was a bit of trouble with the last libX11 fix too
<tjaalton> oh right
<tjaalton> my memory isn't that great
<jcristau> :)
<tjaalton> <g>
<tjaalton> duh, I'm having hard time merging/pulling with a tag.. it keeps getting it all
<jcristau> git-pull . tag <tag>
<tjaalton> hmm
<tjaalton> yeah, looks a lot better, thanks
<tjaalton> not that the patch wouldn't be useful, but it messes up the changelog
<ubotu> New bug: #184191 in vlc (universe) "(gutsy) vlc crash on startup (serial 472 error_code 11) (dup-of: 183969)" [Undecided,New] https://launchpad.net/bugs/184191
<ubotu> New bug: #184192 in vlc (universe) "vlc wont start (hardy) (dup-of: 183969)" [Undecided,New] https://launchpad.net/bugs/184192
#ubuntu-x 2008-01-19
<ubotu> New bug: #17601 in xterm (main) "[xterm] add better charclass map" [Wishlist,New] https://launchpad.net/bugs/17601
<ubotu> New bug: #184212 in linux-restricted-modules-2.6.24 (restricted) "package nvidia-glx-new 169.07+2.6.24.4-4.11 failed to install/upgrade: subprocess post-removal script returned error exit status 2" [Undecided,New] https://launchpad.net/bugs/184212
<tjaalton> bryce: heh, so I ended up on that blog post.. tough
<tjaalton> uh, late ->
<bryce> tjaalton: yeah I saw your name and winced.  I think it was rude of that guy to put people's names there, particularly as the people he listed were the most hard working bug fixers in Ubuntu.  
<pwnguin> heh
<pwnguin> does canonical pay you guys for referrals to their support sales team?
<pwnguin> more importantly, how do i get gdb to display a value?
<pwnguin> "the other thing that'd be interesting is if you can reproduce the crash in gdb,"
<pwnguin> print out dev->name. this way we know which device causes the problem.
<pwnguin> normally i use ddd or similar. but i think you know the problem with that ;)
<pwnguin> cute, it seems that "erasor" is the device segfaulting X
<tjaalton> bryce: any publicity is good publicity :)
<pwnguin> tjaalton: i think 90 percent of user frustration with bugs is caused by fixing bugs in the ubuntu+1 first
<pwnguin> if ever =/
<pwnguin> does anyone on the X team have a wacom device?
<tjaalton> I don't.. not even a touchpad on the laptop
<pwnguin> that must make it hard to package wacom-tools ^_^
<tjaalton> not really, packaging is easy
<pwnguin> well testing
<tjaalton> you just can't test it :)
<tjaalton> maybe a wacom would be useful for photo editing, but the useful devices are like 300EUR and up
<tjaalton> duh, A4 sized are 500EUR->
<pwnguin> ive seen a few for under 100
<pwnguin> but i guess they're not "useful"
<pwnguin> my laptop has one built into the screen, and its highly useful
<ubotu> New bug: #184269 in amule (universe) "amule received an X Window System error (dup-of: 183969)" [Undecided,New] https://launchpad.net/bugs/184269
<soren> I've seen some at $50.
<pwnguin> i assume the statement was useful
<pwnguin> and while they're useful for testing
<pwnguin> i guess that's not quite enough for tj ;)
<soren> meh
<tjaalton> Bamboo One is 56EUR, not too bad but I'm not sure if it would be more than a toy :)
<tjaalton> lenovo sells keyboards that are similar to the ones on thinkpads, and they also have a touchpad
<tjaalton> but it's over 100EUR, but then I'd have a touchpad :)
<tjaalton> butbut
<tjaalton> bryce: the xserver upload failed to build, so I'll take the opportunity to add a couple of patches which are already upstream
<tjaalton> "honor displaysize" and the smartscheduler fix mentioned on u-d-d@
<tjaalton> actually, I'll check if the displaysize patch is upstream or just fedora
<ubotu> New bug: #184295 in libxmu (main) "Please sync a new version from Debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/184295
<ubotu> New bug: #184296 in xserver-xorg-video-ati (main) "Server crash at startup when Xinerama enabled" [Undecided,New] https://launchpad.net/bugs/184296
<ubotu> New bug: #184297 in xorg-server (main) "FTBFS" [Undecided,In progress] https://launchpad.net/bugs/184297
<ubotu> New bug: #173578 in xorg (main) "Videomode not supportet" [Undecided,Incomplete] https://launchpad.net/bugs/173578
<ubotu> New bug: #184396 in xorg-server (main) "[PATCH] Improve the xorg scheduler to improve battery performance " [Undecided,New] https://launchpad.net/bugs/184396
<ubotu> New bug: #184430 in xorg-server (main) "[hardy] X locks with lots of "tossed event which came in late. mieqEnequeue: out-of-order valuator event; dropping."" [Undecided,New] https://launchpad.net/bugs/184430
#ubuntu-x 2008-01-20
<ubotu> New bug: #184492 in xorg-server (main) "xserver-xorg-core update breaks suspend in gutsy" [Undecided,New] https://launchpad.net/bugs/184492
<ubotu> New bug: #184512 in linux-restricted-modules-2.6.24 (restricted) "E: xorg-driver-fglrx: subprocess post-removal script returned error exit status 2" [Undecided,New] https://launchpad.net/bugs/184512
<ubotu> New bug: #184520 in xorg (main) "synaptics touchpad doesnt scroll | Heron-alpha 3" [Undecided,New] https://launchpad.net/bugs/184520
<Q-FUNK> jcristau: have Bart's two x86emu patches been merged in sid?
<jcristau> no
<Q-FUNK> ok.  why not?
<jcristau> because i'm not able to review them, because they're not upstream, and because i spent some time dealing with the security updates for 4 different versions
<jcristau> which was ok, except i had to do that twice
<Q-FUNK> ok.  how soon can you get around it?
<jcristau> when it's upstream
<Q-FUNK> I personally don't expect upstream to react to anything "outsiders" send, so might as well not wait for their blessing.
<ubotu> New bug: #99356 in xorg-server (main) "[Feisty/Gutsy] Keyboard repeats keystrokes like tttthiiiiiiiiiiiissss" [Undecided,Confirmed] https://launchpad.net/bugs/99356
<ubotu> New bug: #134180 in linux-restricted-modules-2.6.22 "X does not start after 8/22 fglrx update " [Undecided,New] https://launchpad.net/bugs/134180
<ubotu> New bug: #184651 in xorg-server (main) "Crash when starting gnome-settings-daemon" [Undecided,New] https://launchpad.net/bugs/184651
<ubotu> New bug: #184686 in xserver-xorg-video-intel (main) "When compiz is enabled, videos and visualizations don't work properly" [Undecided,New] https://launchpad.net/bugs/184686
<ubotu> New bug: #184692 in xorg (main) "[Hardy] screen turns blank when X loading, ATI X1250" [Undecided,New] https://launchpad.net/bugs/184692
#ubuntu-x 2009-01-12
<seb128> tseliot: did you have a chance to look at bug #314406 yet btw?
<ubottu> Launchpad bug 314406 in gnome-desktop "xrandr plugin of g-s-d crashes on startup" [Medium,Confirmed] https://launchpad.net/bugs/314406
<tseliot> seb128: yes, but I'm waiting for Gnome's API freeze
<seb128> tseliot: why?
<tseliot> because I would like to adapt the patch to use the new functions in libgnome-desktop
<tseliot> and I would like to write my patch only once
<seb128> which means g-s-d will crash for everybody who changed their config upgrading to jaunty only because the upstream code might change again?
<tseliot> seb128: no, it means that I would like to rebase my patch on the new code instead of simply keep adding functions which upstream drops
<seb128> ah ok
<tseliot> seb128: BTW doesn't the API freeze begin tomorrow?
<seb128> tseliot: let me look at the schedule
<tseliot> no, sorry, 14
<tseliot> the 14th
<seb128> tseliot: it does start this week indeed
<tseliot> good :-)
<seb128> I doubt anybody will do changes now
<seb128> you can start working on your changes ;-)
<tseliot> ok
<bryce> mm, new xserver 1.5.99.901
<tjaalton> yep
<bryce> tjaalton: I'd also like to see the patch for bug #260138 in our new xserver
<ubottu> Launchpad bug 260138 in xorg-server "Xorg needs client limit raised" [Unknown,Confirmed] https://launchpad.net/bugs/260138
<bryce> tjaalton: should I wait until you've finished the xserver packaging (so I can test builds), or put it in git for now after ensuring the patch applies, or...?
<tjaalton> bryce: I was just thinking about it :)
<tjaalton> the feature
<tjaalton> the proto needs to be fixed first
<tjaalton> maybe after alpha3
<bryce> bug 260138 after alpha3, or the new xserver after alpha3?
<ubottu> Launchpad bug 260138 in xorg-server "Xorg needs client limit raised" [Unknown,Confirmed] https://launchpad.net/bugs/260138
<tjaalton> that bug
<Alexia_Death> tjaalton: there are several input patches merged to 1.6 only recently...
<Alexia_Death> did they get in?
<bryce> tjaalton: ok
<tjaalton> Alexia_Death: I'm not sure
<tjaalton> Alexia_Death: oh, if they were already merged it means that they are in the rc1
<Alexia_Death> tjaalton: the last one was merged today...
<Alexia_Death> not in rc1
<Alexia_Death> and it fixes messed up buttons for tablers.
<Alexia_Death> there also was a crash fix and history buffer fix.
<tjaalton> then it was merged to master, not 1.6-branch
<Alexia_Death> tjaalton: cherrypicked for 1.6 all of them
<Alexia_Death> and merged to both afaik-
<tjaalton> Alexia_Death: which means they are in rc1..
<Alexia_Death> even the one merged today?
<tjaalton> rc1 was tagged 33min ago
<Alexia_Death> oh!
<tjaalton> oh, 23min
<Alexia_Death> O_O
<Alexia_Death> then they are in!
<Alexia_Death> YAY.
<Alexia_Death> then theres only a little issue with wacom diver and we have HOTPLUG!
<Alexia_Death> tjaalton: sorry, I didnt know when rc1 was taged.
<tjaalton> np :)
<Alexia_Death> tjaalton: when its inn I will have mpre testers for my hotplug daemon...
<Alexia_Death> tjaalton: it works btw;)
<tjaalton> cool
<Alexia_Death> got a tablet yourself?
<tjaalton> I've got mine sitting idle..
<Alexia_Death> :)
<Alexia_Death> With those patches in, all thats needed is a little hack in wacom driver to keep X from killing itself when devices are removed and then you can just run the daemon and all will work.
<Alexia_Death> err... except perhaps pad buttons
<superm1> bryce, i had a short call with NV a little bit ago, and i posed a question about upgrading the ABI on older driver releases.  they're not likely to be doing it on r177 and below, but likely r180 and newer only
<superm1> makes you question whether supporting all the other "older" stuff at all in the archive will be worth it
<bryce> dah
<tjaalton> \o/
<tjaalton> :)
<bryce> hrm, well until nouveau is better (or -nv de-obfuscates), that leaves us a bit stuck...
<tjaalton> I know who's going to get all the shit..
<tjaalton> oh, sh*t
<bryce> superm1: I've a call with them tomorrow, do you have suggestions for what I should communicate?
 * bryce passes out fans
<bryce> wish we could do stuff like that...
<tjaalton> maybe we do need a plan-b regarding nouveau (2D)?
<bryce> has there been much testing on older cards?
<tjaalton> no idea
<tjaalton> altough, I'm not sure if it's better than -nv on those
<tjaalton> some extra features yes
<tjaalton> maybe it would be too much of an effort to make it supportable at this point..
<jcristau> canonical could hire a nouveau developer :p
<tjaalton> heh :)
<superm1> bryce, well you can ask them to support more of  the releases, but from what i understand on how their development is working, porting the stub that identifies ABI supported in the driver becomes more and more work for them
<superm1> bryce, so at least from the Dell perspective, we're asking them for current stable driver (r180) + unstable driver (r18[0+x]) match the ABI
<tjaalton> there's a thread on nvnews.net where an update was requested (a couple of months ago), and they said that it was a WIP but low-priority... indeed
<bryce> ideas on quantity of cards that will become unsupported in -nvidia with this, compared with intrepid?
<bryce> few, lots, ...?
<tjaalton> lots
<superm1> bryce, so perhaps a good question to pose to them from your perspective is whether there is any intention of dropping cards with releases, or if they can try to focus on keeping cards supported going forward
<tjaalton> 6xxx and earlier are now unsupported
<superm1> oh they are. psh :(
<tjaalton> well, would be if it's true
<tjaalton> since 173 was the last one supporting 5xxx, and IIRC 177 supported 6xxx?
<tjaalton> and 180 dropped it
<superm1> man, that really sucks then.
<tjaalton> oh sorry, seems like 6xxx is supported by 180.22
<superm1> if they can commit to not dropping cards, then can at least transition people from 177 to 180 at upgrade
<tjaalton> yes
<bryce> okay
<tjaalton> but the ones supported by -96 and -173 would be lost
<tjaalton> but hey, there's hardy
<tjaalton> :)
<superm1> heh
<bryce> feh, really if they intend to stop giving ABI updates for those, and drop card support in the process, they should release the docs for those old chips
<bryce> else they'll just be encouraging people to switch to ATI/Intel
<tjaalton> well, the GF5 series is maybe 5y old
<superm1> well it's a question you can throw out at them at least about docs if they're not going to do ABI updates
<tjaalton> it would be really nice
<bryce> yeah, like "would you be open to considering releasing docs for ...."
<bryce> I think I know the answer, but it's worth asking
<tjaalton> "beep - beep - beep ..."
<tjaalton> :)
<bryce> if 6xxx is supported by 180.22, does that cut down the quantity of unsupported cards?  Or is it still "lots"?
<tjaalton> GF5xxx and the delta between 96/173
<tjaalton> ie. the ones that 96 supports but 173 doesn't
<superm1> sounds like it will be a fun call for you tomorrow :)
<tjaalton> looks like GF4 & GF5
<bryce> superm1: and shuttleworth will be on it too...
<superm1> no pressure or anything
#ubuntu-x 2009-01-13
<bryce> http://i43.tinypic.com/hwh4xw.jpg
<tjaalton> sigh, intel 2.6rc2 fails to build against .28 and libdrm 2.4.3
<tjaalton> ..because XF86DRM_MODE is defined for some reason
<Alexia_Death> When will xserver's 1.6 rc1 hit repros?
<tjaalton> looking more like post-alpha3
<Alexia_Death> in timframe that wouldbe when?
<Alexia_Death> Once it does and wacom driver gets updated or patched hotplug actually becomes possible for wacoms.
<tjaalton> well, Friday at the earliest
<Alexia_Death> :)
<Alexia_Death> Sounds almost perfect. then I can get people to test it without any mess.
<tjaalton> my laptop is utterly broken with the current intel & libdrm 2.4.3, and the 2.6rc2 doesn't build, so I need to sort that out too
<tjaalton> before any xserver sillyness :)
<Alexia_Death> ehee
<superm1> bryce, on that bug about vesa not working on the development hardware; i've got to return the hardware to another group, so is there anything else you'd like on the bug before i do so?
<bryce> superm1: not offhand
<superm1> ok thx
<Alexia_Death> tjaalton: http://a.death.pri.ee/watahod-0.2.tar.gz is the current state of my hotlug daemon. be warned, unpatched wacom driver kills X on rmove.
<tjaalton> Alexia_Death: ok thanks
<Alexia_Death> tjaalton: oh, and dont try it before you run the rc1...
#ubuntu-x 2009-01-14
<bryce> hmm
<bryce> ../../src/i830_dri.c: In function 'I830DRISwapContext':
<bryce> ../../src/i830_dri.c:1162: error: 'drm_i915_flip_t' undeclared (first use in this function)
<bryce> ../../src/i830_dri.c:1162: error: (Each undeclared identifier is reported only once
<bryce> ../../src/i830_dri.c:1162: error: for each function it appears in.)
<bryce> ../../src/i830_dri.c:1162: error: expected ';' before 'flip'
<bryce> ../../src/i830_dri.c:1168: error: 'flip' undeclared (first use in this function)
<bryce> that's with xserver-xorg-video-intel_2.5.1-1ubuntu7.dsc that's already in the archive.  I wonder if libdrm or something has changed?
<bryce> mm bug #308387 perhaps
<ubottu> Launchpad bug 308387 in linux "[Jaunty] trying to overwrite `/usr/include/drm/drm_sarea.h', which is also in package libdrm-dev" [Undecided,Fix committed] https://launchpad.net/bugs/308387
<tjaalton> bryce: we discussed it with jbarnes on #ubuntu-desktop
<tjaalton> the kernel drm headers need updates
<tjaalton> either that or we Replace linux-libc-dev again and ship the intel headers in libdrm-dev
 * jcristau is happy he misses out on that fun for now
<lool> jcristau: :)
<lool> tjaalton: Did they push the updates to the upstream kernel?
<tjaalton> lool: no idea.. there are so many branches to choose from
<lool> tjaalton: Eh :)
<seb128> tseliot: hi
<seb128> tseliot: could you look at bug #316887? I'm wondering if the error comes from your tool to change the xorg config or from the capplet
<ubottu> Launchpad bug 316887 in gnome-control-center "gnome-display-properties: "Mirror screens" problems" [Undecided,New] https://launchpad.net/bugs/316887
 * tseliot has a look at the bug report
<tjaalton> lool: and it's not clear if that's even pushed to the kernel yet
<tseliot> seb128: I've never seen that error before. I'll see if I can reproduce it here
<tseliot> seb128: I doubt it depends on my changes though
<seb128> ok
<tseliot> seb128: it looks like the author of the randr capplet rewrote more or less what I had done in my patch in gnome-rr-config.c
<pcjc2> hi guys
<tseliot> seb128: hehe, less work for me
<seb128> cool
<pcjc2> that last comment sounds like something related to what I'm about to ask
<pcjc2> does anyone else see / has seen reported, a nasty intereaction between gnome-settings-daemon 's Xrandr support, and output probing in the latest Intel video driver?
<pcjc2> I'm getting a loop of events
<pcjc2> Xrandr notify event -> pokes gnome-settings-daemon.
<pcjc2> gnome-settings-daemon requests info on the screens from Xorg
<pcjc2> Intel driver re-probes hardware (l a a a a a a a g g g g)
<pcjc2> Somewhere along the line.. another notify event is emitted, and we get a lovely loop
<tseliot> pcjc2: what happens exactly? What are the symptoms?
<pcjc2> Nasty nasty lagging system, because the intel driver is re-probing its outputs as fast as the loop progresses
<pcjc2> I also get a reprobe for every step-change in backlight brightness - although I don't actually seem to get an infinite loop on that one
<pcjc2> My loop is usually triggered by pulling the AC adaptor out / putting it back in, which seems to fire off a LID event
<tseliot> can you reproduce the problem with backlight without the gnome-settings-daemon?
<tseliot> e.g. if you kill the gnome-settings-daemon
<pcjc2> works much better after killing g-s-d
<pcjc2> although HP still suck for not implementing it as ACPI notifications
<pcjc2> (Hotkey scancodes.. on a machine designed for Vista? That doesn't even meet Microsoft's low standards)
<pcjc2> ah damn
<pcjc2> turned mu brightness right down - seems ot have shut down the backlight, and it won't turn back on
<pcjc2> ok xbacklight managed to fix it, but something busted whatever the usual mechanism is..
<pcjc2> hotkeys don't work
<pcjc2>  /proc/acpi/video/GFX0/*/brightness return unsupported - and they did work before
<tseliot> hmm... it looks like g-s-d listens for any event coming from the screen
<tseliot> and you can control the backlight from randr
<pcjc2> Judging by the lag and system responsiveness after calling xbacklight, that is causing a path which does more work than it ought to
<tseliot> ok, maybe it would be useful to limit the events the g-s-d should listen to
<pcjc2> although I'm not getting the jittering mouse pointer usually indicative of the the intel driver probing its outputs
<pcjc2> I backtraced them.. I can let you know what type of event I was getting
<tseliot> good
<pcjc2> but it appeared to be the same Xrandr subtype for the brightness change, and the situation which got me into a big long loop
<pcjc2> I sent the details to the Xorg ML, should I forward to ubuntu-x?
<tseliot> I can check the X ML
<pcjc2> basically, its event subtype 2 I'm getting
<pcjc2> Subject: 	Xrandr loop with gnome-settings-daemon  [WAS: Re: Intel GM45: Loop of continuously triggered output detections
<tseliot> ok, I found it
<pcjc2> tseliot: Is your patched gnome-rr-config.c in Jaunty?
<pcjc2> (Was wondering if a kindof race could be happening between that and g-s-d's code
<pcjc2> )
<tseliot> pcjc2: yes, but I'm about to rework it.
<tseliot> it only affects when you first load g-s-d from the xml and when you apply your settings from the applet
<pcjc2> fair enough.. do you think the interaction between the two might have been the problem?
<pcjc2> ok
<pcjc2> When I restart g-s-d, I sometimes get an assertion failure in gnome-rr
<pcjc2> ** (gnome-settings-daemon:20549): CRITICAL **: gnome_rr_config_save_to_file: assertion `error == NULL || *error == NULL' failed
<tseliot> I can't reproduce the problem here and I don't touch events at all but you can try the new patch when it's available
<tseliot> that part is going away
<pcjc2> no - I'm suspecting this is something the Intel driver might be exacebating
<tseliot> likely
<pcjc2> I don't see why it needs to probe hardware on a call to request info
<tseliot> right
<tseliot> it's a bit weird
<pcjc2> XRRGetScreenSizeRange causes the probe
<pcjc2> I guess somewhere along the lines, it needs to probe
<pcjc2> OTOH, something really needs to cache if its going to want this info at every brightness change
<tseliot> XRRGetScreenSizeRange is called every time an event from randr is caught by the g-s-d
<pcjc2> you're telling me...
<tseliot> which is not right
<pcjc2> It did smack of "FIXME"
<tseliot> I can write a patch to limit the number of events
<tseliot> the g-s-d listens to
<pcjc2> but I thought it wise to prod the Xorg people to see if the loop was a problem
<tseliot> you did well
<pcjc2> Perhaps we should disable retrival events whilst making a request like that - not sure what the correct locking semantics should be
<pcjc2> New laptop, new drivers... new bugs
<pcjc2> Thanks...
<tseliot> if you change the backlight there's no need to check the size of the screen
<pcjc2> the hardest part was figuring out it was g-s-d's "fault"
<tseliot> and it shouldn't be difficult to change that
<pcjc2> mostly by trauling through sysprof profiles to see which processes were actually executing code during the problem.
<pcjc2> I've still not figured out what event it is which causes the infinite loop - brightness changes don't seem to be the problem
<tseliot> a lot of fun, eh?
<pcjc2> (Although the request triggered by that is causing changing brightness to stall the whole system)
<pcjc2> I already had most of the debug packages isntalled anyway.. I've been doing software development on a GPL Electronics CAD package, and have been testing out the new cairo rendering with the git HEAD intel drivers
<pcjc2> poking sysprof to figure out where the bottlenecks are is kindof routine
<mvo> hey, just to confirm, we currently do not have nvidia drivers for the latest xserver-xorg-core? (not sure if that went though before I disconnected)
<tjaalton> no
<tseliot> nope
<mvo> thanks
<mvo> I add code in update-manager to deal with that for now
<mvo> same for fglrx I suppose?
<tjaalton> yep
<tseliot> mvo: if nvidia doesn't solve the problem we'll have to use X-Kit to enable the IgnoreABI option in xorg.conf for some drivers
<tseliot> as some drivers work with that option in xorg.cofn
<pcjc2> tseliot: looking at /usr/include/X11/extensions/randr.h shows the subtype of the notify events I'm getting back is RRNotify_OutputProperty
<mvo> tseliot: and that works reliable?
<tjaalton> mvo: basically unsupported
<tseliot> mvo: which one? The option or X-Kit?
<mvo> tseliot: is this planed for alpha-3 ? or should I go ahead and enable checks for update-manager to warn the user and update the xorg.conf?
<mvo> tseliot: well, does xorg and nvidia play nicely together if that option is given even if the abi changed?
<tseliot> mvo: not always
<tjaalton> only with 180 AIUI
<tseliot> mvo: I believe it would be safe to disable nvidia in the xorg.conf for now
<mvo> thanks tseliot and tjaalton
 * mvo wonders if you irc need needs to start with "t" to be a great ubuntu xorg guy :P
<tseliot> we should change bryce into tbryce then :-P
<tseliot> pcjc2: let me have a look at the protocol spec
<mvo> yeah :)
<tjaalton> heh
<tjaalton> nice, 12kb diff between i915_drm.h from 2.6.28 and libdrm 2.4.3
<tseliot> pcjc2: ah, the g-s-d catches RRScreenChangeNotifyMask, RRCrtcChangeNotifyMask, RROutputPropertyNotifyMask
<tseliot> pcjc2: it's definitely RROutputPropertyNotify's fault
<tseliot> (for the backlight)
<tseliot> well, catching that is the cause
<tseliot> not the notification itself
<tseliot> I'll patch that out
<mvo> is there a open bugreport about the abi thing in nvidia/fglrx? I would like to subscribe
<tseliot> sure, let me check
<tseliot> https://bugs.launchpad.net/bugs/308410
<ubottu> Ubuntu bug 308410 in nvidia-graphics-drivers-180 "Latest Xorg removes nvidia driver ... conflicting xserver-xorg-video-4" [Medium,Confirmed]
<tseliot> mvo: ^^
<mvo> thanks tseliot
<mvo> tseliot: I added a update-manager task (just so that if there is no update we can prepare)
<tseliot> mvo: ok, good. This time we can use X-Kit as it supports commenting out things now
<mvo> excellent
<pcjc2> tseliot: Good stuff
<pcjc2> I just scanned through the spec, and I don't think it mentions what Xrandr queries might cause the hardware to probe
<pcjc2> but I did notice that if you haven't got the required timstamp (ie.. your idea of the configuration doesn't match the Xserver's), requests will fail
<pcjc2> let me know if you want me to test anything before you push it out..
<pcjc2> I'm pcjc2@cam.ac.uk, and am on the ubuntu-x ML
<tseliot> pcjc2: ok, great. I'll send you an email as soon as my patches are ready
<tseliot> pcjc2: if that request fails you should only get a RRCONFIGSTATUS which corresponds to the error. No additional probing should be involved
<pcjc2> sure.. I just wondered if the reason they poked for details in the first place was so that they had a valid timestamp
<pcjc2> Since they don't appear to have probed a full complement of details, I guess that doesn't really help
<pcjc2> I've got to go now,
<pcjc2> thanks for your assistance
<tjaalton> hum, intel 2.5.99.2 fails after login
<tjaalton> exaCopyDirty: Pending damage region empty!
<tjaalton> boom
<tseliot> nice
<tseliot> :-P
<tjaalton> hmm, maybe xserver-xorg-dev should depend on linux-libc-dev
<tjaalton> since the drm headers have moved
<tjaalton> not that it depends on libdrm-dev either, but..
<tjaalton> jcristau: do you agree with the above ^^ (once you get to enjoy the fun :)
<tjaalton> huh, what's up with firefox.. "Couldn't load XPCOM"
<pcjc2> tseliot: https://bugs.edge.launchpad.net/ubuntu/+source/libxrandr/+bug/307306 sounds like it might (possibly) be similar to the bug I was seeing
<ubottu> Ubuntu bug 307306 in xorg-server "upgrade to 2:1.2.99.2-0ubuntu1 makes session utterly slow" [Unknown,Confirmed]
<pcjc2> although he's bisected it to a libxrandr2 upgrade
<pcjc2> I tested again, and I'm actually still seeing some xrandr slowness with brightness changes, even with g-s-m killed. It _is_ better with it killed though
<tseliot> ok, so we're facing 2 different problems. One in the driver and one in g-s-d
<tseliot> which should really be one problem
<tseliot> i.e. the one in the driver
<tseliot> hmm
<tseliot> I can fix the one in g-s-d. Do you know what's causing the problem when g-s-d is not running?
<tseliot> pcjc2: ^^
<pcjc2> I've not traced it, sorry
<pcjc2> I'm not at my house - otherwise I could GDB the X server from another machine
<pcjc2> It would be telling to check if the reprobing on brightness changes are still coming from a client of the X server, not within it
<tseliot> pcjc2: this would be a first step
<pcjc2> Soren Saandman replied on Xorg saying that its the driver being bad for emitting events during the XRRGetScreenSizeRange request
<pcjc2> When I'm at my other machine, I'll trace it. Right now, if I try to GDB X11, I'd have to do it from VT1, and then the video drivers wouldn't be running properly
<pcjc2> I'd take the view, that since the spec. doesn't say when events are emitted, they can happen at any time
<pcjc2> (Although I do think XRRGetScreenSizeRange ought not to probe unnecessarily)
<pcjc2> KeithP would be the authority on this
<tseliot> yep, this is why I said that it should really be one problem. What we can do is reduce the number of times XRRGetScreenSizeRange in g-s-d. This would be a workaround. KeithP or Jesse Barnes should be able to fix the real problem.
<pcjc2> I'll see if they reply to the thread on -xorg, before proding them privately
<pcjc2> I've worked with Jesse before fixing bugs in the driver, and have had conversations with Keith various cairo, intel graphics, and general electronics issues
<tseliot> yes, they are both very helpful
<tseliot> I met Jesse at the UDS in Mountain View and Keith was very helpful when I asked him some questions via email
<tjaalton> bryce: so what happened with NV?-)
<bryce> tjaalton: ?
<superm1> bryce, assuming he is meaning the conference call you sabdfl and them were on?
<bryce> ahh, thought something happened to -nv :-)
<bryce> right, the meeting was very well attended, and went well, although we focused only on KMS
<tjaalton> no talk about the old drivers?
<bryce> the main outcome of which is that nVidia will be bringing up their issues relating to KMS on the xorg dev list after they've had some time to digest and determine a plan of attack
<bryce> I'm going to follow up on that by email
<tjaalton> ok
<tjaalton> they'll fully release the vdpau-stuff on git.fd.o
<tjaalton> and aaronp asked keith if the video ABI is final for 1.6 (no reply though :)
<bryce> btw, any issues on fglrx?
<tjaalton> issues?
<bryce> nevermind; was just on the amd call, but it's ended now
<bryce> told them we didn't know of any major new issues with fglrx; they know what kernel, etc. versions to target for 9.04 and I told them about kms for 9.10
<superm1> bryce, well does fglrx work with current jaunty even?
<tjaalton> well, fglrx doesn't work currently, thats pretty major so no idea what issues might be waiting to be discovered :)
<tjaalton> the need for fglrx in 9.10 will be pretty low (I hope)
<bryce> yep
<bryce> yeah I figured until they get us a new fglrx build the issues list is going to be short ;-)
<superm1> are there more expected ABI bumps for the 9.10 dev cycle?  or does the X roadmap look out that far?
<bryce> other than kms we generally don't look quite that far
<bryce> however I'd be surprised to not have to do an abi bump for 9.10
<superm1> while we're stuck with these binary drivers situation, it'd be nice to have a release where they worked during development time :(
<bryce> no kidding
<bryce> well I'm hopeful that my early warnings about versions and so on has helped ati in accelerating when they'll supporting version out
<bryce> also, isn't it about time for this month's fglrx release?  Or do they skip january?
<superm1> yeah.  particularly it will be nice if these early KMS warnings play out properly in their roadmap
<superm1> it's every month i thought, so probably very soon?
<bryce> they had asked if we'd tested it yet... maybe they meant had we tested their testing version?
<tjaalton> wonder if nvidia will open the modesetting driver for the kernel..
<tseliot> seb128: I have rebased my patch on the new gnome-desktop API. I don't know whether it solves the problem or not as I can't reproduce the problem described here: https://bugs.launchpad.net/ubuntu/+source/gnome-desktop/+bug/314406
<ubottu> Ubuntu bug 314406 in gnome-desktop "xrandr plugin of g-s-d crashes on startup" [Medium,Confirmed]
<tseliot> oh, he's not here and I'm talking to myself
<bryce> heh, heya tseliot
<tseliot> hey bryce
<tjaalton> the abi versions haven't been changed on master, fwiw
<tjaalton> so it's possible that 1.7 will be abi-compatible with 1.6
<tjaalton> but I don't know if there are pending changes
<tseliot> bryce: do you know where xfree() is defined in X?
<bryce> tseliot: libx11 would be my guess
<bryce> grepping on 'xfree' turns up a few too many hits ;-)
<tjaalton> xserver-xorg-dev: /usr/include/xorg/os.h
<tjaalton> maybe..
<tseliot> ok, thanks
<NCommander> bryce, hola
<Alexia_Death> tseliot: did you try the patches?
<Alexia_Death> tseliot: once rc1 gets in repros you should nit need to patch anything on X side any more.
<NCommander> bryce, I'm working on the issue we're having with Freescale SoC boards with Xorg -configure not working. I think the problem is that the autodetect rountines try and search the PCI and ISA buses, which won't find a framebuffer device on this board
<NCommander> It seems the only reason we can get X working at all is because it defaults to /dev/fb0 if all else fails :-/
<bryce> NCommander: heh
<NCommander> Yeah
<bryce> NCommander: ok first we typically don't use Xorg -configure to configure X, although no reason it shouldn't work, but that's the upstream approach for generating an xorg.conf file
<bryce> you may find it preferable to either use a custom xorg.conf you install directly, or else create a patched version of dexconf
<NCommander> I was asked to look at why it doesn't work, but if we don't use it ....
<NCommander> SO how does Xorg auto configuration work then?
<bryce> now as to the autodetect routines, yes we can certainly fix those up
<bryce> there's two things
<bryce> first is a PCIID-based approach for selecting drivers on a per-chipset basis
<NCommander> That's not going to work here
<bryce> e.g. look in /usr/share/xserver-xorg/pci/
<bryce> right, because the freescale stuff is not pci-based
<NCommander> so what's the second approach?
<bryce> the second approach is a fallback system that selects a fallback driver based on architecture (or whatever)
<bryce> so that's what falls back to vesa, fbdev, or whatever
<NCommander> Which falls back to the fbdev device, which itself can't find the framebuffer, throws up its hands and tries /dev/fb0
<NCommander> Ok, so what's your official suggestion on how to fix this problem?
<bryce> heh, you just asked me how it worked silly ;-)
<NCommander> since method one won't work, and method two isn't what I called desirable
 * NCommander falls over
<bryce> I've no clue
<NCommander> hold on, I need to reboot
<bryce> ummm
<bryce> well you could maybe look into patching the fallback approach since it at least is not pci-based
<bryce> however I suspect that's going to be of limited good
<NCommander> Well, its loading the right driver, amazingly
<NCommander> But yeah, thats a hack, even by my standards
<bryce> beyond that, ehh
<NCommander> Xorg -configure doesn't use the PCI based method, it calls the Probe method of each driver in-turn
<NCommander> Which is why i got confused
<bryce> you probably need to develop something analogous to the PCI based method but that works more appropriately for however your hardware works
<NCommander> I'm going to guess the PCI code isn't something molder, and its just a stack of stuff in a function somewhere
<bryce> yeah Xorg -configure is pretty old school and probably a blind alley for your purposes
<NCommander> Ugh, i was afraid of that
<NCommander> Hold on, I need to restart
<bryce> if it is something you can hardcode into an xorg.conf, then patching dexconf would probably be a viable option... still semi hacky, but for this probably fine
<bryce> cya
<NCommander> bryce, sorry about that
<NCommander> bryce, what's dexconf specifically?
<bryce> it's what's run during install to create the xorg.conf, or when doing a dpkg-reconfigure
<NCommander> On both the LiveCD, and d-i, or just d-i?
<bryce> pretty sure both
<NCommander> Thanks
 * NCommander is writing a report about this now
#ubuntu-x 2009-01-15
<NCommander> bryce, how can I get trace messages out of Xorg?
<bryce> NCommander: strace the X binary.  However, stracing X rarely produces useful output
<bryce> I usually end up using some combination of gdb and debugging print messages in key areas
<NCommander> That will get the TRACE( )informatoion?
<NCommander> Well, I'm not getting anything out of the fbdev driver
<NCommander> I can't even tell if its probe function being run
<bryce> gdb - breakpoints
 * NCommander grabs his ddebs
<bryce> debugging prints use X's internal debug/trace function calls (look around in whatever module you're working on for examples)
 * NCommander nods
<NCommander> Right, but how do I get those trace calls to actually print something, I'm not seeing anything with GDB
<bryce> they should be printing to your Xorg.0.log; if not then presumably there's some option or flag that needs set
<NCommander> Oh, thanks
 * NCommander is an idiot, plain and simple
<NCommander> At least I found my issue
<bryce> heh
<NCommander>         /* For now, just bail out for PROBE_DETECT. */
<NCommander>         if (flags & PROBE_DETECT)
<NCommander>                 return FALSE;
<NCommander> -_-;
<NCommander> Why didn't I see that earlier ...
<bryce> btw fwiw exit error messages print to your /var/log/gdm/ files
<bryce> (although sometimes I find it useful to shut down gdm and use startx, so the errors show up at the console)
<NCommander> Debugging Xorg is a whole new ballgame
<bryce> tell me about it
<NCommander> bryce, want to wager a guess why probing is disabled by default on the fbdev driver?
<bryce> unimplemented?
<NCommander> Well,
<NCommander> doesn't seem like it
<NCommander> SCORE!
<NCommander> I make Xorg segfault!
<bryce> sometimes I also find it interesting to grab the git tree (cgit.freedesktop.org) and browse the changelog for the specific file... sometimes people include more details in their commit message why bits of code were added
<NCommander> ah, handy
<NCommander> I'll try that
<pwnguin> (10:29:01 PM) Justin Dugger: can you bring up a terminal?
<pwnguin> (10:29:06 PM) Dave: yes
<pwnguin> (10:29:27 PM) Justin Dugger: ps aux | grep firefox
<pwnguin> (10:30:13 PM) Dave: GOD DAMMIT
<pwnguin> aww
<pwnguin> crap
<pwnguin> wrong paste buffer =(
<pwnguin> jldugger@jldugger:/var/log $ ls -l XFree86.0.log 
<pwnguin> -rw-r--r-- 1 root root 42035 2005-05-08 01:15 XFree86.0.log
<RAOF> Old school!
<pwnguin> yea
<pwnguin> i just upgrade, and upgrade
<pwnguin> which apparently nobody does
<pwnguin> because i get random bugs like "oh we switched to adm instead of admin"
<pwnguin> meanwhile, my poor friend dave has been suffering in 8.04, where compiz seems to be crashing everything
<pwnguin> wherein he has just admitted to adding things to xorg.conf to fix something
<bryce> "It was slow, so I turned on some experimental options which sped it up.  Btw, it's crashing a lot, do you know what that might be?"
<RAOF> Heh.
<tseliot> seb128: I have rewritten my patch but I'm not sure as to whether it solves the problem since I can't reproduce the it: https://bugs.launchpad.net/ubuntu/+source/gnome-desktop/+bug/314406
<ubottu> Ubuntu bug 314406 in gnome-desktop "xrandr plugin of g-s-d crashes on startup" [Medium,Confirmed]
<tseliot> the patch is in my branch: https://code.edge.launchpad.net/~albertomilone/gnome-desktop/tseliot-fixes
<seb128> tseliot: I'll give it a try thanks
<seb128> tseliot: did you try to use an intrepid config?
<tseliot> seb128: no, I didn't
<seb128> that's what was making it crash
<tseliot> do you have one
<tseliot> ?
<seb128> there is one on the bug no?
<seb128> let me look
<tseliot> ah, right, it wasn't attached but only copied and pasted
<seb128> the xml is in the bug description
<seb128> one of the dup has one too
<tseliot> ok, let me try it
<tseliot> seb128: when I log in an error dialog tells me that the settings cannot be applied and g-s-d doesn't segfault
<seb128> ok good
<tseliot> seb128: however I was able to reproduce another bug (with my own xml file) which creates an endless loop. I would like to fix this one too
<seb128> the one you were discussing on the chan yesterday?
<tseliot> yep
<tseliot> I think that when the backlight is changed, the driver reprobes outputs, etc.
<seb128> do you want to get that in the same upload? that's also a gnome-desktop change?
<tseliot> yes, it's in gnome-desktop and it would be nice to have both patches in the same upload
<seb128> ok, let me know when you want to get those sponsored
<seb128> I'll not upload right now anyway due to the jaunty freeze
<tseliot> seb128: also I didn't say that my patch fixes bug 314 as I wasn't sure that it could actually fix the bug. I'll correct the changelog too
<tseliot> ok
<ubottu> Launchpad bug 314 in baz "Repeated "adding revision" output when archive-mirroring a specific revision" [Medium,Fix released] https://launchpad.net/bugs/314
<tseliot> seb128: I can solve the other problem only if I stop both gnome-settings-daemon and gnome-power-manager on my laptop
 * tseliot tries preventing g-s-d from listening to any kind of randr event
<tseliot> no, it doesn't solve the problem
<tseliot> seb128: I have found a workaround for the 2nd bug
<tseliot> seb128: the reak problem should be in either X or in the Intel driver though
<tseliot> s/reak/real
<seb128> what is the workaround, wouldn't it better to fix the driver?
<tseliot> seb128: if I prevent both g-s-d and gnome-power-manager from listening to RandR events I can't reproduce the problem
<tseliot> yes, it would be better to fix the driver instead. I've never touched Intel code but I'll see what I can do
<seb128> ok
<tjaalton> is this the 'randr-probe bombing' bug, making the session slow?
<tseliot> yep
<tjaalton> AIUI it only happens with the updated libxrandr
<tjaalton> but you already knew that?
<tseliot> no, I didn't
<tseliot> ok, I'll have a look at the diff then
<tjaalton> bug 307306
<ubottu> Launchpad bug 307306 in xorg-server "upgrade to 2:1.2.99.2-0ubuntu1 makes session utterly slow" [Unknown,Confirmed] https://launchpad.net/bugs/307306
 * tseliot > lunch
<tseliot> thanks
<tseliot> seb128: I have fixed another issue in my patch so that it doesn't complain that the xml in .gnome2 is missing when no configuration file is available
<seb128> tseliot: ah good
<tseliot> seb128: I'll put it in my branch soon
<seb128> cool
<tseliot> seb128: another thing. Currently if some of the devices described in the xml are not connected you get an error message on login (every time) which says that your settings cannot be applied. Do we really want this?
<seb128> I would say we don't no
<tseliot> ok, in which case do you think we should show the error dialog?
<tseliot> seb128: shall I simply ignore the error and prevent g-s-d from showing the dialog every time?
<seb128> I think that makes sense
<tseliot> ok
<NCommander> bryce, w.r.t. to the machine id autoconfiguration mechanism discussed on the list, do you think there will be any issues getting that included in Ubuntu Xorg packages? (I'm working upstream git, but it probably will take some time/effort before the changes would flow from upstream into Ubuntu)
<tjaalton> NCommander: sure
<tjaalton> er, I mean it's possible to just add a patch for now
<tjaalton> when it works
<NCommander> tjaalton, well, I'm drafting an email to xorg@lists.fd.org
<NCommander> tjaalton, is there an Ubuntu-X list I can Cc?
<tjaalton> sure, ubuntu-x@l.u.c
<NCommander> tjaalton, thanks :-).
 * NCommander adds this channel to his AJOIN list
<NCommander> tjaalton, sent :-)
<tseliot> seb128: I have updated my patch and the changelog in my branch: https://code.edge.launchpad.net/~albertomilone/gnome-desktop/tseliot-fixes
<seb128> tseliot: ok, sponsoring will not be for today they are still working on the alpha but I'll give it a try later and let you know how it works for me
<tseliot> seb128: ok, great
<seb128> tseliot: could you add a comment to the bug to say that you have an updated version?
<tseliot> sure
<tseliot> done
<seb128> thanks
<NCommander> tseliot & bryce, I'd like feedback on my load mechanism once you get a few minutes.
<superm1> bryce, i'm assuming intel 2.6 will be pulled in for jaunty, correct?  If so, i might try to formulate some patches that will get HDMI audio working without jumping to a whole knew alsa version
<tjaalton> superm1: correct, once it builds against the kernel drm headers
<superm1> oh that's still not sorted :(
<tjaalton> nope
<superm1> where's the disconnect right now?
<tjaalton> it needs some compat stuff in the headers
<superm1> so would it make more sense to ship this then in the X package where you guys can control it for most of the release and switch to the kernel one when you know it gets stable then, or is this more of a one off thing that shouldn't be happening very often?
<tjaalton> well, shouldn't happen anymore after this :)
<bryce> heya
<bryce> tjaalton: what's the next step we should do for getting the kernel headers sorted?
<tjaalton> bryce: filing a bug and assigning it to jbarnes (doing right now)
<tjaalton> there, freedesktop bug 19591
<ubottu> Freedesktop bug 19591 in General "intel driver doesn't build against 2.6.28 drm headers" [Normal,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=19591
<bryce> tjaalton: are there any kernel-side changes to be done in ubuntu?
<tjaalton> bryce: whatever comes from that bug
<tjaalton> once it's applied upstream, it'll be pretty simple for them to pull
<tjaalton> them = kernel-team
<bryce> ok great
<tjaalton> one fix was pulled in earlier, but it wasn't enough
<bryce> so.. next question is xserver; how are we with that, anything I can help get sorted out?
<tjaalton> I've merged it locally.. the only thing that probably should be added is the build-dep on linux-libc-dev, and adding it to xserver-xorg-dev deps
<tjaalton> *the only thing missing until ok to upload, that is
<tjaalton> I'll have time tomorrow :)
<bryce> ok cool
<bryce> perfect; we're in freeze still today anyway :-)
<tjaalton> the drm header mess is holding mesa too
<tjaalton> +back
<bryce> erk, not fixed in the latest rc?
<tjaalton> it doesn't build
<bryce> what's the plan there?
<tjaalton> the same fix as with -intel
<tjaalton> the dri driver from mesa doesn't build
<tjaalton> practically the same error too
<bryce> ok, do we need a bug in on it too, or will someone (jesse?) address it when intel is addressed?
<tjaalton> 'drm_i915_flip_t' undeclared
<tjaalton> once the drm headers are fixed, the dri driver should build
<tjaalton> so it's the same bug
<bryce> ok
<tjaalton> also mentioned there
<tjaalton> (on the bug)
<NCommander> bryce, how much do you know about regular autodetection? it *looks* like the FBDevProbe functions are called, so I'm now extremely confused
<bryce> NCommander: I've tinkered with it only a bit, and more with the PCI stuff than the probe stuff
<NCommander> Well, I'm just seeing if I'm loosing my mind about how AutoConf works
<bryce> iow, at this point you may know more than me... but feel free to bounce ideas off me
<NCommander> Well, it looks like the probe functions ARE called
<NCommander> (i don't see where, the backtrace says its somewhere in xf86CallDriverProbe from InitOutput)
<NCommander> Oh wait, this may be one of those **** I'm an idiot things :-)
<bryce> hehe
<NCommander> Its getting to the fbdev prober because its falling back on it
<NCommander> (no other drivers are loading)
<NCommander> WHich in turn calls its own probe functions.
 * bryce nods
<NCommander> Mystery solved
<NCommander> Now if I can just figure out how to sanely get info out of FB devices :-)
<bryce> sometimes the fallback logic feels like pinball ;-)
<NCommander> This code base burns in all sorts of unclean ways
<NCommander> Figuring out the build system was the first fun bit
<NCommander> I always wondered why it was called the X strike force
<NCommander> Now I know
<bryce> heh
<NCommander> Oh
<NCommander> You are ****ing kidding
<NCommander> the FB ID string can have nulls in place of spaces
<NCommander> ARGHHHHHHHHHHHHHHHHHHHH
<bryce> eww
<bryce> that's crazy
<NCommander> Ugh. it makes me want to scream, rant, rave, find the developer who designed this mechanism, and beat into them that NULLs shouldn't be used like this!
<NCommander>        printf("  id          : \"" "%c%c%c%c" "%c%c%c%c" "%c%c%c%c" "%c%c%c%c" "\"\n",
<NCommander>               fscreeninfo.id[0],  fscreeninfo.id[1],  fscreeninfo.id[2],  fscreeninfo.id[3],
<NCommander>               fscreeninfo.id[4],  fscreeninfo.id[5],  fscreeninfo.id[6],  fscreeninfo.id[7],
<NCommander>               fscreeninfo.id[8],  fscreeninfo.id[9],  fscreeninfo.id[10], fscreeninfo.id[11],
<NCommander>               fscreeninfo.id[12], fscreeninfo.id[13], fscreeninfo.id[14], fscreeninfo.id[15] );
<NCommander> oops
<NCommander> http://paste.ubuntu.com/105322/
<NCommander> That's what's required to print out the ID string
<NCommander> MY EYES
<bryce> oh the fun things you find in the dark corners of that which we call X.  ;-)
<NCommander> That isn't X
<NCommander> That's kernel madness
<bryce> ahh, even darker corners
<kees> er, wrong channel
<kees> NCommander: http://paste.ubuntu.com/105325/
 * NCommander doesn't quite get how xf86MatchDevice works ...
#ubuntu-x 2009-01-16
<bryce> tjaalton: btw I've added links to dsc files at http://bryceharrington.org/X/PkgList/versions_current.html
<tjaalton> bryce: xorg-server rc1 already has the patches you added/modified, and it's the next version that'll be uploaded :)
<bryce> tjaalton: well maybe 155 but not 156
<tjaalton> bryce: yes, you're right
<bryce> I had to sort out 155 to understand 156, so wasn't a complete waste of time ;-)
<tjaalton> good :)
<bryce> btw, I also looked at 107 some more and reviewed all the comments around it in the upstream tracker
<bryce> and I'm much less convinced now that we're going to be able to leave it disabled
<bryce> still, it'll be worth the experiment just in case
<bryce> (ajax's commentary in particular)
<tjaalton> yeah..
<tjaalton> what's the upstream bug again?
<bryce> LP: #254468, http://bugs.kde.org/show_bug.cgi?id=170462
<ubottu> KDE bug 170462 in compositing "Video garbage when drawing new object (Comment #54)" [Normal,Reopened]
<tjaalton> right, I remember that discussion :)
<tseliot> yes, the problem is solved by removing a patch
<tjaalton> tseliot: what you missed was:
<tjaalton> 12:27 < bryce> btw, I also looked at 107 some more and reviewed all the comments around it in the upstream tracker
<tjaalton> 12:27 < bryce> and I'm much less convinced now that we're going to be able to leave it disabled
<tjaalton> 12:27 < bryce> still, it'll be worth the experiment just in case
<tjaalton> 12:28 < bryce> (ajax's commentary in particular)
<tseliot> tjaalton: ah, ok so it's likely that we'll leave the patch in the package, right?
<tjaalton> tseliot: could be, yes.. the next upload will disable it though
<tseliot> ok, let's experiment a bit then
<tjaalton> to see what the performance hit is
<tseliot> right
<Alexia_Death> tjaalton: any chance of those X packages today?
<tjaalton> Alexia_Death: not before alpha3 is released
<Alexia_Death> tjaalton: ok :)
<tjaalton> jcristau: thinking about adding linux-libc-dev to the xserver-xorg-dev Deps, since that's where the drm headers are going in Debian too (sometime)?
<tjaalton> bryce: thanks for bumping the importance of the drm header issue .)
<tjaalton> :)
<tjaalton> heh, so now the intel pageflipping support is being removed from mesa, and AIUI it's closely related to the drm header mess.. I'll try to see if the patch makes mesa build against current headers
<tjaalton> and if it really is broken old code, it should be removed from the ddx driver too..
<tjaalton> oh, and there's a patch sent to intel-gfx@
<superm1> bryce, you had an autofire off on bug 315588. i wont be able to get lspci, but all the information you would get from it should be available elsewhere in the bug
<ubottu> Launchpad bug 315588 in xserver-xorg-video-vesa "Hardware w/ 1600x900 LCD does not boot up using vesa" [High,Incomplete] https://launchpad.net/bugs/315588
<solarion> anyone know where to get the updated synaptics driver to use an elantech touchpad?
<solarion> seems like a resounding no
* You're now known as ubuntulog
<NCommander> hey bryce
<solarion> anyone familiar with synaptics around here?
<BUGabundo1> where is the best place to report bugs or odd behaviour on the nvidia-settings program?
<tjaalton> BUGabundo1: launchpad
<superm1> launchpad.net/ubuntu/+source/nvidia-settings likely
<solarion> tjaalton!
<tjaalton> solarion: I've no knowledge, sorry :)
<tjaalton> don't have one
<solarion> I was just saying hey.  :)
<solarion> though if you happen to know what version of the synaptics driver supports elantech touchpads, I'd be glad for the knowledge.  :)
<solarion> ah "You will need Xorg Synaptics driver 0.99.1 or newer (0.99.2, 0.99.3) to interoperate with the 2.6.28 kernel Elantech driver! "
<tjaalton> oh, jaunty still has 0.15
<tjaalton> 0.15.2 to be precise
<solarion> can I has?  :)
 * solarion would love to frickin' finally be able to use his touchpad as Asus intended
<tjaalton> not before alpha3 is out
<tjaalton> and the backlog is loong
<solarion> aww.  :(
<solarion> do you know why the mouse (without synaptics support) would be jerky?
<solarion> seems to snap to some invisible, non-1-pixel grid
<solarion> the xorg backlog in ubuntu, or jaunty backlog in general?
<tjaalton> xorg
<tjaalton> we have a few packages to update
<solarion> ah
<tjaalton> libdrm, mesa, intel, xserver ...
 * solarion looks forward to the updates
<solarion> is this related to the new intel modesetting(?) code drop in the kernel?
<tjaalton> no, jaunty won't have that
<solarion> what's holding things up?
<tjaalton> it needs 2.6.29
<solarion> ah, and jaunty is 2.6.28?
<tjaalton> yes
<tjaalton> and will be
<tjaalton> *remain
<solarion> aww.  Even though .29 should be released before 9.04?
<tjaalton> still way too late
<solarion> yeah, I was 'fraid of that
<solarion> what's the holdup on the packages?
<solarion> (i.e. the cause of the aforementioned backlog)
<tjaalton> the drm headers are now provided by the kernel (linux-libc-dev), but the userspace expects to see the latest goo
<tjaalton> so -intel and mesa fail to build
<solarion> coding stuff then, not testing
<tjaalton> but in fact the reason seems to be that they both contain stale code that never got in the kernel drm
<tjaalton> yes
<solarion> aww
 * solarion has time to maybe do minor testing, but not any coding
 * solarion heads to lunch
<tjaalton> well, these will hopefully fix a few problems
<jcristau> tjaalton: what does xserver-xorg-dev need that's moving to the kernel?
<tjaalton> jcristau: the drm headers, ie. linux-libc-dev. otherwise the drivers should depend on it
<jcristau> the drivers that include drm headers should build-dep on it, yeah
<tjaalton> ok, the description is a bit misleading then :) "Unless you are developing or building a driver.."
<tjaalton> I mean, does it hurt to have the drm headers installed, compared to adding the dep to the ones that need them=
<tjaalton> ?
<tjaalton> I'm fine with either approach, it's a one-time change anyway.. (hopefully)
<jcristau> it doesn't hurt, no. i just find it ugly :)
<tjaalton> ugly to put in x-x-dev?-)
<tjaalton> ah, yes
<tjaalton> or maybe libdrm-dev should depend on it
<tjaalton> since it #includes drm.h
<tjaalton> that would be Clean :)
<tjaalton> hey bryce_ 
<tjaalton> jbarnes confirmed that the correct approach to make intel & mesa to build again is to drop the pageflipping code from both
<bryce_> ok
<bryce_> yeah I saw th ebug.  I assume you know the patch or change he's referring to?
<tjaalton> yep
<tjaalton> it was on intel-gfx@
<bryce_> ok cool
<tjaalton> and the mesa patch on mesa3d-dev@
<tormod> hi guys
<tormod> are we getting libdrm 2.4.3 in jaunty soon?
<tjaalton> no, but maybe 2.4.4 :)
<tjaalton> when alpha3 is released
<tormod> cool :)
<tormod> alpha3? today?
<bryce_> btw, today I'm heya tormod
<tjaalton> :P
<bryce_> heh
<tormod> bryce_: grammar? :P
<tormod> I guess after libdrm 2.4.4, there will be intel 2.6.0 ?
<tjaalton> yes
<tjaalton> because the new libdrm basically breaks the current intel
<tormod> horse and carriage
<tjaalton> love and marriage
<bryce_> tormod: sorry was in the middle of saying something else
<bryce_> today I'm downtown with some canonical/community folks.  pdx conclave sort of thing
<tormod> bryce_: np, I got that
<bryce_> so will be focusing on hotkey stuff today
<bryce_> next week, my dad is unfortunately going to be in the hospital for surgery, so I'm going to be taking some time off
<bryce_> anyway, so to say I may be semi-AWOL for about the next week or so
<tjaalton> oh, take care..
<tormod> best wishes
<tjaalton> wgrant: hey, I've merged synaptics in git.. could you check if the modifications in the fdi file were ok? synced that with upstream..
<wgrant> tjaalton: Sure, looking now... I'd been meaning to do that myself, but I've been rather tied up with work :(
<wgrant> I think we'll need to alter the defaults a bit, as they're changed significantly from what we have always had.
<tjaalton> ok.. upstream dropped the "match vendor" bits completely, so it'll need some work if you still want to do that
<wgrant> That fdi file looks good.
<wgrant> I mean defaults like disabling edge-scrolling if we can detect multi-finger taps.
<tjaalton> ah, ok
<tjaalton> hrm, mesa build still fails even with the no-pageflipping patch
<bryce_> :-/
<bryce_> btw I spoke with slangasek about hotkey bugs and a default place to put them if we don't know where they actually belong... he suggests filing them against hal
<bryce_> slangasek says alpha3 is now released
#ubuntu-x 2009-01-17
<tjaalton> bryce: great!
<bryce> heya
<tjaalton> morning
<RAOF> I presume the nv driver isn't always this corruption-prone?
<tjaalton> RAOF: how so?
<RAOF> Turning on metacity's compositor appears to make everything not work; I think this is just because it's stupendously slow at drawing fullscreen transparency.
<RAOF> But gnome-terminal gets corrupted, too.
<RAOF> In that everytime a new character is written, or a link is underlined, it's white on an all-white background.
<RAOF> Also, there seemed to be some confusion between usplash and nv, but I'm pretty sure that bug's been filed.
<RAOF> At least nouveau still loves me
<tjaalton> that's nice
<tjaalton> :)
<RAOF> I'll hunt down the bugs/file new ones after housework.
<RAOF> But nouveau is _so much_ better than nv, at least for me.
<RAOF> We should be using it by default.  If only they'd nail down their kernel interface and release something!
<tjaalton> indeed...
<RAOF> At least they've got a full-time paid dev now.  That should speed things up!
<tjaalton> yeah
<tjaalton> I think fedora is pushing to have nouveau KMS ready asap
<RAOF> Which, IIUC, means nailing down the TTM/GEM/whatever MM stuff.
<RAOF> At least, that's what I gathered was blocking it from my idling in #nouveau.
<tjaalton> probably so
 * RAOF doesn't have a nv5x, so has never tested the existing KMS support.
<RAOF> I tried testing the -ng branches for DRI2/tfp/compiz support.  That didn't go well :)
<tjaalton> what marketing names match nv5x?
<RAOF> geforce 8+
<tjaalton> great, I've got one
<RAOF> Oh, and whatever quattro boards match it, too.
<RAOF> But quatros seem to have arbitrary product strings associated with them, so I couldn't even guess which ones are nv5x ;)
<tjaalton> right
<RAOF> I'm not sure if the nv5x KMS is merged in the drm master we have as nouveau-kernel-source, though.  It may still be in -modesetting-101, or something.
<tjaalton> modesetting-gem probably
<tjaalton> -101 is dead AIUI
<RAOF> Isn't modeseting-gem dead, too?
<RAOF> But it died later, certainly.
<tjaalton> dave seems to use it for radeon
<tjaalton> but darktama's branch seems to be the one for nouveau
<tjaalton> repository, even
<tjaalton> hum, no
<RAOF> That's the MM work, right?  I think the initial KMS support went elsewhere.
<tjaalton> yep..
<RAOF> In some branch of some repository there is some KMS support.  Who knows where!
<tjaalton> yeah :)
<RAOF> I suspect the person who knows is darktama :)
<tjaalton> nice, the intel pageflipping patch has six hunks that fail to apply
<tjaalton> no idea what version it's against
<tseliot> tjaalton: where can I get this version of libxcb? https://bugs.launchpad.net/ubuntu/+source/libxcb/+bug/317746
<ubottu> Launchpad bug 317746 in libxcb "Error when building libxcb 1.1.92 on jaunty" [Undecided,Incomplete]
<tjaalton> tseliot: experimental
<tjaalton> .93 builds
<tseliot> aah, ok so there's no need for me to fix it.
<tjaalton> haha, the automated message is hilarious
<tseliot> good
<tjaalton> "Hi bryceharrington,"
<tseliot> hehe he's talking to himself
<tjaalton> me, myself and LP
<tseliot> a title for a new film :-P
<bryce> rotfl
<tjaalton> intel builds now, but really needs the new mesa until it can be uploaded, because starting gnome hangs the machine
<tjaalton> er, starting compiz that is
<bryce> well, progress at least
 * Ng is entirely happy to throw jaunty live CDs at his 3 or 4 different Intel chipset machines, whenever the versions of driver/mesa/etc are a bit settled :)
<Ng> you might even say I was "actually rather keen" to do that, since I want them all to work :D
<Ng> (which is a roundabout way of asking if, when the pieces have landed, you guys could post on the planet asking people to test)
<pcjc2> hi guys.. any more info on the Xrandr loop bug?
<pcjc2> I'm just prodding it with a stick now.
<pcjc2> Seems that whilst this perhaps isn't causing the loop, I'm getting a monitor change event from GDK each time I step brightness up and down
<pcjc2> changing using the hot-key, I get an xrandr event, monitor change event, then another xrandr, and another monitor-change event
<pcjc2> Changing using xrandr directly, I'm seeing an xrandr event (notifying the property change), and a monitor change event from GDK
<pcjc2> I suspect GDK is emitting that event when it shouldn't - looking at the code, it doesn't differentiate property change events from ones which actually effect the displays in a way suggested by the monitor change event
<pcjc2> "The ::monitors-changed signal is emitted when the number, size or position of the monitors attached to the screen change."
<pcjc2> *** infact, I'm not sure this is an infinite recursion loop at all...
<pcjc2> I wonder if it is gnome-power-manager incrementing the backlight in tiny little steps
<pcjc2> (which it does)
<pcjc2> the underlying bug is that each step is taking a very long time because its causing the hardware to be re-probed
<pcjc2> (Which may be due to buggy applications watching for Xrandr notify events, then querying the hardware for each it recieves)
<Makdaam> hi, how do I get the current config out of Xorg? my xorg.conf is empty
<pcjc2> empty xorg.conf means everything is auto-detected
<pcjc2> I'm not sure if there is a way to extract an equivalent config
<pcjc2> you could look at /var/log/Xorg.0.log for clues though
<Makdaam> so rewriting the xorg.conf by hand is the next best thing?
<Makdaam> ok, thanks
<pcjc2> sure, but only if you need to specify some non-standard config
<pcjc2> it is supposed to work without a config file unless you have an unusual case
<pcjc2> jcristau?
<tjaalton> hmm, monospace 7 looks even better now
<pcjc2> Did the font change, or has something else?
<tjaalton> I'm not sure :)
<tjaalton> it's looks a bit smaller, but still is crisp and easy to read
<tjaalton> meaning that I can fit more in my 10x7 screen
<pcjc2> can't be bad
<pcjc2> I'm just debugging Xrandr stuff
<pcjc2> something nasty is going on
<tjaalton> thanks for doing that :)
<tjaalton> it doesn't affect my i965
<pcjc2> I'm not sure if there are any cases where this is a good thing, but GDK is emitting a "monitors-changed" event for every RRNotify_OutputProperty event recieved
<pcjc2> Some apps are listening out for those - as far as I can tell, and retaliate by probing the hardware - which is very expensive
<pcjc2> what Intel driver are you running on the i965?
<tjaalton> currently 2.6.0
<pcjc2> ok, I've not updated yet.. was running git HEAD
<pcjc2> let me fetch 2.6.0 and see if that changes things
<tjaalton> it doesn't build unless you apply the patch from freedesktop bug 19591
<ubottu> Error: Could not parse XML returned by Freedesktop: timed out (http://bugzilla.freedesktop.org/xml.cgi?id=19591)
<pcjc2> Just fetched the package from Xorg-edgers and am rebuilding it
<pcjc2> (Its marked as being for intrepid)
<pcjc2> hmm, the upstream ChangeLog for that package ends at     Bump version 2.5.99.2
<tjaalton> it needs to be manually updated
<pcjc2> something they broken in the released tarball?
<tjaalton> I'm not sure if the tarball ships it at all
<tjaalton> the edgers package is probably built from git
<pcjc2> ok - fair enough
<pcjc2> A simple patch to GTK fixes the Xrandr issues
<pcjc2> Just tell it not to emit a monitors-changed signal for any Xrandr output property notifications
<pcjc2> I don't know if that is the "right thing" or not, but it seems vaguely sensible
<pcjc2> no monitors-changed signal -> gnome-power-manager doesn't perform an expensive probe for every brightness change
<pcjc2> turns out it probably wasn't an infinite loop.. just a lot of small steps to give a fading effect
<tjaalton> great :)
<tjaalton> do you have any idea why it was triggered by updating libxrandr?
<pcjc2> no, but if you know which libxrandr versions the update was between, I'll grab the git repository and look over the appropriate delta
<tjaalton> between 1.2.3 and 1.2.99.2
<pcjc2> only 14 commits.. shouldn't be too hard to track down
<pcjc2> I'm not convinced that there wasn't a problem before though
<pcjc2> My brightness changing problem existed before that librandr update
<pcjc2> hmm...
<pcjc2> there was an interesting bug fixed between those versions, regarding the event's "screen" property
<pcjc2> I noticed GDK tested if screen != NULL before processing the event
<pcjc2> I wonder if that disposed of some events in the old, buggy events case
<pcjc2> oo... cool
<pcjc2> new for Xrandr1.3, there is a new request which allows programs to retrieve the "current" resources without causing a hardware probe
<pcjc2> gah, it was the "window" property of the event which had a bug.. never mind
<tjaalton> heh
<pcjc2> .... but the screen was determined from the window
<pcjc2> its really not obvious whether that could have caused the problem or not
<tjaalton> I bet :)
 * pcjc2 really wishes GTK was in a GIT repository so I could do some decent history diving
<tjaalton> it'll be..
<pcjc2> right.. I think I'll just post findings so far to Xorg, and send some info to gtk-devel
<pcjc2> Now Xrandr 1.3 is available, those apps shouldn't be querying the config on notification... assuming the fact a notification occurred means that the Xserver knows the new state, you can just use the new API to retrieve the current config
<tjaalton> xserver 1.6rc1 seems to work.. will release in a minute
<tseliot> pcjc2: but gnome-desktop and gnome-control-settings are gtk apps which use xlib. Gnome-desktop is maintained in svn and we even have a bazaar branch which keeps track of the changes in the svn repo
<tseliot> ah, I didn't read the "GIT" word
<tseliot> never mind
<tseliot> pcjc2: I think that the idea behind using notifications in the gnome randr applet was to have the cairo widget automatically updated (in theory) when the outputs change
<pcjc2> did you see the last I posted on xorg@...
<tseliot> no, I didn't
 * tseliot checks the mailing list
<pcjc2> You can make the problems go away if you teach GDK not to emit a "monitors-changed" signal when receiving an Xrandr output property change notification.
<pcjc2> With Xrandr 1.3, there is a new API which should avoid the server re-probing hardware. You could use that in response to a notification, since presumably if the server is notifying _you_ of a change, you then just need to ask it what its current understanding of the hardware is.. not use the old API which instructs it to re-probe
<tseliot> ok, so it was GDK. I wasn't aware of the change in the RandR API
<tseliot> aah you're referring to RRGetScreenResourcesCurrent()
<tseliot> yes, that should be cheaper
<pcjc2> I've not actually tested the various versions of libXrandr people bisected this problem to..
<pcjc2> would have to un-patch / reinstall old GTK, then build both Xrandr versions to have a poke and see if GDK behaves differently
<tseliot> I could try patching g-s-d and g-p-m to use RRGetScreenResourcesCurrent instead of RRGetScreenResources
<pcjc2> ordinarily I'd be curious, but part of me thinks we should just approach the necessary people to fix based on what we have now
<pcjc2> that would be cool
<pcjc2> I think g-s-d calls some other costly probe too, but I'm not sure
<pcjc2> with more than one client firing requests in response to the notifications, it became difficult to tell just what was expensive, and what wasn't
<tseliot> heh
<tjaalton> libxcb 1.1.93 uploaded, a fakesync of libx11 will follow
<tseliot> great
<tseliot> if it builds :-P
<tjaalton> .92 didn't build, .93 should
<tseliot> otherwise bryce will have another conversation with himself
<tjaalton> yeah :)
<tjaalton> bryce: for some reason dch doesn't add spaces to the author when you modify the changelog (you have "[name]", instead of "[ name ]"), maybe that's one source of your git griefs?-)
<tjaalton> afk, floorball ->
<tseliot> pcjc2: I can't reproduce the problem with my new patches
<tseliot> seb128 will be happy :-)
 * Alexia_Death grumbles...
<tseliot> Alexia_Death: what's the matter?
<Alexia_Death> Theres an annoying bug in X that is not really debuggable.
<Alexia_Death> my X dies in graphcs driver code if I use my tablet for some time.
<Alexia_Death> and it happens the same wether i use nv or nvidia
<tseliot> did you try vesa?
<tseliot> just for testing
<Alexia_Death> I cant use vesa sensibly on my laptop...
<Alexia_Death> It is not an on demand crash
<tseliot> ah, ok
<Alexia_Death> It usually happens when I start drawing.
<Alexia_Death> and have done it for a little bit.
<Alexia_Death> and usually costs me my work.
<Alexia_Death> I have two dumps for it but they are not really informative.
<Alexia_Death> logs with stack traces that is
<tseliot> did you try with gdb? https://wiki.ubuntu.com/X/Backtracing
<pcjc2> tseliot: What patches?
<pcjc2> Using the new Xrandr 1.3 APIs to avoid the costly probe?
<Alexia_Death> tseliot: difficult... but I think I know why my trace is useless.
<Alexia_Death> tseliot: I dont think I have nv debuging symbols
<tseliot> pcjc2: the one which replace XRRGetScreenResources with XRRGetScreenResourcesCurrent
<tseliot> s/one/ones/
<Alexia_Death> tseliot: isnt jaunty repros supposed to contain debugging symbols for nv?
<tseliot> Alexia_Death: I don't know as I don't maintain it. Either tjaalton or bryce should know it though
<pcjc2> tseliot: ok - cool. Although if they were to go upstream, I guess they'd need to be conditional on detecting Xrandr 1.3 being available
<Alexia_Death> tseliot: Ok. I will ask one of them... They dont seem to tho...
<pcjc2> I still think GDK is emitting more events than it should
<pcjc2> not sure who to bug about that
<tseliot> pcjc2: yes, but g-s-d and g-p-m use xlib directly
<pcjc2> I was hoping someone might pick up the thread. Soren Sandmaan showed an interest already
<pcjc2> g-p-m also handles the GDK event
<tseliot> where?
<tseliot> maybe I missed it
<pcjc2> g-p-m is pretty impotent in responding to the notifications in fact, when I checked out the source
<pcjc2> the code was in an if (FALSE) {}
<albert23> Alexia_Death: you can use the dbgsym from here: http://ddebs.ubuntu.com/pool/main/x/xserver-xorg-video-nv/
<tseliot> ok, let me check
<pcjc2> but.. in when it first sets up the Xrandr stuff, it calls gpm_brightness_xrandr_update_cache
<Alexia_Death> tjaalton: why there are no debugging symbols for nv in jaunty repros?
<Alexia_Death> albert23: how do I use them?
<pcjc2> which connects to "monitors_changed" if it hasn't done so already
<albert23> Alexia_Death: download the deb and install with dpkg -i
<Alexia_Death> they are ddeb-s not just debs.. why?
<pcjc2> <debug>deb
<Alexia_Death> Ooh...
<Alexia_Death> OK:)
<Alexia_Death> Hopefully now I get some more informative dumps out of my crashes...
<pcjc2> might need to fetch a load of debug packages
<pcjc2> libc etc.. as well
<pcjc2> otherwise the back-traces can be incomplete
<Alexia_Death> Its really annoying btw that I have to go to console to coppy out the log or my next log-in will overwrite it...
<pcjc2> some of them are in the repos as libfoo-dbg though
<pcjc2> so you don't necessarily need the -dbgsym version
<Alexia_Death> I have most that are in repros already
<pcjc2> Xorg.0.log.old ?
<Alexia_Death> pcjc2: yes. its overwritten the moment I log in.
<pcjc2> ok - didn't know it fired up a new X server _after_ GDM
<Alexia_Death> Crash, grm starts, crash log becomes .old, I log in the trace is lost...
<Alexia_Death> It would be really neat if gdm stuffed after crash logs somewhere itself...
<tseliot> pcjc2: aah, you meant that it uses gdk to register the event type and add a filter. Yes, this is correct.
<pcjc2> no
<pcjc2> it uses g_signal_connect (G_OBJECT (gscreen), "monitors_changed", ...
<pcjc2> line 610, gpm-brightness-xrandr.c
<pcjc2> it is that callback which is / was causing the slow probe on 
<pcjc2> brightness changes, since GDK is emitting "monitors_changed" for every brightness change
<pcjc2> (Which doesn't fit with its documented function)
<tseliot> yes, that's a property change
<pcjc2> the documentation for "monitors_changed" doesn't say it will get called for property changes
<pcjc2> The ::monitors-changed signal is emitted when the number, size or position of the monitors attached to the screen change.
<tseliot> in theory it should be correct if, for example, you change TV format (which is a property)
<pcjc2> not.. this event will fire for every property change.. including one time for each of the hundreds of steps used when fading the backlight brightness
<pcjc2> I had guessed there might be causes where that signal is needed 
<pcjc2> but the description of the signal is still wrong
<tseliot> that's easy to change ;)
<pcjc2> and the changes to use the "Current" version of the Xrandr getters makes the performance hit go away
<pcjc2> It still feels like it should be possible to filter those monitor-changed events to avoid getting swamped in backlight events
<pcjc2> no point waking up so many processes to do essentially nothing
<tseliot> ok, so are you suggesting something like output-properties-changed?
<tseliot> which should be separate from monitor-changed
<tseliot> in GDK, I mean
<pcjc2> I'd leave that sort of design decision to those who know the realm better
<pcjc2> but its not a bad idea.
<pcjc2> Even if you added "output-properties-changed", you might need to add detail about _what_ property you cared about
<tseliot> that would be nice to have
<tseliot> I guess it will take some time for developers to decide and implement this thing
<tseliot> in the meantime I'll write a patch for gnome-desktop and gnome-power-manager which checks the version of RandR and uses Current accordingly
<tseliot> and of course I'll give credit to you for suggesting the use of the less expensive call
<pcjc2> I think most credit deserves to go to the implementer there...
<tseliot> hehe that's right
<jcristau> monitors-changed firing on property changes sounds like a bad idea
<tseliot> jcristau: the only reason I can think of is that of tv format. But of course as pcjc2 said, it would be nice to be able to separate events
<pcjc2> tseliot: Are you Alberto Milone?
<tseliot> pcjc2: yes, I am
<pcjc2> ok- no need to reply back to your email then ;)
<tseliot> no, I guess not ;)
<pcjc2> Do you have an upload for the new g-s-d and g-p-m packages?
<tseliot> I'm writing things as we speak (so that only if X supports RandR 1.3 we use Current)
<pcjc2> cool!
<tseliot> maybe we should check the version at runtime instead of doing it at compilation timeÃ¹
<tseliot> time
<pcjc2> since it is a dynnamic thing, yes
<pcjc2> although I doubt many users would be connecting to a remote X server using gnome-power-manager
<pcjc2> IIRC, GDK has some code to check the version - if a cheat-sheet would help
<tseliot> I would like to call that function (e.g. XRRQueryVersion) only once though. I don't think we need to check the version every time an event is triggered
<pcjc2> no - that would be roundtrips - which would be bad
<crevette> hey
<crevette> it seems X crashed, but bug reporting with apport doesn't work apparently
<crevette> hmm
<crevette> anyway the stackstrace is useless
<marijus> hello, i compiled 2.6.29-rc2 kernel with kms support and use latest xorg and intel on jaunty a.t.m. But i get a corrupted screen instead of GDM. KMS seems to work tho... anyone want to help? 
<tjaalton> marijus: I guess you'd get more help from #intel-gfx
<tjaalton> doubt many have tested kms here
<marijus> tjaalton, i just posted there... thanks
<tjaalton> np
<bryce> crevette: any ideas on why apport isn't reporting the crash?  I've noticed that not as many crash reports have been coming in as I expected
<crevette> bryce: I have no idea at all, all my bugs reported end with a warning message
<bryce> was anything put into /var/crash?
<tjaalton> bryce: I'll be able to fix the mesa build tomorrow, it turns out to be pretty simple
<bryce> tjaalton: ah good to hear
<tjaalton> bryce: also, I fakesynced libx11 to get it out at the same time with libxcb
<tjaalton> we can sync both when there are new releases
<bryce> I'm about to head down to see my dad and will be gone through Wednesday.  Dunno how internet connectivity will be.  Might try to get some more of the xorg.conf backup/recovery stuff coded if I have time.
<bryce> tjaalton: good deal, yeah it'd be nice to get all these merges through
<tjaalton> ok, take your time.. I'll deal with the fallout ;)
<tjaalton> I noticed that I've had xkeyboard-config merge sitting idle for a looong time.. will check it out too
<Alexia_Death> kmail is not installable because of akonadi btw...
<Alexia_Death> oops
<Alexia_Death> wrong chan
<Alexia_Death> sory
<bryce> yeah I started looking at the xkeyboard-config merge yesterday.  Noticed there's a *bunch* of conflicts
<bryce> what I was thinking was we should work on getting all those changes upstream and drop everything else so we can just sync
<bryce> upstream is reasonably responsive when we forward bugs and changes, so no reason we can't get into a position where we can give them our changes and just sync
<bryce> anyway, put that low on your priority list, and I can take care of it when I get back if you don't get to it
<crevette> bryce: I didn't notice your reply
<crevette> bryce: http://pastebin.ubuntu.com/106069/
<bryce> ok, taking off, cya
<tseliot> take care bryce
#ubuntu-x 2009-01-18
<jonpackard> Hello. I'm having problems with X in a qemu emulated Ubuntu Jaunty Armel system. I can load gdm or run startx to get to a desktop, but once X loads, I cannot use the keyboard or mouse. Here's my Xorg.0.log http://ubuntu.pastebin.com/f5a153034 -- Could anyone please offer any suggestions?
<tjaalton> just what we needed.. a poll about zapping
<Alexia_Death> tjaalton: it turns out that the buttons fix for tablets is not in rc1. It was cherrypiced a bit after tagging...
<Alexia_Death> tjaalton: https://bugs.freedesktop.org/show_bug.cgi?id=19282 the patch is here.
<ubottu> Freedesktop bug 19282 in Input/Core "Events handled wrong when master button map differs from the originating device..." [Normal,Resolved: fixed]
<tjaalton> Alexia_Death: is it here? http://wiki.x.org/wiki/Server16Branch
<tjaalton> seems to be
<tjaalton> "mi: ensure chained button mappings from SD -> MD (#19282)"
<Alexia_Death> yes
<Alexia_Death> the hash thingie matches nice. 
<tjaalton> I'll add it later today
<tjaalton> and will check the list for others too
<Alexia_Death> I havent tested that pach myself  tho... Great... then theres a little catch with the wacom driver and the hotplug should work:D
<tjaalton> a link to the patch and it'll be included as well
<tjaalton> in the driver..
<tjaalton> afk, cleanup ->
<Alexia_Death> hmm.. that will be a bit tricky... theres a hack and something thats supposed to be a solution... the hack works, the solution does not. the hack however is not nice on anything else than 1.6 because it causes a memory leak. in 1.6 double free kills the server.
<tjaalton> Alexia_Death: ok, I'll wait for a bit then
<ogra> tjaalton, have you seen the request from jonpackard above ? i see the same here 
<ogra> (log is identical to his at http://ubuntu.pastebin.com/f5a153034)
<ogra> hal and dbus are running fine 
<tjaalton> ogra: not in detail.. will check
<ogra> (#
<ogra> II) Cannot locate a core pointer device.
<ogra> #
<ogra> (II) Cannot locate a core keyboard device.
<ogra> #
<ogra> (II) The server relies on HAL to provide the list of input devices.
<ogra> #
<ogra>         If no devices become available, reconfigure HAL or disable AllowEmptyInput.
<ogra> thats the issue here i thikn
<tjaalton> no, the last line is more important
<ogra> [config/dbus] couldn't take over org.x.config: org.freedesktop.DBus.Error.AccessDenied (Connection ":1.6" is not allowed to own the service "org.x.config.display0" due to security policies in the configuration file)
<ogra> that one ? 
<tjaalton> yes
<tjaalton> the first ones are just informational
<ogra> note that system is a debootstrapped ARM rootfs 
<tjaalton> oh..
<ogra> with xfce4, xorg and gdm installed on top
<tjaalton> maybe enabling dbus had something to do with it
<ogra> so might be a dependency missing
<tjaalton> can you build the xserver wihtout --enable-dbus?
<ogra> ah, thats builtin now ? 
<tjaalton> sorry, --enable-config-dbus
<tjaalton> yes
<tjaalton> just delete the line from rules
<tjaalton> it was enabled for wacom hotplub
<ogra> i can, will take a while, the arm build machine i hav is a bit slower than x86
<tjaalton> uh, -plug
<ogra> ah
<ogra> googling only found me gentoo probs :) so it might not be enabled in other distros
<tjaalton> Alexia_Death: you've used the dbus setup before.. normal hal hotplug still works?
 * ogra wonders if xfce4 starts up a session bus
<Alexia_Death> tjaalton: yes. Its designed so HAL can do its thing, and just stylus works. then when the daemon runs, it removes the HAL added device and adds fully configured devices.
<tjaalton> actually, I have the same error
<tjaalton> but then hal kicks in and does it's business
<jcristau> is config/xorg-server.conf installed anywhere?
<tjaalton> good catch
<tjaalton> it isn't :)
<Alexia_Death> tjaalton: did you install it? I had to modify the package to install it for intrepid
<Alexia_Death> :)
<Alexia_Death> the 1.5 packages in my ppa do in an hackish nature...
<tjaalton> the destination is /etc/dbus-1/system.d?
<tjaalton> bah, have to go out ->
<ogra> so copying the .conf file in place made the error in the log go away ... but still neither mouse or kbd 
<jcristau> ogra: it would have been unexpected if that made a difference :)
<ogra> well, it fixed the noise in the log :)
<jcristau> heh. i meant other than that
<ogra> yeah :)
<ogra> shuldnt there also be a .service file ? 
<jcristau> lshal lists the devices correctly?
<ogra> no idea, i cant get to the console :)
 * ogra boots with the text kernel option
<ogra> well, withough X running lshal doesnt list any x11 options
<ogra> nor any evdev driven devices
<jcristau> but they show up in /proc/bus/input/devices?
<ogra> there is an AT kbd and a ps/2 mouse
<ogra> argh
<ogra> ah, i thought there was no sysfs mounted, but its all there
<ogra> (note this is qemu ARM, but X used to work in former setups)
<ogra> well, s/X/input/
<tjaalton> ogra: used to work with 8.10?
<tjaalton> or previous xserver?
<ogra> yep
<ogra> build is running ... 
<ogra> lets see 
<tjaalton> yep to which question?-)
<ogra> previous server 
<ogra> we didnt have armel with 8.10 :)
<tjaalton> right
<jcristau> if hal doesn't have the input.x11_driver properties, that's not X's fault, though :)
<tjaalton> true.. and downgrading the server should confirm that 
<tjaalton> bah, still no mesa
<jcristau> tjaalton: what if you use drm_i915_sarea_t instead of struct drm_i915_sarea?
<jcristau> (since the kernel seems to call it struct _drm_i915_sarea instead)
<jcristau> using the typedef should work afaict
<tjaalton> jcristau: where is that?
<tjaalton> I actually googled the error message and found out what it means
<jcristau> in mesa. intelWindowMoved()
<tjaalton> ah..
<tjaalton> well, changing it to _drm_i915_sare worked
<tjaalton> _sarea
<jcristau> it'd break for people using the libdrm headers. hence the suggestion to use the typedef
<tjaalton> well, it didn't work :)
<jcristau> s/struct drm_i915_sarea/drm_i915_sarea_t/ should have worked just the same, unless i'm missing something
<tjaalton> aah
<tjaalton> I left struct there
<tjaalton> bingo
<tjaalton> (my c sucks)
<tjaalton> ok, will build just to be sure it doesn't explode somewhere else
<tjaalton> I mean if there are other bugs left
<tjaalton> yep
<tjaalton> intel_context.c does the same
<tjaalton> and _screen.c
<tjaalton> .. and _screen.h, bah
 * jcristau hands git grep to tjaalton 
<tjaalton> <blush>
<tjaalton> man, that's fast
<tjaalton> ok, so i915_drm.h from 2.6.28 is missing *bo_handle
<tjaalton> sigh
<tjaalton> there is a commit for it
<tjaalton> so, I got mesa to build, but it'll need a kernel update until it's ready to be published
<tjaalton> phew, compiz works again
<tjaalton> and x11perf -aa10text is now up to ~200k chars
<tjaalton> with EXA, not UXA
#ubuntu-x 2010-01-18
<RiotingPacifist> is this the right place to come if im on crack?
<verbalshadow> sure if you know how to help poor x users like me :P
<RiotingPacifist> well i think ive found a bug while on xorg crack (xorg-edgers ppa), but it looks like a packaging mistake rather than a real bug
<RiotingPacifist> i can try and help with your problem but beyond the relatively simple i don't know much about how xorg works
<verbalshadow> I need help figuring out what is make x crash w/ corruption ( "white scanlines" ) in a hard lock ( key/mouse don't work including magic ones alt-sysRq-REISUB )on lucid
<verbalshadow> I need help figuring out what is make x crash w/ corruption ( "white scanlines" ) in a hard lock ( key/mouse don't work including magic ones alt-sysRq-REISUB )on lucid
<Q-FUNK> howdy!  in Lucid, restoring from hibernate on -intel takes more than a minute here.  is this a known issue?
<Sarvatt> bryyce: just dropping patch 100 is enough to make guest sessions and such work and stops the segfaults, finally got around to rebuilding with only that patch disabled. can we move the xf86CloseLog() down under return(signo) in xf86Init() maybe?
<Sarvatt> also xserver-xorg-input-wacom looks like it should be mergeable now unless we were waiting for it to be in squeeze? it doesn't work with serial tablets yet but its working fine with usb on both my graphire 3 4x6 and intuos2 4x5
<Sarvatt> err xf86Init.c I meant
<seb128> hey there
<seb128> bryyce, guest session still crashes xorg with your update
<seb128> so it seems to be a different issue
<apw> bryyce, hey ... i am seeing i915 going to alll one color, typically black or white but i think i've seen a sort of blue.  and this is recoverable by a suspend/resume
<apw> any suggestions as to whether this could be a mesa or kernel issue?
<apw> tseliot, ^^
<tseliot> apw: oh, do either dmesg or Xorg.0.log contain anything useful?
<Sarvatt> apw: after suspend/resume?
<Sarvatt> if so use powersave=0 module parameter for i915
<tseliot> if that does it ^ then it must be some kms issue
<seb128> what does powersave=0 tells us?
<Sarvatt> i915.powersave=0 is needed on my machine and quite a few other peoples to fix the flickering and lockups on a solid color like that
<apw> nothing in dmesg
<seb128> the mini10v has screen flickering after suspend
<seb128> the powersave option workaround it
<seb128> is that a known issue?
 * apw likes the sound of that
 * apw goes apply it
<Sarvatt> I *really* think it needs to be the default module option for lucid
<apw> Sarvatt, if it fixes it for me and pgraner, it _will_ be the default in about 10s
 * Sarvatt cheers
<tseliot> :-D
<pgraner> tseliot: why didn't you tell us this sooner we could have evaluated it for a default setting
<Sarvatt> seen 2 problems from it, 915-945 having flickering and hangs after suspend/resume and 965 flickering straight away after boot constantly
<Sarvatt> there is a commit queued up for 2.6.32.4 that fixes the latter
<tseliot> pgraner: sorry, had I known that I would have told you. I wasn't aware of the problem as I have spent most of the time on proprietary drivers :-/
<pgraner> tseliot: no worries, would have been helpful its killing apw and I we loose screen ever few mins
<tseliot> ouch
<seb128> Sarvatt, is there a reference bug for the flickering bug?
<apw> i can say even with a 32.4 kernel the flickering is not fixed on dell 10v, its different looking but still there
<Sarvatt> sure I can dig up lots for you, one minute
<Sarvatt> http://bugzilla.kernel.org/show_bug.cgi?id=14781
<ubottu> bugzilla.kernel.org bug 14781 in Video(DRI - Intel) "181a533 is causing severe screen flickering on 965GM" [High,Closed: code_fix]
<Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=25598
 * apw is back from suspend with powersave=0 ... will let you know if its the killer setting
<ubottu> Freedesktop bug 25598 in Driver/intel "[965GM] Corruption on resume from hibernation with xf86-video-intel-git" [Critical,New]
<Sarvatt> sorry ignore that second one
<Sarvatt> still digging, have a bunch bookmarked for these 2 major bugs i'm hitting
<Sarvatt> https://bugs.launchpad.net/bugs/492392
<ubottu> Ubuntu bug 492392 in linux "[lucid, intel] After suspend, flickering screen and then blank screen." [Medium,Triaged]
<apw> sounds like what i would have written if i'd filed a bug instead of whining :)
<Sarvatt> guess those are the only two relevant ones to the flickering I was following, the other is alot more major and havent found a fix to it
<seb128> Sarvatt, thanks
<Sarvatt> apw: yeah the "remove render reclock support" commit only fixes some flickering people are getting after booting from what I can see (lots of newer thinkpads hitting this), powersave=0 is still needed on 945GSE here where i'm only getting the problem after resume
<tseliot> jbarnes: any updates on this ^^ ?Ã¹
<Sarvatt> he sent out [PATCH] drm/i915: disable LVDS downclock by default so powersave=0 wouldnt be needed for some of the cases
<apw> yeah the flickering is only after resume on my machine here, the hard locks to a single colour are possible without suspend but defiantly more prevalent afterwards
<seb128> i915.powersave=0 seems to workaround it there too
<seb128> the issue is only after resume
<Sarvatt> i'm on as aspire one, pretty much the same machine you guys are using
<Sarvatt> on an aspire one rather
 * apw will let you know if this fixes me here, and i recon if so then its probabally prudent to turn it off by default and let people turn it on if they are brave
<apw> so far ... so goof
<Sarvatt> lucky we didn't go to intel 2.10 yet, all those mini's would be locking up every hour or so with batchbuffer I/O failures :D been broken in intel git for a month and a half now
<Sarvatt> http://bugs.freedesktop.org/show_bug.cgi?id=25475
<ubottu> Freedesktop bug 25475 in Driver/intel "[i915] Xorg crash / Execbuf while wedged" [Critical,New]
<kamalmostafa> tseliot: Is libGL broken again perchance?  All of the 'octave-*' packages seem to be FTBFS because of
<kamalmostafa>   octave-3.2.3: error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory
<kamalmostafa>   http://launchpadlibrarian.net/38045633/buildlog_ubuntu-lucid-i386.octave-image_1.0.10-2_FAILEDTOBUILD.txt.gz
<superm1> kamalmostafa, he's not signed in right now
<tjaalton> heh, that looks like fun to fix
<superm1> kamalmostafa, is octave-3.2 missing a dependency on libgl1-mesa-glx though?
<tjaalton> no
<tjaalton> ldconfig is not run yet, so it can't find the lib
<superm1> Oh, fun fun
<superm1> the postinst for libgl1-mesa-glx didn't run it?
<tjaalton> oh, it should have, but either it didn't or it doesn't work right
<superm1> it looks like it tries pretty hard to do it.  it's in there twice
<kamalmostafa> tjaalton, superm1: I see a couple of libgl1-mesa-glx "issues" in that build log which may relate:
<kamalmostafa>    Setting up libgl1-mesa-glx (7.7-0ubuntu6) ...
<kamalmostafa>    update-alternatives: using /usr/lib/mesa/ld.so.conf to provide /etc/ld.so.conf.d/GL.conf (gl_conf) in auto mode.
<kamalmostafa> and
<kamalmostafa>    dpkg: warning: while removing libgl1-mesa-glx, directory '/usr/lib/xorg' not empty so not removed.
<tjaalton> those are only informational
<kamalmostafa> ok.  do you suspect the problem to be in liblg1-mesa-glx or in octave-3.2?
<kamalmostafa> should we expect to see a "Processing triggers for libgl1-mesa-glx ..." line in the build log?  There is none.
<tjaalton> it's not a trigger
<tjaalton> the postinst should run ldconfig and the build should then see libGL
<tjaalton> certainly a problem in mesa, not octave
<seb128> bug #506510 is still happening I reopened it
<ubottu> Launchpad bug 506510 in xorg-server "Xorg crashed with SIGSEGV in FatalError() when using guest session" [High,Confirmed] https://launchpad.net/bugs/506510
<kamalmostafa> tjaalton: okay, thank you for the clarification.  I tried building a different package (which) needs needs libgl1-mesa-glx, and it builds fine.  Why would that be?
<kamalmostafa> That package being "fraqtive"
<tjaalton> kamalmostafa: no idea
<kamalmostafa> tjaalton: okay, thanks again for the help.
#ubuntu-x 2010-01-19
<Sarvatt> seb128: fatalerror is segfaulting because of patch 100 in xserver, can see it by just running Xorg from gnome-terminal and seeing the trash after ddxSigGiveUp. Disabling patch 100 fixes the segfaults and gdm handles the fatalerror fine by stopping and starting a new x but then we lose apport, I haven't been able to fix up patch 100 yet but it's really over my head anyway, not sure if we want to drop the xserver apport hooks or what. The error s
<Sarvatt> eems to be coming from the initctl call in the session scripts not being in the exported path anymore (it's in /sbin and adding the path/hardcoding the call to /sbin/initctl fixes it) in the newer GDM's, can fix it in gdm but something does need to be done with that script making it segfault
<Sarvatt> I rebuilt xserver without patch 100 and it works fine, also changing the initctl calls to /sbin/initctl and adding /sbin to the paths in the 2 gdm scripts fixes it
<Sarvatt> /etc/gdm/Init/Default and /etc/gdm/PreSession/Default
<Sarvatt> just dropping the patch will work but I dont know if you need that initctl to actually work and that needs the gdm change, can see that failing in /var/log/gdm/:0-slave.log when you try to use a guest session
<Sarvatt> err in the second message I meant patch making it segfault not script
<fagan> Any x people awake yet?
<tjaalton> always
<RAOF> Ish?
<fagan> Im upgrade testing hardy to lucid 
<fagan> and x is giving hassle 
<fagan> here is one of my many xorg logs http://pastebin.ubuntu.com/358912/
<fagan> I tried doing a Xorg -configure but it segfaults 
<fagan> So any clue whats causing my computer to start in low graphics mode
<tjaalton> what's your xorg.conf like?
 * fagan pastebins
<tjaalton> though the real reason is that the nv driver doesn't support GF8200
 * bryyce waves
<tjaalton> hi bryyce
<bryyce> hi tjaalton
<fagan> http://pastebin.ubuntu.com/358913/
<fagan> Hmmm 
<mvo> fagan: did you had the binary nvidia driver in hardy? and on upgrade you got nv that not supports your card?
<tjaalton> mvo: not according to the xorg.conf
<fagan> mvo: nope fresh install of hardy
<tjaalton> fagan: so you always had vesa
<mvo> oh, so it went vesa -> nv
 * mvo nods
<fagan> Thats weird
<fagan> Was vesa the default in hardy?
<tjaalton> if you had a logfile from hardy..
<tjaalton> no, nv has never supported 8200
<fagan> The binary driver supports the 8200
<tjaalton> the autoconfig probably didn't work the same way
<tjaalton> but nv doesn't
<fagan> Ah
<tjaalton> nouveau likely does
<tjaalton> but, meh..
<fagan> So its just that -nv doesnt support my driver 
<tjaalton> card, yes
<fagan> Oh so then its fine then 
 * fagan always installs the binary anyway
<tjaalton> ok so in that case the upgrader removed nvidia from the config?
<fagan> Yep you have my logs 
<fagan> It seems so
<tjaalton> probably would be the best to move the config away, then you'd get vesa straight away and not via a crash
<tjaalton> nothing valuable in that config anyway
<fagan> tjaalton: will do 
<tjaalton> ..that would be used
<tjaalton> mvo: ^^
<tjaalton> I don't know where that should be done though
<mvo> tjaalton: thanks, it should only comment out "nvidia" if it find that and no nvidia driver binary
<mvo> and the xorg.conf in the pastebin has no "nv" line 
<mvo> or will xorg still behave differently if there is no xorg.conf or a xorg.conf with no explicit driver in it?
<tjaalton> mvo: it'll use the default driver, but if there's no xorg.conf it'll build a list of fallback drivers to try
<tjaalton> with the default one on top
<mvo> nice
<fagan> I have a bug report of the crash that I got earlier https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/509519
<ubottu> Error: This bug is private
<fagan> lol I love that the default is private always 
<fagan> Its public now
<seb128_> fagan, could be bug #506510
<ubottu> Launchpad bug 506510 in xorg-server "Xorg crashed with SIGSEGV in FatalError() when using guest session" [High,Fix released] https://launchpad.net/bugs/506510
<seb128_> did you try to open a new session or guest session?
<fagan> New session
<seb128_> k, likely the same issue then
<fagan> seb128_: Its from an upgrade from hardy to lucid
<bryyce> should be fixed with xorg-server (2:1.7.3.902-1ubuntu9)
<bryyce> upgrade to my latest version and retest
<fagan> Cool
<seb128_> bryyce, I will when it's published
<seb128_> bryyce, do you plan to bring back apport later? or do you want to catch crashes by some other way?
<fagan> win 5
<bryyce> seb128_, I don't know; I already sank a lot more time into this patch than I'd like.  signal handling code is tough to debug
<bryyce> but it's silly for most of our crash bug reports to be due to the patch that enables crash bug reports
<seb128_> right
<seb128_> let's see if that uncover an another crash or if that purely due to that one
<fagan> Yay the update fixed the segfault 
<fagan> One more question is the nvidia binary driver still braking x?
<fagan> Bug #494166 ?
<ubottu> Launchpad bug 494166 in nvidia-graphics-drivers-180 "[lucid] nvidia-glx can't work with new xorg 7.5" [Medium,In progress] https://launchpad.net/bugs/494166
<bryyce> fagan, thanks for testing; please close any bugs you filed that are about this issue
<tseliot> fagan: I guess not
<bryyce> heya tseliot
<tseliot> hi bryyce
<LLStarks> is there anything similar to this for linux? http://www.realtech-vr.com/glview/
<akaihola_> The page https://wiki.ubuntu.com/X/Troubleshooting/Freeze contradicts itself. It claims that a backtrace is a non-symptom, but lists "[mi] EQ overflowing" and X freeze as a relevant problem. A backtrace is included with such log messages.
<akaihola_> Alternatively, what is a good place besides IRC to discuss Wiki pages, if I don't want to join the mailing lists? File a bug in Launchpad?
<jcristau> "what's a good place to discuss this if i don't want to use the right place"?
<tseliot> akaihola_: I think you can talk to bryyce about this. He lives in the US, therefore you might want to send him an email if you can't chat to him directly on IRC (because of time zones)
<akaihola_> jcristau: Ok. It's just a hassle to join and unsubscribe a list just to send a quick note.
<akaihola_> tseliot: Thanks!
<jcristau> akaihola_: yeah subscriber-only lists are a pain i agree
<akaihola_> Just e-mailed bryyce. Thanks guys, moving on...
<tjaalton> whee, I got a X61 tablet for a spin to play with the wacom on it
<coz_> tjaalton,  :)
<tjaalton> bah, it's a serial wacom inside the X61 tablet..
<tseliot> :-/
<seb128> hum tseliot left
<seb128> bryyce, the crash on user switch doesn't happen when booting without the splash
<seb128> ie not using plymonth make it work
<Sarvatt> seb128: did you get any of my messages about the crash happening because the gdm session scripts are trying to call initctl -q emit desktop-session-start DISPLAY_MANAGER=gdm without /sbin in the path? does adding /sbin: to the PATH and changing it to /sbin/initctl -q emit desktop-session-start DISPLAY_MANAGER=gdm in /etc/gdm/PreSession/Default (or /etc/gdm/Init/Default) fix it for you like it does for 
<Sarvatt> me?
<seb128> Sarvatt, to what path do you add those?
<Sarvatt> /var/log/gdm/:0-slave.log shows the error when you try to use a guest session
<seb128> what error?
<Sarvatt> in /etc/gdm/PreSession/Default
<Sarvatt> that it cant find initctl
<seb128> let me try that
<Sarvatt> there were changes so it did it as a user and it cant find /sbin stuff anymore
<seb128> chrisccoulson, ^
<seb128> could interest you as well
<Sarvatt> ugh spotty connection -- <Sarvatt> dropping patch 100 in xserver fixed it so FatalError wouldnt segfault which fixed it for non-plymouth but I guess with plymouth it relies on what its emitting
<seb128> Sarvatt, doesn't seem to be enough there
<seb128> I copied initctl in /bin
<seb128> which should be equivalent to your change
<Sarvatt>  /bin wouldn't be in the path either would it? try /usr/bin?
<Sarvatt> imagine /sbin would be there if /bin was
<Sarvatt> gotta run
<seb128> good comment
<seb128> I will try that
<seb128> thanks
<seb128> Sarvatt, no, that doesn't fix my issue
<chrisccoulson> i'm using /sbin/initctl, and it seems to have fixed my issue
<chrisccoulson> i've got Xorg on different VT's now
<seb128> ok, I will upload a fixed gdm
<seb128> I've some other changes to do anyway
<tjaalton> I don't understand the tablet.. the only device in the udev db related to wacom is under acpi subsystem, not pnp
<superm1> is plymouth supposed to be working on non KMS hardware right now?
<sebner> superm1: /here not working
<superm1> sebner, okay same here then
<sebner> seb128: is gdm to be supposed restartable with upstart (like it worked with init)?
<superm1> got a bug open already?
<seb128> sebner, I don't know, I guess so, sudo restart gdm?
<sebner> seb128: sudo service restart gdm?
<sebner> superm1: dunno
<seb128> sebner, dunno, don't ask me about upstart
<seb128> I've no clue about it
<sebner> heh kk
<cwillu> sebner, sudo restart gdm is the proper incantation
<sebner> cwillu: cool. thx for the hint
#ubuntu-x 2010-01-20
<hyperair> what's the correct target for issue regarding X and resuming?
<hyperair> from hibernate/suspend
<bryyce> hyperair, 'linux' is usually a good starting point
<hyperair> bryyce: no, i think this is purely X. there are some vt-switching issues, and after that, the wallpaper changes to some hideous black and white weird looking thing
<hyperair> bug #510004
<ubottu> Launchpad bug 510004 in pm-utils "[lucid regression] strange resume from suspend to RAM" [Undecided,New] https://launchpad.net/bugs/510004
<hyperair> that
<tjaalton> nvidia-graphics-driver-180 then
<tjaalton> actually, just n-g-d
<bryyce> ah, yeah with -nvidia the kernel team probably couldn't help you any more than we could
<hyperair> indeed
<hyperair> i figured as much
<bryyce> night
<hyperair> night
<geser> is there a bug about libgl1-mesa-glx being sort of unusable on the buildds?
<tseliot> geser: what do you mean?
<geser> tseliot: e.g. http://launchpadlibrarian.net/38095009/buildlog_ubuntu-lucid-i386.octave-ad_1.0.6-3_FAILEDTOBUILD.txt.gz
<geser> this also happens with -0ubuntu7 (tested in my pbuilder)
<geser> although the postinst calls ldconfig, it only triggers it's run at the end (which seems to be to late)
<geser> from a look at /sbin/ldconfig this might work: "LDCONFIG_NOTRIGGER=y ldconfig" in postinst
<geser> this should force ldconfig being run right now and making libGL.so.1 available for the following packages being configured
<tseliot> yes, I was about to say the same about ldconfig. Let me check LDCONFIG_NOTRIGGER
<tseliot> yes, that should be our problem
<tseliot> geser: I'll try to build the package in my chroot with export LDCONFIG_NOTRIGGER=y
<tseliot> bummer, it's building without notrigger here...
<tseliot> which I guess is why you mentioned the problem as affecting buildds
<tseliot> geser: ok, I've just uploaded 7.7-0ubuntu8. Please test octave3.2 again when mesa is published
<geser> tjaalton: in case you didn't notice: libxcb got finally synced today (it triggered a bug in LP which made the previous sync attempts fail)
<geser> tseliot: octave-ad build successfully with mesa 7.7-0ubuntu8
<tseliot> \o/
<tseliot> geser: thanks for testing
<tseliot> jbarnes: any ideas as to what can be causing this? http://pastebin.ubuntu.com/359587/
<tseliot> when switching users (i.e. when launching an additional X session on a different tty)
<tseliot> s/launching/trying to launch/
<tjaalton> geser: yep I noticed, nice
<Sarvatt> wow, didnt notice we had all these plymouth themes installed as well in lucid, solar looks great but the progress bar is a little messed up
<Sarvatt> sudo plymouth-set-default-theme solar --rebuild-initrd  incase anyone else hasn't seen it :D
<geser> are there any screenshots available for all themes?
<Sarvatt> just found a few here http://www.webupd8.org/2010/01/look-at-ubuntu-lucid-plymouth-themes.html
<Sarvatt> tseliot: is it me or does that look like plymouths fault?
<superm1> sebner, https://bugs.edge.launchpad.net/ubuntu/+source/plymouth/+bug/506717/comments/6
<ubottu> Ubuntu bug 506717 in plymouth "[Lucid] plymouth does not display when using nvidia drivers" [High,New]
<superm1> so it should be working with non-KMS.  It just Isn't
<Sarvatt> its tring to load a second display on vt7 and plymouth only drops drm master on vt switch?
<Sarvatt> all this time and it just now hit me to put the intel package on hold and use everything else from edgers :D i've been slacking with the updates lately because I havent been able to use it in months
<Sarvatt> was syncing evdev with origin/ubuntu even though we're just syncing debian so I missed alot of fixes there
<Sarvatt> anyone here been able to use intel 2.10+ on 945 or under successfully?
<jcristau> i haven't even tried since you said it was broken :)
<Sarvatt> it's broken here and for at least 15 other people that I know are using edgers but I haven't asked if anyone was actually able to use it so I'd be interested to know :D
<Sarvatt> I'll put a note on edgers asking for feedback
<jcristau> i was away from my 945 from christmas until yesterday though.  maybe i can try later.
 * Duke` checks his driver version
<Sarvatt> pretty sure 965+ doesn't have the problem because I know alot of people using edgers with that that arent complaining and never seen any reporters that werent using 915 or 945
<Sarvatt> I know you are having the problem as well on 945 with 2.9.99.902+ Duke` :D
<Sarvatt> you were the one that tipped me off that libdrm from 11-25 actually works
<Duke`> 2.10
<Duke`> unfortunately I lost my 11-25 packages, I dunno how :(
<Sarvatt> you are using 2.10 now and not getting the errors? or have you been putting up with it for all this time?
<Duke`> I have the execbuf error EVERY day
<Duke`> I had it some hours ago
<Sarvatt> man you have some perserverence
<Duke`> every day I pray for the holy new version fixing it :D
<Sarvatt> you should just grab the 2.9.1 from lucid and rebuild it for karmic and put a hold on that package
<Sarvatt> change the xserver-xorg-dev (>= 2:1.7), line in debian/control to xserver-xorg-dev (>= 2:1.6), first
<Duke`> if I would like a stable version, I would just disable edgers for some time and use karmic packages
<Duke`> I feel that there is not a lot of activity around this bug at Intel. I hope I'm wrong
<Sarvatt> for sure I agree with you :D
<Sarvatt> it's incredibly frustrating with how its so random though, cant believe you've put up with it for almost 2 months
<Duke`> yeah
<Duke`> but someone must do the testing job ;-)
<Sarvatt> i wont be updating mesa on karmic anymore probably Duke` :(
<Duke`> ah?
<Duke`> well, I'll just like an upload when the fix is released
<Duke`> at least
<Sarvatt> it's changed so much in lucid we cant just use the scripts to update it, and i dont use karmic
<Duke`> oh
<Duke`> well lucid release is in 3 months, it's not too far ;p
<bryyce> btw, I've flagged the exec buf bug to Intel and identified it as a blocker bug that must be fixed before we move to 2.10
<bryyce> however, they're blocked by need for additional debugging information
<bryyce> there is a debugging patch posted to the bug report, so it sounds like they just need someone to work with them on gathering the right data
<bryyce> unfortunately I don't have a 945 that I can do the testing on, and haven't reproduced the issue on !945
#ubuntu-x 2010-01-21
<cwillu> [drm:i915_gem_execbuffer] *ERROR* Execbuf while wedged
<cwillu> debugging patch on which bug report?
<Sarvatt> cwillu: 945 or older?
<cwillu> 945
<Sarvatt> debugging patch doesnt seem to work right but here ya go http://bugs.freedesktop.org/show_bug.cgi?id=25475
<ubottu> Freedesktop bug 25475 in Driver/intel "[i915] Xorg crash / Execbuf while wedged" [Critical,New]
<Sarvatt> i haven't gotten kernel-package working right yet (broken on newer .33 kernels) so I haven't tested with the patch yet
<cwillu> k, I'll take a look tonight
<cwillu> I assume it's also broken with a mainline kernel?
<Sarvatt> didnt build with the first patch because he kept posting refreshed versions of it to intel-gfx mailing list and there wasnt a final one
<Sarvatt> yeah kernel doesnt matter here
<cwillu> okay, that's easy enough then
<bryce_> cwillu, can you provide some feedback on the upstream bug report?
<Sarvatt> bryyce: didnt you get a mini 10v?
<bryce_> Sarvatt, nope
<bryce_> Sarvatt, well, I did but it was for my mother-in-law
<Sarvatt> ahh darn
<cwillu> bryce_, yep, reading through it now
<bryce_> Sarvatt, good news is my boss will be giving me one next month when he's in portland
<Sarvatt> cwillu: if you do use the patch are you going to be building x86 or amd64? can ya pass along the deb if x86?
<cwillu> x86
<cwillu> yep, won't be for a couple hours though
<Sarvatt> no worries, not in any rush and apparently with the patch it'll just hard lock instead when it crashes with it :D
<cwillu> eh?
 * cwillu looks
 * cwillu considers splicing in some extra printf's
<bryce_> can we sync the new wacom into ubuntu at this point? http://packages.qa.debian.org/x/xf86-input-wacom/news/20100110T001218Z.html
<Sarvatt> I was asking about that the other day, figured you guys wanted to wait for it to hit testing or something first
<Sarvatt> works fine here outside of not supporting serial tablets at the moment but its better than nothing
<Sarvatt> haven't heard anything about the xserver patch to allow TTY stuff to get it working on serial ones in a few weeks -- http://www.mail-archive.com/xorg-devel@lists.x.org/msg04311.html
<bryce_> ok
<bryce_> I'll add it to my todo list to see about getting it sync'd
<Duke`> Sarvatt, thank your for the bunch of new karmic packages ;)
<tjaalton> bryce_: no, we need the epoch
<tjaalton> bryce_: wacom merged & uploaded
<tjaalton> and intuos4L bought from an auction.. should get it early next week
<coz_> ooo intuos 4
<coz_> I still have 3
<Sarvatt> Duke`: i lied, mesa 7.8 coming to karmic as soon as dri2proto 2.2 and glproto 1.4.11 build :)
<Duke`> \o/
<Duke`> I've seen two libdrm updates for 20th of january, why the second update? an important patch missing in the first?
<Sarvatt> nouveau commit right after i uploaded one that i added as a patch
<Sarvatt> jcristau: did you mean to make the xutils-dev build-dep for vesa 2.3.0 xutils-dev (>= 7.5~1) instead of (>= 7.5) since it needs xorg-macros 1.3?
<Sarvatt> its marked as 7.5-1 in xutils-dev git but the release was called 7.5~1 which is < 7.5?
<ManDay> Does anyone have a clue when Bug #419328 will be patched in the main archives?
<ubottu> Launchpad bug 419328 in xserver-xorg-video-intel "[i945gme] attaching external monitor: laptop display is black, external monitor too, with frozen mouse coursor" [Unknown,Fix released] https://launchpad.net/bugs/419328
<bryce_> <MacSlow> bryce_, pitti, seb128: today's updates removed xserver-xorg-video-intel on an intel-GPU based system... any idea why?
<bryce_> ^ anyone else experiencing this?
<ManDay> no
<jcristau> Sarvatt: pretty sure it needs macros 1.4
<ManDay> bryce_, still have it
<Sarvatt> configure.ac says 1.3
<jcristau> Sarvatt: which is in xutils-dev 1:7.5+1
<jcristau> configure.ac is wrong
<Sarvatt> ah gotcha, thats what i was going by
<jcristau> the INSTALL_CMD in Makefile.am needs XORG_INSTALL, which was added in macros 1.4
<Sarvatt> it built fine with 1.3 strangely enough
<Sarvatt> http://paste.ubuntu.com/360200/ -- build log with 1.3, not sure if its supposed to have any errors
<Sarvatt> ManDay: looks like the fix requires mesa 7.7, thats not going to hit the official repos for karmic.. You can work around it by not using compiz
<Sarvatt> its fixed in lucid though which has mesa 7.7
<Sarvatt> Duke`: let me know if you have any problems with that mesa 7.8 on karmic, I might have missed something with all the changes
 * Duke` is downloading packages
<Duke`> everything installed fine
<ManDay> not using compiz, Sarvatt , not an option
<Sarvatt> ah no wonder all lpia packages are failing on karmic, libdrm-dev depends on  libdrm-intel1 (= ${binary:Version}) [amd64 i386 kfreebsd-amd64 kfreebsd-i386],
<Duke`> OpenGL renderer string: Mesa DRI Intel(R) 945GM GEM 20091221 DEVELOPMENT 
<Duke`> OpenGL version string: 1.4 Mesa 7.8-devel
<ManDay> when is lucid due?
<ManDay> 2011 :-D ?
<Sarvatt> your hardware is limited to 2048x2048
<Sarvatt> its "fixed" in the newer mesa by being faster with software fallbacks to let it work, it still wont get around the hardware limitation
<Duke`> glxgers running at 1200 fps on mesa 7.8, was running at 700 fps on mesa 7.7
<Sarvatt> its due in april
<Sarvatt> yeah i'm up to 480 fps with compiz enabled from 230 not that it means anything :D
<Duke`> glxgears doesn't bench a lot of things, but at least it show that some code has changed :D
<Duke`> I remember having ~2000 fps with glxgears on the same computer on Windows XP
<ManDay_> guess what just happend again
 * ManDay_ curses
<ManDay_> freaking heck
<ManDay_> Sarvatt, can you repeat what you said to me?
<Sarvatt> <Sarvatt> your hardware is limited to 2048x2048
<ManDay_> 2000 frames per second o_O
<Sarvatt> <Sarvatt> its "fixed" in the newer mesa by being faster with software fallbacks to let it work, it still wont get around the hardware limitation
<Sarvatt> and its due in april
<ManDay_> 1st of april supposedly
<ManDay_> :)
<ManDay_> how can i get a newer mesa on karmic? isnt there that bleeding edge ppa?
<Sarvatt> https://edge.launchpad.net/~xorg-edgers/+archive/ppa
<Sarvatt> with the newer mesa it will be doing the 3D in software, dont expect it to be fast once you go above 2048x2048 combined resolution
<ManDay_> im never above 2048x2028
<ManDay_> and i hardly ever use 3d
<ManDay_> but out of curiousity: why does it?
<Sarvatt> its a hardware limitation of older intel graphics, they cant do hardware 3D with texture sizes bigger than that :(
<Sarvatt> if you're at 1280x1024 and plug in another 1280x1024 monitor you're at 2560 for one side of the big 3D texture
<Sarvatt> Duke`: OpenGL renderer string: Mesa DRI Intel(R) 945GME GEM 20091221 DEVELOPMENT x86/MMX/SSE2
<Sarvatt> OpenGL version string: 2.0 Mesa 7.8-devel
<Sarvatt> OpenGL shading language version string: 1.20
<Sarvatt> check out the new driconf options
<bryce_> tjaalton, thanks
<Duke`> yeah we can enable GLSL for fragment shaders but last time I tried, rendering were wrong for my shaders (with no conditions or loops)
<ManDay_> Sarvatt, it the eee pc really THAT old that it cant do proper hardware 3d?
<ManDay_> anyway: Sarvatt , that means there wouldnt be any difference to what it is now, right?
<bryce_> heh, here I sat down on a test box to figure out why it's keyboard hasn't been working... and today it just works.
<bryce_> must be the kvm or somesuch
<Sarvatt> yes the GPU is a good 4-5 years old now and was severely underpowered even when it was first released
<Sarvatt> there will be a difference because the software fallbacks dont run at like 1 frame per minute in mesa 7.7 like they were in 7.6 going by that upstream bug report :D
<ManDay_> but why do they run properly with the current mesa if its the hardware thats the problem?
<ManDay_> why did they put bollocks in my computer :-/
<Sarvatt> you know metacity can do compositing for you too, and that'll work fine >2048x2048 right?
<Sarvatt> wobbly windows that important?
<Sarvatt> i'd try the newer mesa though, or just grab a lucid livecd to see how fast it with the second monitor hotplugged is if you dont want to mess with your system
<ManDay_> wobbly windows?
<ManDay_> nah but expo, desktop wall and all that stuff
<ManDay_> very very useful on a small screen to have more than one of them
<Sarvatt> speaking of netbooks, have you ever tried window-picker-applet, maximus or the human-netbook gtk theme out? saves me so much screen space over the stock panels  http://sarvatt.com/downloads/netbook.png
<ManDay_> i use the scale plugin of compiz
<ManDay_> that and alt+tab do a pretty neat job
<ManDay_> Super+W arranges all windows on the screen and lets me click the one I need
<ManDay_> I know the netbook theme. It's included with the netbook variant of ubuntu
<ManDay_> i didnt like it very much tho. it helps less than it is different
<ManDay_> if you know what im saying
<Sarvatt> i dont like the netbook spin but I like some of the parts of it, the clutter menu thing gets really laggy over time here :(
<ManDay_> test
#ubuntu-x 2010-01-22
<bryce_> tjaalton, wacom still in the build queue?  I'm not spotting it on packages.ubuntu.com yet
<jcristau> NEW maybe?
<Sarvatt> yep stuck in new right next to libxcb
<RAOF> No-one loves nouveau :(
<RAOF> At least, no one in the kernel team seems to have enough spare time to love nouveau.  I wonder why? :)
<bryce_> RAOF, I'm poking around about it privately to see if I can stoke up some activity
<bryce_> RAOF, I've got a bunch of nouveau tasks I need to get cracking on if we're going to do it, or cross off my list if we're going to leave it to MM
<RAOF> Right.
<bryce_> RAOF, and I gather you're in the same situation as me
<bryce_> sconklin, apw, ^^
<RAOF> Well, I'd just like to know what the end result should look like before investing work in it :)
<LLStarks> hey bryce, what's the status of i915 gallium?
<LLStarks> err bryce_
<tjaalton> bryce_: yep, in the queue
<tjaalton> LLStarks: err, ask upstream?
<RAOF> Or try it out; it's easy enough to build.
<tjaalton> right
<tjaalton> jcristau: should mesa-common-dev depend on libdrm-dev? bug 490811
<ubottu> Launchpad bug 490811 in mesa "mesa-common-dev should depend on libdrm-dev" [Undecided,Confirmed] https://launchpad.net/bugs/490811
<tjaalton> at least the reasoning looks sane
<Ng> erk, switch user just did horrible things :o
<Ng> vt7 looked to all the world like a console, but was still X and I jolly nearly typed my password into IRC ;)
<bryce_> Ng, heh leftover graphics bits
<Ng> eurgh, I had to reboot. I managed to get X back with some xrandr -s trickery, but when I dropped back to vt1 to log that out I could see everything I just typed in IRC here in the console bash's history :/
<Ng> (and I never did get to switch user ;)
<Ng> but this is lucid, so I expect breakage, I just have to figure out if I should be filing a bug :)
<tseliot> bryce_, Ng: I guess this happened (if user switching triggered the problem): http://people.canonical.com/~seb128/Xorg.1.log
<Ng> hrm, lemmie check the logs
<tseliot> Ng: you shouldn't be able to reproduce the problem if you boot without the "splash" parameter
<Ng> yep I have an Xorg.1.log very similar to seb's
<tjaalton> my boot just hangs in plymouth
<tseliot> tjaalton: with what driver?
<tjaalton> tseliot: intel
<tseliot> can you see the splash?
<tjaalton> yes
<tseliot> it works with both ati and intel here
<tseliot> oh
<tseliot> did you file a bug report about it?
<tjaalton> no
<tseliot> please do when you have the time
<tjaalton> without splash and quiet it goes fine
<tseliot> nothing interesting in the logs?
<tjaalton> the boot process doesn't generate any logs
<tjaalton> X didn't get up
<tjaalton> never got that far
<tseliot> maybe upstart didn't launch gdm 
<tjaalton> bug 511121
<ubottu> Launchpad bug 511121 in plymouth "boot hangs showing the splash" [Undecided,New] https://launchpad.net/bugs/511121
<tseliot> thanks
<tjaalton> so it stops after mountall
<tjaalton> c-a-del reboots it nicely
<tseliot> that's all the output you get on a normal boot
<tseliot> normal = when it works well
<tjaalton> yeah looks like I didn't disable quiet after all
<seb128> tseliot, btw do you want a bug with my log?
<seb128> tseliot, or do you have one?
<tseliot> seb128: I wanted to ask you to file one
<seb128> tseliot, ok, on xserver-xorg?
<tseliot> seb128: it might be that plymouth is the cause
<tjaalton> nothing more without quiet
<tseliot> seb128: so, please assign it to plymouth
<seb128> ok
<seb128> tseliot, bug #511134
<ubottu> Launchpad bug 511134 in plymouth "get a text vt over xorg when trying to switch users" [Undecided,New] https://launchpad.net/bugs/511134
<tseliot> seb128: thanks
<tjaalton> huh, so I got the wacom already, and attaching it hung the server :)
<tjaalton> yep, the driver crashed
<tjaalton> oh wait, that was an older snapshot, the one I uploaded works \o/
#ubuntu-x 2010-01-23
<ScislaC> bryce_: new wacom driver works on initial plug (woohoo!), but it seems that if it's unplugged and plugged back in it isn't recognized again, shall I file a report?
<Sarvatt> hmmm, I definitely don't have that issue here with my graphire or intuos http://pastebin.com/f589bd0f9
<Sarvatt> oh i'm using my old wacom udev rules, not the packages
<Sarvatt> seems to be working fine with 69-xserver-xorg-input-wacom.rules too.. hmm
<Sarvatt> what model tablet are you having that problem with?
<ScislaC> Sarvatt: Intuos 2
<Sarvatt> digging out my intuos 2 to see if I have that problem with the ubuntu packages udev rules
<Sarvatt> i did see some pad button fixes in the .33 kernel that are specific to intuos and i haven't tried it on this ubuntu kernel now that I think about it
<ScislaC> Sarvatt: I'm going to restart X real quick to see if that helps... brb
<Sarvatt> wonder why the wacom udev rules didnt get installed with the ubuntu wacom package after upgrading, i had to purge and reinstall it
<ScislaC> Sarvatt: yeah, that made no difference here at all, wouldn't even work on the first plug that time
<Sarvatt> ScislaC: just curious, do you have a /lib/udev/rules.d/69-xserver-xorg-input-wacom.rules ?
<Sarvatt> i had to purge and install it again for it to install that here for some reason
<Sarvatt> if you dont it was using evdev probably
<ScislaC> I do
<Sarvatt> intuos 2 4x6 working fine with multiple plugs/unplugs http://pastebin.com/f8cc1ce1
<Sarvatt> weird
<Sarvatt> oh sorry, intuos 3
<Sarvatt> bah
<Sarvatt> was graphire 2 that i had
<ScislaC> Sarvatt: well, I may reboot to see if there's any magic there (I'm not really sure how many updates I've run during the session of uptime)... not that I expect anything to change, but who knows.
<Sarvatt> Ng: any chance you can try disabling 121_only_switch_vt_when_active.diff from xorg-server's patch series and see if it fixes your problem?
<Ng> Sarvatt: the switch-user-leading-to-crash-and-weird-console issue?
<Sarvatt> yeah
<Ng> sure
<Sarvatt> actually I'm about to upload a new xserver 1.7.4.901 to edgers, I can drop it there and test it out. need to reinstall plymouth first
<Ng> I just uploaded it to my ppa anyway
<Ng> I don't fancy sticking all the build-deps on my laptop and having it build an X server ;)
<Sarvatt> its just switching users to another user that crashes for you? or do guest sessions do it too?
<Sarvatt> hmm his description in the bug there is what I got before adding /sbin: to the path in gdm's PreSession script..
<Ng> Sarvatt: I've not tested a guest session yet
<Ng> I'll have a better answer tomorrow I guess - launchpad reckons it'll be an hour till my package starts building
<Sarvatt> yep, I can reproduce
<Sarvatt> funny enough if i switch to vt1,  login, sudo service gdm stop then sudo service gdm start, guest sessions and such work right from then on
<Sarvatt> or=on
<Sarvatt> ah I'm on vt8 doing that
<Sarvatt> it's odd though, this was all working fine last weekend when I found the /sbin not being in the path problems for gdm
<tjaalton> I wonder if scislac had a newer package version than the one from the official wacom-tools
<tjaalton> x-x-i-w replaces/conflicts the official version, but not anything newer
<jcristau> are the i915 overlay patches in the lucid kernel?  if not are they being considered?
<jcristau> tjaalton, bryce_: ^^
<tjaalton> jcristau: I doubt they are included yet, and don't know if they will be
<jcristau> ok
<tjaalton> apw: ^^
<Sarvatt> Ng, seb128, tseliot: Removing patch 121 from xserver fixes it here
<Sarvatt> http://pastebin.com/f14fb3f54
<Sarvatt> guest session goes to VT8 and works fine instead of trying to open display :1 on vt7 where display :0 is already running
<Ng> ooh yes I was going to install that and test
<Ng> oh bah, I got the version wrong
<Ng> man I hate the debian version number system
<Sarvatt> can just copy the one out of edgers 
<Ng> ouch, 15 hour build queue for amd64 PPAs
<schmidtm_> hi i'm having a problem installing nouveau driver. see my bug report #511726 
<schmidtm_> another thing is that the nouveau druver should also replace the nvidia-current and not only nvidia-glx
#ubuntu-x 2010-01-24
<Sarvatt> Ng: want x64 debs or do you want to just wait for the PPA? I built it on my x64 machine to verify dropping patch 121 fixes it there too but I forgot plymouth wasnt working on that machine so cant test it
<Sarvatt> http://sarvatt.com/downloads/xserver-gdm/
<Ng> Sarvatt: ooh, the PPA built, I'll install it and test now :)
 * Ng sighs, or not
<Ng> why does rebuilding xorg-xserver seem to force you to rebuild xserver-common to have the exact same version? :/
<Sarvatt> its part of the same source package?
<Ng> hrm, what, xserver-common claims to have a Source of xorg-server, but that's what I uploaded and it built, but didn't make a -common package
<Ng> https://edge.launchpad.net/~cmsj/+archive/ppa/+packages
<Sarvatt> it builds with the i386 on a PPA I guess, building locally it builds it
<Ng> ohh, that's arch all, I bet that's only going to get built b... yeah, i386
<Sarvatt> xserver-common_1.7.3.902-1ubuntu9.1_all.deb
<Ng>     *   Start in 20 hours (2605) Rescore build  What's this?
<Ng> I'm just going to install yours ;)
<Sarvatt> sheesh!
<Sarvatt> 20 hours of mozilla queues no doubt :D
<Ng> yeah, probably
<Ng> but there's only like 4 builders right now
<Sarvatt> i think theres a ton of KDE releasing queued to build too
<Sarvatt> releases rather
<Ng> I should set up my own dak instance
<Sarvatt> wonder why that was broken in the past week though, last weekend after bryce updated xserver to drop the patch that was making it segfault on FatalError it was working fine with plymouth
<Sarvatt> somewhere between sunday and wednesday it broke
<Sarvatt> with patch 121 in xserver its trying to start display :1 on VT7 when I do a guest session and giving the drm failed to set master error with plymouth going, and if i drop patch 121 it starts display :1 on VT8 and works right
<Sarvatt> ugh I need to write an upstart job for znc or something
<Ng> Sarvatt: no change, switch user still leaves me with a weird broken console/X hybrid
<Ng> upstart job? are you using it for multiple users or just yourself?
<Ng> I just have znc running for myself as my user:
<Ng> -(cmsj@mairukipa)-(~)- crontab -l | grep znc
<Ng> @reboot znc
<Sarvatt> hmmmmm why did it work here
<Sarvatt> ahh I see what I did
<Sarvatt> my indicator applet session is screwed up and not showing any buttons so I added the log out applet
<Sarvatt> that does things differently
<Sarvatt> if i go to vt1, sudo service stop gdm then sudo service start gdm everything works fine
<Sarvatt> i think that log out applet is just stopping/restarting gdm without automatic login (?) instead of trying to change the session inside gdm
<Sarvatt> dont know how to fix indicator-applet-session to show the logoff/guest session stuff again
<Sarvatt> it works if i use the log off applet and log in again but its not working on first boot ever anymore
<Ng> weird
<Sarvatt> its working for you?
<Sarvatt> maybe if i disable automatic login..
<Sarvatt> yep disabling automatic login made indicator-applet-session work again, and yep its still broken that way here :(
<Sarvatt> if i use log out applet it moves X over to VT8 altogether and things all work but still getting the "[drm] failed to set drm interface version." and "failed to get resources: Bad file descriptor"
<Sarvatt> from a fresh boot using VT7
<Ng> Sarvatt: yeah the indicator applet works fine for me, no automatic login
<Ng> (I mean it works fine in that it shows the right items, they don't all work obviously ;)
<Sarvatt> yeah disabling automatic login fixed it here, guess thats the problem there :(
<Sarvatt> trying gdm without the plymouth integration patch now
<Sarvatt> no luck there
<Sarvatt> that solar plymouth theme sure is pretty, but wow does it kill my boot times http://sarvatt.com/downloads/asuka-lucid-20100123-3.png
<Sarvatt> still feels 2x faster than jaunty though even though I had bootcharts like this back then http://sarvatt.com/downloads/ubuntu-9-jaunty-20090318-1.png
<ScislaC> Sarvatt: FYI, I finally rebooted and the Intuos 2 only works on the first plug. I have to fully reboot for it to be detected (well, or for it to work) again.
<Sarvatt> tjaalton: think ya meant to make it xserver-xorg-input-joystick-dev? http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-input-joystick.git;a=blob;f=debian/control;h=6ba8288cc0593381e0b7391645c812a2cae44400;hb=HEAD
<jcristau> Sarvatt: ack, please feel free to fix it up :)
<jcristau> Sarvatt: also change arch:any -> arch:all maybe
<aclarke> is there a version of the x-server-with-no-backfill patched version of the current x-server for Ubuntu 9.10; my latest apt-get upgrade replaced my patch x-server and my ATI-base windows are slow again :(
<aclarke> the original patched xserver PPA is here: https://edge.launchpad.net/~ubuntu-x-swat/+archive/xserver-no-backfill
<libv> jcristau: sad to hear that you're moving away from debian-x
<jcristau> libv: i need to finish my phd last year, and doing both at the same time doesn't seem possible :/
<jcristau> but thanks
<libv> yeah, makes sense
<libv> jcristau: coming to fosdem this year?
<jcristau> afraid not :(
<libv> too bad, not only for the social stuff, but i will be mentioning your work twice in my talk
<jcristau> heh
<libv> 1) git trees with debian overlays 2) separate libdrmintel
<jcristau> maybe if xdc is in .fr later this year i'll try to make it there
<libv> there's going to be an xdc in europe?
<jcristau> alanc said something like that on #xorg-devel
<libv> heh
<jcristau> wasn't sure yet, but.
<libv> as a response to my complaint about fosdem i'm sure
<libv> why is it that i have to kick ass, every time, before anything changes
<jcristau> dunno in response to what, it was in the middle of freenode netsplits
<libv> ah, so it was not in the last few days?
<libv> hah, 16th.
<libv> f it
<libv> toulouse.\
<libv> fosdem is central, just as far to go to as everything else
<libv> err, for everyone
<libv> no-one without corporate sponsorship will go there
<libv> well, except the redhatters, they will use X.org funds as per usual
<verbalshadow> i would really like some help, I have try remoting into my "sick" machine following https://wiki.ubuntu.com/X/Backtracing#Debug symbol information
<verbalshadow> but the whole machine crashes not just X, so i can never complete the backtrace
<verbalshadow> the screen sometime goes black but normally it just get white "scanlines" on kernels newer than -7
<verbalshadow> sorry this is in lucid
<Sarvatt> hmm
<Sarvatt> dh_install --sourcedir=debian/tmp --list-missing --exclude=joystick_drv.la --exclude=usr/share/man/man4
<Sarvatt> dh_install -d debian/xserver-xorg-input-joystick/lib/udev/rules.d
<Sarvatt> dh_install: xserver-xorg-input-joystick missing files (usr/lib/xorg/modules/input/*.so), aborting
<Sarvatt> ll debian/tmp/usr/lib/xorg/modules/input/*.so
<Sarvatt> -rwxr-xr-x 1 robert robert 203766 2010-01-24 14:53 debian/tmp/usr/lib/xorg/modules/input/joystick_drv.so
<jcristau> fun
<jcristau> dh_install -d debian/xserver-xorg-input-joystick/lib/udev/rules.d
<jcristau> that sounds broken
<jcristau> was probably supposed to be install -d
<Sarvatt> indeed
<jcristau> same for the next one
<jcristau>  dpkg-genchanges -b >../xserver-xorg-input-joystick_1.5.0-2_i386.changes
<jcristau> worked.
<Sarvatt> joystick-dev should be arch: all? should evdev-dev to be arch: all too then?
<jcristau> yes
<jcristau> it's just a bunch of #defines there's no reason to make it arch:any
<Sarvatt> alrighty pushing to both now
<jcristau> debian/rules needs to do stuff in binary-indep for that to work though
<Sarvatt> crap, thats what I get for messing with debian stuff when I don't understand what I'm doing, I left that out and am not sure how to fix it.
<Sarvatt> http://paste.ubuntu.com/362167/
<Sarvatt> does that look right?
<Sarvatt> I just copied your synaptics change
<jcristau> yeah looks sane
<jcristau> basically copy dh_* from binary-arch and add DH_OPTIONS so debhelper does the right thing
<Sarvatt> should I drop ${shlib:Depends} from the -dev and dh_shlibdeps from the binary-indep rules as well?
<jcristau> it doesn't really matter
<Sarvatt> ok joystick works with http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-input-joystick.git;a=commit;h=2a28ce4c4e7b8991b3fe881b6a6c7b99ac24ba2a  now to fix up evdev
<jcristau> thanks!
<Sarvatt> sorry about the trouble and thanks a ton for helping me through it jcristau
<jcristau> np.  i like it when i don't have to do anything ;)
<tjaalton> Sarvatt: hah, I suck
<andruk> please excuse me if this isn't the appropriate place to ask this, but if I'm trying to use XOpenDisplay/XCloseDisplay in a program, is it possible to get a list of the current screens attached to a specific Xserver so i can pick one and use it in XOpenDisplay/XCloseDisplay?
<jcristau> once you've done XOpenDisplay you can walk the screens
<jcristau> ScreenCount(dpy) tells you how many of them there are
#ubuntu-x 2011-01-17
<Takyoji> ripps: installed the package you specified (for the BambooFun) and the tablet is active, just still won't do any input or manipulation of the cursor (I have also tried switching between virtual terminals; Ctrl+Alt+F1, Ctrl+Alt+F7)
<ripps> Takyoji: what kernel are you using?
<hyperair> bryceh: i see. that's nice.
<Takyoji> $ uname -a
<Takyoji> Linux timber-wolf 2.6.35-24-generic #42-Ubuntu SMP Thu Dec 2 02:41:37 UTC 2010 x86_64 GNU/Linux
<ripps> Takyoji: well, the backports package should support it...
<ripps> Okay, here's the alternative:
<ripps> Uninstall the linux-backports package and remove any wacom modules you might have installed.
<ripps> Then try installing the wacom-dkms package from my Wacom PPA: ppa:ripps818/wacom
<ripps> If it still doesn't work, try filing a bug report.
<Takyoji> The xserver-xorg-input-wacom package is apparently depended on by the xserver-xorg-input-all package
<Takyoji> So remove linux-backports-modules-input-maverick-generic, xserver-xorg-input-wacom, and xserver-xorg-input-all (due to it's dependency on the prior package)
<Takyoji> Or just the backports package?
<ripps> Just the backports package.
<ripps> if your problem is with the xserver-wacom driver, there isn't much I can help you with.
<Takyoji> After adding the PPA, just upgrade packages or install a specific package?
<ripps> Takyoji: install wacom-dkms
<ripps> it will build a new wacom driver from scratch
<Takyoji> Then restart the system, or?
<Takyoji> Still nothing apparently
<ripps> *sigh* well, I don't know then. Try filing a bug report then.
<Takyoji> I'm looking at dmesg, and all it does identify a device being connected, but nothing more specific
<Takyoji> just: [   96.056560] usb 2-10: USB disconnect, address 4
<Takyoji> [   97.860031] usb 2-10: new full speed USB device using ohci_hcd and address 5
<Takyoji> When I unplugged and replugged it in
<Takyoji> Is there anything to identify what is operating a USB device, or?
<Takyoji> I'm not sure if it's just a newer revision of the series, thus has a different USB ID number or something
<Takyoji> Bamboo Fun (Model: CTH-661)
<ripps> Takyoji: your not the first person who I've talked to who's had trouble with that line of tablets. The version of the wacom module built in my ppa might not be new enough. Either way, it's best to file a bug report so that it can get fixed as soon as possible
<Takyoji> What useful information would I be able to prepare though?
<Takyoji> I'm trying to see if I can get a USB packet capture of it
<Takyoji> via Wireshark
<ripps> Takyoji: unless your planning on giving that information to the linuxwacom project devs to make a driver with, I'm not sure what that will accomplish. Just file a bug using `ubuntu-bug xserver-xorg-input-wacom`.
<ripps> If your feeling more adventurous after that, try going to the linuxwacom projects homepage and building your own module/driver from scratch.
<Takyoji> otherwise this is for a friend, as they recently have bought it and need help with it working under Ubuntu; thus I temporarily have it. I also temporarily have their laptop for reporting a bug regarding a kernel regression causing USB issues.
<Takyoji> I'm of course testing this tablet on my desktop which I know doesn't have any issues
<ripps> Takyoji: it seems that ppa:irie/wacom has some newer versions of the wacom-dkms and xserver-xorg-input-wacom drivers
<Takyoji> "Wacom tablet powered, but no input" a reasonable title for the bug?
<ripps> try them after your done filing a bug
<ripps> Takyoji: yeah that's fine, I would include the tablet version in there
<Takyoji> "Wacom BambooFun tablet powered, but no input"
<ripps> sure
<Takyoji> ripps: Bug report: https://bugs.launchpad.net/ubuntu/+source/xf86-input-wacom/+bug/703783
<ubot4> Launchpad bug 703783 in xf86-input-wacom (Ubuntu) "Wacom BambooFun tablet powered, but no input (affects: 1) (heat: 6)" [Undecided,New]
<ripps> Takyoji: now try that ppa:irie/wacom ppa and see if the updated driver helps.
<Takyoji> Same package?
<Takyoji> Installed; restarting
<Takyoji> Still isn't working
<Takyoji> If it's relatively straightforward for compiling the latest source code, I wouldn't mind trying
<ripps> Takyoji: meh... it's kinda difficult to explain. I'm sure it's been explained by someone already (and alot better than I could) on some blog somewhere. Do a google search, I think ubuntugeek had an article about it some months back
<Takyoji> Nifty; didn't know DKMS was written by Dell
<Takyoji> If USB stopped working after a specific kernel version in Ubuntu; you'd report it under "linux", correct?
<Takyoji> Did the kernel version jump from 2.6.31-20 to 2.6.35-22 during Ubuntu 10.10, or was only the 2.6.31 series for 10.04?
#ubuntu-x 2011-01-18
<Takyoji> ripps: https://bugs.launchpad.net/ubuntu/+source/xf86-input-wacom/+bug/703783/comments/2 https://bugs.launchpad.net/ubuntu/+source/xf86-input-wacom/+bug/703783/comments/3
<ubot4> Launchpad bug 703783 in xf86-input-wacom (Ubuntu) "Wacom BambooFun tablet powered, but no input (affects: 1) (heat: 6)" [Undecided,New]
<Takyoji> in other words, apparently I've found out that only manipulates the cursor with scribbled on by-finger rather than with the pen for it.
<Takyoji> s/with/when/
<ripps> Takyoji: you might want to try and contact the linuxwacom developers, I think they probably have a bug tracker at sourcforge.net. They might have some idea about what's going on.
<Takyoji> alright
<bjsnider> Sarvatt, you can build this stuff in pbuilder before sending it in to the ppa
 * apw notes that there seems to be an issue with nvidia-detect output format changing ... does anyone know exactly what the nvidia-common postinst is for as it is cirtainly affected
<apw> bug #704471
<ubot4> Launchpad bug 704471 in nvidia-common (Ubuntu) "nvidia-common kernel postinst hook throws test errors (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/704471
<tseliot> apw: let me check, I wrote that script
<apw> tseliot, sounds fun
<tseliot> apw: maintenance surely is ;)
<apw> tseliot, heh ... i twiddled a bit with the script; turning off the Verbose=True seemed to make it more as the calling script expected
<tseliot> apw: pitti modified nvidia-common changing the logic behind modaliases so maybe the debconf code needs to be updated too
 * tseliot doesn't remember what his own code does...
<tseliot> apw: actually, looking at the changelog, it seems that he also updated the postinst
<tseliot> apw: BTW what do you get with Verbose=False?
<apw> tseliot, it is defiantly not working as designed currently
 * tseliot nods
<apw> tseliot, for me verbose=False just says 'none'
<apw> i have no idea what happens if you have nvidia
<tseliot> apw: you can simulate that by overriding self.cards in getCards() in /usr/share/pyshared/NvidiaDetector/nvidiadetector.py or /usr/lib/python2.7/dist-packages/NvidiaDetector/nvidiadetector.py as in the commented lines
<tseliot> apw: you can even pretend to have 4 cards: self.cards = ['10de:02e2', '10de:002d', '10de:0296', '10de:087f']
<Sarvatt> NVIDIA card found (10de:0dd1)
<Sarvatt> Removing unsupported card 10de:0dd1
<Sarvatt> No NVIDIA package to install
<Sarvatt> none
 * Sarvatt wonders if this has something to do with 2.6.37-12 not working
<Sarvatt> ah nvidia package i'm using doesnt have the backporting nightma.. i mean modalias changes
<bryceh> heya Sarvatt and tseliot
<Sarvatt> heyo bryceh!
<tseliot> bryceh, Sarvatt: hey
<Sarvatt> trying to fix up xorg-edgers, what a mess
<tseliot> Sarvatt: ah, thanks for the output
<Sarvatt> they made a crapload of changes to the mesa build system upstream
<bryceh> Sarvatt, what's wrong?
<Sarvatt> ati in there was built from debian-experimental so lost the gallium options and had a ton of emails about it
<bryceh> Sarvatt, fwiw I'd installed it on my netbook Friday and it seemed to work fine
<tjaalton> howdy
<jcristau> hi timo
<tjaalton> I should probably fix my irssi setup so I could use another server too, and join the debian channels again :)
<tjaalton> but first edgers
<tjaalton> jcristau: and hi :)
<evilvish> Sarvatt: remember the RV515 bug i was mentioning about, the one where X freezes during scrolling in firefox?  it does not happen with maverick -edgers \o/
<evilvish> oh and i am using the .37 kernel from edgers, but it was never kernel dependant though
<bryceh> heya tjaalton
<Sarvatt> RAOF: you'll be glad to know libdricore is broken already! :)
<bryceh> http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg
<bryceh> "firegl_public.c:410:5: error: unknown field âioctlâ specified in initializer" hmm, isn't that one already fixed?
<bryceh> (bug #704287)
<ubot4> Launchpad bug 704287 in fglrx-installer (Ubuntu) "package fglrx 2:8.801-0ubuntu2 [modified: usr/lib/fglrx/etc/ati/authatieventsd.sh usr/src/fglrx-8.801/2.6.x/Makefile usr/src/fglrx-8.801/dkms.conf usr/src/fglrx-8.801/firegl_public.c] failed to install/upgrade: fglrx kernel module failed to build (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/704287
<tjaalton> i'll be damned, finally a proper resize-corner with the default theme
<tjaalton> and not 1x1
<bryceh> yeah saw that.  think it's new as of last week
<tjaalton> hmm edgers already has newer mesa that'll get in natty?
<tjaalton> +a
<bryceh> tjaalton, yeah
<tjaalton> ok..
<bryceh> tjaalton, but it's not crazily different, just a handful of changes so far
<tjaalton> ah
<tseliot> bryceh: I think I can fix fglrx. I uploaded a similar fix for the broadcom driver
<bryceh> I suppose we could put exactly the release version in, but sounds like it's close enough to not be worth the trouble.  However I do think we should avoid updating it to newer snapshots until after the upload is done.
<bryceh> tseliot, okie, yeah this sounds like something that got fixed before
<bryceh> at least, the error message sounds familiar... not putting my finger on the bug report yet tho
 * tseliot nods
<bryceh> Sarvatt, could you look at bug #681054 when you get a chance?  Since he can repo it on a livecd, I'm thinking next step is to send it upstream, unless you have an idea for something else he could test first?
<ubot4> Launchpad bug 681054 in xserver-xorg-video-intel (Ubuntu) "screen repeatedly goes black for a fraction of a second (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/681054
<tjaalton> resume still doesn't work with .37, the thing does a cold boot
<bryceh> tjaalton, it's been working for me
<bryceh> tjaalton, maybe chat up the kernel team about it
<tjaalton> yeah
<tjaalton> heh, bug 625364
<ubot4> Launchpad bug 625364 in linux (Fedora) (and 2 other projects) "lenovo/thinkpad T400[s]/T500/W500/X60/T6x suspend fails (affects: 53) (dups: 3) (heat: 337)" [Unknown,Unknown] https://launchpad.net/bugs/625364
<tjaalton> on the top of the list
<tjaalton> hmm, doesn't seem like 100% same
<tjaalton> worked just fine on maverick
<bryceh> file a new bug and just mention that one in reference, the kernel team prefers bugs filed individually and do duping themselves
<bryceh> tjaalton, once it's filed make sure it's tagged 'natty' and nominated for natty, and then ping JFo on IRC.  Ask him to add it to the kernel team's review list
<tjaalton> bryceh: alrighty
<bryceh> RAOF, what do you think the next action should be for bug #681054?
<ubot4> Launchpad bug 681054 in xserver-xorg-video-intel (Ubuntu) "screen repeatedly goes black for a fraction of a second (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/681054
<RAOF> Hm.  I seem to remember a kernel knob that could be tweaked?
<RAOF> Or maybe that was radeon.
<bryceh> yeah, random blanking has been a longstanding radeon issue.  Haven't really seen periodic blanking bugs on intel, at least not recently
<tjaalton> I used to have those on intel during 9.10 or such
<RAOF> Maybe the next thing to do is to ask whether unplugging the VGA monitor changes the behaviour?
<bryceh> tjaalton, regular/periodic, or irregular/random?
<tjaalton> bryceh: more like the latter
<RAOF> There's certainly quite a lot of xrandr probing in the logs.
<bryceh> yeah that was my first thought
<bryceh> but tail -f on it didn't generate more
<tjaalton> yeah i thing it was related to that when i had it
<bryceh> (you'll recall me asking if we had something in there that quells that output after 10 entries or something)
<RAOF> But maybe not enough to explain all teh blanking.
#ubuntu-x 2011-01-19
<RAOF> Hm.  xutils-dev has a build-dependency on xutils-dev :)
<bryceh> is fglrx DRI2 or just DRI1 capable?
<bryceh> [    14.359] (II) fglrx(0): [uki] DRM interface version 1.0
<bryceh> izzat mean dri1?
<RAOF> I suspect that's the kernel<->userspace interface version.
<thesheff17> I'm trying to install ubuntu w/ a ati firepro 2450.  I installed 10.04 fine but for some reason it couldn't detect all 4 monitors.  So I tried 10.10 and it just hangs after I log in.
<thesheff17> 10.04 I did install the restricted ati drivers....still didn't see the other 2 monitors on the second connection...I wonder if the card is defective. 
<RAOF> thesheff17: Hm.  On 10.10 what happens when you log in?
<RAOF> âhangâ can mean many things :)
<RAOF> Is this one of those eyefinity cards with 4 displayport outputs?
<thesheff17> the background just sits there after I hit login on 10.10.
<RAOF> Using the standard desktop session, I guess.  Can you switch to a virtual-terminal (with Ctrl+Alt+F1, etc?)
<thesheff17> waiting about 10 min and just nothing...this also happen end when I hit try ubuntu 10.10
<thesheff17> it looks like those are disabled....
<Azelphur> I've been looking around trying to figure out if it's possible to have pinch zoom in Ubuntu
<Azelphur> I see that the synaptics site says the driver should have pinch zoom support
<Azelphur> but that's about as far as I got :p
<RAOF> thesheff17: If they don't work, then it's likely that the kernel graphics driver has wedged.
<RAOF> Azelphur: Possible (as of 10.10), but you'd actually need to implement it.  Many synaptics touchpads are multi-touch, but you actually need some way of informing the toolkits what those gestures mean.
<Azelphur> RAOF, I'm up for a little code, what would I actually need to write?
<Azelphur> does the synaptic device send some kind of event for pinch zoom
<RAOF> No.
<thesheff17> ok I'm actually trying windows xp right now just to make sure this card isn't defective....give me about 10 min and I will go back to ubuntu....after the ubuntu install I was able to do recovery mode and at least get a terminal...is there a specific file you want me to look at?
<Azelphur> or would I have to read raw events from the touch pad
<Azelphur> and figure it out
<RAOF> thesheff17: Hm.  So that's a dual-gpu card.  The default drivers may only be able to drive one of the two gpus, but that shouldn't cause lockups.
<RAOF> Azelphur: You'd get multiple touch events from the touchpad.  Or, rather, you'd get something - I'm not sure what - from libgrail.  #ubuntu-touch is where you'd want to go for this.
<Azelphur> righto :)
<thesheff17> RAOF: that is the case I think that is happening with ubuntu 10.04 because it only drives 2 of the 4 monitors.......I was trying 10.10 to see if it was any different.
<RAOF> This is currently in a bit of flux - multitouch support is only just now being integrated into the X server - but I think the high level stuff is stable.
<RAOF> thesheff17: I would have thought that the proprietary fglrx drivers would drive both GPUs and hence allow you to light up all four screens, but I've not tried it :)
<thesheff17> RAOF: yea I got my work to buy this card of ebay for $175.....would love to get Ubunu working with a single card w/ four monitors.
<RAOF> I understand that one of the newer EyeFinity cards would work out of the box with up to 6 displayport monitors, but again I haven't tried that, and it's not very helpful for you.
<thesheff17> yea I was looking at the 6 port ati cards but they where too expensive. 
<RAOF> And you need DP monitors, too, or active DPâDVI converters, which also aren't cheap.
<thesheff17> yea that is what is nice about this card...it came with the adapters....even though they are not DP-DVI
<thesheff17> ok yea the video card works fine under windows xp...I can see display a different screen on each monitor....is there anything we can try to power the second dual-gpu on ubuntu 10.04?
<RAOF> thesheff17: I'd have a look at the options to âaticonfigâ.  You might need to generate a new xorg.conf, passing â--adapter=allâ.
<thesheff17> ok I'm re installing 10.04 and installing the restricted drivers...and will try that.
<thesheff17> RAOF 10.04 loaded right away after the install...there must be something with 10.10 that is causing the hang :-/
<RAOF> thesheff17: Yeah - there's a newer set of drivers in 10.10.  We can debug that if you like, or just try to get fglrx working with all your monitors.
<thesheff17> RAOF: I would like to try to get the 4 monitors to work...and then I would even give 10.10 another shot. If you have the time...I just not a x.org expert.
<RAOF> You've installed the proprietary drivers now?
<thesheff17> yea
<RAOF> Now I think you should try running âsudo aticonfig --initial -f --adapter=allâ in a terminal.
<thesheff17> I prob should run updates first :-/
<RAOF> Yes, indeed ;)
<thesheff17> I have a local mirror it will take a only a min.
<thesheff17> RAOF: by the way thanks for helping...I couldn't find anything google for this adapter.  
<RAOF> It doesn't seem likely to be particularly common; the firegl parts appear less in the community than the commodity radeon parts.
<thesheff17> RAOF: I ran that command then restarted X and all the displays came on...I went into the administrator of the aticonfig and placed them 2x2 and now they are freaking out.
<RAOF> Oooh, cool!
<RAOF> Well, partially cool :)
<thesheff17> yea def getting somewhere
<thesheff17> man I wish ctrl-alt-f1 still worked :-/ and why do they disable restarting x with ctrl-alt-backspace
<RAOF> Because it was an excellent way to loose hours of patiently entered data.
<thesheff17> lol...I guess that is true.
<RAOF> ctrl-alt-f1 *should* work, although it might not if the hardware has been freaked out sufficiently.
<thesheff17> ah it did once x loaded
<thesheff17> ok I have all 4 screens working...one of the monitors doesn't have the toolbar....it looks like like each monitor is its own desktop actually.....I can't drag an app like firefox to the other monitor. Is this a setting?
<thesheff17> lol actually I can drag firefox on the top two monitors but not the bottom two :)
<RAOF> Ok, that's because you've got both GPUs driven, but they're starting as separate X sessions.
<RAOF> You *should* be able to make that into a single desktop with 4 screens by setting up Xinerama correctly.  Could you pastebin your /etc/X11/xorg.conf file, and I might be able to see how that should go.
<RAOF> Xinerama is a little bit unloved, though, so it might not work.
<thesheff17> sure
<thesheff17> yea they are all 22" monitors 
<thesheff17> so shouldn't be horrible.
<thesheff17> http://paste.ubuntu.com/555666/
<RAOF> Hm.  Just switching the âXinerama "off"â line to âXinerama "on"â might work.
<thesheff17> cool..trying 
<thesheff17> is sudo /etc/init.d/gdm restart still good?
<thesheff17> it works :)
<thesheff17> Thank you so much :)
<thesheff17> Let me back up the this x.org and do you want to try ubuntu 10.10? it is up to you....
<thesheff17> xorg.conf I meant.
<ripps> *sigh* the latest -ati update in xorg-edgers is causing my X server to randomly crash when I start playing a movie.
<evilvish> ripps: -edgers on maverick? same thing *just* happened here :)
<ripps> evilvish: yeah, it's very random. I can watch half a dozen videos, than suddenly I'm dropped to VT
<ripps> It must have something to do with intializing XV
<evilvish> ripps: yup, same scenario, dropped to vt and then X restarts.. (before that update it was all fine..)
<ripps> from what I can tell from the freedesktop cgit, a new function was added to KMS textured video to prevent memory leaks. I wonder if it's responsible
<evilvish> only these two started the problem: xserver-xorg-video-ati (1:6.13.2-0ubuntu1~xup1) to 1:6.13.99+git20110110.0e432dff-0ubuntu0sarvatt~maverick
<evilvish> xserver-xorg-video-radeon (1:6.13.2-0ubuntu1~xup1) to 1:6.13.99+git20110110.0e432dff-0ubuntu0sarvatt~maverick
<ripps> Oh, according to cgit and version of -ati in xorg-edgers, we just short of a single commit that might fix it
<evilvish> ripps: looks like a Sarvatt cherry picked a patch from upstream > http://launchpadlibrarian.net/62414603/xserver-xorg-video-ati_1%3A6.13.99%2Bgit20110118.6548bb98-0ubuntu0sarvatt3~maverick_1%3A6.13.99%2Bgit20110118.6548bb98-0ubuntu0sarvatt4~maverick.diff.gz
<evilvish> hmm, rolling back from ubuntu is easier to find the debs.. i wonder if ppa also have older debs around.. my /var/cache doesnt have it.. :(
<ripps> Sarvatt: can you pull the latest commit from -ati upstream, I think the latest commit was meant to fix the crashing problem that was introduced in the current version on edgers
<ripps> Can't wait until 2.6.38 gets into natty/xorg-edgers. I want to test out the new pageflipping code to see if it actually improves performance
<evilvish> gah.. i was looking at the wrong updates! :/
<evilvish> 0ubuntu0sarvatt~maverick was the good one.. 
 * evilvish updates  to 0ubuntu0sarvatt4~maverick
<evilvish> grr.. and we have dates to account for too in the version number! so the deb was all along in the /var!!! ;p
 * evilvish blames synaptic for not keeping good track of history ;p
<evilvish> gah.. SC history is worthless without version # and synpatic history does not see apt-daemon updates :/
<Amaranth> hrm, even with X not running the i915 kernel module is responsible for 56.7 wakeups per second
<evilvish> !away > jbs
<ubot4> jbs, please see my private message
<bryceh> ew @ #703553
<bryceh> ew @ bug #703553
<ubot4> Launchpad bug 703553 in linux (Ubuntu Maverick) (and 1 other project) "After upgrade to linux-image-2.6.35-25 graphics are broken (affects: 20) (dups: 2) (heat: 112)" [High,Confirmed] https://launchpad.net/bugs/703553
#ubuntu-x 2011-01-20
<ripps> Wow, have to give the ati gallium devs credit, they're quickly approaching performance parity with the catalyst drivers. Now all we need is some form Video Acceleration for r300-r500 and I'll be a very happy camper.
<RAOF> ripps: I'd try a little reverse-engineering if I were you; the gallium VA architecture is starting to materialise, so there'd be something to hook in to :)
<bjsnider> ripps, yes but the tests were conducted with extremely old hardware.
<ripps> bjsnider: like mine. I have an rv350 radeon 9600 pro
<ripps> This is very good news for me
<bjsnider> it would be helpful if the code also worked for the newer stuff too
<ripps> at least r600g has xvmc, I'm still wallowing in xv only. I'd really like to offload just a small bit of video decoding to the gpu
<bjsnider> there's no video decoding hardware on an old thing like that
<ripps> shouldn't matter, from what I can tell, the upcoming gallium va architecture will shaders, not custom the uvd stuff in the catalyst anyway.
<bjsnider> it would be most important to have help decoding h.264, and i seriously doubt an old gpu would help much
<bjsnider> an old system like you undoubtedly have would not be much good for h.264 video
<ripps> any help, no matter how small would be help greatly
<bjsnider> you know what would be a better solution though...
<bjsnider> new equipment
<ripps> Actually, I've been looking at an upgrade soon. And I was planning to get an nvidia geforce gt 240. Mostly because I wanted access to a decent gpu that allowed for hd playback, and vdpau looked appealing.
<ripps> However, seeing how much progress ati gallium is making, I'm kinda of two minds about it.
<bjsnider> that has vdpau feature set c, which means it decodes just about everything
<bjsnider> but hte gt 210 can come without a fan, has the same vdpau features, and makes no noise
<ripps> actually, which is better? gt 240 or fermi 430? Both are bout the same in price, but the gt240 has gddr5, so shouldn't it be faster?
<bjsnider> yeah, although the fermi has a more advanced gpu, with opengl 4
<bjsnider> they both have feature set c
<bjsnider> a more powerful card will be louder, which is a personal pet peeve, and i don't see how you take advantage of the speed on linux
<ripps> it seems fermi is more target toward the htpc crowd, while gt is more focused toward gamers. Now I hardly ever play PC games, but it be nice to know I could If I ever wanted to.
<bjsnider> you can't play them on linux though
<bjsnider> unless you dual-boot it's irrelevant
<ripps> I'm not opposed to dual-booting
<ripps> But, the last time I had a windows partition, I hadn't boot into it in over a year. Then I erased the drive it was on a few months ago, and I haven't found the need to reinstall windows on it yet.
<bjsnider> has that computer got a pci-express slot? it sounds like you've got an agp card now
<ripps> bjsnider: my current computer doesn't, but I got an old mobo and cpu from dad recently, I just need a decent pci-e video card and a cpu fan.
<ripps> my current computer is very old, so I'm looking forward to the new one. Unfortunately, the new cpu isn't that much faster than my current one, it's just 64-bit
<ripps> bjsnider: so, you think I'd like the fermi 430 better because it would produce less heat, and therefore less noise?
<evilvish> lastlog jbs
<evilvish> hmm, is jbs a bot or ..? looks like he isnt active he except for the nickchange spam
<evilvish> active here*
<runeks> hello ubuntu-x
<runeks> how are we today?
<runeks> ok, not a lot happening in here I can see. i'll just let my question linger then: i can see from old IRC logs that the llvmpipe driver was once included in the xorg-edgers PPA, is there any chance it will be that again in the future? i would really like to try it out, but I must admit that compiling mesa (and all the other things necessary) are too much for me right now, so it'd be perfect if xorg-edgers packaged this. any chance
<runeks> of this happening in the future? running the Gallium drivers for my RV670 now BTW, runs *perfectly* (and quicker than mesa classic!). thanks for this awesome PPA!
<shadeslayer> \o
<shadeslayer> http://imagebin.org/133512 is some weird stuff happening with a friends install
<shadeslayer> he has ubuntu 10.10 ...
<shadeslayer> Also bug 702341 << some weird stuff with his synaptics touchpad ( Cross posted from #ubuntu-kernel since i dont know which channel this should go in )
<ubot4> Launchpad bug 702341 in xserver-xorg-input-synaptics (Ubuntu) "synaptics touchpad does not work (affects: 1) (heat: 416)" [Undecided,New] https://launchpad.net/bugs/702341
<evilvish> shadeslayer: did you try kicking the friend? (not the install) 
 * evilvish hides..
<shadeslayer> heh 
<shadeslayer> evilvish: didnt work :P
<shadeslayer> he's new to this ;)
 * evilvish smiles at the scan! and wonders what bollywood has to do with capacitors  ;p
<shadeslayer> lol :
<shadeslayer> evilvish: http://imagebin.org/133511
<shadeslayer> not limited to a particular area
<shadeslayer> and is completely randomn
<shadeslayer> Mobility Radeon HD 5000 Series << Graphics Card
<evilvish> shadeslayer: hey, so your exams are over now?
<shadeslayer> evilvish: yep :)
<shadeslayer> why are you evil? :P
<evilvish> shadeslayer: you use evilslayer too, right? ;)
<shadeslayer> not right now :P
<bjsnider> ripps, it's tough to say. i use a graphics card that has feature set c, no fan, and the speed is fine for me, but i don't do any gaming or anything. it runs the composited desktop admirably. for me, graphics card noise is a huge annoyance. for you, it might not be
<gord> hi all, can anyone confirm that xorg edgers (and the new xorg) work with nvidia? would like to upgrade to do some testing with unity
<Sarvatt> not with the proprietary drivers
<gord> great, will hold off for a while then
<runeks_> is there any chance that the llvmpipe driver will be included in xorg-edgers again any time soon? i can see from IRC logs that it once was.
<runeks> just testing IRC via Empathy
<runeks> seems to work :)
<runeks> i'm off for now. if anyone knows anything about when the llvmpipe driver might be available in xorg edgers PPA, please write an answer here. i'll just look in the IRC logs for the answer, when time permits. good day everyone!
<Sarvatt> bryceh: ugh what a mess in that bug you linked. looks like ati broke userspace and that commit was picked up in 2.6.35 stable?
<Sarvatt> http://cgit.freedesktop.org/mesa/mesa/commit/?h=7.9&id=773e8fadc8b19aaba5d13f75ac5810badb3968c4 (post 7.9.0...)
<bjsnider> if a thin like that is in the stable kernel, that ought to make linus very happy
<Sarvatt> https://bugzilla.kernel.org/show_bug.cgi?id=24802
<Sarvatt> thats.. nasty
<ubot4> bugzilla.kernel.org bug 24802 in Video(DRI - non Intel) "Graphics errors with Radeon KMS driver on RV770" [Normal,New]
<Sarvatt> mesa 7.9.1+ needs that kernel commit to work right, mesa 7.9.0 wont work right with that kernel commit
<bryceh> Sarvatt, yeah ugh
<Sarvatt> what the heck do we do?
<tjaalton> pull the mesa patch, with versioned depends on the kernel? :P
<tjaalton> or drop the kernel commit
<Sarvatt> yeah its dropped, but newer kernels dont work right on maverick without updating mesa somehow now
<Sarvatt> at least its easy to use metacity in maverick (unlike natty) to work around it :)
<bryceh> http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg
<bryceh> 4 new bugs in xorg-server today
<bryceh> 3 of which are apport crash hook bugs
<bryceh> which is interesting because I thought hook was busted... did it suddenly start working again?
<Sarvatt> why pixman all the sudden? hmm
<Sarvatt> wow you're right, haha
<Sarvatt> how the heck did that happen
<bryceh> hmm, I overheard someone else having trouble getting apport to capture crashes, I wonder if something got fixed?
<Sarvatt> doesn't look like its working quite right though, hmm
<bryceh> oh?
<Sarvatt> StacktraceTop:
<Sarvatt>  XISendDeviceHierarchyEvent (flags=0xbfcccf9c)
<Sarvatt>  DisableDevice (dev=0xaaa8e70, sendevent=1 '\001')
<Sarvatt>  ?? ()
<Sarvatt> they're all that
<bryceh> hrm
<bryceh> Sarvatt, speaking of apport, dunno if you noticed this change went in:
<Sarvatt> retracer isn't working right
<bryceh> revno: 1822
<bryceh> committer: Martin Pitt <martin.pitt@canonical.com>
<bryceh> branch nick: trunk
<bryceh> timestamp: Tue 2011-01-11 16:26:12 -0600
<bryceh> message:
<bryceh>   hookutils.py, attach_dmesg(): Do not overwrite already existing dmesg.
<bryceh> I chatted with pitti about our gpu freeze capture troubles last week
<bryceh> problem was when the gpu freeze handler triggers, it *does* capture the dmesg and other stuff
<bryceh> but after rebooting when apport fires up to report the bug, it RE-collected those files, overwriting the ones that had been captured earlier
<bryceh> now it no longer does that
<Sarvatt> http://launchpadlibrarian.net/62489709/ThreadStacktrace.txt vs https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/705078/+attachment/1799814/+files/ThreadStacktrace.txt
<ubot4> Sarvatt: Error: Bug #705078 is private.
<Sarvatt> ahh cool
<Sarvatt> the retraces aren't working for sure, darn
<bryceh> hrm
<bryceh> Sarvatt, yeah you're right, the retracer is attaching something completely unrelated
<bryceh> Sarvatt, I'll email pitti about this
<bryceh> actually I'll file an apport bug
<bryceh> Sarvatt, hmm actually looking closer, all three bugs have the same stack up through #9
<Sarvatt> thats where the real stack starts
<Sarvatt> rest just looks like cleaning up after the crash
<shadeslayer> Sarvatt: sorry to highlight you, but one of my friends has this http://imagebin.org/133511
<shadeslayer> with a radeon 5400...
<bryceh> Sarvatt, ideas on what is in #4-9?
<shadeslayer> any ideas would be helpful :)
<Sarvatt> shadeslayer: I dont see anything wrong there? :)
<shadeslayer> Sarvatt: the weird colors
<shadeslayer> on the profile pic
<shadeslayer> Sarvatt: http://imagebin.org/133511 << 
<shadeslayer> err
<shadeslayer> http://imagebin.org/133512
<bryceh> Sarvatt, bug #705572
<ubot4> Launchpad bug 705572 in apport (Ubuntu) "retracer attaching incomplete backtrace (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/705572
<shadeslayer> Sarvatt: whereas actually : http://imagebin.org/133588
<bryceh> Sarvatt, notice the xorg.0.log.old's are filled with bo map failed: Cannot allocate memory messages
#ubuntu-x 2011-01-21
<ScottK> How well is Mobile IntelÂ® Graphics Media Accelerator 4500MHD supported in Maverick/Natty?
<RAOF> About as well as any other intel card; 2D/3D should work well, but there's not (yet?) any support for the video decoding hardware.
<RAOF> ScottK: Also, how's the KDE bug travelling?
<Amaranth> bryceh: you didn't actually mark the unlockrect bug private
<Amaranth> there we go, launchpad took a few tries but I managed to do so
<bjsnider> RAOF, there is support for the video decoding through vaapi. the vaapi driver is in maverick and natty
<bjsnider> the vaapi code anyway
<bjsnider> but i can't say if it works well or not
<RAOF> bjsnider: Last I saw of it, libva would assert() if you tried it on that card.
<bryceh> Amaranth, hmm still is marked public
<bjsnider> RAOF, with the code in maverick?
<bryceh> gods how I hate working with proprietary companies
<RAOF> bjsnider: With whatever's latest.
<Amaranth> bryceh: ok, so launchpad must have lied to both of us
<Amaranth> bryceh: I can't believe they gave you such a BS list and now want it private though
<bjsnider> RAOF, well, i say give it the old college try anyway
<bryceh> Amaranth, indeed
<Amaranth> Perhaps they don't want people to know they don't even know how their own driver works :)
<bryceh> Amaranth, I wouldn't argue with you on that
<bryceh> Amaranth, so there was nothing useful in that information they gave us, anyway?
<Amaranth> bryceh: nothing at all
<Amaranth> bryceh: We either do what they say they are limited to or have always _not_ done what they say we are limited to so the limits are clearly not true
<Amaranth> I suppose unity may be doing something extra that the list could help sort out but I question the validity of the entire list
<Amaranth> and I've just tried 3 times to mark the bug private, it won't stick
<bryceh> I'm reporting it to launchpad
<Amaranth> perhaps because I'm not subscribed
<Amaranth> the security bit seems to stick
<Amaranth> but even after subscribing explicitly private won't
<bryceh> sheer craziness
<ScottK> RAOF: Seems fine.  I'm having a hard time getting Sylvia to reply to the bugmail though.  I'm on travel now for $WORK.  I'll reply over the weekend if she doesn't.
<RAOF> ScottK: That's ok.  It won't hurt to let the patch can bake for a while in an actual xserver release before foisting it on all of Maverick.
<bryceh> Amaranth, bug #705713
<ubot4> Launchpad bug 705713 in launchpad "Timeout trying to set bug private (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/705713
<RAOF> Damn you, mklib.  Stop foiling my every move!
<bryceh> tired
<RAOF> You are, or I am?
<RAOF> Or, I guess, both :)
<bryceh> well, I definitely am
<bryceh> car battery dead.  I don't drive enough anymore apparently
<RAOF> :)
<tjaalton> bryceh: you still have the same audi?-)
<bryceh> tjaalton, yep
<tjaalton> cool, me too
<bryceh> wife wants me to sell it and get a minivan
<tjaalton> bah
<tjaalton> quattro ftw
<bryceh> to which I say no no no
<RAOF> Too few kids to have a minivan!
<tjaalton> we have three, and the a4 is surprisingly "roomy" for us :)
<tjaalton> though now we'd have to get the middle "seat" in the back to have a three point safety belt installed
<tjaalton> other than that it's been great
<bryceh> yeah we've gotten along fine with just a sedan, although vacation trips are tough due to all the baby crap we have to cart
<bryceh> strollers and highchairs and whatnot
<tjaalton> ah i remembered you had the avant
<tjaalton> you have 2/3 of the backseat to use, luxury :)
<tjaalton> "when I was a kid..."
<bryceh> plus I think half the crap we don't really need
<bryceh> once we forgot the portable highchair.  It was not a problem:
<bryceh> http://www.bryceharrington.org/files/belt_chair.jpg
<RAOF> Awesome.  McGyver baby!
<RAOF> You win again, mesa!
 * RAOF heads to dinner.
<tjaalton> bryceh: heh :)
<alkisg> I have a school lab with intel 845 cards which is unstable with 10.04 and stable with 10.10.
<alkisg> Is there anything that I could update in 10.04 so that I stick to LTS releases for policy reasons? Or the only solution is to upgrade to 10.10?
<tjaalton> it'd probably need newer drm-modules, libdrm and the intel driver (possibly mesa too, if 3d works at all)
<tjaalton> so delicate backporting and it could work
<tjaalton> make a dkms package of the drm modules from .35
<alkisg> Thank you tjaalton, I'll try backporting those
 * alkisg tries https://launchpad.net/~glasen/+archive/intel-driver ...
<tjaalton> yeah there might be a ready ppa already
<tjaalton> -ready
<tjaalton> ..but that's likely not it :)
<alkisg> Oh. I thought it had the newest intel driver + drm there
<seb128> bryceh, here?
<bryceh> yep
#ubuntu-x 2011-01-22
<Sarvatt> nvidia blob compatible with xserver 1.10 in x-updates and edgers now, needs IgnoreABI in ServerFlags though
<bryceh> Sarvatt, sweet
<bryceh> Sarvatt, check this out - http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg
<bryceh> Sarvatt, the black line is total bugs for the equivalent point during maverick
<bryceh> Sarvatt, also I got my sandybridge bits and pieces today :-)
<bryceh>  * Source Package: nvidia-graphics-drivers
<bryceh>  * Version: 270.18-0ubuntu1~xup
<bryceh>  * Architecture: amd64
<bryceh>  * Archive: ubuntu-x-swat-x-updates PPA
<bryceh>  * Component: main
<bryceh>  * State: Failed to build
<bryceh>  * Duration: nine minutes
<bryceh>  * Build Log:
<bryceh> https://launchpad.net/~ubuntu-x-swat/+archive/x-updates/+buildjob/2187790/+files/buildlog_ubuntu-natty-amd64.nvid
<bryceh> ia-graphics-drivers_270.18-0ubuntu1%7Exup_FAILEDTOBUILD.txt.gz
<bryceh> Sarvatt, ^^
<Sarvatt> bryceh: ahhh sorry I got sucked into trying to figuring out how to make synaptics 1.2.99+ usable with this new acceleration stuff that makes it impossible to move the cursor smoothly on any of my machines.. fixing it up now
<Sarvatt> awesome graph!
<Sarvatt> nvidia doesn't work at the moment anyway
<Sarvatt> they based it off xserver master as of december 7th
<Sarvatt> there's a new extension abi since then and their libglx doesn't work, 2D is fine though
<Sarvatt> [  2354.991] (WW) NVIDIA: This driver was compiled against the X.Org server SDK from git commit 780754050bc9cb1489f92a2a890ab5665e3e6358 and may not be compatible with the final version of this SDK.
<bryceh> bleah
<bryceh> well, I closed the bug report requesting it anyway
<bryceh> Sarvatt, how's your workload looking for next week?
<bryceh> it feels like next week is our big move to get all the X stuff in
<Sarvatt> sounds good to me, need to give mesa a few pokes too
<Sarvatt> requested most all the pending syncs a few days ago and left the driver syncs until after the server comes in
<bryceh> raof had thought he'd get mesa in this past week, but not sure it went through
<ricotz> Sarvatt, thanks for 270.18 :-)
#ubuntu-x 2011-01-23
<tjaalton> hmm, sparc is no longer even in ports.u.c, so x-x-v-sun* could be removed from the archive
#ubuntu-x 2012-01-16
<Prf_Jakob> Sarvatt, RAOF, bryce: When will all the new mesa stuff hit the dailies?
<bryce> Prf_Jakob, tues or weds probably
<Prf_Jakob> bryce: cool thanks
<Prf_Jakob> I'm guessing the packages hit the repositories one day ealier
<bryce> Prf_Jakob, we ended up not working on it during the rally
<Prf_Jakob> Ah, I understand its quiet hecktic, so fair enough
<bryce> xserver 1.11 needs to land too
<Prf_Jakob> ah
<bryce> we probably don't want to do them simultaneously; so that may mean delaying mesa a couple extra days
<Prf_Jakob> ah okay
<Prf_Jakob> You will probably need to redo/rebuild the vmware package after mesa/xatracker lands.
<Prf_Jakob> -probably.
<bryce> Prf_Jakob, yeah Unity team had demands that took much of RAOF's time, and I mainly focused on xrandr-utils
<bryce> Prf_Jakob, ok
<tjaalton> hmm, looks like the dejavu sans mono in precise is worse than on oneiric.. 8pix is a lot wider than before, more like 9pix before
<tjaalton> -before
<tjaalton> looks like it affects other fonts too, so something is wrong
#ubuntu-x 2012-01-17
<tjaalton> alioth (git.d.o) down
<mdeslaur> I'm preparing a security fix for CVE-2011-4613 in xorg. Debian fixed the issue by backing out a change that we added for starting X directly from within upstart wihout using a display manager.
<ubot4`> mdeslaur: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4613)
<mdeslaur> Is anyone aware of anything that actually uses that that could get regressions from that update?
<mdeslaur> bryce: ^
<mdeslaur> (fyi, this is the CVE: http://www.debian.org/security/2011/dsa-2364)
<tjaalton> meh, git.d.o is down, can't check what the change was
<jcristau> i'm not, fwiw
<mdeslaur> tjaalton: basically this: http://paste.ubuntu.com/807415/
<mdeslaur> jcristau: hi!
<jcristau> hi mdeslaur 
<mdeslaur> jcristau: I can't seem to locate anybody who remembers the exact reason we had added that change in the first place :P
<jcristau> i talked to lool when i did the revert
<jcristau> he agreed it was the right thing to do
<mdeslaur> yeah, I talked to him too, and he can't recall the exact use case
<jcristau> ok :)
<mdeslaur> I agree it's the right thing to do, I'm just trying to figure out what the use case was that I will be breaking :P
<mdeslaur> all I can think of that wouldn't use a display manager would be some oem project, maybe unity light or something
<tjaalton> that was over three years ago
<tjaalton> well before unity
<tjaalton> ah right
<tjaalton> oem
<mdeslaur> whoops, I meant ubuntu light
<tjaalton> yeah
<lool> mdeslaur: I think this predates ubuntu light, but it might have been in some moblin / maemo / moblin 2 / meego based projects ; albeit I suspect none of them shipped, but ICBW
<lool> it's hard to tell whether some hacks might have been used at a later date or not
<mdeslaur> lool: hi! well, in theory the oem stuff should vet updates before they are pushed, so I'll just put them in -proposed for a week or two and make sure nothing terrible happens
<lool> mdeslaur: I think that's fair
<mdeslaur> lool: thanks
<lool> mdeslaur: Also, I believe OEM is not pulling updates which concern only local root exploits on single-user devices such as netbooks
<mdeslaur> lool: don't say stuff like that, you make me sad :)
<lool> oh sorry
<jcristau> because clearly there's never any code execution flaw in, say, browsers, that would turn a local root into a remote root
 * jcristau hides
<tjaalton> :)
<seb128> tjaalton, libwacom has a new upstream tarball btw if you want to do the update while you fix the copyright and reupload ;-)
<tjaalton> seb128: yeah I noticed that it got rejected
<tjaalton> seb128: are you planning on putting the new g-c-c in precise?
<seb128> tjaalton, no
<seb128> why?
<tjaalton> just wondering why the interest in libwacom :)
<seb128> it helps for those of us who work on GNOME patches and want to build g-c-c from git
<tjaalton> ok
<tjaalton> hmm, can't seem to work out a watch file for it
<seb128> we don't need to jhbuild or do a git build of libwacom
<seb128> just copy any GNOME one?
<seb128> i.e
<seb128> version=3
<seb128> http://ftp.gnome.org/pub/GNOME/sources/libwacom/([\d\.]+[02468])/ \
<seb128>         libwacom-(.*)\.tar\.xz
<seb128> ?
<tjaalton> it's hosted on sourceforge..
<tjaalton> as a subdir on linuxwacom
<seb128> well
<seb128> http://ftp.acc.umu.se/pub/GNOME/sources/libwacom/
<seb128> it's mirrored there then, track the GNOME side?
<tjaalton> .xz
<tjaalton> do we support that yet?
<tjaalton> sourceforge has only .bz2
<seb128> yes, since oneiric at least
<seb128> GNOME does .xz only since this cycle
<tjaalton> ok
<jcristau> tjaalton: "http://sf.net/linuxwacom/ libwacom-(.*)\.tar.gz" doesn't work?
<jcristau> s/gz/bz2/
<tjaalton> nope
<tjaalton> with or without the space :)
<jcristau> hmm. http://qa.debian.org/watch/sf.php/linuxwacom/ has a libwacom tarball, but maybe it's ood
<tjaalton> yeah, it is
<tjaalton> oh well, I'll see what the status is tomorrow, maybe even alioth is up again :)
<tjaalton> ah, is already
<jcristau> yep, came back up a few minutes ago
<tjaalton> that's nice
<tjaalton> seb128: I'll have it done tomorrow, just the copyright left to fix
<seb128> tjaalton, thanks
<bhearsum> i filed a bug about automatic detection not working properly (https://bugs.launchpad.net/ubuntu/+source/gnome-desktop3/+bug/888134) a couple of months ago. i just now figured out that it's a problem with either only with awesomewm, or with all non-unity/gnome ones - i'm not really sure what else to do to try and debug it, or find a fix - is there anyone that can point me in the right direction?
<ubot4`> Launchpad bug 888134 in gnome-desktop3 (Ubuntu) "automatic detection of plugged in / removed monitor is too aggressive (affects: 1) (heat: 6)" [High,Incomplete]
<bryce> mdeslaur, right that's the old mid stuff
<mdeslaur> bryce: ok, so nothing to worry about?
<bryce> mdeslaur, they used to launch ubuntu on those devices using a startx type script rather than a display manager
<bryce> mdeslaur, let me dig up some background info just to fill in all the details but yeah I'm sure that's utterly obsolete by now
<bryce> mdeslaur, http://irclogs.ubuntu.com/2008/09/08/%23ubuntu-devel.txt start around 10:47
<bryce> mdeslaur, that was one of the hacks to get poulsbo working
<mdeslaur> bryce: awesome, old stuff...thanks!
<bryce> mdeslaur, which we no longer maintain in the distro, so I believe it can be killed with fire with no prob.
<mdeslaur> cool
<tjaalton> mdeslaur: for precise, we could just merge xorg
<tjaalton> ?
<mdeslaur> tjaalton: yeah, that sounds good
<tjaalton> mdeslaur: ok, I could prepare that tomorrow if that's fine
<mdeslaur> tjaalton: that wouldbe awesome, thanks!
<tjaalton> hmm actually, I'll check it the staging ppa already has it
<tjaalton> nope
<tjaalton> maybe this should be uploaded there first
<cnd> RAOF, I *think* all the input-related stuff is in ppa:canonical-x/x-staging
<cnd> in the email I sent out, I mentioned having to rebuild utouch-grail, but that isn't the case
<cnd> I also added the breaks clause for xorg-server myself
<cnd> so now it just needs all the other bits that you can upload (and for the build queue to fall down so something will actually build)
<RAOF> cnd: Awesome.
<cnd> RAOF, we may be able to do a syncpackage for libxi and libx11
<cnd> I haven't looked into it
<RAOF> From Debian?  I'll check.
<cnd> the bug there is that we have x11proto-input-dev 2.1.99.4.really.2.0.2-0ubuntu1
<cnd> and most of the debian libs depend on >= 2.1.99.3
<cnd> so if we want to sync with debian, we need to bump the depends in debian :(
<cnd> to x11proto-input-dev >= 2.1.99.5
<cnd> I'm going to switch to upstream synaptics multitouch work now
<RAOF> Cool.
<RAOF> I can take it from here.
<RAOF> Ah, we've even got the Qt in there.
<RAOF> Magnificent.
<RAOF> Heh.  1 package building: qt4, armhf.
<RAOF> I guess that buildd will be ready to do something else tomorrow :)
<bryce> the buildd's seem slow again today
<bryce> (at least for ppas)
<RAOF> armhf is motoring along.
<RAOF> But that would be becuase general PPAs don't get to build on arm :)
<cnd> RAOF, and on top of that, armhf is new and I had to specifically ask for it
<cnd> there's probably only two or three PPAs with armhf turned on :)
<RAOF> Do we need to build for both armel and armhf, or just armhf?
<cnd> RAOF, it's covered in ubuntu-devel, but they aren't sure yet if they want to support armhf or armel for the LTS yet
<cnd> ogra insisted we build for armhf
<RAOF> Yeah, I saw he wanted us to additionally build armhf.  The PPA is only building armhf, though.
<cnd> oh, hrmph
<cnd> let me ping the lp folks again
<RAOF> Ah, there's more to that thread I haven't read yet.
<Sarvatt> cnd: the upload all at once and let depwait fix it really fails in PPAs where we dont have auto retries for depwait, they need manual retries that are automatically at the end of the build queue and scored lower
<Sarvatt> makes lots of sense to upload protos, wait for published, repeat for libs then server then driver
<Sarvatt> s
<Sarvatt> with the bonus that build depends dont matter that way :P
<cnd> Sarvatt, I planned on watching the ppas and retrying :)
<Sarvatt> they go to the end of a 9 hour queue with a retry, at least new uploads are scored a bit higher :(
<Sarvatt> heck maybe we should make the ppa private for a bit, then it'd get like +10000 build score and skip the queues :)
<bryce> heh
<cnd> they were going to make it private, but I didn't like the idea of a private ppa for ubuntu-specific content
<Sarvatt> cnd: this stuff is going to be copied into ubuntu right?
<cnd> yeah
<cnd> RAOF, all the arches should be turned on now
<Sarvatt> xserver-xorg-input-synaptics	 1.5.0+git20120101-1ubuntu1~nomt3
<Sarvatt> ~nomt3?
<cnd> Sarvatt, that ~nomt3 was meant to be temporary, it probably will be whacked off
<cnd> the initial X upload may be without the multitouch on trackpads
<cnd> cause I'm working on that right now :)
<RAOF> I don't mind having a ~nomt upload to the archive.  But given the PPA queue you'll probably have a fair amount of time to work on synaptics MT before it's an issue :)
<Sarvatt> multitouch seems to be working with 1.12 and synaptics from git with debian's debian/
<Sarvatt>     Event code 334 (BTN_TOOL_TRIPLETAP)
<Sarvatt>     Event code 335 (BTN_TOOL_QUADTAP)
 * Sarvatt tries to figure out how to really test it
<cnd> Sarvatt, that's not multitouch :)
<cnd> that's multifinger
<Sarvatt> 4 finger taps were supported before?
<Sarvatt> yeah http://cgit.freedesktop.org/~whot/multitouch agrees on the no multitouch aspect :P
<Sarvatt> RAOF: wow, 2 nights in hotels between flights?
<RAOF> Yup.
<RAOF> It was awesome.
<bryce> RAOF, did they let you have your luggage?
#ubuntu-x 2012-01-18
<RAOF> bryce: In Melbourne, yes.  Not in Heathrow.
<Sarvatt> heathrow is hands down the worst airport i've ever been to.. terminal 5 wasn't as bad as 3 though
<Sarvatt> telling you what gate your flight will be at 30 minutes before the gate closes, and it takes 20 minutes to get to it if you're in the wrong place?
<Sarvatt> then making you take a bus out to the plane and stand in the cold waiting to board on the tarmac
<bryce> I got stuck in chicago once where they didn't let us offload luggage.  Had to scrounge up a change of clothes and toiletries from hotel gift shops.  Ugh.  Was a nice hotel though.
<bryce> ever since, I always carry a change of clothes and toothbrush in my carryon bag
<RAOF> I'm going to consider that.
<RAOF> Particularly since the lounges I've got access to often have shower facilities (the BA/Qantas lounge in Terminal 3 is really nice).
<Sarvatt> bryce: BA gives you toothbrushes :)
<Sarvatt> RAOF: which lounge did you go to in terminal 3? the new one?
<Sarvatt> with a spa and crap
<RAOF> I don't think it's new, but it does indeed have a spa and crap :)
<Sarvatt> there was one that was new for priority pass this year in the back of the book and not with the other heathrow ones, missed that we could use it
<bryce> RAOF, of course after getting all that set up, I've never needed it.  But I figure the one time I don't bring it, I'll get stuck somewhere.
<RAOF> The nice (?) thing about travelling from Australia is that your first flight is always super-long-haul, so it's always worthwhile to change into a new set of clothes at the end of it ;)
<Sarvatt> sounds like me bringing all manner of medicines in case i get sick and i haven't gotten ubuflu since that first trip :)
<RAOF> cnd: You had some autofoo droppings in your xserver-xorg-input-vmmouse upload to ubuntu-x-swat/x-staging.  There's nothing you need to do, this is just a friendly reminder to pay attention to the files dpkg says are modified :)
<cnd> RAOF, I don't remember uploading vmmouse...
<cnd> RAOF, was it just autogen.sh?
<RAOF> cnd: It was a log from a failed configure run.
<cnd> hmm... I wouldn't have ever built that
<cnd> so I don't know where the genesis of that is :)
<RAOF> https://launchpad.net/~ubuntu-x-swat/+archive/x-staging/+sourcepub/2143616/+listing-archive-extra says otherwise :)
<cnd> yeah, I signed it and uploaded
<RAOF> Eh.
<cnd> I probably saw the message, but didn't bother to do anything because it would require a change in the packaging and I was lazy :)
<cnd> oh wait, I did have to change the packaging
<cnd> hmm.. yeah, I should have caught that
<cnd> thanks for pointing it out :)
<cnd> I guess I do need to pay a bit closer attention
<RAOF> You've got core-dev now, right?
<cnd> yep
<RAOF> Looks like utouch-frame needs build-dep loving.
<cnd> hmm?
<cnd> yes, looks like it does
<RAOF> powerpc has tried to build it before libxi and x11proto-input :)
<RAOF> Thanks, PPC.  At least you've done *something* useful in the last year :)
<cnd> argh, second time I hit that today, libxi-dev is in epoch 2...
<RAOF> Looks like libxi also needs inputproto bump?
<RAOF> I can fix these up for you if you like.
<cnd> I fixed utouch-frame
<cnd> I thought libxi was set up properly
<RAOF> failed to build on armhf; it tried to build before x11proto-input again, and didn't dep-wait.
<cnd> ahh yes, it needs to be bumped to depend on 2.1.99.5
<RAOF> https://launchpadlibrarian.net/90309245/buildlog_ubuntu-precise-armhf.libxi_2%3A1.5.99.2-0ubuntu2_FAILEDTOBUILD.txt.gz
<cnd> because of the 2.1.99.4 precise folly
<cnd> RAOF, yeah, if you don't mind, please fix up libxi
<RAOF> Wilco
<cnd> the good news is that because we are building all the arches, we get put into the "real" archive queue
<cnd> so we're not stuck behind all the PPA builds
<cnd> something like that
<RAOF> Pity it doesn't auto-retry dep-waits :)
<cnd> and IS was nice enough to bump the prio on the x11proto-input build, so that's done too
<RAOF> Yeah.
<RAOF> You haven't pushed xi 0ubuntu2 to git?
 * RAOF folds that in.
<Sarvatt> RAOF: did you already merge intel?
<Sarvatt> its not in git so was wondering, experimental or unstable? :)
<Sarvatt> uxa is in maintenance soon to die only important fixes mode in git so experimental disabling sna might be a good idea
<Sarvatt> RAOF: should i get intel merged in git for ubuntu tomorrow is what i'm asking basically :)
<RAOF> Sarvatt: I've merged 2.17; 2.18 isn't released yet, is it?
<Sarvatt> nope but kibi has some git snapshots in experimental and there are only a handful of really conservative changes
<Sarvatt> but if you have 2.17 already done locally that works too
<RAOF> It's not in the ubuntu+1 branch?
<Sarvatt> it was just if we were starting from scratch i was asking which would be preferred
<Sarvatt> i didnt see it, lemme double check..
<RAOF> It's been in the staging PPA forever ;)
<Sarvatt> theres no ubuntu+1 branch
<RAOF> Urgh.  Apparently I didn't push it.
<Sarvatt> ubuntu branch has my changes at HEAD for 2.15.901
<Sarvatt> ah ok
<Sarvatt> why +1 branch?
<RAOF> 2.17 pushed to git.
<RAOF> Because I didn't particularly want to upload it twice :)
<RAOF> And it wasn't clear how long the 1.11 transition was going to take.
<RAOF> Yay!  XServer has almost built!
<Sarvatt> well thats orthogonal to xserver, and yay you had it using origin/ubuntu not a new branch anyway :)
<Sarvatt> thanks for pushing it
<RAOF> Well, it would have needed a rebuild against the newer server.
<RAOF> Ok.  I'm off for lunch and errands.  By the time I get back xserver should be done and I can finish pushing the world to staging.
<Sarvatt> LIBGL_SHOW_FPS=1 is so kick ass, being able to show speed differences between gpus in arbitrary things like webgl in chromium is really handy :)
<Sarvatt> wow, at this rate tomorrow i might be able to put xserver 1.12 in edgers
<Sarvatt> i only had it all prepared on jan 6th :)
<Sarvatt> darn ppa builders have been backed up since then, having upgrades broken for 8+ hours isn't an option this time
<Prf_Jakob> Sarvatt: cool!
<tjaalton> ricotz: I assume you meant GPL-2+ for the libwacom packaging?
<tjaalton> upstream has no mention on GPL on it, weird
<tjaalton> or any other license for that matter
<tjaalton> ah, MIT of course
<tjaalton> ricotz: meh, put GPL-3+ since I had it handy..
<ricotz> tjaalton, hi, yeah please do
<ricotz> tjaalton, i hope you have seen 0.2
<tjaalton> yep
<ricotz> ok
<tjaalton> uploaded
<ricotz> nice, hoping jonathan is happy now ;)
<tjaalton> apparently was
<tjaalton> seb128: libwacom is now in precise
<seb128> tjaalton, I noticed, thanks!
<tjaalton> np
<jcristau> gpl packaging for mit package?
<tjaalton> can't be mixed?
<jcristau> can be mixed, but the result is gpl, so it's a bit weird
<tjaalton> hmm right
<jcristau> (that said for hysterical raisins the x packaging is at least partly gpl, so it's not like there's no precedent)
<tjaalton> well, now that I look at the dep5 page, "permissive" might be an alternative for the packaging..
<tjaalton> ricotz: http://pastebin.com/PfifLp2K ?
<ricotz> tjaalton, it is fine with me
<tjaalton> thanks, I'll commit that change
<tjaalton> hm, source format 1.0 doesn't like .bz2 tarballs?
<tjaalton> yeah
<tjaalton> so it's a native package now, meh
<tjaalton> how hard would it be to include autogen.sh in the tarballs
<bhearsum> chrisccoulson: i just attached my gsd-debug-randr log - i hope it's helpful
<bhearsum> chrisccoulson: i also tried disbling the media keys, like you mentioned yesterday, but that mad eno difference at all
<ricotz> tjaalton, hmm, you changed libwacom to debsrc v1.0 :\
<tjaalton> ricotz: yes, but git has it in 3.0 again
<ricotz> tjaalton, this is really a step backwards
<tjaalton> why?
<ricotz> good
<tjaalton> 3.0 is bad for vcs
<tjaalton> i removed autogen.sh, which isn't in the tarball
<ricotz> i am prefering to use the proper upstream tarball
<tjaalton> it is the upstream tarball
<ricotz> tjaalton, i am fine with using pristinetar though
<ricotz> ok
<tjaalton> with 1.0 you have the diff in diff.gz
<ricotz> i only saw the ubuntu upload so far
<tjaalton> with 3.0 in separate patch blob
<ricotz> i know the difference between them
<tjaalton> and basically, if you have other patches you're screwed
<tjaalton> after working with several packages in git I realize why 3.0 is making people crazy..
<ricotz> hmm, works for e
<ricotz> `me
<hallyn> to switch from nvidia to vesa, can i just add 'Driver: vesa' to xorg.conf (from rescue boot)?
<hallyn> (i'll try in a min, but if it fails it'll take me 15 mins to reboot from livecd, so thought i'd ask first)
<hallyn> all right, off to go try
<tseliot> tjaalton: are we aiming for mesa 7.12 for precise?
<tjaalton> tseliot: it's 8.0
<tjaalton> and yes
<tseliot> tjaalton: thanks
<cnd> woot, qt4-x11 built for armhf
<cnd> and it only took 14 hours, 57 minutes, 58.2 second
<tjaalton> I've done some work on mesa, but the current debian-experimental branch has lost all the history about debian/, and merging to ubuntu is a huge PITA because of that
<cnd> RAOF, what's going on with xserver-xorg-video-glide?
<cnd> it doesn't seem like it should be arch: any
<RAOF> cnd: I think that's right.  It's just that its build-deps are only satisfiable on amd64 i386 ia64 alpha.
<cnd> so it will perpetually be in dep-wait on arm*?
<RAOF> Yup.
<cnd> ok...
<cnd> that seems wrong to me...
<RAOF> That's how it is in the main archive.
<RAOF> I think that's the expected behaviour for packages with arch-specific dependencies.
<RAOF> Which aren't arch-specific themselves.
<cnd> ok
<cnd> so we're just waiting on qt4-x11 armel
<RAOF> Ah, poor armel :)
<RAOF> Oh!
<RAOF> Thinking of poor armel, that's reminded me that I also need to rebuild some stuff for it.
<RAOF> And do the proprietary drivers, too.
<RAOF> I shall move out to the veranda and do those uploads.
 * cnd wishes he had a veranda, though he wouldn't use it today
<cnd> slush all over the ground here
<bryce> cnd, has it finally gotten wet enough for you?
<cnd> ummm, yeah, you can call off the dogs now :)
<cnd> though I'd probably be fine if it weren't quite so cold and didn't come down as snow/sleet
#ubuntu-x 2012-01-19
<mdeslaur> ARGH: http://seclists.org/oss-sec/2012/q1/191
<RAOF> Win?
<RAOF> mdeslaur: Given that we're preparing to upload a 1.11-based server to Precise I guess that should be considered a blocker? :)
<broder> control-alt-...multiply?
<broder> oh whoa...that's awesome. can we please, please at least keep that in hidden under an xorg.conf option? :)
<RAOF> It looks like it *should* require you to explicitly add those keybindings.
<RAOF> We should at least have prgrabs available.
<Prf_Jakob> If I press reset default in compizconfig-settings-manager I would expect that I would get back what Ubuntu has on install.
<RAOF> I believe the correct rune would be âunity --resetâ
<RAOF> I'm not sure that ccsm's reset button does the right thing.
<Prf_Jakob> RAOF: ah thanks
<Prf_Jakob> If that doesn't work I saved a snapshot just before testing a bunch of old bugs from our internal bugzilla.
<RAOF> :)
<mdeslaur> ROAF: so, xmodmap gives me this: keycode  63 = KP_Multiply XF86ClearGrab KP_Multiply XF86ClearGrab
<mdeslaur> ROAF: that means it's binded, right?
<mdeslaur> was anyone able to reproduce it?
<Prf_Jakob> RAOF: unity --reset seems to do the trick.
<mdeslaur> ah! it's in 1.11
<mdeslaur> ROAF: yes, that would be a blocker for the 1.11 upload :)
<RAOF> mdeslaur: Yes, I think that means it's bound.
<RAOF> Ok.  One more thing added to the 1.11 queue :)
<cnd> RAOF, I think I *might* have an MT version of synaptics tomorrow :)
<RAOF> cnd: Cool!
<cnd> just fyi
<cnd> it seems to be working here, but it's a bunch of spaghetti commits that I need to untangle
<cnd> and then port as patches in a dpkg
<cnd> if nothing bad turns up, I'd rather get this in to the push to precise
<cnd> hopefully I'll be faster than qt4-x11 on armel with a 24 hour head start :)
<RAOF> :)
<RAOF> Ok.
<RAOF> I'm doing some work for DX right now, and then we need to ensure we're not bitten by the security bug mdeslaur pointed out.  Then I think we're ready to do some upgrade testing.
<cnd> RAOF, development releases don't really need to have 0 security bugs :)
<RAOF> cnd: Right, but it would be nice to not have lockscreens be trivially bypassable.
<cnd> psh
<RAOF> And it seems like it should be reasonably easy to fix & verify :)
<cnd> I just realized that the qt patch will need a small fix so MT events from touchpads come through too...
<cnd> I think that fix can wait till after the push though
<cnd> it doesn't cause a crash or anything, it merely doesn't emit any touch events
<RAOF> Yeah, sounds fair enough.
<RAOF> ARGH! GIT SEND EMAIL!
<RAOF> Why is your default behaviour to throw away my message when I mistype the smtp password the first time?
<mdeslaur> RAOF: there's a patch available on the xorg security list
<tjaalton> debian has disabled it in git already
<tjaalton> either works
<jcristau> s/git/sid/ :)
<tjaalton> oh ok :)
<tjaalton> of course
<ricotz> jcristau, hi
<jcristau> ?
<ricotz> jcristau, could you take a look at this http://people.ubuntu.com/~ricotz/g-c-c/
<ricotz> this is suppose to be a libx11 bug
<ricotz> i am not sure who can drag this upstream
<jcristau> what am i supposed to be looking at?
<ricotz> ickle already looked at it and blames libx11 or deeper
<ricotz> jcristau, at the valgrind log
<ricotz> it seems it is using an uninitialized mutex
<ricotz> this is running libx11 1.4.4, but i will try to confirm it with 1.4.99.1
<jcristau> well, look at the source?
<jcristau> shouldn't be hard to find out
<ricotz> right, i was hoping someone with more insights could look at it
<ricotz> which made me pinging you ;)
<jcristau> what's needed is not insight, it's an xlib checkout and vim...
<ricotz> alright, i have both
<jcristau> ricotz: do you call XInitThreads before any other xlib function btw?
<ricotz> jcristau, i dont know
<jcristau> because afaict NewDatabase does _XCreateMutex, which does pthread_mutex_init
<ricotz> but it looks like NULL isnt handled properly here
<jcristau> "here"?
<ricotz> right, but if the creation fail db will be NULL
<ricotz> in NewDatabase
<jcristau> seems unlikely to be your issue
<ricotz> but could be
<ricotz> XrmCombineDatabase handles the null case
<jcristau> http://people.ubuntu.com/~ricotz/g-c-c/gnome-control-center.log says db=0x555555936cc0
<ricotz> hmm, right
<cnd> RAOF, micahg asked that we contact the security team before uploading 1.11
<cnd> I told him you were on top of things
<Prf_Jakob> Who do I need to by a truckload of beer to get a option in ccsm/unity to turn of the menus on top bar?
<Prf_Jakob> buy*
<tjaalton> Prf_Jakob: just deinstall appmenu-gtk & appmenu-gtk3
<tjaalton> and appmenu-qt if you have it
<tjaalton> or edit /etc/X11/Xsession.d/*appmenu*
 * JanC wants menus in the top bar for maximized windows but not for other windows  ;)
<Prf_Jakob> JanC: that be pretty pimp actually.
<JanC> Prf_Jakob: it's mostly about usability for me; for maximized windows it maximizes them more, but for normal windows it doesn't make me travel half around the world to find an application's menu  ;)
<Prf_Jakob> JanC: tell me about it I have 30" monitor.
<JanC> mine is only 22", but still at "Full HD" resolution...
#ubuntu-x 2012-01-20
<cnd> RAOF, will you be following up on the xkeyboard-config security issue?
<RAOF> cnd: Yes.
<cnd> cool
<RAOF> We can fix it without an X patch, just a fixed xkeyboard-config.
<RAOF> (Because the ability to turn on that behaviour is awesome)
<cnd> actually, I needed that functionality last week :)
<RAOF> :)
<cnd> when I hit that bug in the server that was using the wrong timestamps to verify AllowEvents requests
<cnd> silly me, I obviously just needed to hit ctrl+alt+KP_Multiply
<RAOF> :)
<RAOF> I, sadly, don't have a KP_MULTIPLY :(
<cnd> I was going to comment the same, until I glanced over and was reminded how beastly behemoth is
<cnd> sadly, I *did* have KP_Multiply last week, even on the machine I was testing with
<cnd> RAOF, I'd like to upload a version of synaptics with MT
<RAOF> Make it so.
<cnd> my thoughts are to squash all the patches I pushed out to the list today into one big 127_xi22.patch
<cnd> sound good?
<RAOF> Sounds reasonable.  Once those patches are accepted we'll nab a newer upstream snapshot?
<cnd> yeah
<cnd> I don't really know if they'll be accepted in their current form
<cnd> see email 0/6
<cnd> but I think it's the best we're going to get before feature freeze
<RAOF> That's Feb, right?
<cnd> yeah
<cnd> I'm afraid that either this patch set is acceptable, or major synaptics overhaul will be needed
<RAOF> Ah, yeah.  The rebuilding eventcomm thingy.
<cnd> yeah
<cnd> I've asked whot about it a few times in passing this week
<cnd> he seems too busy to think about it much
<cnd> so I just pushed out what I've got
<RAOF> Yeah, I've seen that.
<cnd> RAOF, we really should send a patch upstream to make xtst usage optional at configure time for syndaemon
<cnd> it's annoying having to install, remove, install, remove libxtst-dev
<cnd> each time I switch between building synaptics and anything else
<RAOF> That sounds good.  You can't chroot it, though?
<RAOF> I mean, do all your test-builds in the source tree, with libxtst-dev installed, and then build packages in an schroot.
<cnd> building in chroots is so much slower :)
<cnd> argh, bash keeps segfaulting on me in precise
<cnd> make check in utouch-frame and xserver-xorg-input-synaptics results in:
<cnd> /bin/sh: line 5: 12477 Segmentation fault      (core dumped) ${dir}$tst
<RAOF> Build on tmpfs, with a local mirror.  It's not *that* much slower :)
<RAOF> Except the first time, when it's populating the cache.
<cnd> that's too fancy for me
<cnd> the more it takes for me to set things up, the less likely it is I'll remember when my hard drive dies
 * RAOF should really clean up his sbuild config for that and submit it as a patch upstream.
<cnd> ok, new xorg-server and xserver-xorg-input-synaptics are uploaded with MT support for trackpads
<RAOF> Woot!
<cnd> RAOF, do you want to organize some last minute smoke testing after they finish building?
<cnd> the synaptics stuff is all brand spankin' new
<RAOF> Yes, please.  That would be swanky.
<cnd> I'll send an email to ubuntu-devel and ubuntu-x
<RAOF> Mmmm, segfaults in the testsuite.
<cnd> on the buildds too...
<cnd> wow, the archive buildds are fast
<cnd> xorg-server is already done for amd64 and i386
<RAOF> They're like 18 core super awesomes.
<RAOF> Dear server-side XCB.  Why don't you exist?
<bryce> sarvatt was saying the reason the buildds were unavailable to ppas was the result of a glitch in a script failing to reassign them back to ppa duty, that has been fixed now
<cnd> I'm noting also that it took the buildds 5 minutes, 6.1 seconds to build xorg-server on amd64
<cnd> including the udeb
<cnd> that's way faster than I remember them building on any buildd
 * cnd wonders if they turned on DEB_BUILD_OPTIONS="parallel=<n>"
<RAOF> I'm pretty sure they do.
<cnd> downgrading bash to oneiric doesn't fix things...
<RAOF> I don't think it's bash segfaulting; I think it's your test segfaulting.
<RAOF> cnd: I'm pretty sure that's an artefact of the way autotools runs the tests; when they segfault, they look like that.
<cnd> hmm
<RAOF> Man, wouldn't it be awesome if we had developer tools that didn't occasionally lock up? :/
<cnd> ahh yes, eventcomm-test is segfaulting
<cnd> let's see what's wrong
<cnd> I guess I have a bug in my utouch-frame testsuite too :)
<cnd> I see the issue
<cnd> things should be all better now
<cnd> RAOF, when do you think the xkeyboard-config issue will be fixed?
<cnd> I'm writing up the email to the lists for smoke testing
<cnd> if it'll be fixed in a jiffy, I'll not mention it so as not to cause confusion
<cnd> but if not, then I'll leave a note about it
<RAOF> It should be fixed in a jiffy, I think.
<cnd> ok, my definition of jiffy is in the next couple hours
<cnd> do we have the same definition :)
<cnd> ?
<RAOF> Yes
<cnd> cool
 * cnd would love to hold you to the kernel definition of a jiffy
<cnd> oh, too late...
<cnd> I decided to be safe and mention the security hole
<cnd> ok, I'm out of here
<cnd> leaving on a high note :)
<RAOF> :)
<cnd> see you all tomorrow, unless you're one of those weirdos on the other side of the dateline :)
<RAOF> Ah.  1pm.
<RAOF> So *that's* why I'm hungry!
<cnd> RAOF, I just noticed your wacom upload
<cnd> was it straightforward to fix?
<RAOF> Yeah.
<RAOF> It was just a matter of convincing wacom that input abi 15 didn't mean the options abi was available.
<RAOF> You'll see the diff is pretty small.
<RAOF> Of course, I don't *have* a wacom device, so I'm not sure that it actually works âº
<cnd> same here :(
<RAOF> tjaalton: Oh, hey.  You might think that pkg-xorg can push to your xf86-input-wacom repository on alioth, but all the subdirectories of object are missing write permissions for the group.
<tjaalton> RAOF: oh boo
<cnd> tjaalton, I can never figure you out, is it really early in your day, or really late?
<tjaalton> cnd: really early this time :)
<cnd> heh, ok
<tjaalton> RAOF: ok, it's busted then, now I can't change the permissions on objects owned by you :)
<RAOF> I can change those.
<tjaalton> cnd: don't worry, just got here
<RAOF> And now we win!
<RAOF> Well, um, for a while.
<tjaalton> right..
<tjaalton> if only ron would be willing to move -wacom under collab-maint or sth
<tjaalton> or <gasp> pkg-xorg
<tjaalton> RAOF: actually, the faulty bit is the default umask, i think. and that's hard to fix properly
<tjaalton> so that it doesn't mess the other repos
<RAOF> Yup.
<tjaalton> oh and I have wacom
<tjaalton> also, 0.13 is released but I can do that later
<tjaalton> RAOF: is this all going in today or next week?
<tjaalton> I've still the xorg changelog to update and push to staging
<RAOF> tjaalton: Next week, I think.
<tjaalton> yeah
<RAOF> tjaalton: We can get a little smoke testing over the weekend, and push on Monday.
<RAOF> Well, over *my* weekend.  Over other people's Friday :)
<tjaalton> hehe
<tjaalton> is the newest stuff on a private ppa?
<tjaalton> or was that only used for builds
<tjaalton> oh, new emails
<tjaalton> cnd: you didn't mention where the stack is, though I'm assuming it's x-staging still :)
<Sarvatt> tjaalton: whoops, https://launchpad.net/~canonical-x/+archive/x-staging
<tjaalton> aha, not that private, good
<RAOF> It needed to be a canonical-only team to get access to the non-virtualised PPA, but it's public.
<tjaalton> gotcha
<tjaalton> upgraded to current staging, all is well
<RAOF> tjaalton: Are you using an amd64 box?
<RAOF> tjaalton: I suspect that nvidia-{current,173} amd64 in there are broken, because it seems you can't build the source package properly on i386.
<tjaalton> RAOF: yep, intel though
<ricotz> RAOF, good afternoon :)
<ricotz> RAOF, do you mind syncing pixman? https://bugs.launchpad.net/ubuntu/+source/pixman/+bug/918873
<ubot4`> Launchpad bug 918873 in pixman (Ubuntu) "Sync pixman 0.24.2-1 (main) from Debian unstable (main) (affects: 1) (heat: 8)" [Undecided,New]
<tjaalton> i can do that
<tjaalton> done
<ricotz> tjaalton, thanks! :)
<tjaalton> doing the xorg changelog update now, then push it to the staging repo
<Sarvatt> ricotz: ugh, 2 hour queue for openchrome/qxl/mga
<Sarvatt> and geode
<Sarvatt> RAOF: I think you might like anno 2070 btw
<bryce> Sarvatt, ideas on bug #918769?  seen any dell vostro 360's?
<ubot4`> Launchpad bug 918769 in xserver-xorg-video-intel (Ubuntu) "X blink with Vostro 360 and Ubuntu Oneiric and Precise (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/918769
<Sarvatt> bryce: eDP
<bryce> aha
<Sarvatt> if the system has a video input board, it uses an hdmi display internally, if not it uses eDP, that system was a nightmare
<bryce> so disable that in xorg.conf?
<Sarvatt> nawh just saying there were problems, it was only fixed in 3.2
<Sarvatt> will take some digging but i might be able to find the backported fix for 3.0, its not going to be possible to SRU though
<Sarvatt> aka its a HUGE change
<bryce> this guy finds it happens on  3.2.0-9.16-generic-pae 3.2.1 though
<Sarvatt> oh, hmm
<bryce> Sarvatt, did it show the same symptoms?  blinking every 10 seconds (edid polling??)
<Sarvatt> no display wouldn't turn on at all, sorry for not reading it fully :)
<Sarvatt> that has an upstream bug..
<Sarvatt> hold on, finishing up lunch
<bryce> eDP1 is connected
<Prf_Jakob> hows the X server packaging comming along?
<bryce> Prf_Jakob, are you on the ubuntu-x@ mailing list?  there's been some discussion there as to its status
<Prf_Jakob> bryce: hmm no, maybe I should get on there.
<bryce> Prf_Jakob, x-staging is available for smoke testing.  I think there's some builds we're still waiting on but I should expect the upload any day now.
<bryce> Sarvatt, I think this sounds like a good bug to have the guy test a ppa kernel on
<Prf_Jakob> thanks for the info.
<cnd> Prf_Jakob, bryce: https://launchpad.net/~canonical-x/+archive/x-staging/+packages
<cnd> all green checks now
<cnd> for those we expect to build
<cnd> we'll probably push them on monday unless people have blocker issues
<cnd> hmm... looks like xf86-video-msm should build for armhf
<cnd> it's probably not a blocker though
<xrdodrx> Has anyone had success removing the Xorg-Edgers PPA in Oneiric?
<xrdodrx> The page just says that there are issues, but not how one might fix them.
<xrdodrx> Currently when I try to do so apt wants to remove most installed packages
<Prf_Jakob> cnd: ok nice, onto mesa after that?
<cnd> Prf_Jakob, tbh, I don't know anything about the video side of X
<cnd> so I don't know much about mesa, or what you're even asking :)
<Prf_Jakob> cnd: ok fair enough.
<cnd> bryce, Sarvatt, any ideas for Prf_Jakob? ^^
<bryce> xrdodrx, htorque on #ubuntu-kernel ran into that and manually downgraded stuff to resolve it
<bryce> Prf_Jakob, yes on to mesa following that
<Prf_Jakob> Cool, thanks
<xrdodrx> bryce, do you think he'd help me if I asked him which packages he downgraded?
<bryce> xrdodrx, no idea
<Sarvatt> xrdodrx: give it another hour or so and it'll be fixed
<Sarvatt> the message is saying dont upgrade
<bryce> here's what he said:
<Sarvatt> unless you're using proprietary drivers that is
<bryce> <htorque> Sarvatt: thanks, already on it. ppa-purge might not work, but it seems to give me the right order in which i can mark the packages for a downgrade in synaptic. should be done soon. :)
<xrdodrx> well, I can surely wait an hour
<xrdodrx> thanks :)
<bryce> xrdodrx, yep, that's probably easiest
<Sarvatt> xrdodrx: mind pasting the output of apt-get dist-upgrade (don't accept the upgrade, just want to know whats held back)
<Sarvatt> geode openchrome mga and qxl were just finished building and haven't been published yet, that should be the end of it
<Sarvatt> but I might have missed something..
<xrdodrx> Sarvatt, nothing is held back
<xrdodrx> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
<xrdodrx> I re-added the PPA, however
<ricotz> Sarvatt, feel free to go ahead ;)
<Sarvatt> go ahead?
<Sarvatt> looks like apm and rendition were missed
<Sarvatt> xrdodrx: did you apt-get update after adding it again?
<xrdodrx> yes.
<xrdodrx> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
<ricotz> Sarvatt, i mean you can upgrade to 1.12
<Sarvatt> ricotz: i'm still on your 1.12 ppa so cant see what people usually see trying to upgrade
<ricotz> Sarvatt, oh, ok, i thought you arent using it
<Sarvatt> ok apm and rendition uploaded, what else did we miss..
<bryce> poulsbo!
<Sarvatt> oh cool you got fglrx and nvidia-current
<Sarvatt> virtualbox time
<ricotz> right
<ricotz> if it compiles...
<Sarvatt> building it locally first
<xrdodrx> Sarvatt, forgot to mention I'm using Oneiric and accidentally accepted an update a few hours ago to all my packages ;-)
<xrdodrx> dist-upgrade still shows nothing hold back :o
<Sarvatt> xrdodrx: ohhh i'm sorry, the transition is only for precise, nothings been updated in oneiric in a few days
<Sarvatt> except unity thats building right now
<xrdodrx> Right, the only thing that broke here is 3D acceleration.
<xrdodrx> That's why I'm either trying to downgrade or remove Xorg Edgers.
<Sarvatt> sheesh, I'm blind! ok so you want to revert xorg-edgers.. this is going to be rough :)
<xrdodrx> I'd prefer to just downgrade it, I installed it as my Mesa was not working in default Ubuntu (certain 3D acceleration tasks crashed X)
<xrdodrx> (and resulted in a hung GPU)
<Sarvatt> so with edgers sources enabled, run sudo ppa-purge xorg-edgers, dont accept any aptitude solutions (aka press q), you get a list of packages that need to be downgraded
<Sarvatt> well first off, are you on amd64 or i386?
<xrdodrx> amd64
<Sarvatt> its significantly easier on i386 because ppa-purge works :)
<Sarvatt> darn
<Sarvatt> ok
<xrdodrx> i5-2500, video-intel (sandy bridge graphics)
<Sarvatt> you're going to need to downgrade/remove :i386 versions of xorg-edgers stuff
<Sarvatt> easiest way is going to be to apt-get purge the :i386 stuff completely, let it break multiarch
<Sarvatt> break as in remove other :i386 stuff too
<Sarvatt> like it'll remove wine, skype, maybe flash
<xrdodrx> Sarvatt, I shouldn't need :i386 anyway, right?
<Sarvatt> you can always readd it after you're done but it makes it lots more complicated
<xrdodrx> I use the new 64-bit flash
<xrdodrx> and neither wine nor skype
<Sarvatt> can ya pastebin dpkg -l | grep :i386?
<xrdodrx> http://pastebin.com/vpz8uSLT
<xrdodrx> i have skype installed but i never use it as even the beta is very old
<Sarvatt> ok one sec, let me make up a list for you to start out with
<xrdodrx> okay. thank you :)
<Sarvatt> sudo apt-get purge libpciaccess0:i386  libdrm-intel1:i386 libdrm-nouveau1a:i386 libdrm-radeon1:i386 libegl1-mesa:i386 libdrm2:i386 libegl1-mesa-drivers:i386 libffi6:i386 libgbm1:i386 libgl1-mesa-dri:i386 libgl1-mesa-glx:i386 libglapi-mesa:i386 libpixman-1-0:i386 
<Sarvatt> paste what it wants to remove, will tell ya if its ok
<xrdodrx> Sarvatt, There isn't some way I can just downgrade my xorg-edgers packages?
<xrdodrx> like i said, official ubuntu packages were crashing X on certain video accel tasks
<xrdodrx> here's the paste, in any case: http://pastebin.com/Gt9s1w5w
<Sarvatt> downgrade to what?
<Sarvatt> older uploads?
<xrdodrx> Yes.
<Sarvatt> how much older? did it start with something recent?
<xrdodrx> I don't really want to get rid of Xorg-edgers, I enabled it for a reason...
<Sarvatt> launchpad only stores 2 versions :(
<xrdodrx> ouch
<xrdodrx> much more than 2 :(
<Sarvatt> xrdodrx: you may have packages in /var/cache/apt/archives/
<xrdodrx> currently my X works
<xrdodrx> I just don't have video accel.
<Sarvatt> hmm
<xrdodrx> So xfwm4 runs instead of Compiz.
<xrdodrx> And I can't watch video
<Sarvatt> do you see anything in /var/log/Xorg.0.log that stands out? glxinfo?
<Sarvatt> hmm, one question, do you have oneiric-proposed enabled?
<xrdodrx> I don't think so, no.
<Sarvatt> ok just making sure, was a unity update that would have killed edgers today
<Sarvatt> so glxinfo says it's using software rasterizer? can ya paste your /var/log/Xorg.0.log?
<xrdodrx> Sure.
<xrdodrx> http://pastebin.com/nZ0FjjzW
<xrdodrx> ^ Xorg.0.log
<Sarvatt> that looks fine
<xrdodrx> Compiz (opengl) - Fatal: Software rendering detected
<Sarvatt> what about glxinfo output?
<xrdodrx> different than usual, I'll show you
<xrdodrx> usually it says "Tungsten Graphics"
<xrdodrx> http://pastebin.com/K88vfHCq
<Sarvatt> ok LIBGL_DEBUG=verbose glxinfo output now
<xrdodrx> http://pastebin.com/RMz4QRts
<Sarvatt> err pastebin only got the stdout, can you paste the top few lines at the top before the name of display: :0 part here?
<xrdodrx> that's weird, I used a pipe
<xrdodrx> will do manually
<xrdodrx> fredrick@desktop:~$ glxinfo
<xrdodrx> name of display: :0.0
<xrdodrx> There is nothing before name of display...
<Sarvatt> LIBGL_DEBUG=verbose glxinfo
<xrdodrx> $ LIBGL_DEBUG=verbose glxinfo
<xrdodrx> name of display: :0.0
<xrdodrx> yeah.
<xrdodrx> (I knew I had already set LIBGL_DEBUG so I just ran glxinfo again the first time, sorry)
<xrdodrx> Sarvatt, I just killed X and Compiz works again. It seems to not wait long enough on a first boot, or something.
<xrdodrx> Pretty odd...
<xrdodrx> I'm going to attempt another reboot to see if it happens again.
#ubuntu-x 2012-01-21
<broder> if i have a gpu dump from a natty intel machine that triggered the hangcheck, is that something where somebody could tell me quickly if it's already fixed in oneiric/precise?
<broder> (dump is at http://web.mit.edu/broder/Public/xserver-xorg-video-intel.2012-01-21.crash if someone wants to look)
<tjaalton> hm, X crashed, the old'n'stable one. maybe I should upgrade then :)
#ubuntu-x 2012-01-22
<albert23> The x update from the staging ppa brings back bug 901959. Patch 103_fix_uxa_fill_spans.patch seems to be missing from xxv-intel.
<ubot4`> Launchpad bug 901959 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "Clipping in libreoffice welcome screen (affects: 2) (heat: 20)" [Medium,Fix released] https://launchpad.net/bugs/901959
<albert23> Looks like xserver-xorg-video-intel (2:2.15.901-1ubuntu4) was not in git
<Sarvatt> albert23: thanks a ton for the heads up
<Sarvatt> fixed in git, of course now i see git was out of sync with whats in the ppa
<FernandoMiguel> Sarvatt: hey
<FernandoMiguel> any new optimizations for sandy bridge I should be aware?
<Sarvatt> FernandoMiguel: heyo, not that I can think of, maybe drm.vblankoffdelay=1, thats good for ~1.9% power savings according to ckings testing
<Sarvatt> RAOF: great, Rejected: PPA exceeded its size limit (2389.00 of 2048.00 MiB). Ask a question in https://answers.launchpad.net/soyuz/ if you need more space.
<tjaalton> haha
<FernandoMiguel> Sarvatt: where?
<tjaalton> that's canonical-x/staging?
<Sarvatt> yeah
<Sarvatt> FernandoMiguel: /etc/default/grub
<Sarvatt> kernel command line option
<tjaalton> how can it take that much..
<FernandoMiguel> thanks
<Sarvatt> qt it looks like
<tjaalton> ok..
<tjaalton> guess I wont dput xorg then :)
<Sarvatt> asking for more space now
<Sarvatt> hopefully cnd doesn't have another qt upload queued, i'm only asking for 1GB
<Sarvatt> it keeps around the old one when you upload a new one
<Sarvatt> https://answers.launchpad.net/launchpad/+question/185490
<Sarvatt> will ping people monday
<tjaalton> ok
<tjaalton> Sarvatt: what problems does rc6 + vt-d enabled cause? I've had two hangs within a day, thinking if it's related..
<jcristau> tjaalton: hangs.
<tjaalton> ok then :)
<Sarvatt> tjaalton: intel_iommu is disabled completely in 3.2.0-10 if you're on that, probably not it
<tjaalton> Sarvatt: nah, I actually booted -8 now, thought if -9 had something to do with it but doubtful
<Sarvatt> tried -10?
<tjaalton> not yet
<tjaalton> oh, -meta _is_ bumped
<Sarvatt> yeah been using -10 all week
<Sarvatt> ..or not, uploaded thursday
<FernandoMiguel> my love for mplayer is lost !
<FernandoMiguel> Source image dimensions are too high: 4096x2304 (maximum is 2048x2048)
<FernandoMiguel> FATAL: Cannot initialize video driver.
<JanC> what does GStreamer say?  ;)
<FernandoMiguel> vlc complains , but opens
<FernandoMiguel> I think it downgrades the video
#ubuntu-x 2013-01-14
<tion_> how do i change res in ubuntu only vga is available
<tion_> i need xvga+ res
<RAOF> tion_: #ubuntu is the support channel; you'll be better off asking theer.
<mlankhorst> morning
<tseliot> tjaalton: what version and revision of fglrx-updates did you upload in precise-proposed?
<tjaalton> tseliot: fglrx-installer-updates (2:9.000-0ubuntu0.4)
<tjaalton> didn't touch -updates
<tjaalton> since the change was for the backport stack and it doesn't support the video abi?
<tseliot> tjaalton: it should work with Quantal's ABI, shouldn't it?
<tjaalton> not sure anymore
<tjaalton> oh right
<tjaalton> it's that package :)
<tjaalton> -exp-9 confused me
<tjaalton> didn't touch !-updates
<tseliot> tjaalton: oh, as I uploaded fglrx-installer-experimental-9 (2:9.010-0ubuntu0.3) on 7 January
<tseliot> tjaalton: what did you do in the package?
<tjaalton>   * debian/substvars: Drop the versioned dependency on xserver-xorg-core*.
<tjaalton>     (LP: #1080588)
<ubottu> Launchpad bug 1080588 in jockey (Ubuntu Precise) "jockey suggests not installable packages on renamed stack" [High,In progress] https://launchpad.net/bugs/1080588
<tjaalton> same on -exp-9
<tjaalton> 0.3 was uploaded on Nov 21st..
<tjaalton> uh
<tjaalton> -exp-9 0.3 was uploaded Dec 7th
<tjaalton> those should both be in proposed since some time last week
<tjaalton> nope
<tjaalton> sru uploads don't seem to get through
<mlankhorst> :(
<tseliot> tjaalton: but shouldn't it be 9.010 ?
<mlankhorst> going to be a mess for a while, I hope I can get the mesa sru done soon
<tjaalton> tseliot: I touched those two packages
<tjaalton> both at -0u0.4
<tseliot> tjaalton: I'm a bit confused. I uploaded these packages on 7 January (both waiting for approval): fglrx-installer-experimental-9 (2:9.010-0ubuntu0.3) precise-proposed , fglrx-installer-updates (2:9.000-0ubuntu0.3) precise-proposed
<tseliot> tjaalton: I'm wondering why it didn't reject my uploads
<tjaalton> they are both on the queue
<tseliot> ok, I need to make further changes...
<tjaalton> tseliot: you can find my uploads here https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=
<tjaalton> your's too :)
<tjaalton> -'
<tseliot> tjaalton: excellent, thanks
<tjaalton> 0.4 has both of the changes from the new 0.3, cjwatson suggested I should bump the release when I uploaded those
<tjaalton> but I dropped the xserver dependency completely
<tjaalton> it's redundant
<tseliot> tjaalton: not just the versioned dependency?
<tjaalton> http://launchpadlibrarian.net/127494692/fglrx-installer-experimental-9_2%3A9.010-0ubuntu0.1_2%3A9.010-0ubuntu0.4.diff.gz
<tseliot> tjaalton: do you mind if I ask an admin to reject both mine and your uploads of -updates and -experimental so that I can add the optional dependency on the quantal-lts headers?
<tjaalton> sure, and after re-reading the bug, maybe it was unnecessary to drop the dependency..
<tjaalton> feel free to reuse 0.4
<ogra_> is there already an ETS
<ogra_> err
<ogra_> is there already an ETA when we wiull switch ABIs ?
<tjaalton> no
<tjaalton> maybe early feb
<ogra_> (the arm world will fall over once that happens)
<tjaalton> ish
<tjaalton> before feature-freeze most likely
<ogra_> hmm, k, we dont have any updated binary drivers for any of the arm images atm 
<ogra_> and without unity-2d that means no images without drivers
<tjaalton> then fix it ;)
<tseliot> tjaalton: ok
<ogra_> now ? llvmpipe wont be any solution on arm :P
<ogra_> s/now/how/
<tjaalton> tseliot: not sure if slangasek only meant the version part of "need to touch this for the next stack"
<tjaalton> ogra_: get the cluebat and chase vendors
<ogra_> doing that since a while 
<tseliot> tjaalton: I think it's fine to do this for the LTS
<ogra_> though TI is hard to chase since the whole OMAP team was fired
<tjaalton> heh
<tjaalton> tseliot: ok
<mlankhorst> :(
#ubuntu-x 2013-01-15
<mlankhorst> RAOF: fwiw, bug 1086345
<ubottu> bug 1086345 in lightdm (Ubuntu) "Quantal-LTS-stack: Showing low-resolution screen on shutdown/reboot" [Undecided,Confirmed] https://launchpad.net/bugs/1086345
<mlankhorst> exactly as I feared...
<mlankhorst> This won't work unless libdrm gets haswell support. Since the whole reason for doing a libdrm rename was for plymouth to use the old version, can we please drop the libdrm rename and go back to uploading a new libdrm unrenamed?
<mlankhorst> RAOF: ^
<RAOF> mlankhorst: I'll send a mail to ubuntu-release. We might be able to come up with a better plan, but I'll lay out the problem. Specifically - plymouth needs the new libdrm haswell support to work on haswell.
<mlankhorst> ah k
<mlankhorst> fwiw, I always kept that option open, it's not going to be hard to flip the switch on all the lts packages if we decide not to rename libdrm any longer
<tjaalton> Â¤&/" useless totem firefox plugin.. needs to download the video file completely before playing, and playing again of course means downloading the file again..
<mlankhorst> :')
<mlankhorst> yay on rebase tons of patches I needed are no longer needed :)
<mlankhorst> argh, then I hit a lockdep inversion with efifb, but if I disable efifb macbook blows up.. great
<mlankhorst> ok found fix, found another problem exposed by fix.. sigh
<soren> Have any of you guys tried running X in an LXC container?
<mlankhorst> not crazy :)
<soren> Perhaps a more relevant question is: What is the expected success rate of the Raring X stack on a Precise kernel?
<soren> Or Quantal for that matter.
<tjaalton> there's the backport stack in 12.04.2
<tjaalton> and it should work with the older kernel too
<soren> tjaalton: What I'm really trying to do is see the various desktop environments availalble in Raring, without messing up my Precise laptop.
<soren> tjaalton: So a Rarin X stck on Precise doesn't really help me much.
<tjaalton> hmm
 * soren tries something
<mlankhorst> then this is obviously the wrong channel
<soren> It seems to work!
<soren> I was just missing some device nodes in the container, apparently.
<soren> Keyboard and mouse doesn't work, but meh.
<soren> Progress.
<tjaalton> so running raring on a container, using the host xserver?
<soren> No no.
<tjaalton> oh both
<soren> Precise host, raring lxc.
<soren> Running X inside the lxc.
<soren> So the only "precise" part involved is the kernel.
<tjaalton> you need /dev/input/* on the container
<soren> Everything else is raring.
<soren> I have that.
<soren> Not sure why that isn't enough, but I can go digging now.
<tjaalton> ok
<soren> Thanks!
<tjaalton> for what? :)
<soren> Um... For not breaking it? :)
<tjaalton> hehe
<mlankhorst> hmz for some reason DRI_PRIME=1 fps shot up.. not complaining :D
<Mez> Has anyone managed to get a 12.10 box up and running with 3 screens using an nvidia card?
<Mez> unity just falls over if the compositing is disabled.  and if it's enabled - it doesn't work correctly... (invisible windows!)
<mlankhorst> I thought nvidia only supported 2 screens at a time?
<mlankhorst> on 1 card
<Mez> mlankhorst: on one GPU. 
<Mez> mlankhorst: I'm using an nvidia quadro
<mlankhorst> Mez: nvidia drivers? 
<Mez> mlankhorst: yup
<ejat> bug 1099655
<ubottu> bug 1099655 in xserver-xorg-video-nouveau (Ubuntu) "cant login to unity or kde in raring after lightdm" [Undecided,New] https://launchpad.net/bugs/1099655
<ejat> anyone or someone can verify that ? 
<mlankhorst> RAOF: I guess the xorg bug close means the entire lts stack got promoted to -updates? :)
#ubuntu-x 2013-01-16
<RAOF> mlankhorst: Um, no? Although xorg was a prerequisite :)
<popey> just filed bug 1100110
<ubottu> bug 1100110 in xorg (Ubuntu) "can't upgrade xorg package" [Undecided,New] https://launchpad.net/bugs/1100110
<popey> seems a problem with xorg package in precise-proposed
<seb128> popey, please mention it on #ubuntu-release as well
<popey> roger
<RAOF> bryce: I've rejected the xorg-server in the precise queue; could you please upload again, but including the previous changes in the changes file. We need this so that the appropriate bugs get tracked.
<mlankhorst> oh right
<mlankhorst> f
<mlankhorst> oops
<shadeslayer> bwahahaha
<shadeslayer> tjaalton: I think flash is making my GPU do this : [18022.896878] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
<shadeslayer> I was watching a flash video and the GPU just hanged again
<tjaalton> with sna?
<shadeslayer> yes
<tjaalton> can you do a vt change?
<shadeslayer> err ... I already restarted X
<shadeslayer> but I have the i915_error_state file
<shadeslayer> http://paste.ubuntu.com/1537992/
<tjaalton> can you reproduce it?
<shadeslayer> I'll try
<tjaalton> i'll update the driver to 2.20.18
<shadeslayer> ty
<tjaalton> no idea if it helps there
<shadeslayer> well ... I can't reproduce :(
<tjaalton> the error state is similar to 1099394
<shadeslayer> tjaalton: should I upload my error state to that bug?
<tjaalton> shadeslayer: file a new one just to be sure
<tjaalton> did you get the apport dialog about it?
<shadeslayer> nope
<tjaalton> meh
<tjaalton> running kde?
<shadeslayer> yep
<tjaalton> install xdiagnose
<shadeslayer> I already have that
<tjaalton> sigh
<tjaalton> ok
<tjaalton> just leave it then
<shadeslayer> oh okay
<tjaalton> install the new driver and try to break it again :)
<shadeslayer> tjaalton: heh okay :D
<bryce> RAOF, done btw
<RAOF> bryce: And accepted.
#ubuntu-x 2013-01-17
<mlankhorst> wee and mplayer -vo nouveau vdpau bug found :)
<mlankhorst> erm swap nouveau and vdpau there
<bjsnider> mlankhorst, that shouldn't work, unless there's a gallium state tracker for vdpau
<bjsnider> nouveau users should use gl or gl3
<mlankhorst> $ glxinfo | grep -i nouv
<mlankhorst> OpenGL vendor string: nouveau
<mlankhorst> mesa.git even has hw decoding support on some cards
<bjsnider> so, doing a rotation with xrandr on ivb/sna takes down the xserver
<bjsnider> without sna, all is fine
<bjsnider> that was the only serious sna problem i encountered
<tjaalton> bjsnider: oh, filed a bug yet? assign it to me
<ricotz> tjaalton, hi :)
<ricotz> could you take a look at libwacom 0.7 and update?
<tjaalton> ricotz: tomorrow, sure
<ricotz> should be straight forward -- https://launchpad.net/~gnome3-team/+archive/gnome3-staging/+sourcepub/2851075/+listing-archive-extra
<ricotz> tjaalton, thanks!
<tjaalton> when was it released?
<ricotz> mid december i think
<ricotz> libwacom-0.7.tar.bz2 	2012-12-20 	403.5 kB 	30 	210 downloads
<tjaalton> huh
<ricotz> http://sourceforge.net/projects/linuxwacom/files/libwacom/libwacom-0.7.tar.bz2/download
<ricotz> xf86-input-wacom-0.19.0.tar.bz2 	2013-01-03 	528.6 kB 	103 	196 downloads
<ricotz> ;)
<tjaalton> not announced on any of the lists i'm on
<ricotz> don't worry, i hope you like to push them
<tjaalton> yep, sure
<ricotz> thanks you
<bdmurray> tjaalton: I've installed the new synaptics and I'm still having issue with my trackpad
<bjsnider> tjaalton, i was thinking about it but i thought i might wait until raring to see if it's fixed there. this is in quantal
<tjaalton> bdmurray: that's weird, same backtrace on the log?
<tjaalton> bjsnider: ah, good plan
<bdmurray> tjaalton: not exactly
<bdmurray> [    63.776] (--) synaptics: Apple Wireless Trackpad: touchpad found
<bdmurray> (EE) Apple Wireless Trackpad: Read error 19
<bdmurray> [    93.284] (II) config/udev: removing device Apple Wireless Trackpad
<bdmurray> [    93.307] (II) UnloadModule: "synaptics"
<tjaalton> bdmurray: that's a kernel bug then
<tjaalton> the crasher is fixed
<bryce> tjaalton, ah thanks for taking a look at it
<tjaalton> before it crashed trying to log the error :)
<tjaalton> try the kernel from quantal, should work with it
<bryce> did the kernel log anything?  dmesg?
<bdmurray> Jan 17 10:41:58 impulse kernel: [   63.698471] power_supply hid-c8:bc:c8:f9:78:3d-battery: driver failed to report `capacity' property: -5
<bdmurray> perhaps that?
<bryce> hmm, unlikely
<bryce> tjaalton, any debugging options for synaptics or kernel input he could flip on?
<bryce> tjaalton, what was the fix for the X crash?  a particular patch, or a new version?
<tjaalton> bryce: a patch for synaptics to use signal safe logging
<tjaalton> not aware  about any debugging options..
<tjaalton> whot released a new rc for synaptics, many moons late :)
<tjaalton> should've been out with xserver 1.13
<mlankhorst> heya
<mlankhorst> bryce: I've been fixing some vdpau crash bugs in mesa, I think it should be safe to turn on vdpau now
<mlankhorst> at least on master branch
<bryce> mlankhorst, ok
<mlankhorst> might actually be somewhat useful on fermi/kepler
<mlankhorst> surprised internet's finest news source didn't pick up on it yet
<tjaalton> so, sna or no sna? I'd say yes
<tjaalton> could do the switch tomorrow
<mlankhorst> didn't look like it broke that much
<tjaalton> right
<mlankhorst> I think there's no harm in enabling it as a default now, but have to watch out for all the bugs :)
<tjaalton> ickle is monitoring them as well
<tjaalton> occasionally anyway :)
<mlankhorst> I've pushed my old mesa patches upstream now that mplayer vdpau output no longer crashes
<tjaalton> next week might be a good time to push new mesa out for testing, in a ppa first
<mlankhorst> sure
<mlankhorst> updated http://nouveau.freedesktop.org/wiki/NVC0_Firmware
<mlankhorst> if you're feeling daring you could try to make it work
<tjaalton> ooh
<tjaalton> can't remember what my t420s has, but accelration at least is disabled on it by default
<mlankhorst> if you're really really lucky, try git master :P
<mlankhorst> of git
<mlankhorst> erm linux*
<tjaalton> enabling it results in a hang pretty quickly
<tjaalton> ah
<mlankhorst> there has been a hang recently, but nvd9 is still broken for most
<mlankhorst> hang fix*
<mlankhorst> gah.. tired :(
<bryce> tjaalton, yeah the two sna bugs reported were cosmetic.  Make sure upstream knows about those, and go ahead and flip on sna
<tjaalton> bryce: righty-o
<tjaalton> bryce: seen these before? https://launchpadlibrarian.net/128742080/HookError_source_xorg.txt
<bryce> tjaalton, I noticed them the other day.  Guessing the HookError* stuff is new?
<tjaalton> yeah
<bryce> tjaalton, the flaw in question is bad handling of Xorg.0.log when utf characters are in there.  I've actually got that fixed in my xdiagnose branch.  I've just got a couple more tasks (one of which is thorough testing...) before I can upload it.
<bryce> tjaalton, I found that sometimes invalid utf-8 chars can slip in via the parsed edid in the Xorg.0.log, and that breaks python...
<tjaalton> ah :)
<tjaalton> yeah it's not on every bugreport, but some
<bryce> tjaalton, I've set xdiagnose up with test cases and sample Xorg.0.log's.  So if we see HookErrors like this in the future, I can just add the given log to the test suite...
<tjaalton> nice
<bryce> also added a catch-all that if the parser fails, the bug reports still get filed, just without the details parsed from the log.
<bryce> tjaalton, so, maybe you can help with the other task...
<bryce> I am adding an xedid script which does stuff with edid's
<bryce> e.g. it can parse binary edid files into human readable listings, and convert hex edid from Xorg.0.log to binary ones, and so on and so forth
<bryce> when it extracts the edid from an Xorg.0.log, it can save it to a file, and I'm debating what to name that file by default
<bryce> 01.edid seems uncreative
<bryce> I've seen others use 1024x768.edid and similar, so might try that
<bryce> why this is important is because xedid also permits installing edids into the kernel firmware
<bryce> so we may start seeing these files floating around.  would be nice to ensure they have decent filenames by default...
<tjaalton> what's it for, debugging?
<bryce> no, for cases where something has broken the edid, e.g. kvms or adapters or whatnot.  Or replacing the edid if the monitor came with a bad edid
<bryce> it will probably also be useful for debugging but that's secondary
<bryce> hmm, maybe I'll just go with coded manufacturer-productid-serialno for now
<tjaalton> yeah, no strong opinion about those :)
<bryce> alright, now to the testing....
#ubuntu-x 2013-01-18
<tjaalton> bjsnider: rotation seems to work here (on raring)
<tjaalton> ricotz: libwacom & -wacom updated
<tjaalton> wondering about pushing the libwacom update for precise to x-updates..
<ricotz> tjaalton, thanks
<mlankhorst> wondering about starting the x1.14 rebuild
<ricotz> i guess in a ppa?
<mlankhorst> I was hoping for some more commits to the xserver first, I thought there was still an input abi queued as well
<ricotz> right
<ricotz> it would interesting to have it in edgers though
<mlankhorst> I did the port of xorg-server already in the git tree
<ricotz> building xorg-server is least of the work ;)
<mlankhorst> it's the only part requiring thinking, though..
<ricotz> if all driver (upstream) repos caught up, yeah, then it is
<mlankhorst> yeah we are mostly following those repos already
 * mlankhorst tries piglit
<bjsnider> tjaalton, ah, good. i'll check it out myself in a few weeks.
#ubuntu-x 2013-01-19
<bryce> I've uploaded new xdiagnose.  All tests pass and scripts work and bug filing appears to work, to the limit I can test it locally, so I don't expect any problems, but ping me if you spot anything weird this weekend.
<mlankhorst> bryce: wont do anything this weekend, had to spend today dealing with lts stack, looks like I might need to re-enable the shared libgallium patch for mesa due to disk space on iso
<bryce> mlankhorst, good plan taking the weekend off
<mlankhorst> for now plan is to unrename libdrm (uploaded/accepted, rebuilds are pending), fix up plymouth to no longer require intel on arm (sponsored), and maybe re-enable the gallium patch, pending testing :)
<jibel_> bryce, xdiagnose 3.4 is broken on raring bug 1101688
<ubottu> bug 1101688 in xdiagnose (Ubuntu) "xdiagnose 3.4 installation failed with syntax errors" [Critical,Triaged] https://launchpad.net/bugs/1101688
<bryce> jibel_, thanks
 * mlankhorst pokes Sarvatt 
<Azelphur> Hi folks, trying to get Steam running on Ubuntu 12.10, problem is when I install fglrx-updates, or install the latest version of fglrx from the website, Unity doesn't start at all. Ideas?
<mlankhorst> does glxinfo work?
<bryce> mlankhorst, thought you weren't working this weekend?  ;-)
<mlankhorst> blegh I keep irc open for other channels
<bryce> mlankhorst, I'm just teasing ;-)
<bryce> Azelphur, see the topic
<Azelphur> bryce: https://bugs.launchpad.net/fglrx/+bug/1068661 seems there is already an active topic on the subject, https://bugs.launchpad.net/fglrx/+bug/1068661
<ubottu> Ubuntu bug 1068404 in xserver-xorg-video-intel (openSUSE) "duplicate for #1068661 Low graphics mode in muxless hybrid ATI/Intel GPU systems after fglrx upgrade" [Critical,In progress]
<Azelphur> Unless you want me to go break it again and file a new bug?
<Azelphur> Although, I'm not on a hybrid, this is just a standard desktop with a 7770 in it
<bryce> Azelphur, filing a bug also copies up your log files, which people generally need if you're going to ask them for help
<Azelphur> righto, I'll go do that, just get it into the broken state and run ubuntu-bug xorg?
<bryce> Azelphur, besides, it's possible you *don't* have the same bug.  And if you do, having a new set of logs can help confirm that.  Setting two bugs as dupes is cheap and easy for us.
<Azelphur> yea I agree, will get that done for you now :)
<bryce> Azelphur, that's right.
<bryce> update to latest before you do that; I stuck in some bugfixes today for the apport hook.
<Azelphur> ok, just standard Ubuntu 12.10 update?
<bryce> oh, thought you were on raring; nevermind
<Azelphur> nope, pretty normal 12.10 install :)
<Azelphur> bryce: there we go, #1101948 :)
<bryce> [    16.313] (EE) fglrx(0): Fail to init MGPU configuration:0x0!
<bryce> [    16.456] (EE) fglrx(0): atiddxDriScreenInit failed. Probably kernel module missing or incompatible. 
<Azelphur> interesting, that means the problem is in fglrx?
<bryce> yeah kernel module probably failed to build
<Azelphur> fun
<bryce> check your dkms and make.log files for errors
<Azelphur> where are they at?
<bryce> and probably you fscked your system by also installing the drivers from AMD's site.
<Azelphur> well, I only did that after experiencing the issue in the first place, and I built the .deb packages and installed them as instructed on the Ubuntu help pages :)
<Azelphur> so baring in mind I only ever installed / removed the built packages, should be fine?
<bryce> dunno, sometimes packages leave cruft config files and stuff around
 * Azelphur shrugs
<Azelphur> but yea, how do I check dkms and where is make.log? :)
#ubuntu-x 2013-01-20
<bryce> dkms status
<bryce> and /var/lib/dkms/*/*/build/make.log
<Azelphur> dkms status says "fglrx-updates, 9.000: added"
<Azelphur> hmm, /var/lib/dkms/fglrx-updates/9.000/build is empty
<bryce> anyway, probably you should just remove all fglrx and reinstall the driver from scratch
<bryce> https://wiki.ubuntu.com/X/Troubleshooting/VideoDriverDetection#Problem:_Need_to_purge_-fglrx
<bryce> 9 times out of 10 that "fixes" whatever the issue was.
<Azelphur> will try it now, but as I say I got this issue first time installing fglrx-updates on a fresh install
<bryce> doesn't explain why it broke in the first place, but maybe you can reproduce it.
<Azelphur> bryce: followed those instructions, then reinstalled fglrx-updates, same issue :(
<bryce> 1087840 is probably your bug
<Azelphur> fun, I notice that bug report is requesting unity --replace &, so perhaps I'll post that too
<bryce> anyway, enough looking at fglrx.  it's the weekend.  :-D
<Azelphur> tried to do the apport collect and it says that no information was collected
<Azelphur> :(
<Azelphur> Package fglrx-installer-updates not installed and no hook available, ignoring.
<bryce> Azelphur, I doubt that'll show anything useful.  Like I said, needs to have the build errors from dkms or whatever before can really say what the cause is
<Azelphur> yea
<Azelphur> odd that it doesn't even create a log file
<bryce> could be just a kernel incompatibility or some such
<Azelphur> yea, at least there's a bug up, I'll watch it and see what happens
<bryce> hmm, apport-collect should have gathered it, but I bet I need to specifically add that hook.  oh well
<Azelphur> hehe, tyvm for your help anyway, I'll keep an eye on that bug and hopefully it'll be fixed soon
<agrestringere> Got a quick question: Is there www.launchpad.net based list of all the packages that Ubuntu-X team is responsible for?
<agrestringere> Like a huge index style list?
<bryce> yeah - http://www.bryceharrington.org/Arsenal/ubuntu-x-swat/Reports/package-status.html
<tjaalton> he left already :)
<tjaalton> had the patience to wait full 8min
<tjaalton> I also use https://bugs.launchpad.net/~ubuntu-x-swat/+packagebugs from time to time
<tjaalton> as depressing as it is..
<knittl> hello. I have collected plenty of information about my graphics card/monitor configuration but I'm still not able to get it to work. If anybody has a little time to check my bug report? If more info is required, I'll be glad to provide it https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/727112
<ubottu> Ubuntu bug 727112 in nvidia-graphics-drivers (Ubuntu) "nvidia-current does not detect hardware capabilities correctly" [Medium,Incomplete]
<knittl> hummmâ¦ this looks promising: http://www.nvnews.net/vbulletin/showpost.php?p=2039336&postcount=11
<knittl> f*** YEAH! that did the trick \o/
#ubuntu-x 2014-01-13
<jarkko> well i heard that you usually decide about mesa packages, i think you should push a newer version of mesa 
<tjaalton> because the latest upstream release is not enough?
<tjaalton> huh, why does lts-pkg-rename remove patches?
<tjaalton> mlankhorst: ^
<tomreyn> i'm using r300 mesa drivers on ubuntu 13.10 x86_64, and would like to use AMD CodeXL (the artist formerly known as gDEBugger), but it *really* wants to find libOpenCL.so. is there any easy way to get one which it might not make it crash? i don't care about opencl really, just need opengl debugging.
<mlankhorst> morning
<mlankhorst> tjaalton: it should only remove xmir
<mlankhorst> because xmir is not enabled
<mlankhorst> and I don't trust that the !xmir case of the xmir patch is tested well enough :P
<tjaalton> series is reset
<mlankhorst> erm I fixed that
<mlankhorst> what package is affected?
<tjaalton> I'm on revno 530
<tjaalton> -intel
<tjaalton> check ubuntu-saucy
<mlankhorst> ah right, I didn't push it
<tjaalton> also, probably not wise to remove the patch
<tjaalton> but just drop from series
<tjaalton> diff is smaller then
<tjaalton> diff to saucy
<mlankhorst> ok pushed 531, which is what I used
<tjaalton> hmm so if the current backport doesn't have the xmir patch on the diff, then this one won't either
<mlankhorst> yeah, affected were xorg-server, xxv-nouveau/ati/intel. And if you accidentally drop all the patches in xorg-server you're going to have a bad time. ;-)
<tjaalton> yep remember that now :)
<tjaalton> huh, every upload goes via NEW?
<tjaalton> backport upload, even if a version is there already
<mlankhorst> yes
<mlankhorst> except if there is a version in -proposed
<mlankhorst> it doesn't consider -updates
#ubuntu-x 2014-01-14
<jarkko_> guys
<jarkko_> does ati 7870 install normally on ubuntu/kubuntu 13.10 ?
<RAOF> jarkko_: Worked for me when I tried it, although no 3D accel because I didn't do the glamor fiddling (which you shouldn't need to do anymore)
<jarkko_> can i post here or private?
<jarkko_> i removed closed source driver and i have difficulty to use open source
<jarkko_> i had problem getting kubuntu 13.10 working with ati 7870, i think i installed 13.04 1st and upgraded it and installed closed source driver
<jarkko_> RAOF: why glamour is not needed anymore? since when?
<RAOF> jarkko_: Oh, glamor is still needed, it's just enabled by default.
<jarkko_> well how to enable it then?
<jarkko_> there are 2 open source drivers for ati are they both in active developement?
<jarkko_> RAOF: .
<RAOF> There's only one open source driver for ati.
<RAOF> For quite some time :)
<jarkko_> so its radeonhd?
<RAOF> No, it's radeon.
<jarkko_> how to know if its in use?
<RAOF> radeonhd's been abandoned for some time, and IIRC never had 3D support.
<RAOF> Checking out /var/log/Xorg.0.log
<jarkko_> http://pastebin.com/z8hyEpdi
<jarkko_> what should i look there
<RAOF> You need to turn off whatever has disable kernel modesetting.
<jarkko_> i dont know what to do from now on
<RAOF> You said you'd installed the proprietary driver?
<jarkko_> i could reinstall the closed source and system would work and games would have good performance, but i would like to try the open source drivers
<RAOF> How did you uninstall the closed source driver?
<jarkko_> dont remember anymore the command, i googled
<jarkko_> sudo dpkg remove something
<jarkko_> i reinstalled some xorg packages too
<jarkko_> i reconfigured xorg
<jarkko_> but how to avoid that KMS is not disabled and how to enable glamour?
<RAOF> Urgh.
<RAOF> You've probably broken some things in that process.
<jarkko_> possible
<jarkko_> but i had weird problems when i tried to install manjaro and kubuntu distros
<jarkko_> manjaro has option to boot with open source drivers (which end up blank screen), closed source option worked
<jarkko_> i dont remember anymore how 13.10 install went,but i think it had blank screen too
<jarkko> well it does load glamour
<jarkko> but it tries to load the closed source driver too, which is nowhere to be found
<tjaalton> dpkg --purge fglrx
<tjaalton> or what it's called
<tjaalton> the xserver tries to load the blob too, but that's irrelevant
<jarkko> i upgraded the kernel to the latest
<jarkko> system just dont boot into desktop
<jarkko> but the display didnt go saving mode this time
<jarkko> dpkg: warning: ignoring request to remove fglrx which isn't installed
<jarkko> is there going to be soon mesa, xorg, ati updates for ubuntu/kubuntu?
<tjaalton> check /etc/modprobe.d, there's probably a file that blacklists radeon.ko
<tjaalton> what updates?
<tjaalton> install trusty
<jarkko> that file is blank
<tjaalton> what file?
<jarkko>  /etc/modprobe.d
<tjaalton> it's a directory..
<jarkko> lol
<jarkko> which file should i open then?
<tjaalton> look around
<tjaalton> i don't know
<tjaalton> cat /etc/modprobe.d/*|grep radeon ?
<jarkko> i changed your command
<jarkko> but it found one line of blacklist radeon
<jarkko> dont know the file
<jarkko> actually the name is radeonfb
<jarkko> and i know the file now
<tjaalton> that's not it
<jarkko> then there is none
<tjaalton> so pastebin xorg log
<tjaalton> or, check '
<tjaalton> 'dmesg |grep drm'
<jarkko> http://pastebin.com/fqQZyhyH
<jarkko> http://pastebin.com/qE94Y4En
<tjaalton> [    19.057] (II) [KMS] drm report modesetting isn't supported.
<tjaalton> upgrade your kernel
<tjaalton> oh it's 3.13 already
<tjaalton> weird
<jarkko> i just updated
<jarkko> from 3.12.7
<jarkko> any ideas now?
<tjaalton> then #radeon is probably your friend
<jarkko> lol
<jarkko> i will go there
<tjaalton> what's the pci-id?
<tjaalton> of the card
<jarkko> how do i check?
<tjaalton> lspci -nn
<tjaalton> |grep VGA
<tjaalton> 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller [8086:0162] (rev 09)
<tjaalton> so 8086:0162 is mine
<jarkko> found
<jarkko> 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti LE [Radeon HD 7870 XT] [1002:679e]
<jarkko> this is joker card, made by club3d
<jarkko> more shaders than normal 7870
<tjaalton> should be supported
<tjaalton> so I'm out of idea
<tjaalton> s
<jarkko> what should i do?
<tjaalton> #radeon
<jarkko> already there, quiet
<tjaalton> you didn't ask anything
<jarkko> is the glamour automatically used nowadays or what's the situation?
<tjaalton> that's irrelevant here
<tjaalton> but yes
<tjaalton> [    1.597073] [drm] VGACON disable radeon kernel modesetting.
<tjaalton> that's the root of it
<jarkko> what's actually KMS?
<jarkko> setting video modes?
<tjaalton> kernel mode setting
<jarkko> what does it do?
<tjaalton> #ifdef CONFIG_VGA_CONSOLE
<tjaalton> did you mess with some console settings?
<jarkko> no?
<tjaalton> sets the video mode
<tjaalton> dump 'lsmod' somewhere
<tjaalton> and fulll dmesg
<jarkko> http://pastebin.com/PFuKMQ56
<jarkko> http://pastebin.com/sfszFp9i
<tjaalton> meh, so why do you have nomodeset on the kernel cmdline?
<jarkko> i dont know? i havent changed any kernel settings
<tjaalton> is it in /etc/default/grub?
<jarkko> i just installed the kernel from ubuntu kernel ppa
<jarkko> hanvet changed grub either
<tjaalton> just cat that file
<jarkko> http://pastebin.com/Q6356x3A
<tjaalton> oh you booted the recovery kernel
<tjaalton> why?
<jarkko> normal doesnt boot into desktop
<tjaalton> well, that's your bug then
<tjaalton> #radeon
<tjaalton> or, what do you mean by desktop? the login screen loads?
<jarkko> i have no login password, it just somhow hangs
<tjaalton> ok
<jarkko> failsafe resume goes to desktop
<tjaalton> failsafe resume?
<jarkko> yes
<tjaalton> meaning?
<jarkko> there is a menu you can choose what to do
<jarkko> its the 1st:"resume"
<tjaalton> how do you end up there?
<jarkko> from grub
<tjaalton> by using the recovery kernel?
<jarkko> yes
<tjaalton> anyway, if every kernel hangs like that then #radeon might help
<tjaalton> do you have sshd running on it, or can you do a ctrl-alt-f1?
<jarkko> while normal boot i cannot use another session
<jarkko> sshd =?
<tjaalton> openssh-server
<tjaalton> log in remotely from another machine
<jarkko> i have no use such thing
<jarkko> dont know if its installed default
<tjaalton> nope
<jarkko> how to make sure its not installed?
<tjaalton> apt-cache policy openssh-server
<jarkko> i removed some ssh-agent sometime ago, dont remember the name anymore
<jarkko> it says not installed, but it found a package
<tjaalton> sure
<tjaalton> btw, you have radeon.audio=1 on /etc/default/grub
<jarkko> what about it
<jarkko> i have hdmi...
<tjaalton> it could break things
<jarkko> okay
<jarkko> i try to disable then
<tjaalton> remove it, run update-grub and see if it changes anything
<jarkko> done
<jarkko> boot a bit later
<jarkko> trying to complie newer mesa
<tjaalton> are you on 13.10?
<jarkko> yes
<tjaalton> just upgrade to trusty then
<tjaalton> it has 10.0.1
<jarkko> well how do i do that?
<tjaalton> and 3.13
<tjaalton> ask the internets
<tjaalton> do-release-upgrade -d
<jarkko> kubuntu channel said that there are no ppa
<tjaalton> ppa?
<tjaalton> what ppa
<jarkko> where to fetch updates
<tjaalton> for what?
<jarkko> wanted to try 14.04
<tjaalton> aiui kubuntu stuff is in trusty
<tjaalton> not a ppa
<jarkko> your command works btw
<jarkko> some errors on some repos
<jarkko> HUGE UPDATE
<jarkko> over 700 files changed
<jarkko> no, it updated itself again, now over 1000 files
<jarkko> this takes time
<tjaalton> you could also just download a live-cd
<tjaalton> daily image, to see if it boots
<jarkko> would it be possible to change these huge updates that when it has downloaded something, it starts to install if it doesnt need some files that are downloaded later? it takes time to download and then it rapes your hdd when installing, the install would be faster if it could install and download sametime
<tjaalton> not my problem
<jarkko> but thats one thing that could be improved
<jarkko> installs would take less time
<jarkko_> removing the hdmi part didnt work
<tjaalton> ok
<jarkko_> got reply on radeon
<jarkko_> https://bugs.freedesktop.org/show_bug.cgi?id=60879
<ubottu> Freedesktop bug 60879 in Drivers/Gallium/radeonsi "[radeonsi] X11 can't start with acceleration enabled" [Blocker,New]
<mlankhorst> morning
<jarkko_> that should be high priority bug if it effects 7870 (and what else cards)
<tjaalton> hmm, I only saw the comment from mrcooper
<tjaalton> what's up with my irssi..
<jarkko_> but i think i have the same problem than in the link he posted
<jarkko_> the card id matches with he last post someone made
<tjaalton> sure
<tjaalton> file a bug on launchpad against mesa
<jarkko_> how do you know its mesa
<tjaalton> because of the upstream bug..
<jarkko_> i am installing the distro update
<jarkko_> it says that i am missing firmware files...
<jarkko_> they didnt come with the kernel?
<tjaalton> linux-firmware
<jarkko_> well it downloaded that file
<jarkko_> it install now the files and this said that there are more than 1000 files to download
<jarkko_> i already downloaded lot of files
<tjaalton> just let it complete
<tjaalton> it won't help anyway
<tjaalton> since mesa in trusty is just as broken
<jarkko_> well if i make the bug report how do i proof them that mesa is broken?
<tjaalton> "them"?
<jarkko_> who ever makes mesa
<tjaalton> link to the upstream bug
<tjaalton> it's us
<jarkko_> do you have any clue what needs to be changed to get this work?
<tjaalton> no
<tjaalton> it's upstreams job
<jarkko_> can you gimme link where to report?
<tjaalton> run ubuntu-bug
<tjaalton> but if you don't have an account on launchpad, then don't
<jarkko_> i have
<tjaalton> ok
<jarkko_> should i report it as xorg problem or other?
<tjaalton> mesa..
<tjaalton> or xorg, doesn't matter
<tjaalton> ubuntu-bug mesa
<jarkko_> it just collects info and send them?
<tjaalton> yes
<jarkko_> and says nothing?
<tjaalton> opens a browser tab
<tjaalton> where you'll fill in the details
<jarkko_> dont see any open tab
<jarkko_> it didnt open
<tjaalton> nevermind then
<tjaalton> not worth it
<jarkko_> well the update goes well so far
<jarkko_> over 100 000 open bugs...crazy
<jarkko_> i was able to boot after the upgrade, but still had to use the failsave
<jarkko_> sometimes those upgrades are failures
<tjaalton> i said it's not fixed yet
<jarkko_> OpenGL version string: 2.1 Mesa 10.0.1
<jarkko_> it got updated, but the mesa version is very low...
<jarkko_> i mean opengl
<tjaalton> irrelevant
<jarkko_> back to closed driver
<jarkko_> noticed weird problem on boot
<jarkko_> when i press f8, it brings boot menu where to boot
<jarkko_> i have kubuntu and ubuntu there (only kubuntu installed, never ubuntu), only 1 hard disk..only 1 distro
<jarkko_> the 1 entry goes kubuntu and the another goes to grub
#ubuntu-x 2014-01-16
<Dandel> mlankhor1t, Any idea on what will happen now that XvMC is disabled by default in mesa? ( as a hint, it's due to failed unit tests on R300 and R600 gallium drivers )
<RAOF> We'd like to turn on the actually useful acceleration (ie: vdpau).
<Sarvatt> xvmc was never useful, xv and vdpau werent enabled in debian/ubuntu mesa because of the regressions it causes, what?
<RAOF> Oh, what regressions does vdpau support cause?
<RAOF> Applications start trying to use it, and fail?
<Sarvatt> mpeg2 doesnt work on radeon for one
<Sarvatt> if its enabled it tries to use it and just doesn't work
<Sarvatt> i think the next stable 10.x mesa release might fix that at least
<Sarvatt> some playback apps try to use vdpau if its available, trying to watch an mpeg2 video means it wont work
<Sarvatt> aka it broke xbmc playback of recorded tv shows
<Sarvatt> flash uses vdpau if its available too
<Sarvatt> it advertises mpeg2 acceleration but doesnt work
<Sarvatt> 10.0.2 should do shader based decoding on radeon afaik and make it work, not sure its actually been picked up in stable
<RAOF> t
<RAOF> We wouldn't actually be installing the vdpau libs by default though, would we?
<RAOF> That'd be opt-in breakage :)
<RAOF> Another option would seem to be patching out the "yah, I support mpeg2" bit.
<Sarvatt> 14.04 will for sure have it, but mesa 10.x wasnt good enough imo
<Sarvatt> 10.0.x rather
<Sarvatt> i guess thats true, it could be opt in
<jarkko_> i had 13.10 and not much happened there, but now i upgraded into 14.04 and i get lots of updates...
<jarkko_> there was quite a lot some appamor skipping while installing/updating system
<tjaalton> jarkko_: feel free to reinstall 13.10 if you don't like that. 14.04 isn't released yet so yes you get daily updates until late april or so..
<jarkko_> daily updates?
<jarkko_> someone must be busy then
<jarkko_> i dont see any change in this
<jarkko_> boot time could be better
<tjaalton> well we tried to see if mesa 10 fixed radeon for you, then while it was updating you got the upstream bug report saying it's still broken
<tjaalton> so if you like a quiet distro with fglrx, stick to 13.10
<jarkko_> i am not going to switch back
<jarkko_> no reason
<jarkko_> installing closed source drivers this boots normally again
<tjaalton> yes but they'll break soon :)
<jarkko_> ?
<jarkko_> what do you mean
<tjaalton> the xserver will be updated and we don't have working fglrx for it just yet
<tjaalton> but you can just not blindly update and wait until it's settled
<jarkko_> to the newest x.org?
<tjaalton> yes
<jarkko_> would think that ati releases new drivers soon which has a newer kernel support or newer xorg support
<jarkko_> there is something broken in this style of coding, if the api changes from every release that ati doesnt work
<tjaalton> it was released last month, they're just slow
<jarkko_> do you know when xorg is going to pushed?
<tjaalton> maybe next week
<jarkko_> what's new in latest xorg?
<mlankhor1t> Dandel: not pretty much everything said above, if you want to enable vdpau you can build yourself :p
#ubuntu-x 2014-01-17
 * apw has some really bad tearing in chromium/u-tube video playing, on a gm45 ... known?
<tjaalton> new?
<tjaalton> my gen4 is still in saucy I think, and flash works great there
<tjaalton> hum, unless youtube uses html5 video? don't think it should matter on these though
<apw> tjaalton, yeah i upgraded it from S to T today, sick of the "little squares of doom" we had there
<tjaalton> i'm getting hung sessions with flash on T
<tjaalton> or my wife is
<tjaalton> on snb
<tjaalton> don't see a bug filed about the tearing yet
<tjaalton> upgrading mine to trusty
<Sarvatt> "sna/gen4: Sacrifice performance to workaround render corruption" gutted its speed right before 2.99.907 to fix the "little squares of doom"
<tjaalton> well, fullscreen flash seems to work just fine here
<tjaalton> i'll try with chromium
<tjaalton> that's just as fine
<tjaalton> apw: so, working here :/
<apw> tjaalton, welll sheee
<Sarvatt> apw: shot in the dark but there were a bunch of gen4 changes post 2.99.907, might be worth giving https://launchpad.net/~xorg-edgers/+archive/ppa/+sourcepub/3830735/+listing-archive-extra a shot and if not filing a bug against x-x-v-intel, the driver dev actually triages the bugs there :P
<apw> tjaalton, so this wasn't full screen, it was tearing in just a small window
<apw> heh thanks will try and get to it soon
<tjaalton> well, playing both at the same time non-fullscreen and still no tearing
<Sarvatt> there's a tearfree xorg.conf option if you just want to work around it
<Sarvatt> ala http://paste.ubuntu.com/6768874/
<apw> tjaalton, i will note i have two displays, and that this was on the external one on hdmi
<tjaalton> ok
<apw> tjaalton, and it is just fine full screen ... it is unhappy only when small ... most odd
<tjaalton> hdmi on such an old machine?
<apw> one of the first, this puppy is over 5 years old
<tjaalton> mine has just vga
<tjaalton> k, will hook it up with the telly
<apw> tjaalton, though i just ripped the external out and it still is the same
<tjaalton> worked fine with the tv plugged
<Dandel> tjaalton, apw and mlankhorst is there any chance ubuntu will help with improving/updating vogl once it's released? 
<mlankhorst> no idea what vogl is
<Dandel> OpenGL Debugger
<mlankhorst> probably not, but I'll package it
<Dandel> http://richg42.blogspot.com.br/2014/01/vogl-opengl-tracerdebugger-bonus-content.html?showComment=1389950449081#c343074267754586249 - long link, but it'll be released as 100% open source
<jarkko> Valve's VOGL Debugger To Be Completely Open-Source
<mlankhorst> oh phoronix
<Dandel> It's something that probably should be included ( and updated regularly, like the opengl headers )
<mlankhorst> put it in debian sid, and we'll pull it in ubuntu automatically ;)
<Dandel> mlankhorst, I expect that, and similarly there is now a reference compiler for GLSL ( lunar glass )
#ubuntu-x 2014-01-18
<Sarvatt> apw: crap, missed your pings yesterday, no it wasn't me you talked to
<Sarvatt> i'm sure x-x-v-intel 2.99.907 "fixed" your corruption problem by neutering the speed of your gpu
<Sarvatt> that was http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=9289e2c56b7f0cc78c5123691ad96611f0e04bed
<Sarvatt> the upstream bug looks like they have no clue how to fix it under SNA, https://bugs.freedesktop.org/show_bug.cgi?id=55500
<ubottu> Freedesktop bug 55500 in Driver/intel "[sna gen4 w/a] corrupt rendering (including wrong rendering of characters and flickering on redraw)" [Normal,Assigned]
<Sarvatt> SNA can be disabled on a per GPU generation basis at compile time, worst case disabling it on gen4 might be in order for the lts :)
<Sarvatt> but really if you can file a bug about it the upstream intel driver dev (ickle) triages all the intel bugs on launchpad and will see it
#ubuntu-x 2015-01-13
<RAOF> mlankhorst: Hm. xserver-xorg-video-qxl appears to be a fake-native package?
#ubuntu-x 2015-01-14
<RAOF> mlankhorst: I think your lts-rename scripts are failing a bit - mesa has a bunch of packages with empty Conflicts: / Replaces: (libgbm, for example).
<RAOF> mlankhorst: Breaks on libgl1-mesa-dri-lts-utopic are incorrect - breaking xserver-xorg-core-lts-utopic (<< 2:1.14.3-5) won't match anything; that should break the unrenamed package. Likewise, libgl1-mesa-glx-lts-utopic (<< 7.10.2-4) is unlikely to happen; this could just be dropped, as that's a pre-precise version.
<RAOF> Otherwise, mesa looks sensible.
<RAOF> mlankhorst: Hm:
<RAOF> -Homepage: https://github.com/BlueDragonX/xf86-input-mtrack
<RAOF> +Homepage: https://github.com/BlueDragonX/xf86-input-mtrack-lts-utopic
<RAOF> You *might* want to sanity check your changes before uploading. :P
<RAOF> omap's ok.
<RAOF> I'd expect the Conflicts on xserver-xorg-lts-utopic to be Breaks instead; is the use of Conflicts based on previous experience?
<RAOF> xorg looks otherwise sensible.
<RAOF> You appear to have uploaded vivid's xserver-xorg-input-mouse?
<ricotz> tjaalton, hi, i think you missed some mesa packaging bits
<tjaalton> ricotz: where?
<ricotz> in rules grep for gbm_gallium_drm.so and libopenvg1-mesa
<tjaalton> gbm_gallium_drm.so matches, libopenvg1-mesa not
<ricotz> http://anonscm.debian.org/cgit/pkg-xorg/lib/mesa.git/tree/debian/rules?h=ubuntu#n285
<ricotz> http://anonscm.debian.org/cgit/pkg-xorg/lib/mesa.git/tree/debian/rules?h=ubuntu#n289
<tjaalton> I'm checking against debian-experimental
<tjaalton> if there's ubuntu diff then that's too bad
<ricotz> i see, then you messed up the merge ;)
<tjaalton> and will be dropped of course
<tjaalton> ricotz: debian doesn't have that for-loop for dh_makeshlibs
<tjaalton> so having libopenvg1-mesa there is just ubuntu diff
<tjaalton> besides, it's not uploaded yet :)
<ricotz> alright, so consider this a polite pointer ;)
<tjaalton> sure, thanks
<tjaalton> i've built git master locally too, not too many changes needed there
<tjaalton> mesa-opencl-icd is empty now
<tjaalton> some missing build-dep
<ricotz> yeah just doing an edgers upload
<tjaalton> but that's pretty much it
<tjaalton> hmm opencl being empty was a merge fail again
<tjaalton> guess I'll get it right this time
<ricotz> tjaalton, you dropped the opencl confflags
<ricotz> but how can it be empty for you? it should not build at all due --fail-missing
<tjaalton> what I pushed was wrong
<tjaalton> and just a wip branch
<ricotz> ok, i havent used ubuntu+1 branch but ubuntu
<tjaalton> check ubuntu now
<ricotz> changing fail-missing to list-missing is not ok either
<tjaalton> nope, git push origin was too eager
<tjaalton> should've stashed it instead
<tjaalton> I'll just force it next time
<ricotz> looks ok now
<tjaalton> ricotz: there's another bug in mesa now after egl drivers is gone, I'll fix it in a bit..
<tjaalton> just a heads up that edgers needs another update once it's done
#ubuntu-x 2015-01-15
<mlankhorst> RAOF: do you really get a warning about empty replaces/conflicts?
<RAOF> mlankhorst: I don't get a warning, no. I was checking the diff.
<mlankhorst> is it harmful then? I'd prefer to keep it if conflicts get added in the future
<RAOF> It's slightly harmful in that anyone reading the source package is going to have a WTF moment.
<RAOF> It's not very much effort to remove, right? I don't mean updating the scripts to remove it, I mean just removing it before upload.
<mlankhorst> perhaps but I prefer to keep changes as small as possible :P
<mlankhorst> actually no it's hard..
<mlankhorst> how do you distinguish Conflicts: \n with Conflicts: \n somepackage, some-other-package, etc
<mlankhorst> it has the potential to break other things
#ubuntu-x 2016-01-18
<tjaalton> there, xserver 1.18 pushed to ppa:canonical-x/x-staging.. had to fix xmir first
<mamarley> Cool, thanks!  Are you going to upload the drivers too, or should I recompile those myself for testing?
<tjaalton> i will
#ubuntu-x 2016-01-20
<tjaalton> running 1.18 now, ppa:canonical-x/x-staging has the main drivers built
<mamarley> tjaalton: I have actually been running it since you uploaded evdev and synaptics and haven't had any issues.  Thanks!
<tjaalton> built the rest on your own?
<tjaalton> evdev had a bug
<tjaalton> file conflict with xserver
<mamarley> tjaalton: Nope, my systems have only devices that use evdev and synaptics, and nvidia video cards.  I just removed everything else and --force-conflicted the evdev file.
<tjaalton> ah
<tjaalton> intel defaults to DRI3 there.. ballsy
#ubuntu-x 2016-01-21
<mamarley> ts
<mamarley> oops
<mamarley> tseliot: I added support for the NVIDIA EGL libraries to gpu-manager.c in ubuntu-drivers-common.  It is in ppa:mamarley/staging.  I also tried to add it to prime-select, but I am not a Python programmer and that code befuddled me.
<tseliot> mamarley: actually I'm working on that, and I'm trying to track down a segfault in the new code
<mamarley> Ah, OK, so I guess I wasted my time.  There was just a user complaining about it yesterday, so i figured I would take a stab at it.
<mamarley> Well, at least I can tell him that it is being worked on. :)
<tseliot> mamarley: not necessarily. What code did you based it on?
<tseliot> *base
<tseliot> mamarley: as in, did you use git?
<mamarley> No, sorry.
<tseliot> mamarley: so, no diff
<mamarley> No, not really.  I could take the file I modified and diff it against another one if you wanted though.
<mamarley> One problem I did run into was that the nvidia-xyz-prime/ld.so.conf files only have the path to the mesa GL libs, not the EGL ones, so this may require a modification to the NVIDIA packages as well.
<tseliot> I've just downloaded the sources
<tseliot> mamarley: that is something that we need
<tseliot> mamarley: but aren't the libraries all in the same place?
<mamarley> tseliot: Nope, the GL ones are in /mesa and the EGL ones are in /mesa-egl
<tseliot> mamarley: right, I even added code for that in gpu-manager. Patches for nvidia are welcome, if you have the time
<mamarley> tseliot: You mean patches for the packages in the Ubuntu archives?
<tseliot> mamarley: or for yours. I merged some of the changes from the PPA, and I have them in my local branch, so that might work too
<tseliot> also, the change should be trivial
<mamarley> OK, sure.  Are we doing this only for Xenial?
<tseliot> mamarley: for now
<mamarley> tseliot: OK.  I am a bit busy at the moment but I can upload patched NVIDIA drivers for all the versions for Xenial a little later today.
<tseliot> mamarley: it works for me, thanks
<mamarley> No problem
<tseliot> mamarley: BTW, I might end up adopting your code for gpu-manager. It definitely wasn't a waste. My code, on the other hand... ;)
<mamarley> I was actually surprised at how quickly I was able to get that part working.  I haven't written plain-old C in quite a while, so I was expecting more trouble.
<tseliot> yes, I like simple. I went with a more complex solution, and screwed up at some point
<tseliot> I think I'll simply add the C code that I wrote to make it possible to test the EGL alternatives, and the python code
<mamarley> OK, and I will let you know once I have those patched drivers uploaded.
<tseliot> thanks
<tjaalton> RAOF: did I promise to upload apitrace at some point?
<tjaalton> to debina
<tjaalton> -an
<RAOF> tjaalton: I believe you may have, yes. :P
<tjaalton> hah, so I'll do that now :P
<tjaalton> hmm now that I look at it, the pristine-tar commit shows a different tarball name than the changelog
<tjaalton> changelog has +repack
<tjaalton> RAOF: should it be without +repack?
<RAOF> Hm, let me check.
<RAOF> tjaalton: Bah, pristine-tar should have the +repack.
<tjaalton> ok
<RAOF> Sorry. :)
<tjaalton> so it's the same tarball though, or should have some files filtered out?
<RAOF> It's got the files filtered out, it just has the wrong name.
<tjaalton> ah, ok
<tjaalton> so I'll just rename it
<tjaalton> and maybe import
<RAOF> Yeah. You *can* just rename the files on the pristine-tar branch, but gbp complains wierdly about that.
<tjaalton> heh, first time I've actually checked out a pristine-tar branch..
<tjaalton> was going to just rename the built tarball
<mamarley> tseliot: I have uploaded new versions of all the supported driver versions for Xenial with the Mesa EGL directory in the Prime ld.so.conf to https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages.  346 failed to upload, but that is due to a screwup I made a long time ago while packaging an older driver version.
<mamarley> ricotz: I also uploaded 361.18 again for Wily, Vivid, and Trusty to remove the EGL alternative since those aren't going to get Prime support for EGL.
<tseliot> mamarley: ok, thanks. BTW, I managed to get my gpu-manager code to work. That is well integrated with the test suite, so, I'm going to use that (I appreciate your effort though).
<RAOF> Hm. We should remove the arch qualificatons for the Mir EGL patch.
<RAOF> tjaalton: Mind if I enable Mir in Mesa on aarch64, s390x, powerpc, etc?
<tjaalton> RAOF: nope, go ahead. pushed ubuntu branch too, now that 11.1.1 is in xenial
<RAOF> ???
<RAOF> tjaalton: I do not yet see 11.1.1, apart from on the Ubuntu branch.
<tjaalton> huh
<tjaalton> oh hell, forgot to upload of course
<tjaalton> done
<RAOF> Win!
#ubuntu-x 2016-01-22
<tjaalton> RAOF: well that was quick, apitrace got in sid already
<mamarley> tseliot: Do you have the updated ubuntu-drivers-common and nvidia-prime in a PPA someplace for testing?
<tseliot> mamarley: not yet. I need to try test them on real hardware first
<mamarley> OK
<tseliot> mamarley: also, u-d-c is complete but I haven't looked into nvidia-prime yet. It should be pretty easy though
<RAOF> tjaalton: Yeah. High bandwidth FTP team, apparently!
<tjaalton> RAOF: yup.. push mesa, btw :)
<RAOF> tjaalton: Done, sorry :)
<RAOF> We have reverse problems :)
<tjaalton> yeah :)
<tjaalton> since mlankhorst left I've forgot to push a number of times
<tjaalton> right, btrfs is going out the window once 16.04 is ready with zfs.. so sick of it choking under any kind of i/o
#ubuntu-x 2017-01-16
<soee> mamarley: nvidia drivers work with kernel 4.10rc4 ?
<soee> brb
<ricotz> soee, not without patching
<soee> ricotz: ok, thank you
#ubuntu-x 2017-01-18
<tseliot> ricotz, mamarley: I think you mentioned a few regressions affecting the 375 series. Are they still there?
<mamarley> tseliot: 375.10 caused a number of applications to crash when exiting, which among other things broke the KDE lockscreen, which was fixed in 375.20.  375.20 introduced a new bug that caused issues if one tried to launch too many OpenGL applications or certain games, causing the applications to display nothing but a black screen.  That was fixed in 375.26.
<mamarley> So, no regressions of which I am currently aware.
<tseliot> mamarley: that's good to hear, thanks. I am going to migrate users from 361-367 to 375 (if QA doesn't find any more regressions)
<mamarley> ricotz: soee: https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages
<ricotz> mamarley, oh :)
<ricotz> are you running it already?
<soee> why it is called nvidia-graphics-drivers not nvidia-xxx ?
<mamarley> ricotz: Yep, seems to work fine.
<ricotz> mamarley, will try it out tomorrow
<mamarley> soee: No idea, sorry.
#ubuntu-x 2017-01-19
<soee> did you tried the new beta driver maybe ?
<soee> on laptop with hybrid gpus, i can't activate effects on my desktop ;-)
<mamarley> soee: I tried it, but not on any Optimus systems.  Desktop effects work fine for me.
#ubuntu-x 2017-01-20
<ricotz> mamarley, hi, finally tested 378 and copied it!
<mamarley> :)
#ubuntu-x 2017-01-21
<tomreyn> soee_: you need a bouncer
<soee_> why?
<jcristau> because you keep bouncing :)
<tjaalton> irssi filters ftw
#ubuntu-x 2018-01-17
<mamarley> tseliot: As a heads up, if you go to package 340.106, it still needs the 4.11 patch but all the others can be dropped.
<tseliot> mamarley: ok, thanks
<mamarley> ricotz: 340.106 is ready in https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages (for everything except Bionic, which is already in the main archive).
<ricotz> mamarley, nice, did you took the same tarball? are the ppa-specific kernel-patches still needed?
<mamarley> ricotz: I did it before tseliot, so no.  But I can grab his tarball and reupload mine.  All the patches except the one for 4.11 are dropped.
<ricotz> mamarley, please do so, so it matches the archive
<mamarley> Sure, I will do that in just a minute.
<ricotz> mamarley, better cancel all those pending builds https://launchpad.net/~mamarley/+archive/ubuntu/staging/+builds
<mamarley> ricotz: OK, it is uploaded (in https://launchpad.net/~mamarley/+archive/ubuntu/staging3/+packages this time since the orig.tar.gz is different and it wouldn't let me put it in the normal place).
<ricotz> mamarley, thanks
<tseliot> mamarley: sorry, I didn't check the staging ppa when looking for the tarball, so I didn't use yours
<mamarley> No problem.
#ubuntu-x 2018-01-18
<tjaalton> tseliot: do you know when the nvidia update in bionic will be built on arm?
<tseliot> tjaalton: the builder says "Start in 2 hours"
<tjaalton> armhf builders are offline still
<tjaalton> was wondering if you had contacted lp admins
<tjaalton> I've done that now
<tjaalton> correction, all non-x86 builders are offline
<tseliot> ok, thanks for checking, I had no idea
<tjaalton> it's blocking mesa :)
<tjaalton> I'll upload 17.2.8 to xenial/artful despite that..
<tjaalton> tseliot: building now
<tseliot> tjaalton: great :)
<ricotz> tseliot, hi, https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-340/340.106-0ubuntu1
<tseliot> ricotz: hi, Was that a question?
<ricotz> tseliot, did you made this armhf build get bumped too?
<tseliot> tjaalton: ^
<tjaalton> no, just the one blocking mesa
<ricotz> tjaalton, please do the same for this one
<tjaalton> it
<tjaalton> it
<tjaalton> huh
<tjaalton> it's something only lp admins can do, manually
<tjaalton> poke wgrant then
<ricotz> tseliot, ^
<tseliot> ricotz, tjaalton: done
<ricotz> thanks
#ubuntu-x 2019-01-15
<mamarley> ricotz: 415.27 is ready in the normal place.
<ricotz> mamarley, great :) thank you
<mamarley> No problem
