#ubuntu-x 2007-06-04
<bryce> tepsipakki: do you have an i810 desktop you could test this bug on to confirm it?  https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/103223  
<ubotu> Launchpad bug 103223 in xorg "X incorrectly defaults to using disabled Intel onboard graphics card instead of nVidia FX5500 PCI card" [Undecided,Unconfirmed]  
<tepsipakki> bryce: yes I do, with 965Q
<tepsipakki> ..but no nvidia pci-card :)
<tepsipakki> maybe lspci still shows the card even though it has been disabled in bios?
<tepsipakki> because the scripts use the first capable device it finds
<tepsipakki> he could try running without a conffile and see how the server handles it
<bryce> ah that could be
<tepsipakki> I have the xorg merge ready (for couple of weeks now), should I upload that? It makes use of the new defaults that the server has, ie. Fonts and Modules sections are not needed anymore and not generated on new xorg.conf's
<tepsipakki> also, the new fglrx should work with server 1.3, I asked on #ubuntu-kernel if that could be updated to 8.37.6
<tepsipakki> but maybe it's too late/early for their timezone ;)
<tepsipakki> (=no reply yet)
<bryce> on the xorg merge, yes go ahead
<bryce> I'm planning to look at xauth and xinit tomorrow or Tuesday and getting them merged in, so that'd be good
<bryce> fglrx is another thing high on the todo list, so that's good to hear it works with 1.3
<bryce> I have no idea what's involved with upping restricted-drivers, but I did notice the Ubuntu version is way behind by several revisions
<tepsipakki> we should be able to just sync xauth and xinit from debian experimental
<tepsipakki> since the split packages have passed NEW
<tepsipakki> sorry, xinit is still NEW
<bryce> when do you think they'll get into unstable?
<tepsipakki> when there is agreement over the version numbers :)
<tepsipakki> xinit/xauth have their upstream version, but the bundles are 0.1 now
<tepsipakki> but that could be changed to the katamari version
<bryce> how long do you think that'll take?
<tepsipakki> no idea.. maybe a couple of weeks
<bryce> hmm
<tepsipakki> so not for tribe 1
<tepsipakki> but maybe tribe2
<bryce> I've thought for the blueprint stuff I need to do for the failsafe X stuff, having xinit and xauth (and xorg) all up to date would probably save some potential headaches
<tepsipakki> well, I believe there won't be too many changes to those
<tepsipakki> before they are uploaded to unstable
<bryce> anyway, I'll take a look at merging from experimental.  I haven't done that before
<tepsipakki> the packages should install fine, so a sync request should do
<tepsipakki> for xauth
<tepsipakki> and xinit when it's passed NEW
<bryce> hmm, libx11 1.1.2 is out
<tepsipakki> yep, but maybe worth to wait until it's in debian
<tepsipakki> the xcb-business is pretty unclear still
<bryce> maybe... although you know, we're still waiting on the x apps to come through...
<tepsipakki> you mean apps not failing with xcb?
<bryce> no, that they're not syncing (at least, I haven't seen them via 
<bryce> http://people.ubuntu.com/~bryce/Xorg/versions_current.html
<bryce> ok, I'm falling asleep at the keyboard again.  I'm heading to bed. night!
<tepsipakki> yes, they were in xbase-clients, but now in x11-* which are in experimental
<tepsipakki> yeah, good night
<ubotu> New bug: #99337 in usplash (main) "[feisty]  no german umlauts () on terminal (dup-of: 91422)" [Medium,Confirmed]  https://launchpad.net/bugs/99337
<ubotu> New bug: #115499 in usplash (main) "console fonts are improperly configured (dup-of: 91422)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/115499
<ubotu> New bug: #69559 in usplash (main) "Console displays local characters incorrectly (dup-of: 91422)" [Undecided,Confirmed]  https://launchpad.net/bugs/69559
<ubotu> New bug: #87031 in usplash (main) "Fonts do not get set when one boots using usplash (dup-of: 91422)" [Undecided,Confirmed]  https://launchpad.net/bugs/87031
<ubotu> New bug: #107295 in usplash (main) "console fonts look weird after the latest update (feisty) (dup-of: 91422)" [High,Confirmed]  https://launchpad.net/bugs/107295
<jcristau> hmm, usplash bugs get here too?
<ubotu> New bug: #92031 in usplash (main) "Wrong Latin2 characters on tty1-tty6 consoles. (dup-of: 91422)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92031
<ubotu> New bug: #58016 in xorg (main) "Edgy choice of UK Dead Keys Layout in Gnome" [Low,Fix released]  https://launchpad.net/bugs/58016
<ubotu> New bug: #26552 in xorg (main) "Dutch keyboard layout doesn't work in Breezy" [Medium,Fix released]  https://launchpad.net/bugs/26552
<ubotu> New bug: #27509 in xorg (main) "Wrong keyboard layout used in X" [Medium,Fix released]  https://launchpad.net/bugs/27509
<ubotu> New bug: #30489 in xorg (main) "X.org don't detect my monitor refresh rates (on dapper flight 3 live cd)" [Medium,Fix released]  https://launchpad.net/bugs/30489
<ubotu> New bug: #31827 in xorg (main) "Scrolling fast with the mousewheel triggers history back and forth" [High,Fix released]  https://launchpad.net/bugs/31827
<ubotu> New bug: #34627 in xorg (main) "french canadian layout incorrect?" [Medium,Fix released]  https://launchpad.net/bugs/34627
<ubotu> New bug: #39570 in xorg (main) "Regression: X stuck at 640*480" [High,Fix released]  https://launchpad.net/bugs/39570
<ubotu> New bug: #42800 in xorg (main) ""et" keyboard layout is actually "us"" [Medium,Fix released]  https://launchpad.net/bugs/42800
<ubotu> New bug: #43598 in xorg (main) "Croatian (Hrvatski) keyboard layout is broken" [Medium,Fix released]  https://launchpad.net/bugs/43598
* Starting logfile irclogs/ubuntu-x.log
<ubotu> New bug: #27442 in xserver-xorg-driver-mga (main) "mga dri "Failed to map DMA buffers list"" [Medium,Fix released]  https://launchpad.net/bugs/27442
<ubotu> New bug: #118635 in xserver-xorg-video-i810 (main) "Top rows of screen botched on Toshiba Libretto U105" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118635
<ubotu> New bug: #118661 in xorg (main) "[gutsy]  xserver-xorg (1:7.2-3ubuntu1) configure error" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118661
<bryce> tepsipakki: still about?
<tepsipakki> bryce: what's up?
<ubotu> New bug: #23902 in linux-restricted-modules-2.6.15 (restricted) "Fglrx driver is broken with Ati Radeon 9200 SE." [Medium,Unconfirmed]  https://launchpad.net/bugs/23902
<ubotu> New bug: #51498 in linux-restricted-modules-2.6.17 (restricted) "fglrx: booting on battery - acpi fails to set low power" [Low,Needs info]  https://launchpad.net/bugs/51498
<ubotu> New bug: #52084 in linux-restricted-modules-2.6.15 (restricted) "GDM logout or restart gives me a blank screen" [Medium,Needs info]  https://launchpad.net/bugs/52084
<ubotu> New bug: #118681 in xresprobe (main) "resolution on monitor is wrong. Set to 1024x768, should be 1280x960" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118681
<ubotu> New bug: #25927 in xserver-xorg-input-synaptics (main) "Tapping on touchpad does not work anymore in MS Win XP after using Live CD" [Medium,Rejected]  https://launchpad.net/bugs/25927
<jcristau> heh, nice one
<bryce> yeah hehe
<ubotu> New bug: #44001 in Ubuntu "Using nVidia driver causes Xorg to not start after upgrade from 5.1 to 6.06 flight 7" [Medium,Rejected]  https://launchpad.net/bugs/44001
<ubotu> New bug: #34405 in linux-restricted-modules-2.6.15 (restricted) "Broken nvidia-glx-legacy-7174+2.6.15.7-1_386.deb" [Medium,Rejected]  https://launchpad.net/bugs/34405
#ubuntu-x 2007-06-05
* Starting logfile irclogs/ubuntu-x.log
<tepsipakki> bryce: aren't xorg-docs and xorg-sgml-doctools syncable?
<bryce> tepsipakki: what do you mean?
<tepsipakki> they are at -2 in debian
<tepsipakki> same upstream
<bryce> yes, they could be sync'd
<bryce> I don't know if the changes are really that significant though, but wouldn't hurt to sync them
<bryce> anyway, g'night!
<tepsipakki> yeah, night!
<ubotu> New bug: #118667 in xorg (main) "xorg consumes a huge amount of memory" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118667
<ubotu> New bug: #118798 in xserver-xorg-video-ati (main) "X crashes when simultaneous rendering is triggered" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118798
<ubotu> New bug: #17908 in xserver-xorg-video-s3 (main) "[s3]  breaks vga16fb after server start" [Medium,Rejected]  https://launchpad.net/bugs/17908
<ubotu> New bug: #35627 in xserver-xorg-video-ati (main) "dual video (radeon+voodoo) is broken" [Medium,Needs info]  https://launchpad.net/bugs/35627
<ubotu> New bug: #47925 in xorg-server (main) "Synaptics touchpad not configured in xorg.conf on Samsung X20 (dup-of: 40503)" [Medium,Needs info]  https://launchpad.net/bugs/47925
<ubotu> New bug: #118848 in xorg (main) "Video not detected on Lenovo T60P WS" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118848
<ubotu> New bug: #118852 in xrandr (main) "please make a -dbgsym package for Feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118852
<ubotu> New bug: #45881 in xresprobe (main) "The refresh rates for my monitor were not set during install" [Medium,Rejected]  https://launchpad.net/bugs/45881
#ubuntu-x 2007-06-06
<ubotu> New bug: #107805 in xorg (main) "Thinkpad T60p ati 5250 video card not "completly" detected; result is powerstate not lowered when on battery power" [Undecided,Confirmed]  https://launchpad.net/bugs/107805
<ubotu> New bug: #21416 in xserver-xorg-video-via (main) "KN400: Blank / black screen when switching to text consoles" [Medium,Needs info]  https://launchpad.net/bugs/21416
<ubotu> New bug: #51964 in xserver-xorg-input-mouse (main) "Upgrading to 1.0.3.1 cause Gnome's panel and taskbar to disappear (PPC)" [Medium,Needs info]  https://launchpad.net/bugs/51964
<ubotu> New bug: #52288 in xorg (main) "Extras buttons of Microsoft Comfort Optical Mouse 3000 doesn't work." [Low,Needs info]  https://launchpad.net/bugs/52288
<ubotu> New bug: #55739 in xorg (main) "No more mouse events" [Medium,Needs info]  https://launchpad.net/bugs/55739
<ubotu> New bug: #38031 in linux-source-2.6.15 (main) "ps/2 mouse not recognized on IBM X21 laptop" [Medium,Needs info]  https://launchpad.net/bugs/38031
<ubotu> New bug: #51133 in xserver-xorg-video-sis (main) "X crash on IBM thinkcentre" [Medium,Rejected]  https://launchpad.net/bugs/51133
#ubuntu-x 2007-06-07
<ubotu> New bug: #50576 in xserver-xorg-video-i810 (main) "XServer Crashes with "Active ring not flushed" error." [Undecided,Confirmed]  https://launchpad.net/bugs/50576
<ubotu> New bug: #56295 in xorg (main) "X in edgy crashes with large transparent panels" [Undecided,Needs info]  https://launchpad.net/bugs/56295
<ubotu> New bug: #41869 in xserver-xorg-video-i810 (main) "Not able to get refresh rate higher than 60Hz in X resolutions above 1024x768 on i810 graphics" [Medium,Rejected]  https://launchpad.net/bugs/41869
<ubotu> New bug: #119050 in xterm (main) "xterm -fn 5x7 no longer works" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119050
<pochu> Sometimes, when I close the laptop lid, and open it later, the window doesn't turn on again, and I cannot move to a VT. I have to turn off the computer the bad way. Might it be an -intel bug?
<pochu> I can't find either in -intel or xorg bugs.
<jcristau> no errors in /var/log/Xorg.0.log.old after the reboot?
<pochu> jcristau: just the /dev/input/wacom ones.
<pochu> (grepping for EE)
<jcristau> no crash at the end?
<pochu> jcristau: No, it doesn't look wrong to me
<jcristau> ok, dunno then
<pochu> I would file a bug, but since the log doesn't look usefull...
<tepsipakki> sounds like an acpi-problem
<tepsipakki> ie. your laptop hangs
<pochu> It's an Acer 1642zwlmi. Is there any log/settings I can check?
<ubotu> New bug: #119032 in xorg (main) "[gutsy] EXA crashes X when enabling compiz" [Undecided,Needs info]  https://launchpad.net/bugs/119032
<bryyce> heya guys
<ubotu> New bug: #119093 in compiz (main) "Dialog repaint problem with desktop effects enabled (dup-of: 89189)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119093
<ubotu> New bug: #50535 in linux-restricted-modules-2.6.15 "Hardlocks w/ latest FGLRX" [High,Needs info]  https://launchpad.net/bugs/50535
<bryyce> http://people.ubuntu.com/~bryce/BulletProofX/
<jcristau> bryyce: looks cool
<tepsipakki> yeah
<bryyce> I wonder if the X cursor can/should be changed to a pointer
<jcristau> the missing decorations are probably due to the lack of a window manager?
<bryyce> I assume so
<tepsipakki> that's true
<jcristau> so you can just start twm :)
<bryyce> I think I need to stick with stuff that's included in the base install
<jcristau> yeah; just joking, i don't think ubuntu users will like twm much
<jcristau> :)
<bryyce> ah :-)
<bryyce> oh I also had a question maybe you know
<tepsipakki> who does :)
<tepsipakki> (like twm)
<bryyce> # TODO:  Ugly hack to make helpmsg.sh display in foreground
<bryyce> sleep 2 && $BULLETPROOF_X_PATH/failsafeHelpmsg &
<bryyce> $DISPLAYCONFIG_GTK_PATH/displayconfig-gtk \
<bryyce>   --data=$DISPLAYCONFIG_GTK_PATH/data
<bryyce> displayconfig-gtk is the client
<bryyce> but I want the help dialog to pop up in the foreground
<bryyce> having it sleep 2 seconds is a really ugly hack
<bryyce> is there a better way of doing this?
<jcristau> no idea
<jcristau> i assume you can't just start it after displayconfig-gtk
<bryyce> right
#ubuntu-x 2007-06-08
<ubotu> New bug: #119125 in linux-restricted-modules-2.6.22 (restricted) "Black screen after suspend with compiz (dup-of: 96240)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119125
<ubotu> New bug: #119340 in xorg-server (main) "libXau.6 is corrupted: Xorg will not start" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119340
<ubotu> New bug: #119283 in xorg (main) "Monitor not detected" [Medium,Confirmed]  https://launchpad.net/bugs/119283
<ubotu> New bug: #119341 in xserver-xorg-video-vesa (main) "glxinfo command causes Xorg to abort on Dimension E520" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119341
<ubotu> New bug: #119347 in xserver-xorg-video-ati (main) "Unknown ATI graphics controller on Dimension E520" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119347
<ubotu> New bug: #119353 in mesa (main) "dlopen /usr/lib/dri/i915_dri.so failed" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119353
<jcristau> heh, of course dri doesn't work if the dri drivers aren't installed :)
<ubotu> New bug: #119362 in xserver-xorg-video-intel (main) "Unknown Intel graphics controller on Intel D63578-200 motherboard" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119362
<bryyce> tepsipakki: is debian going to be breaking apps like xcalc, xeyes, etc. out into separate packages, or are they going to be in the x11-apps?  I haven't been able to find split out apps in experimental, so am wondering if I misunderstood debian's plans
<jcristau> bryyce: they'll be in x11-apps
<bryyce> aha, they're not broken out then, gotcha
<jcristau> only xauth and xinit have been broken out, the rest stay in conglomerate packages, but smaller than today's xbase-clients
<bryyce> ok, gotcha, I wasn't clear on that
<jcristau> (we already have too many packages anyway :))
<ubotu> New bug: #119370 in xorg (main) "Intel Xorg driver not detected when installing Gutsy Tribe-1 on an Intel GMCHB0ICHB0 motherboard" [Undecided,Needs info]  https://launchpad.net/bugs/119370
<ubotu> New bug: #119371 in xorg (main) "Gutsy Gibbon - Poor Video - Intel 82801H" [Undecided,Needs info]  https://launchpad.net/bugs/119371
#ubuntu-x 2007-06-09
<ubotu> New bug: #119445 in xorg (main) "[Testing of apport hook] " [Undecided,Unconfirmed]  https://launchpad.net/bugs/119445
<ubotu> New bug: #119447 in xorg (main) "[Testing of apport hook] " [Undecided,Unconfirmed]  https://launchpad.net/bugs/119447
<ubotu> New bug: #119446 in xorg (main) "[Testing of apport hook] " [Undecided,Unconfirmed]  https://launchpad.net/bugs/119446
<ubotu> New bug: #119449 in xorg (main) "[Testing of apport hook] " [Undecided,Rejected]  https://launchpad.net/bugs/119449
<ubotu> New bug: #119451 in xorg (main) "[Testing of apport hook] " [Undecided,Unconfirmed]  https://launchpad.net/bugs/119451
<ubotu> New bug: #119458 in xorg (main) "Display not configured with proper resolutions on install" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119458
<ubotu> New bug: #18874 in xorg (main) "synaptic touchpad: can't turn it off." [Medium,Unconfirmed]  https://launchpad.net/bugs/18874
<ubotu> New bug: #111315 in Ubuntu "windows appear black when several applications are working (dup-of: 96473)" [Undecided,Rejected]  https://launchpad.net/bugs/111315
<ubotu> New bug: #27667 in xresprobe (main) "Problems with xresprobe & Samsung 243T LCD" [Medium,Unconfirmed]  https://launchpad.net/bugs/27667
<ubotu> New bug: #28606 in linux-restricted-modules-2.6.15 (restricted) "restricted modules aren't upgraded when kernel is" [Wishlist,Fix released]  https://launchpad.net/bugs/28606
<ubotu> New bug: #50048 in xserver-xorg-video-i810 (main) "Unable to adjust refresh rate.." [Low,Confirmed]  https://launchpad.net/bugs/50048
<ubotu> New bug: #51541 in xorg (main) "Xorg.config Flag needed for cursor, had problems with mouse cursor disappearing as a pointer" [Medium,Needs info]  https://launchpad.net/bugs/51541
<ubotu> New bug: #52034 in xterm (main) "multiple xterms not restoring from X session save" [Medium,Needs info]  https://launchpad.net/bugs/52034
<ubotu> New bug: #119589 in xserver-xorg-video-intel (main) "Can't view videos using xv on intel 855GM" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119589
<ubotu> New bug: #52769 in xorg-server (main) "Live CD starts at 640x480 and a low refresh" [Medium,Needs info]  https://launchpad.net/bugs/52769
<ubotu> New bug: #32311 in Ubuntu "Unexpected screen resolution (dup-of: 5801)" [Medium,Needs info]  https://launchpad.net/bugs/32311
#ubuntu-x 2007-06-10
<ubotu> New bug: #119635 in xorg (main) "logout hang xserver" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119635
<ubotu> New bug: #42327 in Ubuntu "i can only change resolution once" [Medium,Rejected]  https://launchpad.net/bugs/42327
<ubotu> New bug: #32685 in control-center "no devanagari in keyboard indicator applet " [Medium,Confirmed]  https://launchpad.net/bugs/32685
#ubuntu-x 2008-06-02
<pwnguin> does anyone know what the hell is going on in bug #188787?
<pwnguin> also, where'd the bot go?
<tjaalton> pwnguin: didn't look at it closely, but the new package should fix that?
<pwnguin> it might
<pwnguin> wacom's changelogs are pretty vague and i dont build directly from them
<pwnguin> is there a way to get a unified diff from a cvs repo?
<pwnguin> reporter says it might not always work, but there's nothing in the upstream bugtracker
<tjaalton> pwnguin: use -u
<tjaalton> tseliot: what files/dirs were you referring to that nvidia can't ship?
<tseliot> tjaalton: there are a few things
<tseliot> too many "patches" dirs
<tseliot> e.g. we don't need a patches dir in debian.binary
<tseliot> we don't need a Makefile
<tseliot> or a devfs.devices
<tseliot> or nvidia_supported, etc.
<tjaalton> you mean we don't have to patch the modules?
<tjaalton> ever :)
<tjaalton> if they don't break anything, I'd keep them there
<tjaalton> to make the diff smaller
<tjaalton> haven't looked inside the tarball yet
<tseliot> we have a patches folder in debian.binary and 3 patches-related dirs in debian
<tseliot> err not in debian
<tseliot> in the main directory
<tseliot> actually we might want to keep only the one in debian.binary
<tseliot> and we'll also have to get rid of nvidia-settings since it's maintained separately
<tjaalton> commented out already
<tseliot> and I'm not comfortable with having a separate package such as nvidia-glx-ia32
<tjaalton> the debian version does not have any debian/patches dir
<tjaalton> it's not included in my version
<tjaalton> if you looked at the diff
<tseliot> I applied the diff. Maybe something went wrong
<tjaalton> on top of which?
<tjaalton> it's against the debian package
<tseliot> the -4 revision of the package in unstable
<tjaalton> right
<tjaalton> look at debian/control
<tseliot> control.in?
<tjaalton> both
<tseliot> you're right the ia32 package is commented out
<tjaalton> patches.save or patches.dpatch.save are not used
<tjaalton> the debian maintainer _might_ want to clean it up a bit..
<tseliot> did you move such libraries to another dir in nvidia-glx in the debian/rules?
<tjaalton> yes
<tjaalton> usr/lib32
<tseliot> ok, perfect
<tjaalton> just open the diff, it's easier to see the changes :)
<tseliot> ok, I'll use Kompare to do so
<tjaalton> "less" is enough
<tseliot> yes, I know but Kompare lets me browse through the files and see the changes, it's nice
<tseliot> also we might want to remove the diversions created by both nvidia-glx-new and nvidia-glx-new-envy, etc.
<tseliot> s/to remove/try to remove/
<tseliot> since the -envy flavour should be a dummy package in Intrepid which will point to our packages (and to Mario's)
<tjaalton> those should be removed by the packages itself
<tjaalton> in postrm or so
<tseliot> I was thinking of dist-upgrades, etc.
<tseliot> I want to make sure that we don't break upgrades from Hardy to Intrepid, no matter what
<tjaalton> ok so they are not touched on upgrade
<tjaalton> currently
<tseliot> and we'll have to be very careful about the Conflicts/Replaces in the control file
<tseliot> not that I need to remind you of this
<tseliot> ;)
<tseliot> shall we make an additional package which contains a tarball such as the one which is currently provided by nvidia-kernel-source?
<tjaalton> why?
<tseliot> I'm asking you since nvidia-kernel-source will only contain the DKMS part
<tjaalton> again, why? :)
<tseliot> why what?
<tjaalton> why can't it have both the source and dkms stuff?
<tjaalton> why another package?
<tseliot> should we put the same source twice in the same package?
<tjaalton> I don't understand..
<tseliot> the dkms source contains the content of that tarball + dkms.conf and other stuff
<tjaalton> ah ok
<tjaalton> that's enough imho
<tseliot> and it will be installed to /usr/src
<tseliot> ok, agreed
<tseliot> do you think that Debian will ever accept our changes to this package?
<tjaalton> no idea
<tseliot> when the package is ready I would like to put the latest release of the nvidia driver since it removes the need of a hacky patch and improves hardware support
<Q-FUNK> hm. seems that bryce's geode 2.9.0-1ubuntu2.1 doesn't work whereas my own package does.
<Q-FUNK> this realy should have been done as per the debian 2.9.0-3 package
<Q-FUNK> could video-all be updated to pull geode instead of amd?
<Q-FUNK> amd really is a transitional package, nowadays
<Q-FUNK> including in hardy
<jcristau> what's the point? it's not like the transitional package is going away from hardy
<Q-FUNK> removing the transitional package also removes -all
<jcristau> then don't remove it :)
<Q-FUNK> :-P
<Q-FUNK> that kinda spoils the concept of transitional package now, doesn't it?
<jcristau> maybe, but i don't quite see why that would warrant an update in a released version
<jcristau> just my opinion, though
<Q-FUNK> ok, it seems that the short answer is:  trying to maintain any sort of backward-compatibility with the old -amd driver makes LTSP fail on Geode hardware.
<Q-FUNK> the simplest way to really fix hardy is to make video-all Depends on -geode >= 2.9.0-3 and Conflicts on -amd (any version)
<jcristau> uh
<jcristau> that sounds wrong
<Q-FUNK> how so?
<jcristau> how does ltsp fail?
<Q-FUNK> jcristau: the reverse-compatibility links between amd_drv.so and geode_drv.so break it
<Q-FUNK> ditto if there's a link between amd.ids and geode.ids
<jcristau> there should not be an amd.ids
<Q-FUNK> why not?  
<Q-FUNK> creates additional PCI ID conflicts as a result of the symbolic link?
<jcristau> pci id conflicts are not an issue
<jcristau> the server will just pick the first one it finds
<Q-FUNK> why not then?
<jcristau> you still haven't replied to my first question though. how does ltsp fail?
<jcristau> because it's useless
<Q-FUNK> fails to launch X
<jcristau> how
<jcristau> 'it fails' is somewhat vague...
<Q-FUNK> if the symbolic links are there, X won't detect the Geode LX and falls back to console.
<jcristau> meh
<jcristau> that still doesn't give any detail
<Q-FUNK> if the symbolic links are gone, X launches as expected
<Q-FUNK> and uses the corrects driver
<jcristau> have a log/config?
<Q-FUNK> nope
<jcristau> then get one
<Q-FUNK> good luck on thta one. it all happens in a ramdisk.
<jcristau> that's like the first step for any problem with x
<Q-FUNK> except that here, simply A/B testing shows thta removing the symbolic links fixes it.
<jcristau> you said you were dumped to the console. pretty sure you can get logs from there
<Q-FUNK> no need to investigate any further.
<Q-FUNK> no
<Q-FUNK> LTSP disables console login and doesn't set any password for the squashfs that is used to get LDM 
<tjaalton> http://www.googlefight.com/index.php?lang=en_GB&word1=TTM&word2=GEM
<tseliot> LOL
<tjaalton> hmm, http://www.googlefight.com/index.php?lang=en_GB&word1=translation+table+maps&word2=graphics+execution+manager
<jcristau> you might want to remove xserver-xorg-video-newport from ubuntu
<jcristau> (see debian bug 393709)
<ubottu> Debian bug 393709 in xserver-xorg-video-newport "xserver-xorg-video-newport: video-newport should only exist on mips" [Wishlist,Closed] http://bugs.debian.org/393709
<tjaalton> x-x-v-all should be changed too
<jcristau> right
<bryce> I just checked in a change to s/-amd/-geode/ to that
<jcristau> i removed the -newport dependency in 1:7.3+11
<tormod> which package should ship xmesa.h from mesa? xserver needs it, but it was rejected for instance from mesa-common-dev in a Debian bug report.
<bryce> tormod: I don't know...  I'd have guessed mesa
<tormod> bryce: yes, but which binary package?
<tormod> maybe it should be included in the server itself now
<bryce> tormod: libgl1-mesa-dev maybe?
<bryce> tormod: hmm mesa-common-dev might be better
<tormod> bryce, yes other files from the same source dir ends up there.
<bryce> maybe tjaalton or jcristau could have something more useful to advise
<tormod> the related bug is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354019
<ubottu> Debian bug 354019 in mesa-common-dev "mesa-common-dev: doesn't contain xmesa.h" [Normal,Closed] 
<Q-FUNK> howdy
<Q-FUNK> http://mentors.debian.net/debian/pool/main/x/xserver-xorg-video-geode/xserver-xorg-video-geode_2.9.0-4.dsc
<Q-FUNK> I'm thinking of removing the symbolic links to -amd completely and instead warn people who still have "amd" in their xorg.conf to change it to "geode".
<bryce> o_O
<Q-FUNK> I know
<Q-FUNK> but further testing shows that 2.9.0-ubuntu2.1 doesn't fix it.  the real fix is to remove the symbolic links completely, otherwise LTSP still barfs
<Q-FUNK> and it's easy enough to reply to eventual bug reports about standalone host by pointing to a simple Device change from "amd" to "geode" than to keep this in a half-broken state.
<Q-FUNK> my first guess with 2.9.0-3 at debian was to move the symbolic links to the transitional -amd package, but this would only work if -video-all is made to no longer depend on -amd and instead depend on -geode
<Q-FUNK> then people upgrading from Gutsy would get -geode as a byproduct up upgrading -amd and/or -all, would also get the symbolic links if they run on a standalone host, but since -all doesn't pull -amd anymore, then LTSP would always work
<Q-FUNK> and so changing -all to depend only on geode, rather than -amd, and adopting 2.9.0-3 for hardy would be the most reasonable course of action.
<Q-FUNK> for debian, the above -4 makes more sens,e since we've never had -amd in the first place.
<bryce> I've checked in that change to git this morning
<Q-FUNK> but we are too late for the hardy.1 release, right?
<bryce> yup
<Q-FUNK> :(
<Q-FUNK> any way we can push 2.9.0-3 and -all with -geode instead of -amd into proposed for hardy.2 ?
<bryce>  dunno
<bryce> I guess I'd rather hold off until we know for certain what the fix is
<bryce> it seems like there's been too many sru's for this -geode change, each time "this will definitely fix it", but it didn't
<bryce> I don't know what the .2 release schedule is, but presumably it's a ways off.  So better to focus on getting this fixed properly in intrepid and validate the solution definitively on all affected hardware, and *then* do an SRU
<Q-FUNK> well, changing the dependency in -all had been discussed before. I still don't even known how hardy.0 even shipped with the dependency still on -amd.
<Q-FUNK> and keeping the symbolic links in -geode wasn't my idea of a fix either.
<Q-FUNK> it rather was pitti's idea to keep all files within the established 2.8.0 packaging's idea.
<Q-FUNK> and since 2.8.0 was released with the symbolic links in -geode rather than -amd, he opposed changing that for 2.9.0
<bryce> nonetheless, I think we need to get it fixed and validated in intrepid before talking about sru's.
<bryce> even if we know changes are needed (like the -all change), it should be easy enough to test in intrepid first.  If it turns out that more is needed, then there seems little point in pushing an incomplete solution to hardy, esp. since 8.04.2 is a ways off anyway.
<Q-FUNK> true, that
<Q-FUNK> I'm still sad that the -all change didn't go thru
#ubuntu-x 2008-06-03
<bryce> would have been trivial to do if I'd known about it last week
<Q-FUNK> I mentioned it even before that, back when Hardy was frozen, this spring.  there's just always too many things to watch for and it probably got lost in the shuffle.
<bryce> yeah could be
<Q-FUNK> and during UDS, there were far too many issues to tackle too
<Q-FUNK> in fairness, I lost far too much time hunting down debian-specific changes in X that affect driver behavior in ways that other distros with fewer diffs don't get.
<Q-FUNK> backporting all geode-related changes in 1.5 that work for other distros, only to find that it only solves half the issues on debian/ubuntu, wasn't exactly a pleasant suprise.
 * bryce nods
<tormod> bryce, upload sponsor day today? thanks :)
<bryce> :-)
<bryce> yup taking a break from spec writing to catch up on my sponsoring queue
#ubuntu-x 2008-06-04
<bryce> tjaalton: I notice that a lot of the proto libs on http://people.ubuntu.com/~bryce/Xorg/versions_current.html aren't syncing to debian, but aren't listed on MoM either...  any ideas what's up with them?  
<bryce> I suspect the ubuntu changes can just be dropped
<pwnguin> bryce: i think those were stupid epoch changes?
<bryce> yeah possibly, although some aren't epoched
<pwnguin> i know epoch's a pita for wacom
<bryce> wtf, will bug reporters never learn to attach their Xorg.0.log file??
<pwnguin> i didnt do it
<pwnguin> exit
<pwnguin> doh
<pwnguin> i should go through and clean up wacom bugs a bit
<bryce> that'd be a big help.  I hardly ever look at those myself
<pwnguin> hmm
<pwnguin> on #179453, one person says its fixed and the other says it's broke
<pwnguin> if the original reporter says it's broke, should i mark it incomplete?
<tjaalton> bryce: different tarballs
<tjaalton> so nothing we can do unless upstream releases new versions
<tjaalton> there should be no epoch changes in XSF maintained packages (which wacom-tools is not)
<tjaalton> I mean epochs in our versions..
<pwnguin> ah thats right
<pwnguin> packaging is so confusing somehow ;)
<tjaalton> bah, straightforward and easy :)
<tjaalton> ..if you know the policy manual inside-out (which I don't)
<tjaalton> bryce: so, if the tarball is different, the package should be fakesynced; unpack the debian version, change the maintainer, add a changelog entry, and before building the new source package move our tarball in place so it uses that one
<bryce> tjaalton: ah ok; what's the easiest way of detecting that it's a tarball difference?
<tjaalton> bryce: reading the changelog :)
<tjaalton> if it says "fake sync"
<tjaalton> tseliot: btw, were you building a xorg.conf parser? fedora already has a library for that, called libxf86config
<tseliot> ï»¿tjaalton: yes, I did it
<tseliot> I'll have a look at their parser
<tseliot> tjaalton: they hardcoded resolutions???
<tjaalton> tseliot: hm?
<tjaalton> you only need to look at gutsy and see that we did the same
<tseliot> in their parser, I mean
<tjaalton> don't know, never looked at it
<tseliot> it looks like that parser relies on ixf86config, which I can't find...
<tseliot> ok, found
<tseliot> no, not really
<tjaalton> so that Ademan-guy is trying to write a program to configure mice..
<tjaalton> there should be one already, but can't remember the name
<tselio1> tjaalton: I'm glad to have warned you against updating the fglrx driver for Ubuntu's .1 release. I'm working on the -envy package and I'm facing a black screen
<tjaalton> tselio1: joy..
<tselio1> ï»¿tjaalton: I have tried removing all the patches in lrm (even though they were applied without problems), I have tried the installer from AMD without solving the problem.
<tselio1> the new beta driver works
<tselio1> but I can't include it since it experimental and secret
<tselio1> :-/
<tselio1> I will update only the NVIDIA driver
<tjaalton> ok
<tjaalton> pwnguin: I've merged wacom-tools, but let's see if it builds on ppa
<pwnguin> tjaalton: excellent!
<pwnguin> i should probably upgrade my laptop
<bryce> heya
<pwnguin> bryce: is there a decent way to distinguish between a kernel freeze and an X freeze?
<pwnguin> i recall mjg saying the capslock key was helpful for determining whether a laptop had failed to resume or simply failed to bring up video
<bryce> pwnguin: ssh seems to be a good distinguisher
<bryce> if you can't ssh into the box, it's likely something's wrong with the kernel, not just X
<tseliot> ï»¿bryce: did you have a look at my changes to the wiki?
<tjaalton> GPU lockups tend to freeze the machine
<tjaalton> sorry, that's not correct
<tjaalton> the kernel should be alive then
<bryce> tseliot: not yet, going to do so today (I ended up spending yesterday mostly sponsoring uploads)
<tseliot> ï»¿bryce: no problem, I know that you're all very busy ;)
<unggnu> hi all
<bryce> heya
<unggnu> https://wiki.ubuntu.com/X/Backtracing - Debug symbol information
<unggnu> hi bryce
<bryce> cool thanks
<unggnu> It is a little to complicated atm imho. The dbgsym packages aren't needed anymore for Gutsy an later afaik so what do you think about cleaning it up?
<unggnu> And it seems that libgl1-mesa-dri-dbg is also needed.
<unggnu> I thought about
<unggnu> You will need to install the package {{{xserver-xorg-core-dbg}}}, {{{libgl1-mesa-dri-dbg}}} and if available the one for your graphic driver {{{xserver-xorg-video-<name>-dbg/sym}}}.
<unggnu> Is it ok?
<tjaalton> bryce: re: the brainstorm blog entry; radeon is not blacklisted :)
<bryce> tjaalton: in hardy?  are you sure?
<bryce> unggnu: I think cleaning it up is a brilliant idea.  Go for it if you're up for it.  :-)
<tjaalton> less =compiz
<unggnu> thx :)
<tjaalton> the version in proposed blacklists i815, but nothing else
<bryce> oh they took it out recently?
<tjaalton> unless there's another blacklist somewhere
<tjaalton> well, the released version didn't blacklist any chips
<tjaalton> so i815 was added recently
<tjaalton> I thought that the mobile chips were blacklisted, but apparently not
<tormod> tjaalton, bryce: you talking about compiz blacklisting?
 * bryce nods
<tormod> radeon on laptops is blacklisted AFAIK
<tjaalton> tormod: but where? the compiz wrapper doesn't show it
<bryce> tjaalton: well, anyway radeon was blacklisted at the point I looked into it
<tjaalton> yeah
<tormod> line 268 of /usr/bin/compix
<tormod> *compiz
<bryce> hmm, yeah still there
<tormod> OTOH the PCIID blacklist is commented out
<bryce> radeon is blacklisted for laptops only -- I might have not made that clear in my post
<tjaalton> aha! :)
<tjaalton> didn't look far enough
<tjaalton> anyway, night ->
<bryce> cya
<tormod> bryce, for sponsoring, do you have special tools, or do you have to do all the unpacking, patching, building dance - so in the end you could have fixed smaller things more efficiently yourself instead of using someone's debdiff?
<bryce> well, even in those cases, having the debdiff to reference does help speed the process
<bryce> the main "tool" I use, 'debsponsor' is an alias
<bryce> alias debsponsor='debsign -ke0e67611'
<bryce> where that hex code is my pgp key
<tormod> I guess I should ask dholbach (again) since the sponsoring seems inefficient and has a huge backlog
<tormod> apropos your pgp key, you saw the comment in -devel earlier about your signed .changes files :)
<bryce> tormod, you ought to work towards getting motu and core dev
<tormod> I think there should be easy for people like me (non-devs) to contribute efficiently anyway
<tormod> it's already great in Ubuntu, but could be better
<bryce> agreed
<bryce> yes agreed
<tormod> personally I am not interested in Universe, and not enough time to think about core-dev
<tormod> I just want to get my stuff fixed fast :)
<bryce> yeah I saw the comment about the .changes.  In this case I don't think it matters.  I almost uploaded the package myself, just wanted to get a validation
<bryce> fwiw, the easiest situation from a sponsoring point of view, is if you do the packaging to produce a .dsc and .changes, and put that somewhere I can pull
<tormod> well I thought it was funny because I didn't think about that possibility, although someone already tried to upload my ppa packages to hardy proper :)
<bryce> (then I can review, and then just debsponsor it up)
<tormod> I am surprised if daniel doesn't have a script to pull down a debdiff and generate all that :)
<bryce> possibly
<tormod> was sponsoring discussed at UDS?
<bryce> I'm relatively new to sponsoring stuff (I got the powers after feature freeze, so only recently have had many opportunities to use them)
<bryce> hmm, if so it was in a session I didn't attend
<tormod> well I should let you to time to look at that laptop-mode-tools patch instead of asking all these questions ;)
<bryce> hehe
<bryce> weird:
<bryce> $ apt-cache madison laptop-mode-tools
<bryce> laptop-mode-tools | 1.42-1ubuntu1 | http://us.archive.ubuntu.com intrepid/main Packages
<bryce> laptop-mode-tools | 1.35-1ubuntu1 | http://us.archive.ubuntu.com intrepid/main Sources
<tormod> bryce, thanks! I guess I just ran "dch -i" and forgot to change the release
<bryce> no prob
#ubuntu-x 2008-06-05
<tjaalton> pwnguin: wacom-tools built fine, now uploaded to intrepid
<pwnguin> neat
<tjaalton> there's at least one big regression reported on debian
<tjaalton> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482826
<ubottu> Debian bug 482826 in xserver-xorg-input-wacom "xserver-xorg-input-wacom: Mouse device wrecks input system" [Normal,Open] 
<tjaalton> but maybe that's already on launchpad
<pwnguin> i saw that before when i was checking for crazy bugs, but i only skimmed it and thought it was some goofy joystick thing
<pwnguin> perhaps not
<pwnguin> guess i need to upgrade to intrepid
<tjaalton> i can crash the server if using input-hotplug and plugging in a joystick and move it :)
<tjaalton> maybe 1.5 is better
<tjaalton> it'd better be :)
<pwnguin> so on a scale from 1 to 10, how likely is an ibid upgrade to work?
<tjaalton> don't know, i'm not running intrepid yet
<bryce> I put intrepid on one of my boxes early on, and have been updating it irregularly; no problems so far
<bryce> I use it more as a build server than as a desktop though
<pwnguin> my laptop has two installed ubuntus
<pwnguin> i normally keep a stable and a dev with a shared /home
<tjaalton> how do you handle grub?
<pwnguin> very carefully
<pwnguin> if i were smarter
<tjaalton> you don't have a shared /boot?-)
<pwnguin> id have grub installed to the partions and basically a dual stage grub
<pwnguin> or a /boot
<tjaalton> right
<pwnguin> but the dual stage would actually work
<pwnguin> a shared /boot wont
<tjaalton> bryce: btw, you can drop fonttosfnt from the status page. also lrm, mesa-utils, and probably compiz should be dropped as well (compiz not maintained by us)
<tjaalton> and I'm wondering about dropping unichrome from the archive..
<tjaalton> upstream is hostile and not willing to make releases :)
<tjaalton> and too busy updating it
<bryce> tjaalton: the script just pulls from what's on https://bugs.launchpad.net/~ubuntu-x-swat/+packagebugs
<tjaalton> bryce: oh :)
<bryce> plus a handful of extra packages (like mesa) that I added
<tjaalton> mesa and mesa-utils have the same source (mesa)
<bryce> hmm
<bryce> I don't specifically add mesa-utils... it must magically come in somehow
<bryce> anyway, in general what's included in the report can be controlled by subscribing/unsubscribing ubuntu-x-swat
<tjaalton> fonttosfnt is not on that page, and why aren't the other lrm's listed?
<bryce> yeah I don't know how fonttosfnt is sneaking in...  looking into that
<bryce> for lrm, hmm...  maybe the version number is getting parsed out or something... not sure
<tjaalton> also x11-common is unnecessary on that page
<tjaalton> source is xorg
<bryce> ok, nuked
<bryce> btw, here's the current "extra" packages:
<bryce>        x11-apps x11-utils x11-xfs-utils
<bryce>        x11-xkb-utils x11-xserver-utils
<bryce>        xserver-xorg-video-avivo
<bryce> 	xserver-xorg-video-psb
<bryce>        xserver-xorg-video-openchrome
<bryce>        xserver-xorg-video-radeonhd
<bryce>        libdrm2
<bryce>        libxcb
<bryce>        mdetect
<bryce>        libpixman
<bryce>        xserver-xgl
<bryce> probably would be better for us to sub -swat to those
<tjaalton> already is
<tjaalton> not mdetect though
<tjaalton> libdrm2 source is libdrm
<tjaalton> all the x11* are subscribed
<tjaalton> avivo is not in the archive anymore
<tjaalton> libxcb is missing, subscribing
<bryce> ah, the reason lrm-2.6.24 is the only one listed is because the script only checks hardy and intrepid, and older lrms aren't seen by apt-cache madison
<bryce> when there is a lrm-2.6.25, and when it's subbed by -swat, in theory it should just show up
<tjaalton> but what does it give us?-) debian doesn't have that
<tjaalton> and probably it won't even include any video drivers anyway
<bryce> then if we don't sub -swat to it, we'll not see it
<bryce> and lrm-2.6.24 will drop off when we move to intrepid+1
<tjaalton> ok.. let's wait for the split
<bryce> hmm, I'm a little mystified by fonttosfnt.  By chance did you unsub us from that recently (within the last 24 hrs?)
<tjaalton> and yes, mesa-utils is subscribed because there was a source package named mesa-utils. but since there are no bugs assigned to it, I'll unsub from it
<tjaalton> no, must've been before
<tjaalton> when it was dropped from intrepid
<tjaalton> it had no bugs
<bryce> I'll regen the page and we can see where we're at
<bryce> maybe fonttosfnt will just drop off
<tjaalton> yeah
<bryce> ok reload
<bryce> hrm still there
<tjaalton> stubborn lil' bastard
<bryce> ahhh I know
<bryce> the way the script works, I guess it's a little backwards than we'd expect
<bryce> first it looks at the xorg releases page and gets a list of packages from that
<bryce> then it looks at hardy and intrepid to see if they carry any of those packages listed according to apt-cache madison, and if so, it includes them
<tjaalton> heh :)
<bryce> then it also overlays additional packages listed on the -swat report 
<bryce> so fonttosfnt gets grandfathered in since xorg still carries it, and because it's present in hardy
<tjaalton> ok, unless it's easy to blacklist it from the script, let's live with it :)
<bryce> if it really bugs you I can blacklist it, but it doesn't bother me (it doesn't affect the ultimate stats, and I like having the 'history' showing what we dropped)
<tjaalton> bryce: no it's fine
<mnemo> i need to rebuild my X.org DRI module but autoconf says "cant find dri2proto"... what package do I need to install?
<jcristau> there isn't one for dri2proto yet
<jcristau> so --disable-dri2
<mnemo> ah, it's a new feature which is not used in ubuntu yet?
<mnemo> hmm, it didn't work.. seems like the driver still checked for dri2proto
<jcristau> what driver is that?
<mnemo> intel
<mnemo> im trying to build i965 dri module
<jcristau> oh
<jcristau> well you can build a package from git://git.debian.org/git/pkg-xorg/proto/x11proto-dri2
<mnemo> thanks I'll give it a try
<mnemo> that one says "make: nothing to be done"
<jcristau> it shouldn't
<mnemo> when I run ./autogen.sh it creates dri2proto.pc
<mnemo> and then exits
<jcristau> right
<mnemo> is that how it's supposed to work?
<jcristau> it's a bunch of headers, so there's nothing to build. if you want a package, run 'dpkg-buildpackage -b'
<mnemo> ahh I see.. I've never seen such a thing before
<jcristau> a debian package?
<mnemo> well I've seen .deb files before but never some source code from git that was supposed to converted directly into a .deb
<jcristau> ok
<mnemo> i usually just try "./configure ; make ; make install" or maybe ./autogen.sh if it exists
<mnemo> there is some many different instructions for different packages
<mnemo> very hard to get started learning about these things
<mnemo> i mean, a simple INSTALL or README file for the x11proto-dri2 would have come a long way
<jcristau> './autogen.sh; make; make install' would have worked
<mnemo> ah, I got stuck on "make" because it said it did nothing but I suppose that was "by design" sort of
<jcristau> right
<mnemo> another problem getting started contributing to x.org in ubuntu is that it's so hard to get an overview of all the packages and how they interact with each other... like what is DRI, DRM, MESA and so on.. i want to help but I get totallt confused by all these packages that depend on each other ;/
<jcristau> we all are
<mnemo> ;)
<bryce> yeah me too
<mnemo> haha =)
<jcristau> i suppose i should get the dri2proto packages in debian at some point
<bryce> mnemo: I've found phoronix sometimes has really good articles explaining what the acronyms and such mean
<mnemo> cool
<bryce> it'd sure be nice to have an "X.org glossary"
<bryce> and I definitely agree an overview document explaining how all the various gears interact would be handy
<bryce> you can sort of piece things together via the X.org website and wikipedia
<bryce> but the dependencies are still confusing
<mnemo> yeah, it's like a puzzle and just when you think you got it they invent ttm or something like that, heh
<bryce> and just as you come to terms with ttm, they change their mind and switch to using gem
<bryce> and then gem isn't available yet X-P
<mnemo> ;>
<jcristau> i thought the problem was that nobody had come to terms with ttm, really
<bryce> jcristau: the article on phoronix about it and gem makes it sound like keithp and co. have no intent to support seeing ttm upstreamed, and prefer to wait until gem is ready to go
<jcristau> i don't read phoronix. i read the thread on dri-devel and the article about it on lwn though
<bryce> tjaalton: I'm going to try dropping the greedy patch from -intel 2.3.1.  I *think* we no longer need it, but I'll just comment it out in case folks find it's still needed.
<bryce> tjaalton: the patch still applies and builds, so if we need it, it should be easy to switch back on
<jcristau> but, yeah, the intel guys don't seem too happy about ttm, hence gem
<bryce> from what I know of the kernel guys, it'd surprise me if they took ttm when there isn't a consensus, esp. without keithp's backing.  And if the kernel is iffy on taking it, I wouldn't imagine many driver developers putting time into it
<bryce> but who knows; if red hat strongly favors it and is pushing hard for it... 
<jcristau> the only ttm user is poulsbo, afaik
<bryce> doesn't redhat also have patches enabling it for -intel in fedora9?
<jcristau> yeah, probably, for the modesetting stuff. but that just needs a memory manager, not necessarily ttm
<Q-FUNK> ok, I have new -nsc and -geode packages in my PPA with the GX2 support pulled back into geode and removed from nsc.
<tjaalton> bryce: ok, sounds fine. there's time to experiment
#ubuntu-x 2008-06-06
<tjaalton> what the.. why do I get a newly generated xorg.conf after a reboot. the old one works fine
<tjaalton> happened on two machines, both using nvidia blob and both had their cards changed
<pwnguin> physically?
<pwnguin> nvidia ships an xorg.conf file munger; perhaps it runs automatically now, I donno.
<pwnguin> tjaalton: btw, im running intrepid now, testing wacom. 
<tjaalton> no, it's the xorg.conf dexconf would produce
<tjaalton> and I've seen bugreports where people complain that they need to reinstall the driver after every boot
<tjaalton> I think bp-x kicks in somehow
<tjaalton> yep, definately bp-x
<tjaalton> oh right, no extra power on the card
<tjaalton> *cable connected
<tjaalton> but the other machine still ran dexconf for no reason
<tjaalton> bah, no time to debug it now
<mnemo> I tried to test various intel drivers from .deb packages and git repos and how I can't get direct rendering to work around
<mnemo> "glxinfo | grep direct" says direct rendering is disabled
<mnemo> how can I reinstall x.org and all drivers etc so make sure I get the normal hardy xorg+driver again ??
<Q-FUNK> guys, isn't there any way we can get -all to depend on -geode rather than -amd for hardy.1 ?
<Q-FUNK> I know thta hardy.1 froze a while back and is currently being rollled out in hardy-updates, but still...
<Q-FUNK> as much as I try, the only way to fix this geode issue permanently is to make -all stop depending on -amd and to use my new package structure, where the symbolic link is in the transitional -amd 
<Q-FUNK> http://q-funk.blogspot.com/2008/06/kuradne-geode-draiveri.html
<tseliot> bryce: yesterday was the deadline for the specs on launchpad. How does it work? Do we need someone to approve the spec?
#ubuntu-x 2008-06-07
<cjb> Hi!  Are there any Ubuntu X packages with mpx available?
<bryce> cjb: not yet
<bryce> http://farm4.static.flickr.com/3227/2438454269_a3489e2235.jpg
<pwnguin> so what are the rules for marking a bug "confirmed" when I can't duplicate it?
#ubuntu-x 2009-06-01
<tormod> Sarvatt, michaellarabel: writing this from the xorg-edgers live CD 0.1 :)
<michaellarabel> tormod: Nice
<tormod> basically karmic daily-live + Kanotix kernel + xorg-edgers - openoffice/mono
<tormod> will add PTS and some branding and publish tomorrow :)
<hyperair> intel with KMS on whacks up resume from suspend to ram/disk =(
<hyperair> it hangs upon resuming
<hyperair> no make that only resume from suspend to disk
<tjaalton> ewww. kanotix kernel..
<tjaalton> jbarnes_LHR: stuck at the airport?-)
<jbarnes_LHR> tjaalton: nah just shorthand for jbarnes_somewhere_in_london :)
<tjaalton> jbarnes_LHR: ah, sounds better ;)
<maco> just wondering, is the -intel driver strictly limited to 1280x1280, or is there something i can do to convince xrandr that i really do want a 1280-width screen next to a 1680-width screen?
<hyperair> maco: a newer mesa should fix that.
<hyperair> maco: assuming, of course, that you're using 965
<Sarvatt> if his problems were 3d related maybe :D
<tormod> michaellarabel: I gave up on PTS on the live CD, I tried kano's debs, but they do not have proper package dependencies. PTS does not play so nice with the Debian/Ubuntu package system AFAICS, since it is installs stuff on its own.
<Sarvatt> <maco> Screen 0: minimum 320 x 200, current 1280 x 960, maximum 1280 x 1280 can't use his external 1680x1050 monitor 
<hyperair> oh
<hyperair> wooh xrandr shows my maximum 8192x8192
<hyperair> =D
<hyperair> by the way, i can't resume from hibernation with KMS on.
<hyperair> using latest everything
<tseliot> maco: try either switching to "UXA" or setting the virtual resolution to whatever you need
<tormod> anyway the live cd build script is on https://code.edge.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools
<tseliot> s/whatever/whatever size/
<maco> after enabling KMS and rebooting with screen plugged in i now have that 8192x8192 max
<tormod> tjaalton: kanotix kernel = karmic kernel updated to latest git + patch for aufs
<maco> both screens are at native resolution, but for some reason i can't quite get them to behave in a next-to-each-other fashion
<tjaalton> tormod: ok, I'm just allergic to Kano's practices ;)
<tormod> no comment :)
<tseliot> maco: xrandr --output $your_first_output --left-of $your_second_output --auto
<maco> yeah i tried that --left-of and --right-of stuff....not workin so well
<tseliot> setting the resolution (mode) for each output should do it
<maco> ahhh ok the --auto makes it go
<maco> and wow its confusing having one workspace on each screen
<tormod> bryce: can you host a xorg-edgers live CD somewhere?
<maco> ahhhh if i switch the right display to the workspace the left display is showing, they swap! 
<michaellarabel> tormod: PTS handles Debian/Ubuntu just fine. It installs some dependencies, but for the vast majority it will install them using its own way. It's one of the few ways that there can be sane, comparable results between distributions using PTS. Otherwise who knows what slight patches, build optimizations, etc that a package maintainer for a distribution could have done to those packages.
<tormod> michaellarabel: but if you just install the PTS and run it, it will fail on missing stuff, like "patch" and "g++" etc.
<tormod> some a bunch of packages should be added to its dependencies
<michaellarabel> tormod: It should install those automatically with PTS.
<jcristau> ewww.
<michaellarabel> I don't know what Kano's package looks like, but otherwise even just run: phoronix-test-suite install-all-dependencies and it will install its Ubuntu dependencies.
<tormod> at least the "standard" deps should be deb dependencies
<michaellarabel> Yeah, sure, I didn't package it so bring it up with Kano.
<tormod> I think actually it is the same with your official 1.0 debs...
<tormod> 1.8 I mean
<bryce_> tormod: I can probably make that happen.  how much space is required?
<bryce_> tormod: nice work getting the cd put together so swiftly!  anything else I could do to help besides hosting?
<bryce_> tormod: also, can you tell me about the kernel being used in this?  should I contact the kernel team to get them to build a better one for us?
<tormod> the iso is 561 MB (now). not sure if we need to keep some older versions around
<tormod> if the iso could be build somewhere it would be even better, I have a slow uplink
<bryce_> ok, I'll see what I can do
<tormod> the kanotix kernel is simply the karmic kernel, merged with latest upstream, patched with aufs and 2 other small patches
<tormod> as soon as the kernel team makes a live-cd capable kernel I'll use it
<bryce_> ok, emailing kernel team
<bryce_> tormodvolden@ubuntu.com ?
<bryce_> ah, tormod.volden@gmail.com
<tormod> bryce_: use lists.tormod if it ends up in mailing lists
<bryce_> tormod: ok email sent
<bryce_> tormod: I can put the image onto my people.ubuntu.com account for now.  I'll forward the request to cjwatson to set up something more permanent and easy to update.
<bryce_> tormod: do you have the iso somewhere that I can download it?
<tormod> bryce_: thanks
<bryce_> if not, I can give a shot to generating it myself tomorrow (I'm down with ubuflu today unfortunately)
<tormod> the problem is I have my ISO locally on _A_DSL
<tormod> it should be easy to regenerate. get better soon!
<tormod> I just tried to create it on an VPS now, but loop mounting fails on it...
<Sarvatt> tormod: http://sarvatt.com/downloads/xorg-edgers-0.1-i386.iso
<Sarvatt> NICE! Just saw the patches on the intel-gfx mailing list to fix the UXA gl compositing memory leak, time to test those out
<Sarvatt> tormod: are you around? got a question about a new mesa hook
<jcristau> Sarvatt: the patch is broken
<Sarvatt> ah is it? the updated one he posted?
<jcristau> yeah
<Sarvatt> dang, got my hopes up :D
<jcristau> i mean, the idea might be good, i have no idea :)
<jcristau> but the patch is not quite there yet
<Sarvatt> thanks for the heads up, saved me alot of trouble :)
<Sarvatt> would be nice to be able to use compiz again, not worth downgrading to use EXA over for now though
<Sarvatt> bryce: btw I take back what I said about -intel 2.7.99.1, jcristau updated it to the latest and greatest incase you didn't see, drm is updated over there in drm-snapshot instead of libdrm too :) 
<bryce> Sarvatt: ok thanks
<tormod> bryce: as you can see Sarvatt built the live CD, so you can mirror it
<bryce> tormod: yep, already doing so
<tormod> me too :)
<Sarvatt> might want to make sure it works first, I have nothing to boot it off of handy. Typing this in traffic atm :D 
<tormod> theoretically it should be the same as the iso I made myself, but I will test yours
<bryce> mirroring finished:  http://people.ubuntu.com/~bryce/xorg-edgers-0.1-i386.iso
<Sarvatt> i can put up a build log if ya give me a few
<Sarvatt> tjaalton: dont know if you saw it but we need to change mesa-common-dev.install in 7.5+ to factor out the glxew.h header install that makes it conflict with libglew1.5-dev
<Sarvatt> they started shipping it with 7.5+ for building some demos
<tjaalton> Sarvatt: ok, fixed
<Sarvatt> nice, one more hook we can drop! thanks tjaalton :)
<Sarvatt> we just started adding --disable-gallium to the confflags too since it builds by default (but not shipped) and just wastes build time :D i hope the 8xx intel fixes end up getting pulled back into 7.5 as well as the UXA memory leak fixes whenever those hit
<Sarvatt> nice, the new e2fsprogs 1.41.6 shaved a decent chunk of time off my boot time there
<Sarvatt> ubuntu needs to update to mesa 7.5 already, would like to up jaunty to 7.6 since there was MAJOR intel fixes only in 7.6 
<Sarvatt> basically there was no 3d support for 8xx series intel with tiling enabled until a few days ago :D
<Sarvatt> ah jeeze wrong channel again
<Sarvatt> way to make a <not so nice word> out of myself, I'm sorry :) only said that because we decided to hold off on 7.6 in jaunty on edgers until 7.5 hit karmic
<bryce> heh
<bryce> between uds and catching ubuflu, I'm a bit behind in merging in stuff, but  hopefully it'll be in within a week or so
<bryce> tjaalton usually does the mesa updates, so perhaps if he has time he'll be pushing that in; if not I'll get to it later after -intel is updated
<Sarvatt> tormod: build log from your script - http://sarvatt.com/downloads/xorg-edgers-live-cd-buildlog.txt
<tjaalton> there's still the issue about what to do with gallium. jcristau sent a post about it on debian-x@
<tormod> bryce, QED the live iso works fine
<tormod> and mesa-rewrite is still broken, QED2
<Sarvatt> anyone have any ideas on what to do about installing dri.pc with mesa? which package it should go under (libgl1-mesa-dev?)? it's required for xserver 1.7 and I have been manually changing the check in configure.ac to check the gl package instead of dri to work around it.
#ubuntu-x 2009-06-02
<cwillu> bryce, kms and intel and vbetool:  be advised that pm-utils also makes calls to vbetool, which causes some grief.  
<cwillu> bryce, I added a note to #372480
 * cwillu pokes ubottu with a stick
<cwillu> https://bugs.edge.launchpad.net/ubuntu/+source/pm-utils/+bug/372480
<ubottu> Ubuntu bug 372480 in acpi-support "vbetool should not be called on -intel when KMS is in use" [High,Fix released]
<Sarvatt> weird, it should be removing all quirks and adding the nochvt one when it detects KMS is active via /usr/lib/pm-utils/sleep.d/98smart-kernel-video
<Sarvatt> not to mention it had a kernel fix to work around it just incase people were still using it, are you on jaunty by any chance?
<Sarvatt> because jaunty's pm-utils doesnt have the extra KMS handling is why I ask, sorry
<cwillu> Sarvatt, no, karmic
<cwillu> removing the execute perm from vbetool fixed it, so I'm assuming pm-utils is to blame
<cwillu> I see that file now, wonder why it didn't work
<Sarvatt> hmm, the fix was added to 2.6.30-rc6 and should be in ubuntu's 2.6.30-6.7 kernel if you're using that, thats strange
<Sarvatt> [   61.162844] [drm:i915_wait_request] *ERROR* something (likely vbetool)
<Sarvatt> disabled interrupts, re-enabling
<cwillu> yep
<Sarvatt> you saw that in the log?
<cwillu> I'm using a daily out of the mainline ppa, there's another bug that causes a nicely gradual crash after resume
<cwillu> yep
<cwillu> under 2.6.30rc7 or our normal kernel, I crash on resume.  On the mainline daily, I don't
<Sarvatt> jbarnes: ping incase you are interested that vbetool is still causing some problems after the deal from http://bugzilla.freedesktop.org/show_bug.cgi?id=20896
<ubottu> Freedesktop bug 20896 in DRM/Intel "[GM965 KMS] X does not draw untill mouse is moved. Probably IRQ problems" [Major,Resolved: notourbug]
<Sarvatt> yeah there were some great fixes for intel merged on the 29th that arent in rc7
<cwillu> god I hate backing out of my statements
<cwillu> must have gotten lucky 2-3 times in a row, right after I disabled vbetool
<cwillu> it's broken again
<cwillu> mouse cursor moves, but I can't interact with the screen or change vterms
<cwillu> let me ssh in and check dmesg
<cwillu> touchpad works, external mouse is dead, even after replug
<cwillu> no errors in dmesg or xorg.0.log
<cwillu> machine itself is live
<Sarvatt> the classic intel crash :D
<cwillu> can't interact, change vt's via ctrl-alt-f1
<cwillu> Sarvatt, but why would the external mouse not work?
<Sarvatt> i have no idea, thats just how all my intel crashes play out, x dying but the machines still alive and the touchpad works
<Sarvatt> there have been a *load* of fixes for those types of hangs in the newer libdrm/intel drivers though, might be worth trying newer ones from https://edge.launchpad.net/~xorg-edgers/+archive/ppa if its annoying enough to be unusable but you still want KMS, or trying again in a few days when bryce updates the ones in karmic 
<cwillu> I'm on edgers already
<Sarvatt> ah
 * cwillu does that thing where he checks one more thing he forgot about
<cwillu> hmm, worked that time
<cwillu> let me suspend 9 more times and then I'll have some confidence in that :p
<cwillu> nope, failed the next time
<Sarvatt> funny, I've actually heard people complaining about suspend/resume hangs alot in the past week since this commit too - https://bugs.freedesktop.org/show_bug.cgi?id=22010
<ubottu> Freedesktop bug 22010 in Driver/intel "[945GM] [Bisected] X hang after suspend" [Normal,New]
<cwillu> the earlier suspend issue I had (the reason why I'm on a daily kernel) is unrelated to X, 
<Sarvatt> yep, X just hung and mouse pointer still functional when i did a suspend/resume there :D
 * cwillu cheers
<Sarvatt> building it now after reverting that commit to see if it makes any difference, i'll put it on edgers if so
<cwillu> sweet
<Sarvatt> well that looks good, first suspend/resume is fine
 * Sarvatt prepares to eat his words
<cwillu> regurgitated words are so tasty
<Sarvatt> 2 3 and 4 are fine \o/
<cwillu> gimmegimmegimme!
<Sarvatt> already uploaded to edgers but it probably wont get built before the publisher runs at 20 after, just want the deb?
<cwillu> sure
<cwillu> :)
 * cwillu beams
<Sarvatt> http://sarvatt.com/downloads/xserver-xorg-video-intel_2.7.99.1+git20090601.704771f1-0ubuntu0sarvatt_i386.deb
<Sarvatt> no KMS cursor flicker patch in it though :D
<cwillu> whatever will I do :p
<Sarvatt> SHOOT cwilllu, wait a second
<Sarvatt> i am using xorg 1.7, built it against that
<Sarvatt> and I doubt you are too lol
<cwillu> heh
<Sarvatt> nooo, i386 just finished
<Sarvatt> 1 minute after the publisher ran
<Sarvatt> 10 suspend/resumes fine here, woohoo
<cwillu> :)
<Sarvatt> i'll hold off updating jaunty until you say it works for you too just incase
<cwillu> are you uploading another deb, or am I waiting for the edger build?
<Sarvatt> edger build, would probably take me the 10 minutes till that gets published to set up pbuilder for it :) it takes less than a minute to compile on my atom cpu if you want to build it yourself though
<cwillu> nah, I can wait an hour :p
<cwillu> I get the feeling there's a kernel bisect in my future anyways :p
<Sarvatt> also reverting to karmics -intel would tell you if that was the problem too
<Sarvatt> well it might have problems in other areas with the same symptom too possibly :D
<cwillu> I need to run, but I'll let you know when I get back
<Sarvatt> oh http://ppa.launchpad.net/xorg-edgers/ubuntu/pool/main/x/xserver-xorg-video-intel/xserver-xorg-video-intel_2.7.99.1+git20090601.704771f1-0ubuntu0sarvatt_i386.deb
<Sarvatt> good luck with it
<cwillu> up already?
<cwillu> nice
<Sarvatt> 25 suspend/resumes, pretty safe to say that fixed it for me
<Sarvatt> gotta love these 2 second flicker free suspend and resumes with KMS, thats for sure
<cwillu> Sarvatt, I know, I squealed the first time I saw the resume work
<cwillu> I mean, okay, fast reboots are nice
<cwillu> but a suspend that's so fast that I'm tempted to change "blank screen" to "suspend" is another thing entirely :)
<Sarvatt> cant beat 2 seconds though, agreed lol
<Sarvatt> talked to 4 people now that reverting that commit fixed suspend/resume for
<cwillu> I just got back, I'll have another yay or nay for you in a minute
<Sarvatt> you have gotta update that drm at least though :D
<Sarvatt> if you're still on 2.4.9 from may 2nd like in that bug report
<cwillu> 2.4.11
 * Sarvatt crosses fingers for you
<Sarvatt> hyperair, check out the mesa i just uploaded to edgers, 30 minutes of running a loop opening/killing firefox and i'm at 211MB gem object bytes with compiz running :)
<Sarvatt> that would hit 1GB in 30 minutes before and it was 186MB just enabling compiz after a fresh boot
<tjaalton> Sarvatt: the dri.pc -issue is already fixed in git
<Sarvatt> woohoo!
<hyperair> Sarvatt: my gem memory has hit 900MB
<bryce> morning
<jcristau> hi bryce. feeling better?
<bryce> yep, much better
<Tm_T> hi kids
<hyperair> Sarvatt: do your brightness keys work with KMS on?
<hyperair> Sarvatt: doesn't work for me
<Sarvatt> i built my own devicekit-power and gnome-power-manager because the 2.26 ones in karmic were buggy as hell for me, but yes they do work :D
<Sarvatt> i like how gnome-power-manager has powertop built in now too
<hyperair> yeah i like it too =)
<hyperair> but i didn't rebuild those two
<jbarnes_LHR> Sarvatt: just pushed a fix for the tearing problem
<hyperair> so gpm only detects my battery level sometimes.
<jbarnes_LHR> Sarvatt: wanna package up a fresh xf86-video-intel for edgers? :)
 * cwillu bounces
<hyperair> thank goodness for the battery charge monitor applet
<Sarvatt> nice, sure thing, was just in the middle of updating mesa
<jbarnes_LHR> cool
 * hyperair sticks a trampoline underneath cwillu before cwillu lands
<hyperair> Sarvatt: anyway: 6h of usage and ~702M GEM memory used. this is much better than what it was previously =)
<hyperair> Sarvatt: but 702M is still excessive.
<jcristau> is that with the mesa patch?
<Sarvatt> i'm at 308MB used after about 14 hours of running an open/close firefox loop that would put me at 1gb in about 30 minutes before
<Sarvatt> yeah I put his take3 patch and the other one on edgers last night
<jcristau> cool
<hyperair> Sarvatt: what's your pciid?
<Sarvatt> are you running the clutter test hyperair? that still leaks to hell for me
<hyperair> er no i'm not
<hyperair> i'm lazy to compile it =(
<hyperair> need a whole lot of dependencies which i'm lazy to track down
<Sarvatt> but he even said it didnt fix clutter
<hyperair> hm
<hyperair> so basically we can conclude that the mem leak had many sources
<hyperair> the fact that you're not seeing it any more means that the source that both you and i had was fixed. but there's another source of memory leaks =O
<hyperair> which i still see
<hyperair> =(
<hyperair> 706M
<Sarvatt> jbarnes_LHR: uploaded, it'll be published at 40 after
<jbarnes_LHR> Sarvatt: cool I'll pull it then
<Sarvatt> darn, yeah, suspend/resume is broken unless I revert http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=8e942b70cb9a784b3f1311affd6fc74c4bcf68bb
<jbarnes_LHR> Sarvatt: oooh you should file a bug for that
<jbarnes_LHR> or raise it on intel-gfx@lists.fdo at least
<jbarnes_LHR> offhand though the revert looks ok
<jbarnes_LHR> with the possible exception of the actual emit call
<jbarnes_LHR> looks like the arg order changed
 * cwillu perks his head up
<cwillu> Sarvatt, I've still got the hang post resume, although the external mouse will move the cursor once if I'm moving it while resuming
<cwillu> not sure if this is relevant to that commit revert
<cwillu> on the other hand, I can suspend dozens of times in a row with kms disabled
<jbarnes_LHR> Sarvatt: what's the version number?
<jbarnes_LHR> Sarvatt: ah nm, got the git commit
<Sarvatt> sorry, stepped away while mesa was building, it was a bug report for the same issue that got me to try it after reverting to see if it fixed it and it did, its https://edge.launchpad.net/%7Exorg-edgers/+archive/ppa/+sourcepub/642605/+listing-archive-extra
<Sarvatt> did you want me to apply your cursor flicker patch to it too?
<jbarnes_LHR> w00t
<jbarnes_LHR> no tearing
<Sarvatt> did you mean for me to apply your cursor flicker patch too jbarnes?
<jbarnes_LHR> Sarvatt: nah that one isn't as important
<hyperair> ooh there's a cursor flicker patch!
<hyperair> O_O
 * hyperair would really love a more substantial mem leak patch, though this will do nicely for now
<hyperair> until i need to virtualize anything
<Zorael> Question: When I log out, X crashes with a backlog in Xorg.0.log and shoves me to the terminal. As I'm running the intel driver with KMS enabled, should such a bug be filed against X or xserver-xorg-video-intel?
<hyperair> the last time i ran virtualbox, i oom-ed within 2 hours.
<Zorael> backtrace*
<Zorael> obviously. :3
<Sarvatt> hyperair if you were using edgers you were using the cursor flicker patch for about 2 weeks :D
<hyperair> Sarvatt: ..no way.
<hyperair> Sarvatt: i still see a flickering cursor damnit.
<Sarvatt> does it go corrupted sometimes too?
<hyperair> er no
<hyperair> actually the cursor itself doesn't flicker
<hyperair> the area around it does
<hyperair> like one square area
<Sarvatt> yeah
<Sarvatt> thats what i meant, sorry
<hyperair> oh, and some of my icons get corrupted
<hyperair> e.g. my battery charge applet
<hyperair> the gnome-panel applet
<hyperair> not gpm
<Sarvatt> i'm glad its down to just little things like that compared to being completely able to use uxa with all of the crashes a month ago at this time :D
<Sarvatt> *completely unable
<hyperair> heh yeah
<hyperair> wait
<hyperair> i've got oen moer issue
<hyperair> er
<hyperair> resuming from hibernation, basically
<hyperair> it hangs upon resuming from hibernation
<hyperair> it doesn't appear to happen for suspend
<hyperair> but hibernation, yes.
<hyperair> so i've been walking around with my notebook draining power in suspend to ram state
<Sarvatt> hmm at 741mb gem objects now, looks like those mesa patches fixed it for opening and closing firefox but its still leaking during actual use (albiet slower)
<Sarvatt> but its no increasing no matter what i do now, something just made it jump 300mb in the past hour
<hyperair> hmm
<hyperair> interesting eh
<bryce> Sarvatt: I see there is a 0602 snapshot of -intel in edgers now; how much testing has that one gotten?  Is it sane for me to pull that into karmic, or would an older snapshot be safer?
<Sarvatt> it's basically the same as debian-experimental and the one thats been in edgers for a week with a fix for video tearing jbarnes just pushed a few hours ago
<bryce> ok, I'll pull it
<Sarvatt> heyo tormod, they reverted that gamma commit you had a problem with in xserver master. uploading it now since i wanted to test out changes to the hooks anyway :)
<Sarvatt> not that it'll build anytime soon with the firefox build bot of doom running still
 * cwillu points out the existence of bug #382884 to Sarvatt :p
<ubottu> Launchpad bug 382884 in xorg "[KMS] [GM945]: Xorg hang after resume from suspend" [Undecided,Confirmed] https://launchpad.net/bugs/382884
<cwillu> that's odd
#ubuntu-x 2009-06-03
<bryce> libdrm, 2.7.99.1+git uploaded
<tjaalton> compiz is still disabled for i965.. mvo?
<mvo> tjaalton: yes, is the driver all good now so that this can be changed?
<tjaalton> mvo: I've been using it for a couple of weeks in karmic with no issues
<mvo> tjaalton: thanks, I fix it in bzr
<tjaalton> mvo: cool, thanks
<lool> Is "xset force dpms off" supposed to work with KMS?
<apw> damn .... xorg sigsegv, not handy
<apw> jbarnes, is in the UK?
<apw> jbarnes_LHR, even
<apw> bryce, seeing coredumps on the standard xorg server (not kms) on an intel deskside
<jbarnes_LHR> yep in the UK
<jbarnes_LHR> london near the tower bridge
<apw> heh, for long?  having fun?
<tjaalton> apparently not ;)
<jcristau> lool: not sure dpms is hooked up yet
<tseliot> tjaalton, jcristau: is xserver-xorg the only package that calls dexconf?
<jcristau> tseliot: if it's not, i'd love to know
<tjaalton> should be, yes :)
<tseliot> jcristau: I built an image with a package that modifies the xorg.conf (for the OEM team) and I predepend on xserver-xorg but it looks like my modified xorg.conf is renamed as xorg.conf.$date and dexconf is called
<tseliot> my package modifies the xorg.conf in the postinst and I'm wondering why xserver-xorg modifies the xorg.conf after my package
<tseliot> despite the predepends
<tseliot> maybe debconf is delayed?
<jcristau> dpkg tells you when it configures packages
<jcristau> so check what gets configured after your package?
<tseliot> This happens before my package is installed: Setting up xserver-xorg (1:7.4~5ubuntu18) ... xserver-xorg postinst warning: not updating configuration as per $XORG_CUSTOM 
<tseliot> then my package is configured. The rest is just a standard jaunty installation
<tseliot> jcristau: these are configured after my package:
<tseliot> Setting up xinit (1.0.9-2) ... Setting up xinput (1.4.0-1) ... Setting up xorg (1:7.4~5ubuntu18) ... Setting up xscreensaver-gl (5.07-0ubuntu3) ... 
<jcristau> none of those touch xorg.conf..
<tseliot> yes, I know
<tseliot> but it looks like the xorg.conf that my package modifies is still empty in spite of the fact that xserver-xorg has already been configured
<tseliot> the preinst of xserver-xorg creates an empty file
<tseliot> which is filled in the postinst of xserver-xorg
<tjaalton> default jaunty installation results in an empty xorg.conf
<tseliot> tjaalton: not here. It has Device, Screen and Monitor sections
<jcristau> tseliot: ah right.  i should fix that.
<tseliot> jcristau: ? What do you need to fix (and how)?
<jcristau> make sure i don't create an empty xorg.conf
<tseliot> ok
<tjaalton> tseliot: ok, maybe happens only when doing a preseeded installation
<tseliot> tjaalton: and how can I get around the problem? Shall I predepend on the "xorg" metapackage?
<jcristau> 'not updating configuration as per $XORG_CONFIG' means you set XORG_CONFIG=custom in /etc/default/xorg, so xserver-xorg.postinst exits without doing anything
<tseliot> jcristau: but there's no such file in the generated image
<jcristau> *shrug*
<tseliot> and dexconf is being called. Maybe something reconfigures xserver-xorg at a certain point
* You're now known as ubuntulog
<tseliot> jcristau: shouldn't this: http://pastebin.ubuntu.com/187401/ be more like this? http://pastebin.ubuntu.com/187404/
<jcristau> dunno, what's the difference?
<jcristau> i mean, why not allow XORG_CONFIG from the environment rather than that default file?
<tseliot> where can that variable be defined apart from the default file?
<jcristau> your environment
<tseliot> ok, so somewhere in this system has that variable set to custom...
<tseliot> without sourcing?
<bryce> morning
<tseliot> hey bryce
<bryce> tseliot: heya, all done with demos and such?  hope all went well :-)
<tseliot> bryce: I'm still fighting with xserver-xorg which is overwriting my customised xorg.conf even though I predepend on it :-(
<bryce> apw: if you can reproduce the crash and get a full backtrace (process documented at http://wiki.ubuntu.com/X/) it could help
<apw> bryce, yep 100% reproucible
<tseliot> jcristau: removing the postinst/preinst, etc. of xserver-xorg shouldn't cause problems, right? (just to be sure)
<jcristau> dunno.
<Sarvatt> wow, now this looks interesting http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h=5112f5941c34ea49155a02672647c61afb1e6bf5
<micahg> bryce: could you look at a bug for me, it seems to match an upstream link for 2 other bugs you were workign on
<micahg> bug 374398
<ubottu> Launchpad bug 374398 in xserver-xorg-video-ati "Glitches around checkboxes in Firefox" [Undecided,New] https://launchpad.net/bugs/374398
<bryce> hi micahg, what aspect needs looked at?
<micahg> if it should be merged with bug 291053
<ubottu> Launchpad bug 291053 in xserver-xorg-driver-ati "[R500 x1400] Occasional mouse cursor corruption [EXA enabled]" [Unknown,Confirmed] https://launchpad.net/bugs/291053
<bryce> fwiw, there's a slew of known glitches with -ati since we moved to EXA.
<micahg> that's good to know
<bryce> yes, it could well be a dupe
<micahg> do you want to change what's appropriate in the title in the original?
<micahg> or does more triage need to happen
<bryce> it can probably be changed to "Small pixmap corruption [EXA enabled]" to match upstream's bug title
<micahg> ok, and I should just mark as dupe then?
<bryce> micahg: at this stage what needs done is to test patches alex provides and give feedback
<bryce> micahg: yes that sounds good
<micahg> are the patches upstream?
<bryce> they get posted on the upstream bug report
<bryce> alex likes to have folks test them before he puts them in the upstream tree
<micahg> Where should people comment about the patches, upstream, right?
<bryce> yes, on the upstream bug
<micahg> ok
<micahg> done
<bryce> thanks micahg :-)
<micahg> no problem, I just wasn't sure what to do as I normally work on Firefox bugs
<micahg> now I know where to go for X bugs :)
<bryce> micahg: what do you work on normally?
<micahg> Firefox bugs
<bryce> ah kewl
<micahg> bryce: may I PM you
<bryce> yeah, oftentimes the firefox X bugs are display issues rather than freezes/crashes, so since they're cosmetic often aren't given as much attention
<bryce> so if you can take them upstream directly, it could help out a lot
<bryce> micahg: if it is about something private; otherwise if it's just X questions this channel is most appropriate
<micahg> the problem is usually figuring out which other component is causing the trouble
<bryce> micahg: btw there's some info at http://wiki.ubuntu.com/X/ that could be useful
<bryce> covers how to triage X bugs, how to troubleshoot issues, and so forth.  It should help answer the question about what component causes what problem
<micahg> I should probably read that
<bryce> as a general rule, display issues are almost always caused either by the video driver the user is using
<apw> bryce, added the full stack trace to the bug
<bryce> s/either//
<bryce> apw: excellent thanks
<apw> I830DRI2CopyRegion() goes pop :)  have fun
<bryce> micahg: er I should say, if the problem is an X bug, it's usually in the video driver.  Sometimes with firefox the issues have been further up the stack in cairo or an intermediate library
<bryce> apw: was this while viewing a really large jpg?
<apw> nope.  this is while engaging the screen saver
<bryce> hmm
<apw> it fades to black then dumps
<Sarvatt> gl screensaver?
<apw> i guess its making a big black square to hide the screen
<bryce> ahh
<apw> default gnome screen saver
<bryce> apw: the 2.7.99.1 upload I did yesterday had a fix for a crash bug involving I830DRI2CopyRegion() when viewing large jpg images
<apw> hrm when might that hit the archives.  i updated within the last two hours
<bryce> yikes, there is a fricken huge spider on the ceiling above me.
<bryce> apw: should have hit last night some time
<apw> it wants you for lunch
<bryce> apt-cache madison xserver-xorg-video-intel
<apw> apw@chloe:~$ apt-cache madison xserver-xorg-video-intel
<apw> xserver-xorg-video-intel | 2:2.7.99.1+git20090602.ec2fde7c-0ubuntu1 | http://gb.archive.ubuntu.com karmic/main Packages
<apw> xserver-xorg-video-intel | 2:2.7.99.1+git20090602.ec2fde7c-0ubuntu1 | http://gb.archive.ubuntu.com karmic/main Sources
<bryce> apt-cache policy xserver-xorg-video-intel ?
<bryce> (spider got away, crazy fast mfker)
<tormod> famous last words
<Sarvatt> bryce: this relevant? http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=b8e360bf2b77d28559d15a7c0f9c766848eb6ced
<Sarvatt> regarding apw's backtrace
<Sarvatt> also http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=5901a67fc85ac80fabfa98b78202a388445275c3
<apw> apw@chloe:~$ apt-cache policy xserver-xorg-video-intel
<apw> xserver-xorg-video-intel:
<apw>   Installed: 2:2.7.99.1+git20090602.ec2fde7c-0ubuntu1
<apw>   Candidate: 2:2.7.99.1+git20090602.ec2fde7c-0ubuntu1
<apw>   Version table:
<apw>  *** 2:2.7.99.1+git20090602.ec2fde7c-0ubuntu1 0
<apw>         500 http://gb.archive.ubuntu.com karmic/main Packages
<apw>         100 /var/lib/dpkg/status
<Sarvatt> updating edgers now
<apw> bryce, need anything else?
<bryce>  pDestBuffer = (DRI2BufferPtr) 0x0
<bryce> apw: nope, looks like a good trace I can take it from here
<apw> ouch ...
<bryce> apw: later we may have some patches to test
<apw> sure thing.  ping me, i may be here still if not shove them somewhere and i'll get to them first thing
<apw> i am guessing most of us are using the edgers things to get kms and not testing what the basic users get!
<bryce> ok, may be a few hours, I have an AMD confcall in a few hours
<apw> i don't need the machine its on for interactive use so it can hang around waiting for you
<apw> ie. no rush, whenever suits
<cwillu> apw, re: the 2.6.30-999 resume swapper crash I had recently, I wasn't at home, so I didn't have netconsole running.  I'll try to duplicate it again today.  I've got a different issue when I resume with kms enabled, so I'm trying to split my time between the two ways I can make it crash :)
<apw> heheh fun for all the family for sure
<cwillu> re: trace, you just want the console output, right?
<cwillu> I'll try to work off 2.6.30-7 #8 with kms off, if that dupes easily, I'll move up to the latest daily and dupe it there too
<Sarvatt> apw: https://edge.launchpad.net/~sarvatt/+archive/ppa/+sourcepub/643434/+listing-archive-extra
<apw> Sarvatt, looking good here
<Sarvatt> good to hear, there was a last minute commit to enable vsync for DRI2 CopyRegion (to fix tearing problems) that made it into the 06-02 and it got fixed up by a bunch of commits this morning
<apw> and your test there was just picking up those fixes too
<apw> Sarvatt, this is logged under bug #383129
<ubottu> Launchpad bug 383129 in xorg "x server dies with a SIGSEGV when gnome screen saver blanks the display" [Undecided,New] https://launchpad.net/bugs/383129
<Sarvatt> holy hell, anholt's latest commit in for-review on drm-intel sped up 3d performance in UXA an amazing amount for me
<Sarvatt> sorry, wrong channel yet again
<Sarvatt> relevant here though, I'm seeing a 50% 3D performance increase in everything i've run so far on intel, not just openarena at high settings like the commit says. i put a kernel here incase anyone else wants to test it out http://sarvatt.com/downloads/LATEST/
<bryce> Sarvatt: kewl
<crevette> wow, kms is wonderful, instant switching between VT
<crevette> and full resolution in terminal
<bryce> :-)
<jcristau> and no vt switch on s/r
<crevette> I rarely suspend my laptop
<tjaalton> jcristau: do you think we could --disable-gallium until the packaging issues are sorted out?
<tjaalton> of mesa
<jcristau> tjaalton: i was going to wait for a reply from michel
<tjaalton> jcristau: ok
<jcristau> tjaalton: maybe you can ping him about it on irc?
<tjaalton> sure, could do that
<hyperair> Sarvatt: did i mention yet that the cursor gets hopelessly corrupted after hibernating and resuming?
<Sarvatt> just hibernate or suspend/resume too? why dont you file bug reports on fd.o about the problems you have? :D
<Sarvatt> if its suspend/resume too -- http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h=596652e1094a9c7bebcd4d36a7f3d3a2d9698950  can try that kernel i just pasted to see if its fixed by that
<solarion> is the intel driver crashing Xorg (sig 11) when full-screening things a known problem?
<Sarvatt> yup
<Sarvatt> can grab https://edge.launchpad.net/%7Esarvatt/+archive/ppa/+sourcepub/643434/+listing-archive-extra or disable compiz until its updated
<solarion> why is it a compiz problem?
<solarion> ah, not a compiz probelm; compiz-triggered
<Sarvatt> yeah compiz triggered, sorry
<solarion> is ok; just saw a compiz update come through
<solarion> any idea when it'll get fixed in the ppa or karmic?
<Sarvatt> just linked a PPA with the fix in it :)
<solarion> it's not the ubuntu-x-swat ppa
 * solarion is leery of installing from unknown repos
<Sarvatt> the one i linked is drop in replaceable with karmic, its also in xorg-edgers but you'd have to upgrade drm too to use that one
<Sarvatt> ah understandable
<solarion> is there any point to having the jaunty x-swat repo in?
<solarion> it's too bad you can't limit what can come out of a repo
<solarion> the best I can figure atm is not including the keys and then watching what comes unsigned, but it's unsigned.
#ubuntu-x 2009-06-04
<hyperair> bah. mplayer hangs with DRI failure now?!
<hyperair> oh wait. no, this is a pulseaudio issue
<hyperair> stupid flash
<hyperair> Sarvatt: do you get crashes when the scale plugin of compiz is activated?
<hyperair> Sarvatt: http://pastebin.com/f4d192c93 <-- looks like an upgrade in mesa caused it
<hyperair> Sarvatt: the 0602 mesa git doesn't cause the crash.
<Milan-BV> I'd like to debug KMS on 2.6.30rc kernels, with an Intel i915 card - is this the place for it, or do you prefer me to go to the kernel channel?
<apw> a tricky one, as the x side belongs here and the kernel side on #u-k, but i'd recommend starting here
<Milan-BV> OK
<Milan-BV> actually, my system won't finish to boot when I enable KMs and updat emy initramfs
<apw> what card do you have
<Milan-BV> the screen gets blank in the middle of the boot
<Milan-BV> Intel i915 GM
<apw> do you have the updated x-server components you need for kms?
<Milan-BV> 2.7.1
<jcristau> you probably want something newer than 2.7.1
<apw> and mesa etc?
<apw> there is a specific ppa for kms support iirc
<Milan-BV> I guess, I'm using the ubuntu-x-swat PPA
<Milan-BV> do you think 2.7.99 is required?
<Milan-BV> I've tested it too, but there are terrible mem leaks, so that's not very practical for now
<jcristau> terrible mem leaks shouldn't prevent booting
<Milan-BV> but since I have problems before X starts, I think the problem comes from elsewhere
<jcristau> when does the monitor turn blank?
<Milan-BV> no, they don't, but this means I must go back to 2.7.1 after testing to really work on my box
<Milan-BV> in the middle of the boot
<apw> is the machine up after it turns black?  does ctrl-alt-f1 get you a console?  can you login over ssh?
<jcristau> that's not terribly specific :)
<Milan-BV> and then my fan starts, just like the GPU/CPU was working too hard
<Milan-BV> no, complete freeze
<Milan-BV> I've not tried SSH, though
<Milan-BV> I'd like to know what logs you need before doing so
<apw> can you try booting with quiet and splash removed and see what the last thing said was
<apw> if you can login then dmesg would be interesting, and a ps listing
<Milan-BV> yeah, that's an idea
<Milan-BV> actually, I had tried that in another situation:
<Milan-BV> if I only change the conf file in /etc/modprobe.d, I'm able to boot with older 2.6.30 rc's
<Milan-BV> the screen goes blank, but when GDM starts everything is fine
<apw> so thats normal behaviour yes, sl
<Milan-BV> and then I noticed the screen went blank when the manual modules were loaded - includin gi915 I guess
<apw> splash, black, gdm
<Milan-BV> yeah - logical
<Milan-BV> OK I can just reboot and tell you what logs I get
<apw> as you get hte hard hang and fans, i'd guess kernel hang, and i'd say the first thing to try is removing splash/quiet
<Milan-BV> would you need GPU batch buffers too?
 * apw is a simple kernel guy ....
<jcristau> Milan-BV: start with dmesg for now :)
<Milan-BV> OK, I start with dmesg - anyway that avoid the need to SSH, which is a pain (Windows laptops...)
<Milan-BV> see you soon...
<Milan-BV> so I'm back
<Milan-BV> with good new: you were right
<Milan-BV> I had not tested the combination 2.6.30rc7 and latest 2.7.99
<Milan-BV> that works now
<jcristau> cool
<Milan-BV> the problem was with one of the many versions of kernels and drivers I've tested
<Milan-BV> now I just need Intel guys to fix my leak ;-)
<Milan-BV> one question though: it seems that the boot splash is not using a high resolution
<Milan-BV> when I stop the computer, it's much nicer and bigger
<Milan-BV> (maybe that's not a concern if many changes will be going on before Karmic, though)
 * apw waves to brye
 * apw waves to bryce
<bryce> heya apw
<apw> bryce, is the xedgers pile going to support kms ati should we have it?
<apw> and do you have something that can test with an ati kms enabled kernel?
<bryce> yep, that's the plan
<apw> plan as in it will, or as in it should?
<bryce> sure, I've got a test box with pci nvidia and ati cards
<bryce> should
<apw> ok i've put up a dirty roll-forward kernel in a PPA if you are intrested in testing it
<bryce> yes, definitely
<apw> its a simple roll forward of gliss' patch pile so i have no idea if it even boots
<bryce> ok, I need to update my box but can probably test it later today or tomorrow
<apw> https://edge.launchpad.net/~apw/+archive/daily
<apw> is a badly documented kernel the kms1 one ... it has the radeon patch stack on it.  any feedback you can get is perfect
<bryce> cool, yeah I just need to update -intel for that bug you found yesterday, then will hammer on ati
<bryce> hmm, this has an RV680 in it currently; wonder if that's too new?
<Sarvatt> you'd need different drm, drivers and mesa than edgers and the ati kms specific branches arent mergeable yet last i looked so it'd probably have to be another PPA
<Sarvatt> as far as I could see, it was all so confusing because theres so many different branches of everything out there for it specific to certain cards
 * Sarvatt groans at the pain in the butt the XI2 merge is turning out to be
<Sarvatt> does your kernel generate a new linux-libc-dev apw?
<Sarvatt> ah sorry i can look myself
<apw> Sarvatt, likely yes
<apw> is that good or bad i wonder <- Sarvatt 
<jcristau> apw: probably good, as the drm headers will be needed for libdrm-radeon
<jcristau> for the new ioctls and stuff
<apw> ahh thats handy
<Sarvatt> doesnt look like it does, just wondering because you'd have to add Replaces: linux-libc-dev and override the header deletion from the libdrm package built for it
<tseliot> tjaalton, wgrant: are we going to get a new release of synaptics for karmic?
<tseliot> i.e. newer than the current version
<apw> why would i need to replace it, as the new one would be a direct replacement
<Sarvatt> i'm blind and i thought i didnt see the new linux-libc-dev in the dsc, sorry apw
<apw> :)
<Sarvatt> tseliot: been alot of complaints about the lastest synaptics in karmic with the default tap disabled, thats for sure
<tseliot> Sarvatt: that's because I haven't ported my patches to the new driver in Karmic ;)
<Sarvatt> they all still apply fine except 108 and 109, i think wgrant fixed up 109 to apply on the lastest though on his PPA but not sure how relevant it is anymore
<Sarvatt> (the alps one)
<tseliot> one of my patches re-enabled tapping
<tseliot> hmm... I see only 2 patches in the karmic package
<tseliot> neither of which is mine
<jcristau> that's probably bug 378391
<ubottu> Launchpad bug 378391 in xserver-xorg-input-synaptics "Source rename clobbered local changes (so tapping not working in Karmic)" [High,In progress] https://launchpad.net/bugs/378391
<bryce> apw: fix for bug 383129 is uploaded
<ubottu> Launchpad bug 383129 in xserver-xorg-video-intel "x server dies with a SIGSEGV when gnome screen saver blanks the display" [Undecided,Confirmed] https://launchpad.net/bugs/383129
 * hyperair waves at Sarvatt 
<tjaalton> tseliot: I believe so, why?
<Sarvatt> ahhh what a headache, my x11proto-input-dev.install needed changes, only took me 3 hours and a crapload of builds to figure it out lol
<Ng> interestingness, the occasional, logless X crashes on resume I was having in jaunty with all versions of the intel driver appear to be entirely reproducible in karmic
<Ng> which is a shame because I like suspending, but on the plus side, I now have a couple of logs of the backtrace
<Ng> I'll get it all in a bug on LP just as soon as I go find a keyboard so I can log into the machine that has my jaunty stuff backed up onto it, including the ssh key I need to get into that machine ;)
<Ng> oh wow, locking the screen and pressing a key crashes X too
<Sarvatt> Ng what driver are you using? 
<tseliot> tjaalton: so as not to have to rewrite my patches more than once ;)
<Ng> Sarvatt: karmic's intel
<bryce> Ng: if the latter crash is bug 383129, I just uploaded a fix for it
<Sarvatt> the git200602 has problems where it'd crash X with just about anything fullscreen
<ubottu> Launchpad bug 383129 in xserver-xorg-video-intel "x server dies with a SIGSEGV when gnome screen saver blanks the display" [Undecided,Fix released] https://launchpad.net/bugs/383129
 * Sarvatt cheers
 * Ng has a peek
<tjaalton> tseliot: push them upstream if the defaults are wron
<tjaalton> +g
<tjaalton> gotta go ->
<Ng> bryce: certainly sounds similar, I'll wait until that hits the archive to test it
<Ng> I'm really glad I decided to do a karmic re-install on my week off, I already found a bunch of bugs :)
<Ng> bryce: I'd expect it might actually fix both things, since resuming will involve doing fullscreeny things like locking
<Sarvatt> you could test now by disabling compiz and seeing if it works :D
<Ng> Sarvatt: testing from a gdm screen it doesn't crash :)
<Ng> it's also damn fast :o
<Ng> can we get rid of the stupid fading thing for screen locking? that seems to take the longest ;)
<Sarvatt> thats a compiz plugin isnt it?
<Ng> quite possibly, but I'm not sure
<hyperair> i think gnome-screensaver does the fading.
<hyperair> at the very least, i don't have any compiz plugin that fades stuff so slowly
<Ng> Sarvatt: oh, it continues to not crash when testing suspend/resume from gdm, but the mouse pointer does disappear until I switch vt and back
<hyperair> by the way, Sarvatt, did you get my message about the mesa crash?
<Sarvatt> login/logout plugin in compiz maybe?
<hyperair> is there such a thing?
<hyperair> oh there is
<hyperair> it's not enabled for me
<Sarvatt> no i didnt, been busy all morning trying to get xserver 1.7 working with the XI2 merge before the firefox buildbot of doom runs in an hour and makes it so you cant retry builds for 4 hours :D
<hyperair> hahahahaha
<hyperair> xD
<hyperair> good luck =p
<hyperair> by the way, does XI2 mean i get one pointer for my mouse and one pointer for my touchpad? O_o
 * hyperair is about to go git bisecting
<hyperair> then i'll be able to isolate the commit
<Sarvatt> in a bit when i get this working i'll upload a mesa without the 2 patches
<hyperair> i dont' think it's the two patches.
<hyperair> the two patches were enabled in yesterday's build, right?
<hyperair> i mean 0602's
<hyperair> 0603 has issues.
<hyperair> 0602 doesn't
<Sarvatt> can you install the dbg packages for the backtrace? wasnt any info in the one you pastebinned
<hyperair> and oh hell, i accidentally purged my /tmp instead of ./tmp folder
<hyperair> right
<Sarvatt> scale plugin is working fine here
<hyperair> is it?
<hyperair> hmm
<Sarvatt> 945 though and im not using edgers
<hyperair> ah.
<hyperair> the edgers' mesa had issues =\
<hyperair> has
<Sarvatt> i'm using the same mesa but its built against a newer dri2proto
 * hyperair groans. how long does mesa take to compile?!
<jbarnes_LHR> hyperair: it's fast if you disable everything and only enable the driver you want
<hyperair> it's been 40 minutes already!
<hyperair> hmm
<hyperair> disable everything huh
<jbarnes_LHR> --disable-gallium --disable-glut --with-dri-drivers=i965 (or whatever)
<hyperair> O_o
<hyperair> hmm
<hyperair> i should do that huh
<hyperair> hmm
 * hyperair pkoes around the debian/rules
<hyperair> it looks scary
<hyperair> positively scary
<Sarvatt> anyone happen to know what could be causing that build error? http://tinyurl.com/qow2tr
<Sarvatt> sorry, guess i should ask in MOTU
<Sarvatt> hyperair, one sec i'll give you a rules to build a minimal version
<hyperair> thanks
<hyperair> but wait
<hyperair> i think if i override DRI_DRIVERS i can get a minimal version, right?
<Ng> bryce: looks like that upload fixed both the things I was seeing \o/
<bryce> Sarvatt: you need newer x11proto-input
<bryce> Ng: excellent
<Sarvatt> Unpacking x11proto-input-dev (from .../x11proto-input-dev_1.9.99.10+git20090604.56da1968-0ubuntu0sarvatt2_all.deb) ...
<Sarvatt> my x11proto-input must be messed up
<bryce> oh wait, I'm wrong
<bryce> this is the error:
<bryce> ../configure: line 11256: syntax error near unexpected token `XI,'
<bryce> is the comma out of place?
<bryce> anyway, it's unhappy with something in this line:
<bryce> ../configure: line 11256: `PKG_CHECK_MODULES(XI, xproto >= 7.0.13 x11 >= 1.1.99.1 xextproto >= 7.0.3 xext >= 1.0.99.1 inputproto >= 1.9.99.10)'
<hyperair> wait a sec
<hyperair> if that line is there, then PKG_CHECK_MODULES was not expanded
<hyperair> the macro wasn't expanded.
<hyperair> are you missing pkg-config or something?
<Sarvatt> yeah i dont know why the comma is screwing up but it doesnt screw it up from libxi with the same line in the script 2 days ago
 * hyperair still thinks that the macro wasn't expanded.
 * hyperair pokes Sarvatt 
<hyperair> PKG_CHECK_MODULES should not appear in the configure script at all.
<Sarvatt> it all builds fine locally so i'm guessing its a build depends problem but the same exact build depends were working 2 days ago in thjaeger's PPA
<hyperair> Sarvatt: add pkg-config to the build-dep. it should fix the issue.
<Sarvatt> it's in it already
<hyperair> are you sure?
<hyperair> the build log doesn't seem to show pkg-config being installed
<Sarvatt> hmmm
<Sarvatt> ahhhh hell
<Sarvatt> teach me to do that at 6 am
<Sarvatt>  x11proto-input-dev (>= 1.9.99.10)
<Sarvatt>  pkg-config,
<Sarvatt> no comma
<bryce> aha
<Sarvatt> thanks guys :)
<hyperair> hehehe
<hyperair> meh maybe i should have done -j2
<Sarvatt> now i wonder if i should be rebuilding input drivers from master or merging in whot's seperate XI2 input driver repos into them..
<hyperair> note to self: lower cpu frequency before pulling something like make -j2 off.
<bryce> Sarvatt: I can sympathize!
<bryce> er, nevermind
<Sarvatt> sure would be nice to move this whole PPA over to edgers where other people could help (hint hint tormod)
<Sarvatt> go figure he isnt in here :D
<Sarvatt> sorry we're using 7.5.0 and 7.6.0 for mesa by the way, thats how it comes out with the scripts and i dont know how to go back and fix it now without getting people stick on the package versions they have now since 7.6~git would be lower
<Sarvatt> ah looks like the animated cursor patch needs to go now too
<Sarvatt> yeesh, in over my head now - http://launchpadlibrarian.net/27504178/buildlog_ubuntu-karmic-i386.xorg-server_2%3A1.6.99.1%2Bgit20090604.993daf06-0ubuntu0sarvatt3_FAILEDTOBUILD.txt.gz
<bryce> ew
<bryce> apw, hmm, testing your -ati kernel bits now.  Kernel boots up okay and gdm displays the login screen, but I get an unusual gconf error message when trying to log in.
<bryce> "There is a problem with the configuration server."  Haven't seen that one before.
<apw> bryce, would we say kms is on?
<bryce> but this is after doing a full dist-upgrade to latest bits, so could be some other thing
<apw> gnome-settings-manager has been changed, and if i am right is taking near 30s to start
<bryce> apw: doesn't look like it... do I need to set a modprobe.d flag like with intel?
<apw> as my cpu stays in perf for some time
<apw> hrm
<Sarvatt> do you see a drmfb loading in the dmesg?
<bryce> Sarvatt: nope, but I see an error message
<apw> the help on the option i enabled claiimed to enable by default
<apw> but then its prolly lying
<bryce> [drm:radeon_driver_load_kms] *ERROR* Failed to initialize radeon, disabling IOCTL
<bryce> fwiw, this is on a RV630.  Probably I need a >=R5xx card
<bryce> mm
<apw> MODULE_PARM_DESC(modeset, "Disable/Enable modesetting");
<apw> module_param_named(modeset, radeon_modeset, int, 0400);
<apw> though i enabled CONFIG_DRM_RADEON_KMS which is meant to default it on
<Sarvatt> There is no support for r6xx/r7xx (so your card is not supported) hw yet.
<Sarvatt> thats what jglisse says about that error to someone on his livejournal http://jglisse.livejournal.com/1822.html?thread=7198
<apw> bottom
<rawler> anyone else with problems using KMS on their Mac Mini?
<rawler> just found http://lists.freedesktop.org/archives/intel-gfx/2009-February/001249.html about the problem.. seems like there's a semi-hack-patch for a quick workaround..
<bryce> ok, I also have an x1550 which purports to be an R520, let's try that next...
<rawler> doesn't seem to be in the Karmic kernels yet, though.. any pointers on getting it there?
<Sarvatt> it is and its completely different now
<Sarvatt> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=history;f=drivers/gpu/drm/i915/intel_lvds.c;h=53731f0ffcb52b4d3444cdfe659f38b5fec479a0;hb=HEAD
<rawler> oki.. must be something else b0rking, then.. :)
<bryce> ...yay \o/ kms on -ati
<rawler> maybe that dmesg is shouting "i915 0000:00:02.0: DVI-D-1: no EDID data"
<bryce> logs in ok too now
<bryce> fb0: radeondrmfb frame buffer device
<bryce> apw: success
<apw> bryce rocking ... thanks
<bryce> I'll take a quick shot running my xsmoke test on it...
<apw> bryce, excellent
<Sarvatt> rawler: maybe search bugs.freedesktop.org for mac mini (or mac EDID kms) too see if you can get any hints about it
<bryce> um, this is weird
<bryce> not even sure how to describe it...  the console got shifted over to the right and wraps from right to left
<hyperair> yay second step of bisect done.
 * bryce tries running individual tests manually...
<bryce> apw: hmm, no DRI or DRI2 loaded for some reason (so no compiz)
<bryce> wait, I think I know the cause of this...
<hyperair> O_o
<bryce> nope, I'm wrong.  Something is not right in DRM land here
<apw> bryce, hrm ... 
<rawler> Sarvatt: yep.. I have been..
<bryce> (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.
<bryce> [dri] Disabling DRI.
<bryce> (II) AIGLX: Screen 0 is not DRI2 capable
<bryce> version mismatch... sounds fixable
<rawler> Sarvatt: I found https://bugzilla.redhat.com/show_bug.cgi?id=501042, which fits my problem (I get those same messages in dmesg, and are using DVI-over-HDMI)
<ubottu> bugzilla.redhat.com bug 501042 in kernel "unable to read EDID block when using TV connected via HDMI to DVI cable" [Medium,New]
<rawler> Sarvatt: so, I tried connecting it to my raw-dvi-monitor, which finally gave me some sort of picture, but it was severly distored, and the system didn't really boot..
<bryce> ok, on to next test... video playback
<Sarvatt> did you use arlied or jglisse's kms apw?
<Sarvatt> guessing jglisse's since it didnt work on his rv630
<apw> jglisse 
<apw> as airlied's handn't been updated when i cehcked
<apw> bryce, there are two new commits in glisse's tre
<Sarvatt> when i get some free time i can put together the other bits you need, modesetting-gem of libdrm, radeon-gem-cs3 of xf86-video-ati
<bryce> okayyy no xv
<bryce> xrandr seems to work though :-)
<bryce> chvt works, but it's not as quick as I've seen on intel
<bryce> heya tormod
<Sarvatt> drm built
<bryce> tormod: we've got kms on -ati :-)
<tormod> hi bryce, I think I heard rumour about it
<tormod> in a ppa? which libdrm branch/patch?
<bryce> suspend/resume sort of worked.  I got a zebra stripe corruption on the screen but vtswitching cleared it
<bryce> tormod: <apw> https://edge.launchpad.net/~apw/+archive/daily
<Sarvatt> i'm putting the other packages you need here (the karmic ones as they come along), feel free to copy it over :)
<Sarvatt> https://edge.launchpad.net/~sarvatt/+archive/ati
<bryce> tormod: I didn't do any -ati or libdrm changes, this is just with the X bits currently in karmic
<bryce> tormod: however X came up without DRI or Xv so it's a bit unuseful, but otherwise works
<tormod> nice, oh really no funky branches needed?
<Sarvatt> only problem is modesetting-gem is 2.4.4 and I think radeon-rewrite needs 2.4.5
<Sarvatt> yeah funky branches needed
<bryce> tormod: well, probably for DRI and Xv and fast vtswitching and so on we'll need more funkiness, but good start so far
<tormod> Sarvatt: I saw a patch floating around against current libdrm
<tormod> apw: bad changelog :) which branches of which repo did you merge in?
<bryce> Sarvatt: kewl thanks for doing the ppa
<tormod> Sarvatt: http://neo-technical.wikispaces.com/kms-glisse links to a patch
<Sarvatt> ./auto-xorg-git -d origin/debian-unstable -u git://people.freedesktop.org/~glisse/xf86-video-ati -b radeon-gem-cs3 -e 1 -H hooks-karmic ati    for ddx
<Sarvatt> oh nice
<bryce> mm, time for lunch first.  bbiab
<tormod> Sarvatt: let's make a "radeon-kms" ppa in xorg-edgers
<Sarvatt> sure, copy stuff over :D
<tormod> will you try that patch or should I take a look?
<Sarvatt> i just loaded the page
<Sarvatt> ahh thats gonna take a bunch more work, all you :)
<Sarvatt> oh hmm, didnt notice mesa failed to build on edgers, same package built fine on testing
<tormod> Sarvatt: I'm on it
<Sarvatt> getting lots of these errors the past few days and they go away after doing a rebuild 
<Sarvatt> /usr/bin/install: cannot create regular file `/build/buildd/mesa-7.6.0~git20090604.81a0ef3f/debian/tmp/usr/lib/pkgconfig/gl.pc': File exists
<tormod> (libdrm I mean)
<Sarvatt> lol here's why
<Sarvatt> WARNING: The following essential packages will be removed.
<Sarvatt> This should NOT be done unless you know exactly what you are doing!
<Sarvatt>   mktemp
<Sarvatt> problem in karmic right now
<Sarvatt> why drm failed on the ati ppa i mean
<Sarvatt> well I put a drm and ddx that will work up on mine, they wont build because of the problem in karmic right now but copying after its fixed should be ok
<Sarvatt> could actually copy the radeon-rewrite from jaunty too in that PPA too, only one trivial commit since then
 * Sarvatt can't speak properly today aparently.
<tormod> thanks I will copy in your radeon-rewrite/jaunty to radeon-kms/karmic once I see my libdrm builds
<tormod> so everything in karmic using mktemp will fail to build?
<tormod> seem like it yeah
<Sarvatt> yeah
<Sarvatt> probably will be borked for awhile too
<Sarvatt> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=531846
<ubottu> Debian bug 531846 in coreutils "coreutils: Upgrading to 7.4-1 makes apt-get ask for 'Yes, do as I say!' because of mktemp" [Important,Open]
<Sarvatt> want me to build anything in karmic for ya tormod?
<tormod> on your local machine?
<Sarvatt> yeah
<Sarvatt> can try out your drm
<tormod> thanks
<tormod> I guess someone will fix this pretty soon though, no?
<tormod> just wonder if apw's kernel has some changes header files that will be used when building libdrm?
<Sarvatt> ah wait, yeah would need his linux-libc-dev
<tormod> Sarvatt: I will install his kernel and build libdrm here
<Sarvatt> giving up on xi2 xserver 1.7 for today, got a nasty dbus problem building it that i have no idea how to fix that I'm hoping other people have :D
<tormod> hmm I don't even have a real karmic installation
<tormod> oh and my libdrm package is broken anyway :)
<bryce> hmm, probably should merge debian's -ati for karmic next I guess
<tormod> are there Ubuntu changes?
<bryce> some patches
<bryce> nothing major
<tormod> is it based on 6.12 branch?
<bryce> yes the 6.12 branch
<bryce>   * Pull upstream commits from 6.12-branch up to 248b435a.
<hyperair> Sarvatt: found it. 7f8000db8bd45bb95bda4a4f8535c49b8ef74254
<bryce> craptacular, LP is down again
<Sarvatt> oh, http://cgit.freedesktop.org/mesa/mesa/commit/?id=7f8000db8bd45bb95bda4a4f8535c49b8ef74254 makes your scale plugin crash?
<hyperair> yes
<hyperair> not just scale
<hyperair> rotate
<hyperair> er
<hyperair> ring window switcher i mean
<tormod> bryce: scheduled downtime again? or broken?
<bryce> scheduled iirc
<bryce> think it's supposed to be short.  *reload* *reload*
<tormod> do they have to schedule it to hacking prime time :)
<bryce> gahh still down
<bryce> <elmo> tsimpson: yeah, we ran into some difficulties
<bryce>  services are coming back up now
<bryce> aha back
<tormod> bryce: what went wrong with the xorg fglrx apport hook?
<bryce> tormod: I'm not sure exactly, but the shelling out call was failing
<bryce> in some cases it printed an error in the bug report, in other cases the bug report could not be filed
<tormod> from the traceback it seems to fail in "report" and not in command_output
<tormod> anyway., "redundant" means there is something else flagging fglrx?
<bryce> yep
<bryce> see for example https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/383486
<ubottu> Launchpad bug 383486 in xserver-xorg-video-intel "all displays fail to output applications when virtual is set" [Undecided,New]
<bryce>     # Detect proprietary drivers                                                                                                  
<bryce>     if 'fglrx' in report['ProcModules']:
<bryce>         report['fglrx'] = recent_syslog(re.compile('fglrx'))
<bryce>     else:
<bryce>         report['fglrx'] = 'Not loaded'
<bryce> I think maybe mdz did that
<tormod> hah grep returns 1 when not found, that's all
<tormod> in a shell script script (or makefile) you would use grep ... || true
<tormod> I think "fglrx: Not loaded" should be silenced away
<tormod> g'night
<bryce> night
<bryce> tormod: building new -ati now; will upload once I've tested it.
<tormod> will anything build in karmic ATM?
#ubuntu-x 2009-06-05
<Sarvatt> bryce: doubt there will be any difference in it under KMS if thats what you're after, the KMS support is in jglisse's xserver-xorg-video-ati git tree seperate from the main one :( you can grab the drm 2.4.4 and -ati from here and build them locally if you want to test it out though, i dont know if tormod got the 2.4.11 patch working but if so that'd let you build radeon-rewrite thats on here also  https://edge.launchpad.net/~sarvatt/+a
<Sarvatt> rchive/ati
<bryce> Sarvatt: no, this is just to resolve a few bug reports
<Sarvatt> oh gotcha, sorry
<bryce> clean up patches, &tc. so when we pull a git snapshot it'll be less involved
<Sarvatt> just looked and all patches (besides 01_gen_pci_ids.diff of course) are upstream so that'll help :D
<Sarvatt> well everything here at least http://patches.ubuntu.com/x/xserver-xorg-video-ati/extracted/
<Sarvatt> in xf86-video-ati master that is
<bryce> the exa patch was not in the 6.12 branch so I've kept it
<bryce> I see debian dropped 01_gen_pci_ids.diff
<bryce> I'm going to test once without that to see if it works without it.  I'm guessing we can only drop it once we've revved xserver up
<bryce> yep works
<bryce> hmmm
<bryce> maybe I had a pre-existing pci file tho
<bryce> I'm going to chicken out and leave patch 01 in for now
<Sarvatt> it should work, that default to vesa patch was screwing things up in that regard while you were on vacation though
<Sarvatt> yeah i was doing that too for awhile on edgers after debian dropped it from everything :D
<bryce> when was I on vacation?
<bryce> oh, allhands/uds right
<Sarvatt> when we got updated to 2.7.1 on intel a few weeks ago, xserver wasn't working right with the default to vesa patch and not having the pciids so alot of people were getting shot to vesa. hmm just noticed debian added two new patches regarding pci device detection in xorg-server since our 2:1.6.1.901-2ubuntu1
<bryce> well that was fun.  We're having a major thunderstorm, and a power dip took out my desktop (WTF UPS?) then fsck decided there was a problem with my disk, ......
<bryce> how my sister's cat deals with the heat:  http://www2.bryceharrington.org:8080/Photos/Cats/Leah/
<Sarvatt> lol!
<Sarvatt> smart cat :) mine run for their lives away from the tub
<Sarvatt> anyone have a rough idea of what would be lost using --disable-config-dbus for xserver? 1.7 builds fine disabling it and I noticed debian disables but ubuntu enables it.
<Sarvatt> seems to work fine and even loaded up a little faster, strange
<apw> tomod yeah i know it has a bad changelog.  it wasn't worth the 20 minute upload time to fix it as it was meant for bryce t touch test.  i'll make sure its documented correctly for the next one :)
<crevette> heya, good morning
 * apw waves to bryce ... got any nvidia hardware?
<bryce> apw: indeed
<apw> cool.  i am just getting some test builds of a kerenl with nouveau in it
<Sarvatt> apw: where is the kernel development for that at? I could test that out on a few machines as well even though i'm really happy with the binary driver on those 
<Sarvatt> apw's kernel requires newer libdrm-nouveau1 and ddx than whats on edgers to use though (api bumped this morning). i dont know much about how the nouveau packages are set up, will try to get those updated on edgers today if noone else does it :)
<bryce> Sarvatt: cool thanks
<bryce> I'm setting up a box to test the nouveau kms today
<cwillu> Sarvatt, more new behaviour:  this last time I tried suspend, it came with everything working except that the mouse cursor is invisible, but it still interacts with the desktop
<Sarvatt> now thats odd
<cwillu> bryce, re: https://bugs.freedesktop.org/show_bug.cgi?id=22039 , how useful is it to add additional intel-gpu-dump's when I see 'different' broken behaviour?
<ubottu> Freedesktop bug 22039 in Driver/intel "Xorg hangs after resume from suspend when KMS enabled on GM945" [Major,New]
<cwillu> I mean, "symptom of the day" effect I have probably means it's just random corruption of some sort, but is it still useful to have more raw data?
<bryce> cwillu: it can be useful, however if it's at all likely to be a different bug, it can be better to file a new bug
<bryce> yes more data is usually useful
<Sarvatt> anything interesting in /var/log/pm-suspend.log cwillu?
<cwillu> it's like a 1 time in ten that suspend works, although there's always something else broken
<cwillu> oooo, mouse cursor just came back
<cwillu> ...and moments later X locked up
<cwillu> one sec, I'll check
<cwillu> success on every line
<cwillu> Sarvatt, ^^^
<Sarvatt> ok drm for nouveau is up on edgers, gotta look into the ddx since it needed some hook changes last time i tried it
<bryce> Sarvatt: shall we set up a 'Nouveau crack - kernel modesetting' PPA like was done for Radeon?
<bryce> oh also I wanted to ask how you're doing the drm-snapshot packages, and vs. rolling them as 'libdrm' package snapshots?
 * cwillu didn't think to check hibernation before
<cwillu> 5 hibernation cycles so far, X hasn't hung yet.
<bryce> -ati 6.12.2-2ubuntu1 uploaded.
<apw> bryce, a nouveau crack PPA would be handy as i could then not make a combined kernel for testing and would be easier to manage.  sounds like you have management issues trying to shoehorn both into the same package too (ati and nouveau)
<Sarvatt> shouldnt be needed as far as I can see, nouveau works straight on mesa/drm master vs ati having a crapload of specific branches for different things that arent compatable with each other and need different DDX depending which you go off of.. but I think we might have to package gallium for 3d support for nouveau in mesa, i havent looked into that at all yet
<apw> well let me know if you have any luck with my kernel, if so i have a strategy for a combo job there
<Sarvatt> might actually be able to enable KMS with the nouveau module in drm-snapshot..
<bryce> ok, guess we can always add it later if we absolutely need it
<bryce> shame you can't *delete* ppa's
<apw> bryce, yeah i could do with a purge too
<hyperair> bryce: you can, by poking the launchpad people
<bryce> hyperair: what I have in mind is being able to set up quickie ppa's for specific short-term objectives (like this kms stuff) and then destroy them once that experiment is complete or merged in
<hyperair> bryce: yeah, that would be really awesome.
<bryce> hyperair: bugging the launchpad guys each time an experiment is complete would probably annoy them too much ;-)
<hyperair> agreed =p
<hyperair> well just reuse them ppas
<bryce> but it's a good point; maybe once a lot of cruft has built up they could be pinged to do cleanup
<hyperair> delete all the packages
 * bryce nods
<bryce> I've been using that approach with some of my personal ppa's.  I ended up just giving them abstract names so I could use them for multiple purposes... 'blue', 'green', etc.
<bryce> but that's a pretty ugly hack ;-)
<jcristau> bryce: if you annoy them enough they'll end up implementing it
<hyperair> lol
<hyperair> =p
<hyperair> i have one called "bugfix". i just dump anything and everything there.
<hyperair> i even have a prototype uswsusp package with usplash support
<hyperair> i just can't figure out how to make uswsusp *not* hang when resuming with usplash
<hyperair> it seems alt+sysrq+e is a quick workaround to the hang
<hyperair> probably usplash hanging
<hyperair> ah well
<Sarvatt> yeah I just started naming PPA's I add with more generic names so I can wipe it all and reuse it for something else, they are starting to add up lol
<crevette> heya
<crevette> do you need some report about kms working with intel?
<hyperair> i think there's one somewhere around..
<hyperair> in the wiki
<hyperair> say... i haven't noticed the cursor corruption for a while O_o
<Sarvatt> https://wiki.ubuntu.com/X/KernelModeSetting
<hyperair> could it be that it's fixed? O_O
<Sarvatt> not here
<Sarvatt> ya do something different recently?
<hyperair> hmm wait
<hyperair> is there a sure fire way to reproduce the cursor corruption thing?
<Sarvatt> i havent ever seen an animated cursor come up and not get glitchs within 2 seconds :D
<hyperair> my resize cursor is animated
<hyperair> no glitches
<hyperair> =\
<Sarvatt> its funny, the glitches I get with the cursor actually happen to the whole screen sporadically on windows though
<crevette> is UXA activated in Karmic, or should I keep my configuration file?
<hyperair> hmm mine was confined 
<hyperair>     Declares that file is expected in the directory defined above. In Autoconf proper, this macro does nothing: its sole purpose is to be traced by third-party tools to produce a list of expected auxiliary files. For instance it is called by macros like AC_PROG_INSTALL (see Particular Programs) or AC_CANONICAL_BUILD (see Canonicalizing) to register the auxiliary files they need. 
<hyperair> oh hell
<hyperair> #$%^&*( compiz
<Sarvatt> wonder if theres something related to how it displays the cursor and how windows display video overlays
<hyperair> my super+middleclick ends up middle clicking into urxvt.
<Sarvatt> keep your configuration file crevette, it is activated by default but also disabled by default (confusing huh)
<crevette> uh?
<Sarvatt> when you build the kernel you get an option to enable KMS by default or not, enabling it by default links all the other modules in the correct order with it, ubuntu enables it by default there so those things work right but makes the default modeset option for the i915 module 0 so its off
<Sarvatt> doing it that way makes it work  properly by just adding it to a modprobe option in /etc/modprobe.d/
<Sarvatt> oh shoot crevette, I misread your question as "is KMS activated" lol
<Sarvatt> sheesh
<Sarvatt> there's only UXA in karmic right now, dont need to keep your config
<crevette> okay sweet
<crevette> thanks Sarvatt
<Sarvatt> no worries, sorry about the confusion :D
<crevette> "(note that UXA is enabled by default). " /me should have read better the wiki
<Sarvatt> does anyone know of a reason why xserver is built with --enable-conf-dbus on ubuntu and what might be hurt disabling it? It's defaulted to no upstream, disabled in debian and moblin and seems to boot a little faster disabled. I had to disable it for xserver 1.7 to build post xi2 merge and I can't find anything broken by it
<jcristau> Sarvatt: some hack involving wacom
<jcristau> before wacom got fixed to work with hal
<Sarvatt> ahh I see
<Sarvatt> thanks jcristau
<crevette> I have the message paste in http://dpaste.com/51959/ in the Xorg log, I know this is armless. Should I submit this to any upstream / downstream BTS?
<jcristau> submit what?
<crevette> the EDID
<jcristau> probably not, if you don't have a problem with it?
<crevette> no, no, I was just reading my xorg log file, to check there is no error after kms activation
<crevette> my point is just if yo see a warning, report it :)
 * crevette tries suspend
<jcristau> ugh. what's this la_AU locale that got added to ubuntu libx11?
<hyperair> Sarvatt: just hibernated and resumed. no cursor corruption.
<hyperair> Sarvatt: however, i had corruption on my terminal upon resuming
<hyperair> Sarvatt: as in, rxvt, which was configured to use argb.
<hyperair> resizing the window solved the issue
<Sarvatt> unrelated but just curious, are you using the older mesa with those patches or the newer one hyperair?
<Sarvatt> wondering if removing the patches fixed the problem you bisected down
<hyperair> Sarvatt: custom compiled mesa, with the commit 700something reverted.
<hyperair> the patches are in place
<Sarvatt> ah
<hyperair> but i reverted the commit that caused my crash
<hyperair> i'm using the rc8 kernel from kernel.ubutnu.com
<hyperair> ubuntu*
<Sarvatt> why not karmic's 2.6.30-8.9?
<hyperair> er.
<hyperair> is it the same?
<Sarvatt> its rc8 yeah
<apw> bryce, Sarvatt, those kernels built finally
<apw> its not the same.  the rc8 mainline kernel has no ubuntu delta
<Sarvatt> except its got all the ubuntu patches and changes instead of being based on jaunty and dropping the cust...... apw beat me to it
<hyperair> i see
<Sarvatt> by same i meant rc8 based, sorry
<hyperair> i'm going to try using the -8 kernel then
<hyperair> off i go to reboot.
<apw> yeah its mostly the same for sure, karmic's delta is smaller
<hyperair> ooh. -8-generic has no issues either!
<hyperair> cursor's 100% okay
<crevette> hyperair: yeah it's running fine here
<hyperair> woohoo
<hyperair> =D
<hyperair> Sarvatt: 086ecea179ed572c89aa77c5f465671a5cef87a7 <-- my mesa is of this particular snapshot, with your patches enabled, and commit 7f8000db8bd45bb95bda4a4f8535c49b8ef74254 reverted.
<hyperair> Sarvatt: why did you drop the uxamemleak patches though =\
<hyperair> Sarvatt: won't that cause the uxa memory leak to regress back to its previous state?
<Sarvatt> if its the right solution it'll be upstream soon, rather not possibly cause problems for everyone using it in that PPA :)
<hyperair> hmm
<hyperair> why wait? =p
<hyperair> is the commit i reverted that important, anyway?
<Sarvatt> heyo tormod
<tormod> heya sarvatt
<tormod> did they fix the buildds?
<Sarvatt> yup
<Sarvatt> guess i'll fudge the date to switch to libdrm over drm-snapshot, failing to upload because of the stale older version i deleted 4 hours ago
<Sarvatt> its 0606 somewhere in the world :D
<tormod> Sarvatt: I sometimes jump timezones to get the right datestamp :)
<tormod> but more often the other way, to be proactive
<Sarvatt> ugh, mesa failed to build in general just now
<Sarvatt> what the hell, it built fine in my xorg-testing PPA
<Sarvatt> /usr/bin/install: cannot change permissions of `/build/buildd/mesa-7.6.0~git20090605.b7aa5b1d/debian/tmp/usr/include/GL/glxext.h': No such file or directory
<Sarvatt> its happening on all arches now
<Sarvatt> maybe its the new mktemp from coreutils having problems
#ubuntu-x 2009-06-06
<tormod> https://edge.launchpad.net/~xorg-edgers/+archive/radeon-kms on top of Jaunty :)
<tormod> https://edge.launchpad.net/~xorg-edgers/+archive/radeon-kms
<tormod> http://pastebin.ca/1449325
<bryce> tormod: :-)
<tormod> heh wobbly glxgears \o/
<ripps> How's the performance and stability of ati-kms?
<tormod> not extraordinary
<bryce> btw, I added a new PPA to ubuntu-x-swat, 'x-retro'
<bryce> it is the inverse of 'x-updates'.  Instead of providing packages newer than what's in the distro, it provides packages that are older.
<tormod> like intel 2.4 for jaunty ? :)
<bryce> precisely
<bryce> if you ever run into cases where we need to carry reverted versions of -ati, that'll be where to put them
<tormod> I was thinking of that once "xorg-aunties"
<ripps> tormod: does xv work in kms?
<tormod> firefox scrolling is slow
<tormod> hang on
<tormod> totem seems to struggle with aspect ratio, can this be related to kms?
<tormod> how do I tell if it's really using xv
<cwillu> tormod, gstreamer-properties should allow you to force it to a particular approach
<tormod> done that
<tormod> so unless there is any fallback it runs xv
<tormod> does not look great but it works
<tormod> the film wobbles with the window in compiz
<ripps> tormod: are sure it's xv or is it x11 fallback. Use mplayer from commandline, it'll tell what output it's using
<ripps> use mplayer -vo xv filename
<tormod> if you try radeon-kms ppa, you might need to add Driver "ati" to xorg.conf (at least in Jaunty)
<tormod> and I would recommend to boot with "text" and use startx
<ripps> If xv works properly, than I can deal with a few performance issues, but poor video playback is a deal breaker. Otherwise, I'd be glad to help test and debug issues
<tormod> well try it out, you can always revert the packages
<tormod> bryce, maybe you want to spin a live-cd with this ppa?
<tormod> good night
<bryce> tormod: yes, but will need to be next week
<bryce> night tormod
<bryce> I had wanted to do some ati/nouveau testing today but ended up mostly spending it on that #$%^% Jaunty X freeze bug...
<cwillu> heh, running two independent xorg's with their own physical cards, the mouse moves the cursor on both screens :)
<maxb> The latest -video-ati makes mention of requiring firmware... what's the status of that?
<maxb> What exactly is low graphics mode? Is it -video-vesa ?
<Sarvatt> maxb, can ya pastebin your /var/log/Xorg.0.log if you're still around?
<Sarvatt> phew, found a fix for the --enable-config-debus compile error for 1.7 post xi2 merge, but part of me wants to keep it disabled to figure out whats actually not working because I havent been able to for the past few days :)
<Sarvatt> even wacom's working right http://sarvatt.com/downloads/Xorg.0.log.txt
<hyperair> debus?
<hyperair> O_o
<hyperair> on a side note...
<hyperair> my X session is only 2 hours old.
<tormod> apw, bryce: around? I have a kms iso to be mirrored
<hyperair> and gem_objects has overflowed already!
<hyperair> =(
<pwnguin> i guess its time i should upgrade my wacom tablet to karmic
<hyperair> wow, your wacom tablet runs ubuntu? O_o
<pwnguin> yes?
<hyperair> does it even have storage?
<hyperair> O_o
<pwnguin> its a tabletPC
<hyperair> ah.
<hyperair> heheh
<pwnguin> thank you very much, capt'n snark
 * hyperair chuckles
<hyperair> =p
<pwnguin> https://wiki.ubuntu.com/LaptopTestingTeam/ToshibaTecraM7
<hyperair> fascinating
<hyperair> hmm i wonder if xD cards and sony memory sticks will get open source drivers anytime soon =\
<pwnguin> do you have any?
<hyperair> i've got an xD
<pwnguin> everyone uses SD anyways
<hyperair> and a m2 memory stick, yes.
<hyperair> yeah true.
<hyperair> but sony ericsson phones use m2
<pwnguin> you're weird :P
<Sarvatt> memory sticks work fine, ubuntu just doesnt enable the modules
<hyperair> and olympus cameras use xD cards
<hyperair> Sarvatt: do they?
<hyperair> Sarvatt: which modules?
<Sarvatt> yeah I have one in right now
<pwnguin> probably depends on the chipset
<hyperair> Sarvatt: and why aren't they enabled?
<hyperair> Ricoh.
<Sarvatt> theres a whole memory stick section in the kernel config
<Sarvatt> yeah ricoh and jmb work fine for me
<hyperair> hmm
<hyperair> Sarvatt: what are the config opts?
<hyperair> Sarvatt: and how come ubuntu doesn't enable them?
<Sarvatt> CONFIG_MEMSTICK=m
<Sarvatt> CONFIG_MEMSTICK_UNSAFE_RESUME=y
<Sarvatt> CONFIG_MSPRO_BLOCK=m
<Sarvatt> CONFIG_MEMSTICK_TIFM_MS=m
<Sarvatt> CONFIG_MEMSTICK_JMICRON_38X=m
<pwnguin> i wonder if there's a choice between them and suspend / resume working
<Sarvatt> heck if i know
<pwnguin> or if there's some patent to consider
<Sarvatt> suspend/resume works fine for me, i even enable unsafe resume on both sd and MS
<pwnguin> probab
<pwnguin> probably, unsafe resume is about the media write integrity, not the suspend
<Sarvatt> it was pretty new and not stable on 2.6.28 though
<hyperair> i see
<hyperair> i gave my SD cards to my dad
<hyperair> 512M each.
<pwnguin> heh
<hyperair> i've got 2G usb sticks
<pwnguin> tiny things
<pwnguin> i have a 2gb microsd
<pwnguin> and i think SDHC goes up to 32GB now?
<hyperair> heh
<hyperair> yeah i think so
<Sarvatt> need to have unsafe resume to be able to suspend/resume/hibernate with important things mounted on it, i've got /opt on a SD with some gnome applets in there
<hyperair> i see
<hyperair> i just use my hard disk =D
<hyperair> 160G. i wish it was bigger.
<pwnguin> i guess thats one way to test out unstable builds
<pwnguin> doesn't work? just pop the sd card out
<Sarvatt> yeah if only my aspire one supported booting from SD i'd be happy
<pwnguin> im pretty sure my tablet does
<hyperair> hmm i've never tried O_o
<hyperair> how expensive are SD cards anyway? the last tiem i bought SD cards, they were pretty expensive
<Sarvatt> i paid 35 bucks for 2 16gb ones, real cheap now
<Sarvatt> that was 6 months ago too, sure its cheaper
 * hyperair pokes Sarvatt to put back the two memleak patches =(
<Sarvatt> ya upgrade and it got worse?
<hyperair> 35 bucks for 2 16G eh..
<hyperair> yes
<hyperair> very much worse
<hyperair> 2h and it's already showing negative memory usage
<hyperair> -1693499392 object bytes
<Sarvatt> i'll do it by monday if its not upstream, they dont really commit anything on weekends but it might go up monday
<hyperair> hmm cool
<hyperair> it would be nice if the patch could be fixed to not conflict with the commit i highlighted the other day
<Sarvatt> if you want a kernel to try to see if memory sticks work for you -- http://sarvatt.com/downloads/2.6.30-rc8/
<tormod> ripps and whoever wondered about radeon-kms and xv: it's fixed now
<hyperair> cool, thanks =)
<tormod> a live cd is available from https://launchpad.net/~xorg-edgers/+archive/radeon-kms
<tormod> but you will need to apt-get upgrade to get xv fixed in -ati/-radeon
<pwnguin> we really need to start a Ubuntu kernel enthusiast support team
<hyperair> er what for?
<pwnguin> i donno. maybe it's just me
<pwnguin> just for newbies who might have questions or want to share custom configs/builds
<Sarvatt> tormod, which kernel are you using? the one with only ATI?
<Sarvatt> because apw made another with nouveau too
<pwnguin> I used to build my own kernel on debian, but stopped when i switched to ubuntu. the official builds have only gotten more complicated
<Sarvatt> more complicated? they cut down on ubuntu specific stuff so much lately
<pwnguin> perhaps its improved since i last looked
<hyperair> i used to compile my own kernel =\
<hyperair> using make-kpkg
<hyperair> wasn't too hard
<hyperair> but very time consuming
<Sarvatt> yeah its just recently that its gotten really cut back on ubuntu specific stuff
<pwnguin> -restricted-modules is a challenge to figure out
<pwnguin> but its been quite a while since i last tried, and a while longer before i'll try again, so i'll pipe down
<pwnguin> gotta get stunnel working on osx
<Sarvatt> dont even need that anymore in karmic
<tormod> Sarvatt: the kernel from the radeon-kms ppa, so I guess no nouveau
<Sarvatt> linux-restricted-modules-common is only 90k, think it just has intel wireless firmware now?
<hyperair> now all we need is to get iwl firmware open. =D
<Sarvatt> dont even see a lrm branch on kernel.ubuntu.com for karmic anymore
<pwnguin> ah right; that's my wifi chipset
<pwnguin> but im pretty sure there's still an nvidia binary package
<tormod> pwnguin: I guess you don't need a "team" to discuss kernel configs - there are forums for it
<Sarvatt> yeah, thats independant of the kernel though, uses dkms to build the modules every time you install a new kernel. wish i had a netbook with nvidia graphics because i love the binary drivers :D
<tormod> for instance the "kernel master thread" on ubuntuforums
<Sarvatt> i need to figure out how to combine all the split configs so i can reconfigure things and split it up again some day so I can just build them on a PPA
<tormod> nobody loves binary drivers in sovyet russia
<Sarvatt> so is kms working out for you tormod?
<Sarvatt> i might sit down and work out packaging gallium for nvidia this week so I can do some nouveau testing
<tormod> expect from suspend/resume, I actually can not make it crash !
<Sarvatt> nice!
<Sarvatt> 3d acceleration/dri working and everything?
<tormod> so it's better than stock intrepid, jaunty, karmic
<Sarvatt> lol
<tormod> dri2 you mean :)
<Sarvatt> its unstable for you on radeon-rewrite without the KMS kernel still isnt it?
<tormod> radeon-rewrite on the old stack is still broken
<Sarvatt> ah
<tormod> maybe it's an DRI (1) issue
<Sarvatt> did you get libdrm-radeon all packaged up?
<tormod> yes good enough that it works
<Sarvatt> hmm you should try the xorg-testing stuff out, mesa and drivers should be older in there so wont upgrade those
<Sarvatt> oh the drm is newer
<tormod> but I wonder why mesa fails on amd64. libdrm builds some objects first with -fPIC then without (for libdrm-radeon.a) and then mesa complains about missing fPIC like it is picking up the wrong library(?)
<tormod> I can try xorg-testing again from a live-cd but it is not so long since last time
<Sarvatt> libdrm_radeon.a: could not read symbols: Bad valu
<Sarvatt> huge changes since last time though with the XI2 stuff
<tormod> aha could be fun to try
<jcristau> tormod: sounds like libdrm_radeon.so is not there. missing dep somewhere?
<tormod> jcristau: I am pretty sure I did not do the libdrm_radeon.so packaging properly, but it works in i386/lpia
<tormod> mesa failing build log: http://launchpadlibrarian.net/27564711/buildlog_ubuntu-karmic-amd64.mesa_7.6.0~git20090606%2Bradeon-rewrite.c1ccc7d5-0ubuntu0tormod2_FAILEDTOBUILD.txt.gz
<tormod> libdrm build log: https://edge.launchpad.net/~xorg-edgers/+archive/radeon-kms/+build/1060730/+files/buildlog_ubuntu-karmic-amd64.drm-snapshot_2.4.11+git20090604+libdrm-radeon.2cb4c64d-0ubuntu0tormod2_FULLYBUILT.txt.gz
<Sarvatt> lookin over the source now to see if i see anything
<Sarvatt> do you need a libdrm_radeon.pc.in set up tormod?
<jcristau> your libdrm-dev doesn't depend on -radeon1
<jcristau> tormod: ^
<tormod> jcristau: aha
<Sarvatt> patch didnt add that
<tormod> gotcha
<jcristau> oh and it worked on i386 because non-PIC in shared libs works there
<jcristau> it fails most everywhere else though
<tormod> btw why are those libdrm_radeon libdrm_intel split out and not just shipped in libdrm2?
<Sarvatt> it is all in one in the modesetting-gem mesa/drm tree, looking at my source for the 2.4.4 from there i built the other day
<jcristau> tormod: so their sonames can change independently
<tormod> right
<tormod> but if they're from the same source, why would they have different sonames?
<jcristau> 'same source'?
<jcristau> you can remove a function from libdrm-intel without it affecting libdrm-radeon
<jcristau> or libdrm itself
<Sarvatt> ihmm tormod incase it helps any - http://cvs.fedoraproject.org/viewvc/rpms/libdrm/F-11/libdrm-radeon.patch?view=log
<tormod> Sarvatt: thanks that looks awfully handy
<Sarvatt> maybe we should set up a bzr branch or git repo somewhere for the two libdrm branches to make things easier updating it with the scripts, need so many changes building current libdrm against origin/ubuntu just for the current 2.4.11. rules needed changing a bit and theres a bunch of new symbols to add
<tormod> jcristau: mesa built on amd64 now, thanks!
<jcristau> tormod: np. have fun :)
<maxb> Sarvatt: My problem turned out to be that I had "radeon" installed but not "ati", and the latest packages break the pciids detection in that situation. I've filed a bug
<Sarvatt> tormod: funny how that looks like the exact same problem we had building amd64 mesa 7.5+ with egl from the logs
<tormod> true
<Sarvatt> same package that it was failing on i mean at least
#ubuntu-x 2009-06-07
<Sarvatt> yuck, looks like gimp is still crashing with XI2
<Sarvatt> [mi] miSpriteRealizeCursor called for floating device.
<Sarvatt> [mi] miSpriteSetCursor called for floating device.
<Sarvatt>  then segfault
 * Ng wonders why X's screensaver is enabled
<Ng> or is this a weird interaction between gnome-screensaver and g-p-m I wonder
<Ng> I really hate that display locking/power stuff is split across those two
<Sarvatt> i've got an xserver 1.7/xi2 live cd up here incase anyone wants to try it :D https://edge.launchpad.net/~sarvatt/+archive/xorg-testing
<Sarvatt> ahh just realized it has the ati KMS kernel in it still so it'd probably have problems on ati hardware, whoops.
<lesshaste> hi
<lesshaste> does anyone know about running two graphics cards, specifically one is an onboard one and the other a gforce nvidia card in a pci express slot
#ubuntu-x 2010-06-07
<Sarvatt> how about uh.. http://sarvatt.com/downloads/patches/0001-Add-Gallium-support-via-an-xorg.conf-option-enabled-.patch
<RAOF> Looks like it'll work, although it won't fall back, will it?
<Sarvatt> yeah really stumped on the fallback, it'll fallback to swrast though I think? wish i had one to test all this junk out :)
<RAOF> Heh.
<RAOF> In RADEONPreInit_kms you could simply stat() /usr/lib/dri/radeong_dri.so, right?
<RAOF> If it doesn't exist, set useGallium to false.
<bjsnider> people are sending me angry emails asking why the lucid nvidia updates have to be in the x-updates ppa
<RAOF> Do they offer to field any angry emails we get when nvidia updates in the main repositories break for users? :)
<Sarvatt> bjsnider: what lucid nvidia updates?
<bjsnider> drivers
<Sarvatt> the newest released driver is in lucid already I thought?
<bjsnider> no, the 256 line
<Sarvatt> non-beta
<bjsnider> they want the sexy 256 line
<bjsnider> RAOF, no, they mean in that ppa and not my ppa
<bjsnider> you pretty much have to run dozens of ppas if you want cutting edge stuff these days
<bjsnider> there isn't one ppa you can go to for every little thing is what i've been telling them
<Sarvatt> wow only 6 patches didn't apply to xorg-server_1.8.99.0+git20100606.f03be727-0ubuntu0sarvatt.
<Sarvatt> was expecting it to be more like 29
<Sarvatt> err 20
<RAOF> ARGH!  The back button is not your friend when editing bugs.
<Sarvatt> checking host system type... Invalid configuration `technical': machine `technical' not recognized
<Sarvatt> kay!
<Sarvatt> doesn't like bryce's change :)
<RAOF> Oh, that's no fun at all.  It looks like a guest user can bring down my system.
<Sarvatt> yeah bryce's change doesn't work even on the straight ubuntu branch
<Sarvatt> configure: WARNING: you should use --build, --host, --target
<Sarvatt> configure: WARNING: invalid host type: http://www.ubuntu.com/support)
<RAOF> There probably needs to be some quoting.  I'll look at it.
<Sarvatt> its just too much quoting
<Sarvatt> --with-builderstring="xorg-server 2:1.8.1.901-1ubuntu1 ("For technical support please see http://www.ubuntu.com/support")"
<bryceh> sheesh
<RAOF> Yeah, just unquoting fixes that.
<bryceh> right, let me push an updated commit
<bryceh> hmm, git's refusing to let me push
<bryceh> probably quite wise of it
<RAOF> There are probably changes up there.
<Sarvatt> lol i was editing it in one tree and test building changes in another, doh
<Sarvatt> i bet googling for bryce brings up hundreds of pastebins now :)
<bryceh> :-/
<bryceh> I literally just got scolded by my wife for working on the weekend ;-)
<Sarvatt> doh sorry bryce! we coulda fixed that, i was referring to you as bryce so it wouldn't ping you :)
<RAOF> It's got to be pretty late for you there too, right?  Go have some fun!
<bryceh> it's only 7:20pm
<bryceh> been out in the shop most of the day
 * RAOF understands âshopâ to be short for âworkshopâ aka shed.
<bryceh> yep
<bryceh> technically it's part of my garage
<RAOF> Cool.  I managed to prune half a rosebush inbetween showers last weekend.  It's now somewhat less totally, unnecessarily huge and convoluted.
<bryceh> pushed
<bryceh> I was out there to paint some shelves for my game closet, but ended up starting a medium sized reorganization project
<Amaranth> Sarvatt: If we get compiz 0.9 we won't need any max texture size checks
<RAOF> Amaranth: Is that magical future compiz _likely_ to be in Maverick?
<Amaranth> RAOF: They've put out a call for testing, it should be feature complete at this point
<Amaranth> RAOF: I was working on packaging it but seb128 says we need to get the package back to syncing from Debian or small changes from Debian
<RAOF> Seems reasonable.
<Amaranth> But Debian still has compiz-gtk, a completely nonsensical package as it depends on most of GNOME
<Sarvatt> is this really the cycle to do that with things being held up by squeeze?
<Amaranth> And we'll waste a bunch of time trying to coordinate on the new naming and packaging scheme considering there is no compiz-fusion anymore
<Amaranth> Sarvatt: He was willing to stick to just keeping the plugins packaged synced from Debian but that is the part most likely to need a major change (get rid of the fusion name)
<Amaranth> I was trying to coordinate on at least naming with the person I think is the Debian maintainer (he was going to be working on 0.9 packages for testing, anyway)
<Amaranth> But I haven't heard from him in a few weeks
<Sarvatt> i guess we'll be on this same old 0.8.4 thats already over 8 months old in MM then? :D
<Amaranth> Sarvatt: possibly
<Sarvatt> i tried packaging the new one up but man I hate cmake
<Amaranth> I don't have much interest in working on 0.9 packages if the debian maintainer is eventually going to be his own set and we need to use his
<Sarvatt> couldn't find any good examples of other things using cmake
<Amaranth> https://code.edge.launchpad.net/~amaranth/compiz/0.9 https://code.edge.launchpad.net/~amaranth/libcompizconfig/0.9
<Amaranth> here have some packages :)
<Sarvatt> \o/
<Amaranth> Sarvatt: I stopped there because I went to ask seb128 if I could use multiple tarball support to roll the plugins-main and plugins-extra sets in to the compiz package so we could easily split the plugins in to what we use and what we don't
<Amaranth> Without a gst-plugins-bad, gst-plugins-bad-multiverse, etc kind of split
<Sarvatt> who did you contact about it?
<Amaranth> Sarvatt: sean finney
<Sarvatt> nice, you got bzr-builddeb set up for it too??
<Sarvatt> i'm not really sure what all the move to .9 entails package renaming wise, maybe you could send an email to debian-x with the problems since it looks like its on life support at the moment in debian?
<Sarvatt> like is it just transitioning the plugins to compiz-plugins-foo instead of compiz-fusion-plugins-foo?
<Sarvatt> i know the whole build system got an overhaul
<Amaranth> Sarvatt: Yeah, and rewriting the rules file for the build system
<Amaranth> Sarvatt: But sean was interested in doing the plugins as a part of compiz as well but using git submodules for some reason
<Amaranth> Sarvatt: So we'd really need to nail that down
<Sarvatt> no bzr-builddeb if you do that :(
<Amaranth> eh
<Amaranth> I can't use it so long as I'm doing git snapshots anyway
<Amaranth> brb, reboot
<Amaranth> well, if I can get it to give me the option...
<RAOF> You could totally use it for git snapshots; just install bzr-git and pull as normal.
<Amaranth> I don't use put the source in bzr
<Sarvatt> or a get-orig-source target?
<RAOF> Sarvatt: Were you merging xserver-xorg-video-nv?
<Sarvatt> i think mvo was? we could just sync it, just one fedora patch that wasnt a bugfix
<RAOF> And the crazy probe logic.
<Sarvatt> yeah even superm1 agreed that should be dropped though
<Sarvatt> xserver master actually turned my machine off for me, how thoughtful! :D
<Sarvatt> just trying it out because it looks like the last of the abi breaks went in earlier so it'll probably branch soon
<RAOF> Sarvatt: That was really X, and wasn't the kernel doing it's panicâshutdown dance?
<Sarvatt> i did a startx, launched gnome-terminal and it was all white, and 10 seconds later my machine was completely off :)
<Sarvatt> time to grab a core dump to play with
<RAOF> I wonder if launchpad will accept my 255MiB vmcore this timeâ¦
<Sarvatt> aren't you an aussie?? thats like 1/10th your monthly bandwidth limit!
<RAOF> Uploads don't count.
<Sarvatt> weird the selinux stuff is showing up in the log now, it wasn't like a week ago - http://sarvatt.com/downloads/xorg.txt
<RAOF> At least on my ISP, as long as you don't have fiber.
<RAOF> So, watcom.  Where are we at there?
<RAOF> Is anyone currently merging it?
<Sarvatt> thats the one i'm worried about
<RAOF> Difficult merge?
<RAOF> Also, no hardware to test?
<Sarvatt> not sure what all these ubuntu changes were, we kind of forked it..
<RAOF> Bah.
<Sarvatt> do we have the history in bzr?
<Sarvatt> somewhere
<Sarvatt> i've been meaning to look for that, the changelog doesn't help much
<Sarvatt> if you do upload it remember to autoreconf, lol
<Sarvatt> been hit by that so many times
<RAOF> It doesn't autoreconf during build?
<Sarvatt> nope
<RAOF> Well, that's silly.
<RAOF> Hm.  When it's cold I kind of wish this x200s had a touchpad as well as a nub.
<Sarvatt> tjaalton was going to put it on pkg-xorg and redo the packaging some but he disappeared, think he's in the last few weeks of college now
<Sarvatt> https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/maverick/xf86-input-wacom/maverick yay found it
<RAOF> Yup.  lp:ubuntu/xf86-input-wacom
<RAOF> Only 9 revisions, though.
<Sarvatt> i dont think any of this applies if we sync..
<Sarvatt> still looking though
<Sarvatt> hmm bryce brought in xsfbs to it
<Sarvatt> so just the n-trig patch, i doubt thats upstream but have to check
<RAOF> Hm.  That may well be upstream.
<Sarvatt> its not and it doesn't apply anymore
<Sarvatt> http://linuxwacom.git.sourceforge.net/git/gitweb.cgi?p=linuxwacom/xf86-input-wacom;a=blob;f=src/wcmUSB.c;h=249a7bfb3e96454df82b0ca9e67cfdcb5e7aefa4;hb=HEAD
<Sarvatt> and http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/xf86-input-wacom/maverick/revision/5#debian/patches/100_ntrig_2010_02_03.patch
<Sarvatt> doesn't look hard to refresh, they just made it more generic for waltop tablets
<Sarvatt> hmm does it work without the patch now even?
<Sarvatt> looks like it does
<Sarvatt> except it doesn't get those custom dimensions 
<Sarvatt> defaults to 1016x1016 for unknown devices and that patch was setting it to 1122,  934 if i'm not mistaken, but could do that in a snippet.. i think bryce has one of the devices, gotta bug him tomorrow :)
<RAOF> :)
<RAOF> Yes, he does.  I saw it at UDS.
<RAOF> It's pretty fun.
<Sarvatt> darn, was going to suggest a git checkout but it requires util-macros 1.8 now which isnt released in debian :)
<seb128> hi there
<seb128> is there known issue with the matrox videocards on lucid?
<seb128> seems that we received quite some bugs from users getting invisble gnome-panel when compiz is on
<jcristau> the mga drivers are abandoned, and nobody tests them, so i wouldn't be surprised.
<jcristau> (well other than server stuff where you don't want to run compiz anyway)
<seb128> do you think it's worth trying to get those fixed or should we rather turn compiz off on those cards?
<Sarvatt> seb128: got any links to any of them with good info? xsession-errors would probably say why the panel died. mga hasn't really been touched in mesa in at least 3 years though :(
<seb128> Sarvatt, the issue is a graphical refresh one it seems ot visual corruption with compiz
<seb128> compiz was not enabled on matrox before according to mvo
<seb128> the wrapper used to filter matrox out because they though it didn't work with it
<seb128> the new compiz in lucid dropped the wrapper and filter out on pci ids though
<seb128> it doesn't filter out those matrox cards it seems
<seb128> I'm wondering if we should do that again or try to figure what is wrong with the matrox driver
<Sarvatt> i'll see if i can dig up anything
<jcristau> probably wouldn't be extremely hard for someone with the hw and interest
<Sarvatt> yeah looks like it was blacklisted back in 07..
 * jcristau has neither
<Sarvatt> yeah for sure it looks like an oversight that the blacklist got dropped
<Sarvatt> same problem even back in gutsy
<seb128> well the thing is that it's somewhat working
<seb128> so we can decide either to try to fix or filter it out again as it was
<Sarvatt> hmm need to look at what the default dri settings are for mga, not sure why its even allowing this by default - /usr/bin/compiz (core) - Warn: Exceeded max texture size
<Sarvatt> all this time i didnt know about xdriinfo :D
<Sarvatt> darn why do these gnome-panel bugs have to have no useful info on them
<Sarvatt> maybe theres one filed against x-x-v-mga
<jcristau> i didn't even know mga had tfp
<keffie_jayx> hello all, I al here because I am interested in helping out with this bug. https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-sis/+bug/301958. To be honest it is a big beyond my expertice but I can try spliting the 1.6 patch into smaller ones and see. This is an issue that should be resolved if a patch were sent upstream. 
<ubot4> Launchpad bug 301958 in xserver-xorg-video-sis (Ubuntu) (and 1 other project) "[needs-packaging] no working driver for sis 671/771 video cards (affects: 40) (dups: 14) (heat: 256)" [Wishlist,Triaged]
<jcristau> it'd also be fixed by getting better hw
<Sarvatt> it's very doable, just need a lot of time
<Sarvatt> if you ignore parts of it like the acceleration code thats wildly different you can port chunks of it over to sis pretty easy though, the resolution settings code would be a good start since it has a ton more modes than sis
<Sarvatt> have you checked if mandriva updated it?
<Sarvatt> shouldn't be *that* much needed to go from 1.6 to 1.7, take a look at xf86-video-sis in git and see the changes they did and apply it there too
<keffie_jayx> Sarvatt: let me see what I can do :)
<Sarvatt> not a single person in that bug posted logs with stock ubuntu drivers.. sheesh
<Sarvatt> keffie_jayx: what is your problem with SIS? does it not load at all?
<Sarvatt> or is it just that you dont get the right resolution?
<keffie_jayx> Sarvatt: recently I just get the vesa driver with 800x600
<keffie_jayx> in karmic I would get no video at all
<Sarvatt> on mine I get SIS at 800x600, but what I do is unblacklist sisfb and set the resolution through that
<keffie_jayx> sorry no X at all
<keffie_jayx> Sarvatt: my idea is to get this to a state of parity with some distros
<keffie_jayx> it works in fedora and in mandriva, and sme success in open suse
<Sarvatt> well they aren't shipping that sisimedia driver, so why does it work there and not here?
<keffie_jayx> you suggest that I get the resolution settings code sorted out and see
<keffie_jayx> Sarvatt: black magic, unshared btw
<Sarvatt> fedora's sis is stock upstream with no patches
<Sarvatt> mandriva was using the sisimedia but last i looked they stopped after they updated to xserver 1.7
<Sarvatt> yeah fedora 10-13 are all just stock upstream releases at least
<Sarvatt> is it possible they aren't blacklisting sisfb?
<Sarvatt> huh, fedora kernel has CONFIG_DRM_MRST=n?
<Sarvatt> yeah fedora doesn't even build sisfb so it isn't that, all I can think of is the autoconfiguration stuff was screwed up in the past releases.. checking the pci id now
<Sarvatt> keffie_jayx: if you could get an xorg.0.log from both a broken ubuntu livecd and a working fedora livecd that would help a ton to figure out where the problem is
<keffie_jayx> Sarvatt: rigth, I am on it then, can i ping you when I have it?
<Sarvatt> yeah, please do, thank you for that
<Sarvatt> it should be pretty obvious from the logs whats going wrong
<Sarvatt> oh man, today's the save the crappy gpu day or something, i'm actually working on merging this sis671
<Sarvatt> this is surprisingly less hard than i thought it'd be, just imported it into git and am working my way through the commits in reverse
<seb128> Sarvatt, oh btw bug #572550
<ubot4> Launchpad bug 572550 in xserver-xorg-video-mga (Ubuntu Lucid) (and 3 other projects) "Panel utilities not shown on startup using Matrox gfx with compiz (affects: 15) (dups: 6) (heat: 115)" [Low,New] https://launchpad.net/bugs/572550
<seb128> Sarvatt, that's the bug about the matrox compiz issue
<Sarvatt> yay one of the dupes actually has some logs on it
<seb128> Sarvatt, do you think we should make compiz not run on those?
<Sarvatt> for sure
<seb128> ok, thanks
<Sarvatt> hmm http://launchpadlibrarian.net/48707922/CurrentDmesg.txt
<Sarvatt> i'd like to see a glxinfo from one of these
<Sarvatt> every single one with logs has +/usr/bin/compiz (core) - Warn: Exceeded max texture size in it
<seb128> Sarvatt, it's an open bug tracker, feel free to ask questions or add comments ;-)
<Sarvatt> i'm sure one of these has logs, will ask if i dont find it of course :)
<Sarvatt> ah when it says "/usr/bin/compiz (core) - Warn: Exceeded max texture size in it" it launches the fallback window manager and quits compiz
<Sarvatt> i dont think any of these people are even using compiz
<Sarvatt> they all fall back right after gnome starts in the .xsession-error logs
<seb128> hum
<seb128> so comments are confusing
<seb128> because people said they solved the issue by uninstalling compiz
<Sarvatt> i think its because they uninstalled compiz-gnome
<seb128> how would that make a difference if they don't run compiz?
<Sarvatt> because its still loading gtk-window-decorator always if you ever start compiz
<Sarvatt> and doesn't quit it even if you stop running compiz
<Sarvatt> have you seen issues with gtk-window-decorator and gnome-panel? because that might be what these people are hitting
<Sarvatt> /usr/bin/compiz (core) - Warn: Exceeded max texture size
<Sarvatt> Starting gtk-window-decorator
<Sarvatt> that persons on a savage with the same problem
<Sarvatt> seb128: i can reproduce it on my intel
<Sarvatt> seb128: enable compiz, then go back to no effects
<Sarvatt> and in a terminal run compiz-decorator
<Sarvatt> panel disappears
<seb128> Sarvatt, ok, thanks, so compiz bug?
<Sarvatt> yeah
<seb128> Sarvatt, thanks for investigating
<Sarvatt> the decorator runs before compiz finishes bailing out if it cant load
<seb128> the decorator should not be running if compiz doesn't run
<seb128> I don't really get what is happening
<Sarvatt> it never stops, I guess the old wrapper used to handle stopping it when compiz quit before?
<Sarvatt> will look in git, digging through a trace of whats going on
<seb128> hum
<seb128> what doesn't stop? the decorator?
<Sarvatt> yeah, before when the compiz wrapper stopped it stopped the decorator too but now they're seperate and stopping compiz doesnt stop the decorator
<seb128> Sarvatt, ok thanks
<seb128> Amaranth, ^
<seb128> mvo, ^
<seb128> do you guys know about that?
<seb128> mvo, seems compiz doesn't run on matrox it's just that the decorator is still running after it bails out
<Amaranth> The decorator shouldn't be doing anything if compiz isn't running to tell it what to do
<Sarvatt> i'm not supposed to have /etc/xdg/compiz/compiz-manager anymore right?
<Amaranth> it doesn't get used
<Amaranth> but we can't remove config files
<Sarvatt> just making sure before i remove it, thanks :)
<seb128> Amaranth, did you read the bug pointed before?
<asac> RAOF: http://launchpadlibrarian.net/49818073/buildlog_ubuntu-lucid-armel.libdrm_2.4.20-2ubuntu1~10.04~eglppa1_FAILEDTOBUILD.txt.gz
<asac> RAOF: so do we want to not produce -intel there? guess we should make INTEL then more specific in rules
<asac> hmm ... wonder why the build in maverick succeeded
<Sarvatt> darn I was hoping launching compiz with the decoration plugin on the command line would kill gtk-window-decorator when you replaced it but nope. looks like this is a common problem with compiz going by how other distros handle it
<Sarvatt> hah, thats funny because intel was added to arm specifically for libdrm even though it makes no sense
<Sarvatt> because plymouth needed it
<Sarvatt> that looks like a rules failure because it built, just didnt install?
<Sarvatt> RAOF: Package: libdrm-intel1
<Sarvatt> Section: libs
<Sarvatt> Architecture: amd64 i386 kfreebsd-amd64 kfreebsd-i386
<Sarvatt> thats why it didnt build
<bryceh> morning
<Sarvatt> morning bryceh!
<Sarvatt> bryceh: how do you want to do your n-trig quirk in wacom now? patch doesn't apply anymore but it looks like you can load wacom for any tablet now with an xorg.conf snippet
<Sarvatt> not sure though
<bryceh> n-trig quirk?
<bryceh> refresh my memory
<bryceh> Sarvatt, is xorg-server ready to upload?  Can you give me a url for the orig tarball to use?
<bryceh> Sarvatt, also, let me know status on debdiffs for anything you'd like to get uploaded later today once the xserver goes in
<bryceh> anyway, I'll wait for you or raof to cue me when/what to upload, so lemme know
<bryceh> http://www.theinquirer.net/inquirer/news/1652779/powercolor-hd5970-display-outputs
<Sarvatt> phew, its fun trying to install a system with no network and only the letters asebom working on my only usb keyboard :D
<Sarvatt> wanna finish setting up this fglrx box real quick and i'll get right on the debdiffs
<bryceh> btw only going to be available 3 more hrs; wife is doing major housecleaning today and demands being taken out to dinner this evening
<Sarvatt> testing out xorg-server now, with http://xorg.freedesktop.org/releases/individual/xserver/xorg-server-1.8.1.901.tar.gz
<jcristau> should i upload an xorg-server 1.8.1.901 to experimental so you have a tag/tarball to merge from?
<bryceh> jcristau, that would be quite helpful
<jcristau> ok, will try to do that then.  bad wireless permitting.
<Sarvatt> RAOF: are you around?
<Sarvatt> i got caught up putting together two radeon machines, sorry if I kept you hanging today :( haven't heard from RAOF since this morning, it sounded like he already did some of the merges
<Sarvatt> bryceh: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/xf86-input-wacom/maverick/revision/5#debian/patches/100_ntrig_2010_02_03.patch
<Sarvatt> thats the wacom patch
<Sarvatt> http://linuxwacom.git.sourceforge.net/git/gitweb.cgi?p=linuxwacom/xf86-input-wacom;a=blob;f=src/wcmUSB.c;h=249a7bfb3e96454df82b0ca9e67cfdcb5e7aefa4;hb=HEAD
<Sarvatt> and thats upstream
<lucazade> hi
<Sarvatt> hopefully debian is far enough behind that it applies :)
<lucazade> there is a patch to fix opengl for poulsbo on lucid
<lucazade> https://bugs.freedesktop.org/show_bug.cgi?id=28077
<ubot4> Freedesktop bug 28077 in Acceleration/EXA "X segfault in miCopyRegion / fbCopyNtoN" [Normal,New]
<lucazade> is a a bug in Xorg 1.7.6 EXA codeÂ 
<lucazade> is it possible to apply this patch in the backport repository?
<lucazade> now we have 2D/3D and video accel
<kees> RAOF: does this new major bump of Xorg gain us a higher max client count?
<kees> RAOF: (bug 260138)
<ubot4> Launchpad bug 260138 in xorg-server (Ubuntu) (and 2 other projects) "(needs x11 protocol update) Xorg needs client limit raised (affects: 2) (dups: 1) (heat: 9)" [Wishlist,Triaged] https://launchpad.net/bugs/260138
<Sarvatt> no, thats X12 I believe kees :)
<kees> Sarvatt: oh... Major major.  ;)
<Sarvatt> just curious, what do you do that hits the limit? seen ya asking for that for years :D
<bryceh> Sarvatt, when I try to pbuilder this xserver I get some unmet deps:
<bryceh>   pbuilder-satisfydepends-dummy: Depends: xutils-dev (>= 1:7.5+3) but it is not installable
<bryceh>                                  Depends: libxau-dev (>= 1:1.0.5-2) but 1:1.0.5-1 is to be installed.
<bryceh>                                  Depends: libxfont-dev (>= 1:1.4.1-2) but it is not installable
<bryceh>                                  Depends: libpciaccess-dev (>= 0.11.0-2) but it is not installable
<bryceh>                                  Depends: mesa-common-dev (>= 7.8) but it is not installable
<bryceh>                                  Depends: libgl1-mesa-dev (>= 7.8) but it is not installable
<Sarvatt> you're building in a lucid pbuilder
<Sarvatt> or not updated in a few weeks?
<bryceh> just now updated it
<bryceh> sudo DIST=maverick pbuilder build xorg-server_1.8.1.901-1ubuntu1.dsc
<kees> Sarvatt: I don't, but a friend of mine hits it all the time due to him running like 9 desktops and hundres of shells and firefox windows
<bryceh> Sarvatt, regarding that ntrig quirk patch, it still looks valid, you just need to refresh it.  Lines 12-14 in the patch need to be changed to match lines 444-446 from http://linuxwacom.git.sourceforge.net/git/gitweb.cgi?p=linuxwacom/xf86-input-wacom;a=blob;f=src/wcmUSB.c;h=249a7bfb3e96454df82b0ca9e67cfdcb5e7aefa4;hb=HEAD
<bryceh> I suspect everything else in that changeset remains the same
 * Sarvatt wishes there was a git-bzr
<jcristau> ok, got my xserver upload to people.d.o, so the painful part is done. now to sign it and move it over to ftp-master.
<Sarvatt> and a gitlib in python while i'm at it
<jcristau> bryceh: http://people.debian.org/~jcristau/xorg-server_1.8.1.901.orig.tar.gz is the tarball i uploaded.
<bryceh> thanks!
<jcristau> (with 1.9 we'll use the upstream tarball, since alanc removed the README.DRI file we'd been stripping.)
<Sarvatt> is using an old xsfbs going to screw things up in xf86-input-wacom? looks like we imported it for some patches
<jcristau> (and just to be sure, sha1sum is 46e647e61b3608dc4db5ae368f1bc9036c837d5c)
<bryceh> Sarvatt, well you could probably use a newer xsfbs without any problem, but you'll need some sort of system there to apply the patch
<bryceh> xorg-server_1.8.1.901-1ubuntu1_source.changes uploaded to my ppa
<Sarvatt> well we dont have any of the provides so I guess it doesn't really matter
<bryceh> rebuilding my maverick pbuilder instance, will try building it locally again after that
<bryceh> ok, building nicely now
<bryceh> built
<bryceh> uploading...
<bryceh> ...uploaded.
<bryceh> Let the Games Begin
<bryceh> [ubuntu/maverick] xorg-server 2:1.8.1.901-1ubuntu1 (Accepted)
<RAOF> Thanks!
<RAOF> bryceh: Could you also upload the SRU in the xorg-server ubuntu-lucid branch?  It's 2:1.7.6-2ubuntu8 with the miCopyRegion segfault & others fixed, not the GLX 1.4 backport
<RAOF> Sarvatt: dulwitch is a gitlib in python.  Used by bzr-git.
<bryceh> RAOF, I think that numbering is wrong
<RAOF> Hm.  Quite possibly.
<Sarvatt> bryceh: 2 more here, http://sarvatt.com/downloads/merges/ would you mind acking those sync requests on here https://wiki.ubuntu.com/X/PackageNotes ?
<bryceh> alright
<bryceh> RAOF, that's a lot of changes for an SRU...  do you have all of the 4 bugs there filed as SRU reports? 
<RAOF> Yes.  The first two were filed by you, the third by pitti, the last by me.
#ubuntu-x 2010-06-08
<Sarvatt> whoa! syncpackage -d unstable -r maverick -V 1:1.0.1.xsf1-3 --uploader="Robert Hooker <sarvatt@ubuntu.com>" -b 589528 libxprintutil   
<Sarvatt> syncpackage -d unstable -r maverick -V 1:2.3.0-3 --uploader="Robert Hooker <sarvatt@ubuntu.com>" -b 589530 vesa
<RAOF> I've pushed to the branch again, now as 2:1.7.6-2ubuntu7.1 and targetting lucid-proposed.
<Sarvatt> oops xserver-xorg-video-vesa for that second one
<Sarvatt> at the end
<Sarvatt> syncpackage -d unstable -r maverick -V 1:1.4.11.dfsg-4 --uploader="Robert Hooker <sarvatt@ubuntu.com>" -b 589531 xserver-xorg-video-mga
<Sarvatt> syncpackage -d unstable -r maverick -V 6.8.1-3 --uploader="Robert Hooker <sarvatt@ubuntu.com>" -b 589540 xserver-xorg-video-r128
<Sarvatt> that rocks, auto uploads and closes the bugs
<bryceh> Sarvatt, ok syncs updated, ack'd, and archive subbed
<Sarvatt> syncpackage -d unstable -r maverick -V 1:12.6.9-2 --uploader="Robert Hooker <sarvatt@ubuntu.com>" -b 589925 xserver-xorg-input-vmmouse
<Sarvatt> i dont know raof's email for the evdev one
<bryceh> RAOF, should be 7.2 - remember my "don't email bryce" patch the other day ;-)
<RAOF> Aaah!
<bryceh> sorry, didn't know you were planning to maintain the lucid xserver in git else I'd have committed it there
<Sarvatt> syncpackage -d unstable -r maverick -V 0.8.8-4 --uploader="Robert Hooker <sarvatt@ubuntu.com>" -b 589535 xf86-input-evtouch
<bryceh> actually if I'd known I'd have just slipped it in with these four, that'd be easiest
<RAOF> bryceh: Yeah.  These fixes got a little bit lost in the ubuntu branch.
<Sarvatt> ahhh synaptics, merging
<Sarvatt> err building i should say
<RAOF> Sarvatt: It's already merged, innit?
<Sarvatt> yup
<bryceh> https://wiki.ubuntu.com/X/PackageNotes updated
<RAOF> bryceh: Launchpad doesn't seem to think you've uploaded xorg-server with the âdon't email bryceâ patch?  It should therefore be possibly to merge the patch in with the other four?
<bryceh> RAOF, alrighty, you mind merging it in?
<RAOF> Not at all.
<bryceh> worst case the admins will ask us to redo it and untangle
<bryceh> I got an ack but no indication it's been accepted into the queue yet
<Sarvatt> we arent in import freeze so you can just upload directly cant ya? those lines i pasted earlier automatically grab everything and upload and close the bugs
<bryceh> oh do they?  hmm
<Sarvatt> yeah need ubuntu-dev-tools from bzr though! its an awesome script
<bryceh> bryce@blumonc:~/src/xorg-server$ syncpackage -d unstable -r maverick -V 0.8.8-4 --uploader="Robert Hooker <sarvatt@ubuntu.com>" -b 589535 xf86-input-evtouch
<bryceh> Command not found
<bryceh> bryce@blumonc:~/src/xorg-server$ apt-cache search syncpackage
<bryceh> bryce@blumonc:~/src/xorg-server$ 
<Sarvatt> yeah ubuntu-dev-tools git, its not released yet
<bryceh> git?
<Sarvatt> http://sarvatt.com/downloads/merges/xserver-xorg-input-synaptics/ (its building now to be sure itsall there)
<Sarvatt> bzr
<Sarvatt> sorry :)
<bryceh> do I just run from the bzr tree or is there some installation magic?
<Sarvatt> deb is here if you are on i386 http://sarvatt.com/downloads/merges/
<bryceh> ok
<Sarvatt> oh its all arches
<bryceh> E: No credentials found for 'ubuntu-dev-tools', please see the manage-credentials manpage for help on how to create one for this consumer.
<Sarvatt> too good to be true huh
<Sarvatt> oh guess i already created credentials
<bryceh> ok sorted that out
<bryceh> hmm, doesn't like me trying to upload stuff as you
<Sarvatt> try passing -k KEYID?
<bryceh> should I specify myself as the uploader?
<bryceh> or do I need to just import your key or something?
<bryceh> gpg: skipped "KEYID": secret key not available
<Sarvatt> nah just do it as yourself, more important we get them uploaded anyway
<jcristau> replace it with your actual key id :)
<bryceh> aha
<bryceh> dpkg-buildpackage: binary and diff upload (original source NOT included)
<bryceh> xf86-input-evtouch_0.8.8-4fakesync1_source.changes
<jcristau> RAOF: so i'm looking at putting stuff in pristine-tar for xorg-server, and every tarball i import seems to add 1M to the repo.
<bryceh> what is "-b 589535"?
<bryceh> bytes?
<jcristau> bug?
<Sarvatt> bug number it closes
<bryceh> ahh
<bryceh> Successfully signed dsc and changes files
<bryceh> xserver-xorg-input-vmmouse_12.6.9-2_source.changes
<Sarvatt> nice, it adds Launchpad-Bugs-Fixed: to the .changes
<bryceh> bryce@blumonc:~/src/ubuntu-dev-tools$ syncpackage -k E0E67611 -d unstable -r maverick -V 6.8.1-3 --uploader="Robert Hooker <sarvatt@ubuntu.com>" -b 589540 xserver-xorg-video-r128
<bryceh> WARNING! Overwriting modified Ubuntu version 6.8.1-2ubuntu1, setting current version to 6.8.1-2
<Sarvatt> huh
<bryceh> hmm same with mga
<bryceh> $ syncpackage -k E0E67611 -d unstable -r maverick -V 1:1.4.11.dfsg-4 --uploader="Robert Hooker <sarvatt@ubuntu.com>" -b 589531 xserver-xorg-video-mga 
<bryceh> WARNING! Overwriting modified Ubuntu version 1:1.4.11.dfsg-2ubuntu1, setting current version to 1:1.4.11.dfsg-2
<Sarvatt> hmm now ubuntu-dev-tools has acksync in it too! wth
<bryceh> hrm, got it for -vmmouse too, but didn't notice it before doing the upload
<bryceh> $ syncpackage -k E0E67611 -d unstable -r maverick -V 1:12.6.9-2 --uploader="Robert Hooker <sarvatt@ubuntu.com>" -b 589925 xserver-xorg-input-vmmouse
<bryceh> WARNING! Overwriting modified Ubuntu version 1:12.6.5-4ubuntu2, setting current version to 1:12.6.5-4
<jcristau> i guess the warning is to make sure you really want to get rid of the delta?
<bryceh> jcristau, yep
<bryceh> also the -evtouch sync failed... needs to be fakesync'd
<bryceh> so add that one to the merges pile
<jcristau> RAOF: so i'm looking at putting stuff in pristine-tar for xorg-server, and every tarball i import seems to add 1M to the repo :/
<RAOF> jcristau: Urgh, really?
<Sarvatt> nice, ack-sync even has an option to build the packages too
<Sarvatt> its just a wrapper around syncrequest
<RAOF> jcristau: I don't have much more insight than âman, that sucksâ, though :)
<RAOF> Sorry, call with Rick.
<jcristau> RAOF: i'm thinking it's because it has a lot of autotools-generated files, which aren't in git
<RAOF> That may well be it.
<bryceh> ok looks like for -mga the only change is a patch that's already upstream, according to https://edge.launchpad.net/ubuntu/maverick/+source/xserver-xorg-video-mga/1:1.4.11.dfsg-2ubuntu1
<bryceh> so I've put -mga through
<RAOF> jcristau: Incidentally, I noticed there were a lot of files in git but not in the tarball.  I've removed them locally, so lintian now doesn't complain about changing files outside of debian/.  I'll merge that in to debian-experimental later, if you like.
<Sarvatt> yup, made sure each of those had every patch we had upstream before requesting it (or bugged jcristau to update things to sync) :D
<bryceh> Sarvatt, ok are you 100% sure all of these can just sync and ignore the ubuntu changes?
<Sarvatt> syncpackage -d unstable -r maverick -V 1:2.3.2-6 --uploader="insert roafs info here" -b 586659 xserver-xorg-input-evdev
<bryceh> otherwise we'll need to go through and check each individually
<Sarvatt> yes 100% positive, i didn't request anything that wasn't in debian or upstream already
<Sarvatt> and if it was in upstream and not debian i updated debian :D
<bryceh> alrighty
<bryceh> xserver-xorg-video-r128_6.8.1-3_source.changes done
<RAOF> syncpackage -d unstable -r maverick -V 1:2.3.2-6 --uploader="Christopher James Halse Rogers <raof@ubuntu.com>" -b 586659 xserver-xorg-input-evdev
<RAOF> ^^ That's what you were after, Sarvatt  ;)
<jcristau> RAOF: i tend to ignore this lintian bit.  the files are in upstream git, so deleting them means merge pain if they get modified upstream, and unless they're huge removing them doesn't buy us much. i don't care much though.
<bryceh> RAOF, thanks
<bryceh> xserver-xorg-input-evdev_2.3.2-6_source.changes uploaded
<jcristau> RAOF: (if they're in the debian branch but not upstream, then that's a different story, but i think we mostly got rid of that a while back)
<RAOF> jcristau: Fair enough.
<bryceh> libxprintutil_1.0.1.xsf1-3_source.changes uploaded
<bryceh> Sarvatt, got more for me?
<Sarvatt> going back over and seeing what ya uploaded
<bryceh> everything in the Waiting list at https://wiki.ubuntu.com/X/PackageNotes was done
<bryceh> except one
<bryceh> -evtouch has to be fakesync'd
<Sarvatt> sweet, edit-patch automatically adds patches if you have any local ones now too
<bryceh> 15 min remain... anything else I can help y'all with today?
<RAOF> The xorg-server SRU would be good.  I've merged your patch, and double checked that it builds.  I'll just push up to git.
<bryceh> ok
<RAOF> Pushed in git.
<bryceh> uploaded to lucid-proposed
<RAOF> Thanks!
<RAOF> bryceh: Have a good dinner tonight!
<bryceh> no prob, good luck with the rest of the uploads
<bryceh> hopefully you'll be able to find other sponsors but if you get in a pinch lemme know
<RAOF> I think I'll be able to tap some of #ubuntu-desktop :)
<Sarvatt> argh, had to run out there, take care and thanks bryce
<Sarvatt> not to ppa-purge all these machines and upgrade as things come :)
<Sarvatt> now to do that rather
<Sarvatt> and \o/ you dropped the ati patch series, that ended up not doing anything for those bug reports anyway
<Sarvatt> oh.. you probably just forgot to git add huh? :( we had some other real post 6.13 fixes in there
<RAOF> Sarvatt: What are you talking about?
<Sarvatt> ati?
<Sarvatt> in git?
<RAOF> Hm.  Maybe I did forget to git add.
<RAOF> Well, it hasn't been uploaded yet.
<Sarvatt> i think i hit a new point of lazyness when i rename a tarball and include all the new commits as patches in the diff :D
<Sarvatt> mv libdrm_2.4.20+git20100527.607e228c.orig.tar.gz libdrm_2.4.20+git20100607.66375fd6.orig.tar.gz it is!
<Sarvatt> such a pain syncing libdrm and people think they are using the old one because of the name
<Sarvatt> bjsnider: your vaapi acceleration stuff is all in there now
<bjsnider> in the libdrm?
<RAOF> Ah, the multi ringbuffer patch has finally landed?
<Sarvatt> yeah
<RAOF> That was a bit of a drama.
<bjsnider> wish i had an intel card to test it on
<bjsnider> wait, no i don't
<RAOF> Hah.  You totally do.  Intel hardware rocks.
<bjsnider> yes it does
<jcristau> RAOF: so running git import-orig on all tarballs to get the upstream/* tags on http://git.debian.org/?p=users/jcristau/xorg-server.git + the pristine-tar branch there adds up to ~15M afaict, which is more reasonable.
<RAOF> That's not terrible.  It's mostly a one-off cost, too, and bandwith is (generally) cheaper than my attention :)
<jcristau> i downloaded all tarballs from snapshot.debian.org so that should be pretty much all xorg-server tarballs ever uploaded to debian
<RAOF> Excellent!
<RAOF> Sarvatt:  You've added 102-disable-page-flipping-v2.patch to xf86-video-intel - on what hardware is that meant to be a problem?  Is there a bug link available?
<Sarvatt> i dont have a bug link handy because wenever shipped it, it's been a problem all throughout the late 2.10+ cycle and still a problem today in git and fedora is shipping the same thing
<Sarvatt> they haven't figured out where the problem is yet
<RAOF> Sarvatt: I ask this because I'm very happily running without that patch on my invincible laptop.
<Sarvatt> 915-X3100 seems to be the range bad off
<RAOF> Fair enough.
<Sarvatt> and some of the devs are having it on GM45 too
<Sarvatt> (what you have)
 * RAOF can recognise his own chipset :)
<Sarvatt> here is fedoras http://cvs.fedoraproject.org/viewvc/F-13/xorg-x11-drv-intel/intel-2.11-no-pageflipping.patch?view=markup
<Sarvatt> some people like hyperair can't go 10 minutes with it enabled, figured it was better to patch it preemptively since there isn't any kind of freeze
<Sarvatt> https://bugzilla.redhat.com/show_bug.cgi?id=588421
<ubot4> bugzilla.redhat.com bug 588421 in xorg-x11-drv-intel "Pageflipping disabled in F13" [Medium,Assigned]
<Sarvatt> http://www.pubbs.net/201005/fedora/1529-page-flipping-on-intel-211-driver.html
<RAOF> Man, that's a useless bug report :)
<Sarvatt> (the patch was from jbarnes, I just changed the info message in it)
<ripps> That's it, I'm taking the plunge and upgrading to maverick
<RAOF> Get in quick, before xserver 1.8 has been published :)
<ripps> I'm already using 1.8 from xorg-edgers, is it very different?
<Sarvatt> ppa-purge first!!
<Sarvatt> no its the same but ati has had a ton of changes since 6.13
<Sarvatt> word of warning though, i'm putting edgers on 1.9 any day now :D
<Sarvatt> just in maverick
<ripps> good, I'll probably try it from maverick
<ripps> xorg-edgers has maverick packages, right?
<Sarvatt> yeah, basically the same as lucid now, i upload the same stuff to both
<Sarvatt> maverick's i686 instead of i486 though
<Sarvatt> if you're on x86
<ripps> I use a athlonxp 2500+, I'm pretty sure that's i686
<stenten> Wait, would being on xorg-edgers interfere with the 1.8 switch in Maverick?
<ripps> I'm purging xorg-edgers now
<stenten> Most of the people on the Maverick Forum are running edgers.
<ripps> I have alot of ppa's, any other's I should purge, like nautilus-elementary?
<RAOF> stenten: Yeah, they're not really helping test X in Ubuntu.
<ripps> I should probably purge the Unity and gnome-shell stuff too, while I'm at it
<Sarvatt> well they probably wont be on edgers soon with all the breakage incoming :)
<RAOF> Sarvatt: So, it looks like there's at least one pageflipping bug that's been fixed upstream.  I think I'll pull those patches and drop the pageflipping disablement patch.
<Sarvatt> okie, the bugs will be hard hangs with the system completely dead and no way to get info out of it when you come across them
<RAOF> Hm.  I might check that we've actually got the kernel side of the fix - it doesn't seem to be in yet.
<Sarvatt> i've been dropping the patch from edgers every kernel upgrade to see if its fixed and readding it when its not
<Sarvatt> some of the hangs might be fixed in rc2 though, i saw a few commits
<RAOF> It doesn't look like it's in 2.6.35-rc2, so that puts the kybosh on enabling page flipping it seems.
<Sarvatt> i think it was merged in the rc2 cycle but the commits were old enough to be back before rc1
<Sarvatt> drm/i915: Kill dangerous pending-flip debugging is one
<RAOF> There should also be a gen 3 patch; that doesn't seem to be in any git repository.
<Sarvatt> looks like thats it upstream :(
<RAOF> I'm talking about http://lists.freedesktop.org/archives/intel-gfx/2010-April/006463.html
<Sarvatt> yeah i saw it on the lists
<Sarvatt> april...
<RAOF> So, the result is: page flipping is probably still broken, leave it disabled.
<RAOF> Anyway, lunch time!
<Sarvatt> will ask jbarnes whats up
<Sarvatt> that one patch of his fixing hangs on dpms events still isn't upstream and it was from january i think..
<RAOF> Hah.  We get 1.8 uploaded and 1.9 rc1 gets branched.
<Sarvatt> yeah been testing it the past few days, intel is horribly broken :)
<Sarvatt> i'm blaming the gtk stuff since other people arent seeing it
<Sarvatt> was hoping bgnr support could make the cut :(
<Sarvatt> holy crap, i got almost10k karma from uploading all the x driver/libs/protos
<Sarvatt> ever figure out whats forcing 96 dpi everywhere?
<Sarvatt> we had a patch doing it before -     - 138_fedora_xserver-1.3.0-default-dpi.patch
<Sarvatt>       Changes default dpi to 96.
<Sarvatt> hmm might be gdm's xsettings manager plugin?
<ripps> okay, system has been cleaned of a lot of ppas
<RAOF> We interrupt your regularly scheduled IRC proxy to bring you 5.8 GiB swap usage.
<RAOF> Sarvatt: http://bugs.freedesktop.org/show_bug.cgi?id=23705 is why X is set to 96 DPI
<ubot4> Freedesktop bug 23705 in Server/general "xserver 1.7.0rc0 uses wrong dimensions" [Normal,Reopened]
<RAOF> I'd like to revert that and let GNOME and KDE handle it if they feel they must.
<lucazade> hi Sarvatt
<lucazade> did you read my message yesterday about poulsbo patch?
<asac> RAOF: !!
<asac> RAOF: did you get my message about stuff failing on armel?
<RAOF> asac: Hi!
<RAOF> asac: Ah, yes I did, but for some reason I didn't read it as something that needed responding to - I got it quite a lot after you sent it.
<RAOF> asac: Does any arm hardware actually have intel graphics hardware?  If not, it shouldn't be hard to just drop the dependency and drop the intel build (on arm, so the same package builds appropriately in the archive)
<jcristau> building libdrm-intel on arm is nonsense afaik
<asac> RAOF: it fails on armel with intel .so not there
<asac> yes
<RAOF> Aha.  Ok.  I'll update the packaging to handle that, then.
<RAOF> (Tomorrow)
<RAOF> Hm.  Now that there's an openvg library to build against, I wonder how cairo's openvg backend doesâ¦ :)
 * RAOF is off to the movies.  See you tomorrow!
<asac> RAOF: whats the idea?
<asac> i can do that too then?
<asac> RAOF: we could --disable-intel on !x86/amd64 i guess?
<RAOF> asac: The idea would be, in debian/rules, to not build anything that requires libdrm_intel on arm.  Right something like that.
<asac> RAOF: yeah. so just not on armel or everywhere? how does the package actually build for all the archs in maverick?
<RAOF> I didn't think intel built by default, but perhaps it does.
<asac> it seems to do ... but i see that the build succeeded everywhere in maverick ... which feels like this might not be the problem
<asac> anyway, enjoy your evening. i will try :)
<RAOF> The current archive package would build everywhere because it only enables i915 and i965 on amd64 and i386.  But it also --disable-gallium's
<RAOF> Ta.  Good luck!
<apw> Sarvatt, seems i am about to expire out of xorg-edgers are you able to wave a wand over that?
<Sarvatt> asac: you need libdrm-intel1 to build plymouth on arm :)
<asac> Sarvatt: why is that?
<asac> then i will just enable all the intel packages everywhere
<asac> they seem to build ... not sure why just the intel1 package was disabled on arm in the first plac
<tseliot> asac: because plymouth has a drm plugin with different backends for radeon, intel and nouveau. It's what it uses to map the framebuffer, etc.
<asac> kk
<asac> will remember that when touching it next time
<asac> (reenable intel everywhere)
<tseliot> good
<jcristau> tseliot, Sarvatt: plymouth needs to be able to disable some of the backends.
<tseliot> jcristau, Sarvatt: I *think* it's possible to disable the drm renderer (thus disabling radeon, intel and nouveau)
<jcristau> not good enough
<tseliot> I'm not even sure about that. I haven't checked
<nperry> Hello guys, wondered if somone could have a look at xserver-xorg-video-nouveau for maverick, it seems to of failed its last build becuase its still depending on  Xserver 1.7
<seb128> nperry, it didn't fail it's depwaiting
<seb128> there is a known soyuz issue that it's taking a while to see that the depwait is cleared
<seb128> the new xorg has only be newed some hours ago so you just have to wait
<nperry> Ah ok, no problems!
<bryceh> there was an email to ubuntu-devel@ sent about this the other day
<RAOF> asac: Any joy with the mesa build?
<asac> RAOF: let me check ;)
<asac> took more time then i had before leaving so felt good
<asac> thumbs up: https://edge.launchpad.net/~asac/+archive/armel1/+build/1778126
<asac> yay
<RAOF> Yay!
<asac> RAOF: anyway, i was told that we need to resurrect intel for something
<asac> will just enable it everywhere
<asac> it seems to build everywhere at least ;)
<asac> right
<asac> here the reason:
<asac> 17:51 < tseliot> asac: because plymouth has a drm plugin with different backends for radeon, intel and nouveau. It's what it uses to map the framebuffer, etc.
<asac> RAOF: ^^
<asac> for me it feels not particular !armel specific to build a driver for an intel chip
<asac> as long as it builds it should be fine imo
<asac> so anything against just setting the intel1 thing to any?
<RAOF> Apart from the fact that there's no hardware it could possibly drive on !{i386,amd64}, not really.
<RAOF> It'll just needlessly inflate the build times & package sizes on those archs.
<asac> right
<asac> but i think things like radeon and ati could in theory exist
<asac> why not intel ;)
<asac> if its a usb/pci card, then it should just work
 * asac considers to find a card for his intel chipset ;)
<RAOF> Intel don't make usb/pci cards :)
 * cwillu feels a sudden urge to check for video chipsets on digikey :p
<asac> they dont? hmm ... /me sees a market gap ;)
<asac> opportunity its called
<asac> btw, http://identi.ca/notice/35424509 ... just so you know ;)
<jcristau> asac: plymouth just needs fixing.  it's a 5 minutes job..
<RAOF> That would be the other option, yes.
<asac> ok i let you guys figure ouw what you want ... imo usb/pci based drivers don't need to be disabled just because its arm and its called intel ;)
<jcristau> it's not usb/pci.  it's integrated graphics on intel kit.
<jcristau> it comes on the chipset with an intel cpu.  or on the same chip as the cpu, lately.
<asac> jcristau: but the driver is registered as pci ;)
<asac> isnt it?
 * asac types lspci
<cwillu> asac, when a device becomes available, the driver can be trivially enabled
<cwillu> until then, why waste the resources?
<asac> cwillu: right. why waste resources and disable it ;) ... we can just keep it enabled and dont need to touch packging
<lifeless> RAOF: so, I have a gt200 (gtx260) reva
<lifeless> RAOF: and I play games on it
<RAOF> A fine use of a dedicated GPU.  GO on.
<lifeless> RAOF: also, remind me about cedega full screen being offset by a couple of inches
<lifeless> RAOF: what driver should I run on the gt200 - is nouveau there yet for (say) wow, civIV, steam:source games ?
<RAOF> No, I don't think so.
#ubuntu-x 2010-06-09
<RAOF> Among other things I think that steam does some GL vendor string parsing and freaks out about gallium drivers.
<RAOF> The nouveau drivers would be pretty featureful, but significantly less stable.
<RAOF> And significantly less fast, too.
<lifeless> brb
<lifeless> right, where was I
<lifeless> oh yes
<RAOF> In Sacrifice?
<lifeless> heh
<lifeless> so in lucid
<RAOF> Cedega fullscreen being off by a couple of issues is likely to be either (a) cedega's fault or (b) a VGA connector issue. 
<lifeless> and I just upgraded my games machine, so its new
<lifeless> when it goes fullscreen, most of the time, its offset to the bottom-right
<lifeless> *but the desktop shows in the gap*
<RAOF> Ah.  Silly cedega.
<lifeless> worked in karmic
<Sarvatt> intels gpu's are such crap noone would buy a seperate card and they know it :)
<RAOF> And it turned out doing a GPU in software on top of a bunch of tiny x86 cores wasn't as easy as they thought, too.
<RAOF> Worked in Karmic, eh?
<lifeless> RAOF: this occurs with both i915 or whatever my laptop has, and the nvidia in my games machine
<lifeless> RAOF: and it was pixel perfect yesterday morning before the upgrade
<Sarvatt> what upgrade?
<lifeless> karmic-lucid
<lifeless> my games machine was shipped transtasmin so this was the first chance to do it
<lifeless> http://imagebin.org/100511
<lifeless> RAOF: ^
<RAOF> I think this is unlikely to be an X problem.
<lifeless> shows both the offset, and the other thing I wanted to query you on
<RAOF> Oh, a third thing? :)
<lifeless> yes
<lifeless> choosepixelformat failed
<lifeless> which google tells me was fixed in 2006 with glx1.3
<lifeless> and glxinfo claims the nvidia driver is glx1.4
<lifeless> whats particularly special is alt-tab to and from the fullscreen app aligns it correctly on the screen
<RAOF> I think google might be wrong, because the open drivers haven't been claiming glx1.3 support untilâ¦ Lucid, until we disabled it.
<lifeless> well, I know that I know not, in this space.
<lifeless> I'm going to get a vanilla wine install of steam up
<lifeless> and see if its better
<Sarvatt> yeah that'd be the first thing i'd try too
<lifeless> though that itself appears to be black magic
<Sarvatt> ? it installs fine here
<Sarvatt> i'm in the process of installing counterstrike now in it
<Sarvatt> pretty sure you can just use the cedega one too since its just wine
<lifeless> blows up when I run regular wine on it
<lifeless> with WINE_ENV or whatever set
<lifeless> cleaner to start fresh, I think
<Sarvatt> looks like wine with the blob starts things at 60hz when it changes resolutions
<Sarvatt> the blob lies about what refresh rate you're at for its twinview crap
<Sarvatt> try adding Option		"DynamicTwinView"	"false" to your xorg.conf?
<Sarvatt> found an old forums post from 07 with the same problem it looks like - http://ubuntuforums.org/showthread.php?t=629173
<lifeless> I'm in awe of your googlejuice
<Sarvatt> wine fullscreen xserver 1.7 found it :)
<lifeless> ah 
<lifeless> thats for the offset thing, not the pixel format
<lifeless> right
<Sarvatt> looks like disabling compiz will fix the choosepixelformat error
<lifeless> I have visual effects set to None already
<lifeless> I thought that disabled compiz ?
<Sarvatt> oh, darn :(
<Sarvatt> http://forums.steampowered.com/forums/showthread.php?t=1282981
<Sarvatt> looks like it picks directx mode by default and that switched it to opengl so it works
<lifeless> that screenshot was set to gl mode :)
<lifeless> d3d mode goes boom
<lifeless> I'm pulling down cs in a fresh wine setup
<lifeless> will report back in a couple hours I guess
<lifeless> for now, bzr stuff awaits
<Sarvatt> intel needs a rebuild :( looks like the server was stuck in NEW
<Sarvatt>  Provides: xserver-xorg-video-6
<lifeless> RAOF: so, lucid wine does a bit better
<lifeless> Sarvatt: the twinview thing helped
<ripps> I'm trying to use ppa-purge to downgrade xorg-edgers to default maverick, but I'm having some kind of dependency problem with xserver-xorg-core and the virutal input packages.
<ripps> Sarvatt: ^
<RAOF> ripps: Yes, you will.  Not everything's built for the new server yet.
<ripps> RAOF: ah, okay. Any idea when they'll roll out?
<RAOF> Today.
<lifeless> RAOF: cedega is still naffed :-) chalk one up for open sores
<RAOF> Heh.
<lifeless> RAOF: now, just have to remove pulseaudio and everything should be happy again
<RAOF> Ok.  Weirded out by that mesa backtrace.
<ntr0py> I have a very strange bug indicating gdm starts too early in upstart on lucid resulting in low graphics mode with nvidia-current installed via jockey...
<ntr0py> This is very irritating for people installing the suggested nvidia driver via jockey and on next reboot they get "ubuntu is running in low graphics mode" error message...
<bryceh> ntr0py, http://ubuntu.com/support
<ntr0py> To avoid the effect of this issue it is enough to delay the start of gdm for only 2 seconds on my system, but it leaves the causes (upstart race) untouched...
<ntr0py> bryceh: What should i do with your url??
<bryceh> ntr0py, if your interest is merely in getting your machine working with lucid, there are plenty of support channels to go through.  This is a development channel.
<ntr0py> bryceh: I do have a working machine with a the dirty hack avoiding the effects of this issue (delaying gdm start), but i think this is a bug in upstart (race condition).
<bryceh> then analyze it fully and submit a bug report (and perhaps a patch against the upstart rule if you're conversant in upstart)
<bryceh> however you might check if it's just that the nvidia kernel module didn't finish building before gdm tried to start X, which is already a known issue.
<bryceh> patches definitely welcomed on that one, as the number of developers who support the proprietary driver is pretty limited.
<bryceh> anyway, nite.
<RAOF> bryceh: Good night!
<ntr0py> bryceh: I did analyse it finding out the hack and tried adding something in /etc/init/gdm.conf ("and graphics-device-added nvidiactl PRIMARY_DEVICE_FOR_DISPLAY=1"), but unfortunately im not familiar enough with upstart to do this...
<RAOF> ntr0py: Something like that would be the way to do it, yeah.
 * RAOF is also off.
<ntr0py> Any ideas how i could wait with gdm's start on nvidia module having build and beeing ready for use in upstart?
<seb128> the current intel driver got built with the old xserver
<seb128> should it be rebuilt to get the new abi?
<jcristau> yes.
<seb128> is there a list of things that need to be rebuilt still somewhere?
<seb128> jcristau, do you know if the rebuild is hold off for a reason or if I should just do a no change upload for it?
<jcristau> don't know of a reason you should hold off
<seb128> ok thanks
<seb128> I will let a bit for somebody to comment if there is a reason or do an upload in an hour otherwise
<jcristau> it's the middle of Sarvatt's night and RAOF said he was off an hour ago :/
<seb128> seems quite some other drivers didn't get rebuild though
<seb128> let's give some build retries
<seb128> soyuz depwait handling got turned off yesterday
<seb128> they had issues with it since the new update
<bigjools> it's coming back RSN :)
<seb128> how rsn is?
<bigjools> it's getting cherry picked right now
<seb128> which means it will land in production today?
<seb128> ie it will be active once cherry picked?
<seb128> or does it still need to wait a rollout?
<bigjools> it'll be in production when it's picked
<seb128> ok thanks
<seb128> I will stop to manually retry all the drivers then
<asac> whats the story about gallium driver? what benefit/use case is that targetting?
<RAOF> seb128: I've got a set of no-change rebuilds locally plus a new siliconmotion upstream to build against 1.8.  You're welcome to retry or upload no-change rebuilds for all the video drivers.
<seb128> RAOF, seems they fixed depwait now
<seb128> RAOF, do you plan to upload your no change rebuilds?
<RAOF> I don't have upload rights for them.  I was going to beg for for sponsorship from Luke tomorrow.
<seb128> do you have them ready somewhere?
<RAOF> Yeah.  I'll put them on my webserver
<seb128> so it's just debsign and upload?
<RAOF> Right.
<seb128> can you give the url on #ubuntu-desktop?
<ripps> grr... still can't downgrade from xorg-edgers yet... when are they gonna finish building those packages.
<RAOF> asac: The gallium architecture is meant to make it easier to write graphics drivers for modern cards.  The idea is basically to have a low-level architecture which maps easily to modern graphics chips (which are all about programmable stuff) that you can build APIs on top of (OpenGL, OpenVG, DirectX, etc)
<asac> RAOF: so is that something that will become interesting for ARM (or already is?)
<jcristau> as long as arm means sgx...
<asac> ok so its vendor responsibility to make that happen i guess ...
<asac> but is that of benefit for us?
<asac> e.g. should i go to vendors and tell them to do gallium?
<RAOF> Only if it makes sense for their hardware.
<asac> please elaborate a bit ;)
<RAOF> The gallium architecture only makes sense for GPUs which look sufficiently like current desktop GPUs - where there's not much fixed-function hardware, and pretty much everything is programmable and shader-y and such.
<RAOF> If your GPU hardware looks sufficiently like that, then building your driver using the gallium code will make it easier to support lots of API frontends - OpenGL, GL|ES, OpenVG, etc.  Video decode acceleration is also likely to be implemented there (at some point).
<RAOF> If your GPU hardware doesn't look like that - it doesn't have flexible shaders, it's got a lot of fixed-function stuff - then using the gallium code won't be helpful.
<RAOF> The classic mesa infrastructure is more suitable for fixed-function hardware, and is not going to be going away.  We still need it to support the fixed-function desktop hardware, like pre r300 ATI, and older intel chips.
<asac> RAOF: whats your personal opinion? do you think the win through reduced efforts in writing driver frontends is worth this extra level of abstraction?
<asac> ok ... so all modern stuff is using gallium?
<RAOF> A lot of modern development is using gallium.
<RAOF> Almost all of the recent work on r300-r500 cards has been in the gallium driver, and gallium offers a much easier path to get to OpenGL 3 and 4 than the classic mesa drivers.  We'll likely be shipping the r300 gallium driver instead of the r300 classic driver for Maverick.
<asac> ok so there is consent that gallium is the way forward for modern hardware. thanks for the background
<RAOF> Nouveau only has a gallium driver for nv30+.  The older chips (nv04-nv2x, corresponding to TNT â GeForce 3) have a classic mesa driver.
<RAOF> asac: Right.  Anything which looks like a modern desktop GPU should be using gallium.  ARM GPUs have significantly different constraints, so I'm not sure how much like a modern desktop GPU they behave.
<RAOF> Hm.  Anything which is supposed to support GL|ES v2 is probably enough like a desktop GPU to benefit from gallium.  From what I read of GLES v2 it's very much about programmable pipelines and shaders, which is what gallium requires.
<Dr_Jakob> RAOF: Anything that has shaders and want to implement either GL or DX is suitable for gallium
<Dr_Jakob> Which is all modern hardware
<Dr_Jakob> including low powered ARM gpu's..
<RAOF> Dr_Jakob: Didn't know you idled here!
<Dr_Jakob> I do now :)
<RAOF> I think I'd talked myself around to the position that ARM gpus probably wanted gallium, since they GLES v2 appears to be all about the shaders, too. :)
<Dr_Jakob> I dunno about the mali GPU but for SGX most people pay PowerVR for their closed source driver.
<RAOF> I think we're aiming to be in a position to show demand for opensource drivers, rather than actually having any drivers currently.
<hyperair> aaargh
<hyperair> third time crashing due to intel gpu hang, third time re-running mp3gain, and third time fixing corrupted banshee sqlite db.
 * hyperair groans
<ilmari> hyperair: gpu hang or driver deadlock?
<hyperair> er
<hyperair> how do i tell which?
<ilmari> which gpu?
<hyperair> intel gpu
<hyperair> er
<hyperair> 2a02
<hyperair> 965
<hyperair> X3100
<hyperair> the first number is my pci-id
<hyperair> the last two are the two different model numbers my gpu appears to go by
<hyperair> well i'm using xorg-edgers, so i can't really blame anyone but myself for getting these wonderful hangs >_.
<ilmari> ah
<ilmari> I used to get gpu lockups on lucid, but that stopped. now I get x/kernel deadlocks instead :(
<ilmari> on arrandale (core i7 integrated graphics)
<hyperair> ilmari: how do you tell the difference between a gpu lockup and an x/kernel deadlock?
<ilmari> hyperair: by SSHing in when it happens and looking at dmesg, Xorg.0.log, intel_gpu_dump
<hyperair> ilmari: ah i see. well soudn hangs for me, so i'm sure it's a deadlock then =p
<hyperair> time to start mp3gain again..
<hyperair> and hope that it doesn't fail miserably this time >_>
<ilmari> also SysRq-d (show held locks, requires a kernel with lock debugging), SysRq-w (show blocked tasksk)
<hyperair> eh?
<ilmari> to show  what's blocking
<hyperair> no sysrq keys all crash for me
<hyperair> i mean
<hyperair> the sysrq keys no longer do anything.
<ilmari> not even sysrq-b? wow
<ilmari> (preferrably preceded by s and u)
<hyperair> not even that.
<ilmari> that sounds like a GPU or other hardware hang
<hyperair> =\
<ilmari> my deadlock is https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/568138
<ubot4> Launchpad bug 568138 in xserver-xorg-video-intel (Ubuntu) "[arrandale] deadlock in i915_gem_madvise_ioctl (affects: 6) (dups: 1) (heat: 36)" [Undecided,Confirmed]
<hyperair> AAAAAAAAAAAAAAAAAAAAAAAARGH!
<hyperair> AGAIN!
<Sarvatt> hyperair: 945 and g33 are fine here, no idea whats up with yours
 * hyperair switches from forbid-version to hold
<Sarvatt> what kernel?
<hyperair> .35-rc2
<Sarvatt> maybe try rc1 again and see if its ok there still?
<hyperair> nah, things only went sour after last night's upgrade
<hyperair> after mp3gain finishes, i'll turn on X to see what's going on.
<Sarvatt> machine dead when it hangs or can you get any more info out of it?
<Sarvatt> there were huge changes in 965 mesa yesterday
<hyperair> haaaaaaaangs.
<Sarvatt> maybe try disabling compiz?
<Sarvatt> so ya can blame mesa
<hyperair> and go non-composited for hours on end until it hangs?
<hyperair> nothanks.
<hyperair> i'd end up ignoring the machine, which would in turn ignore me and refuse to hang.
<Sarvatt> metacity compositing? :D
<ThisOtherGuy> hi all - can anyone help me with this: http://pastebin.com/7wdqrVdH
<hyperair> Sarvatt: ._. that sounds terrible.
<hyperair> Sarvatt: i really meant compizless though. gnome-shell is still tolerable, but i can't really go without compiz's extra features, particularly scale for long before cracking and switching to my desktop
<Sarvatt> hyperair: build compiz from git where opengl is optional? :D
<hyperair> Sarvatt: don't have the plugins require opengl?
<hyperair> Sarvatt: actually i've been meaning to, but at the rate i'm crashing, i'll never get to clone compiz from git.
<Sarvatt> i dunno, lets see. i dont think they do though
<Sarvatt> 	    <requirement>
<Sarvatt> 		<plugin>opengl</plugin>
<Sarvatt> so scale does :(
<hyperair> heheh
<Sarvatt> could always just purge xorg-edgers and use 2.11 from x-updates :D
<Sarvatt> of course mesa is going to suck then
<Sarvatt> why did we make nvidia-graphics-drivers provide a video abi again? it supports multiple abi's with the same package..
<Sarvatt> (needs to be no change rebuilt too)
<Sarvatt> nvidia-173 and lower dont work with 1.8 either yet, i think they'll work with the IgnoreABI option though
#ubuntu-x 2010-06-10
<RAOF> Sarvatt: Do you have any insights into why we have xserver-xorg-video-radeonhd in the archive?
<Sarvatt> some people still use it, it's certainly more maintained than half the other video drivers.. :D
<RAOF> I guess so.
<RAOF> It doesn't work with KMS, though.
<RAOF> I guess we're not going to remove it, so we should rebuild it.
<RAOF> Hm.  Actually, we can remove it.
<bryceh> yeah it can be dropped now
<bryceh> we pulled it in back when there was a lot of excitement about it, but really haven't done anything with it
<bryceh> and in fact I think I already unsubbed ubuntu-x@ from its bug tracker (and I think I wontfixed all its bugs)
<RAOF> You didn't wontfix them, but I've just confirmed & sub'd ubuntu-archive on the removal bug.
<bryceh> ok
<bryceh> well, the bugs certainly can be wontfixed now :-)
<RAOF> Yup :)
<Sarvatt> oh man, that canonical-desktop-team/une ppa trashed things :)
<Sarvatt> think i'll hold off on indicator-appmenu until its in maverick
<Sarvatt> cant launch my most used app with it (geany)
<ripps> Sarvatt: unity is in the maverick repos now
<Sarvatt> appmenu-gtk isn't though
<Sarvatt> i can't find libappmenu.so in any package
<Sarvatt> was trying to follow the ubuntu desktop installation section on here - https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationMenu
<ripps> Damn, still can't downgrade from xorg-edgers yet.
<RAOF> Yup.  We're beavering away solidly at that.
<Sarvatt> hmm
<Sarvatt> Source: xserver-xorg-video-glide
<Sarvatt> build depends on  libglide2-dev
<Sarvatt> Package: libglide2-dev
<Sarvatt> Section: libdevel
<Sarvatt> Architecture: i386
<Sarvatt> fails on amd64
<Sarvatt> [ 46933.281] xorg-server 2:1.8.99.0+git20100609.8e97e5f9-0ubuntu0sarvatt (For technical support please see http://www.ubuntu.com/support)
<Sarvatt> hmm that looks kind of out of place for xorg-edgers :)
<Sarvatt> xserver 1.9 PPA looks good to go though, just need to refresh the nouveau autoconfig patch
<RAOF> Score.
<Sarvatt> the BGNR stuff is all busted though, could be problems in maverick :)
<RAOF> Maybe hang back a little bit on the update until people can downgrade.
<Sarvatt> oh yeah it'd be a week or two before i did it, its not even branched yet still
<RAOF> It got sent upstream, though, so that's +1
<Sarvatt> yeah had to ask 3 different people if they'd upstream it in the past few months since noone knew who originally wrote it and airlied did the other day \o/
<RAOF> Once we *have* got maverick upgradable feel free to break everyone's X using -edgers.  There shouldn't be any ABI changes at this point, so 1.9 is good to go!
<Sarvatt> the bgnr patch that got sent to the lists breaks the video abi
<ripps> Yeah, wait a bit on 1.9. I'm still unable to downgrade from xorg-edgers due to unfinished X migration in maverick
<Sarvatt> ripps: i wouldn't, dont worry :)
<Sarvatt> and yeah it stinks, i have 9 machines here and can't test stock maverick on any of them, lucid ones cant upgrade to maverick, maverick ones are all on edgers because I was testing upgrades and cant downgrade
<Sarvatt> xorg metapackage really needs to be updated so people can just remove xserver-xorg-{video,input}-all and actually upgrade maverick now
<Sarvatt> but xserver-xorg-core still needs wacom and i didnt have any luck with that merge, that package is such a PITA
<RAOF> Sarvatt: You don't have any wacom hardware, do you?
<Sarvatt> yeah i've got 2 tablets
<Sarvatt> i use that from git regardless of what i'm on though, too many fixes going into it too fast
<ripps> I have to rebuild my wacom module every linux update now, kernel doesn't have support for bamboo ctl-460. I wrote a script that builds, loads, and configures it automatically.
<Sarvatt> ripps: checked linux-input to see if they submitted it upstream even yet?
<ripps> Sarvatt: the last wacom patch was on april 21
<ripps> Does anybody know how make a kernel module backport package? I might be able to help some people by just having a package they can install easily.
<ripps> Even better, how to make a dkms package.
<Sarvatt> they haven't even tried sending them upstream :(
<Sarvatt> just looked at the last 6 months of linux-input on patchwork.kernel.org
<Sarvatt> what was the deviceid again? 00d4?
<Sarvatt> 0xd4 works with xf86-input-wacom, just not the darn kernel module
<Sarvatt> maybe fedora patches it in their kernel, lessee
<hyperair> Sarvatt: ah, seems i overdid my phc, which caused the hang yesterday.
<Sarvatt> lol ok that makes more sense
<Sarvatt> was wondering why i couldn't find anything
<Sarvatt> thats odd, getting [ 46933.277] 1 XSELINUXs still allocated at reset in Xorg.0.log even though i'm building with --disable-xselinux
<RAOF> Sarvatt: want to try a new xserver-xorg-input-wacom?
<Sarvatt> yep throw it at me :)
<RAOF> www.cooperteam.net
<Sarvatt> amd64... :D
<Sarvatt> only machine on amd64 is on lucid
<RAOF> Have a source package, then.
<Sarvatt> grabbing it, with that i should be able to downgrade to stock maverick  if xorg built
<Sarvatt> debian/local should go
<RAOF> Oh, totally.
<RAOF> Whoops, forgot about that.
<RAOF> Fixed.
<Sarvatt> looks good to me
<Sarvatt> built fine, files in the debs are right, and it works :)
<Sarvatt> the udev rules probably could use some updating but might as well keep it the same as debian, only the serial part setting ID_INPUT_TABLET is needed anymore
<RAOF> Oh, really?
<Sarvatt> yeah the rest is done by the snippet
<Sarvatt> but it works as it is, no point changing it really
<Sarvatt> is the ntrig device in 50-wacom.conf the same as we added? i can't remember
<Sarvatt> yep it is
<Sarvatt> looks good to me!
<RAOF> Yeah.  And they've also dropped the tablet thingy that doesn't have a kernel driver.
<RAOF> With that, coffee time.
<RAOF> Thanks for testing!
<Sarvatt> might as well just do no change rebuilds of nvidia-graphics-drivers* too?
<RAOF> No; I want to mess with their apport scripts.
<Sarvatt> trying to see how we can add IgnoreABI to the xorg.conf installed by 173 to make it work
<Sarvatt> planning on doing that today though? people with it installed have broken package managers until its rebuilt?
<RAOF> Planning on doing it after coffee.
<RAOF> It won't take long.
<Sarvatt> oh okie! 
<Sarvatt> what the heck package is the xorg.conf generated in
<Sarvatt> ah jockey
<Sarvatt> jockey needs something like this
<Sarvatt>         if self.version == '173':
<Sarvatt>             self.xorg_conf.addOption('ServerFlags', 'IgnoreABI', 'True', optiontype='Option', position=0)
<Sarvatt> awesome, they're talking about doing video device matching with xorg.conf.d snippets upstream
<RAOF> Sarvatt: And it works properly with IgnoreABI?
<Sarvatt> yeah it does
<Sarvatt> http://aur.archlinux.org/packages/xorg-server-1.8-catalyst-maximize-fix/xorg-server-1.8-catalyst-maximize-fix/fglrx-xorg-version.patch
<Sarvatt> so yeah, bug against fglrx-installer asking us to pick that patch up to make fglrx work with xserver 1.8
<Sarvatt> gave me a good laugh before sleep :D
<RAOF> No.
<RAOF> :)
<alf__> RAOF: Hi!
<RAOF> alf__: Yo!
<alf__> RAOF: What is the current status of mesa-egl on maverick?
<RAOF> Waiting for me to finalise the packaging of unrelated parts of mesa.
<RAOF> It's been lower-priority with the xserver transition.
<alf__> RAOF: I can imagine :)
<Sarvatt> it'd be worth investigating the changes in 7.9 too since thats the target in maverick and its *completely* different than 7.8 there
<RAOF> Right.  I was going to do that, too.
 * Sarvatt tries building git with origin/ubuntu again to see whats u0
<Sarvatt> up
<alf__> RAOF: Any ETA on mesa-egl maverick?
<RAOF> alf__: Is it blocking your work?
<alf__> RAOF: Without it we have to do work on lucid instead of maverick
<alf__> RAOF: So, yes and no :)
<RAOF> The packages in the mesa-egl ppa will build & work on maverick.  I can make maverick archive packages a priority if you like.
<alf__> RAOF: If that isn't too much trouble it would be great!
<Sarvatt> it won't for long because libdrm will be updated any time now and it wont build against 2.4.21
<alf__> :S
<RAOF> Yay!  libkms will now build against the in-tree headers.
<Sarvatt> well, we could disable nouveau until 7.9
<seb128> waouh, new xorg works on my mini10v
<RAOF> Or pull in an appropriate nouveau_class.h
<seb128> it just broke gnome-screensaver idle detection or something, when it starts locking moving the mouse doesn't stop it
<RAOF> Hm.  I haven't seen that.
<Sarvatt> seb128: you mean like a fade out before locking?
 * Sarvatt doesn't use gnome-screensaver so not sure
<Sarvatt> the fade when locking was disabled in gnome-screensaver recently i think though, might have something to do with it?
<seb128> when it starts locking after idle usually you can undo the locking by moving the mouse
<seb128> that working this morning and I just upgraded the xorg stack 
<seb128> ie sudo apt-get install xserver-xorg
<Sarvatt> odd, it works here
<Sarvatt> aspire one netbook but i'm using xorg-edgers
<Sarvatt> oh joy, this again
<Sarvatt> Fatal server error:
<Sarvatt> [  2826.174] Caught signal 3 (Quit). Server aborting
<RAOF> What fun!
<jcristau> sigquit knew you missed it, so it decided to come back?
<RAOF> jcristau: So, final stab at libgl1-mesa-dri-experimental.  Nouveau's happy to go in there, but for radeong one of four things needs to happen: 1) it doesn't go in there at all, 2) the package conflicts with libgl1-mesa-dri, 3) dpkg-divert rears its ugly head, 4) alternatives madness!
<RAOF> jcristau: I lean towards 1).
<RAOF> Do you have any strong opinion here?
<jcristau> 1 seems best.
<jcristau> 3 i very much dislike
<RAOF> Yup.  Good.
<kees> RAOF: is it safe to update maverick yet?
<bryceh> kees, think he's asleep for a few more hours
<bryceh> however looking at http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/versions-current.html it appears all the video drivers are merged in now, so I'll bet it's safe
<bryceh> (for the usual alpha-2 definition of the word 'safe')
<kees> bryceh: ah, cool.  thanks!
<bryceh> kees, your comment break...  http://launchpadlibrarian.net/50085515/break2.png
<bryceh> bbiab (dr appt)
<ripps> xserver-xorg-video-fbdev is still holding back my xorg-edgers downgrade
<Sarvatt> its stuck in NEW because of the udeb
<kees> bryceh: rock!
<ripps> I don't really understand the deal wit udebs
<jcristau> that's fine, you don't have to.
<Sarvatt> jcristau: it ok if I merge libdrm 2.4.21 in experimental? already have it done and test built locally - http://sarvatt.com/git/cgit.cgi/libdrm/
<jcristau> should be fine i think
<timboy> with maverick can I have two mouse cursors yet?
<jcristau> you can with lucid.
<timboy> jcristau, how?
<jcristau> http://lwn.net/Articles/283957/
<chek0v> hey guys, i realise this is a dumbass qusetion most likley
<chek0v> https://launchpad.net/~ubuntu-x-swat/+archive/x-updates
<chek0v> thats an official, or at least known/run by ubuntu folks repo 
<chek0v> ie you guys, right?
<Sarvatt> yep, whats up?
<chek0v> well im looking to update the nvidia drivers
<chek0v> from .15 to .24
<chek0v> and im just wondering how safe it is
<chek0v> not really game to roll the dice much on this machine as i use it for work
<Sarvatt> .24 isn't in there
<chek0v> ok well, that answers that then
<chek0v> not sure why i thought itwas
<chek0v> ;)
<Sarvatt> it's got 256.29 (the newest beta release)
<chek0v> ah
<Sarvatt> I think 195.24 is in -proposed? or did that never get pushed to lucid?
<chek0v> do you know if these dirvers will eventually make it to the main ubuntu repos?
<chek0v> yeah its still proposed afaik
<Sarvatt> not for already released ones most likely but for the development version yeah
<chek0v> so if im understanding you correctly, i will never get a driver update from the default ubuntu repos
<chek0v> that accurate?
<Sarvatt> pretty much for the binary blob driver, yeah :(
<chek0v> np, just want to understand
<chek0v> ill probabluy image this install
<chek0v> then roll the dice on one of the updated drivers ;)
<timboy> Is the facility to just plug two mice in and get two pointers going to be in maverick?
<Sarvatt> chek0v: there is a package you can install in that PPA that will completely remove it
<Sarvatt> sudo apt-get install ppa-purge && sudo ppa-purge -p x-updates ubuntu-x-swat
<Sarvatt> it'll revert everything back to the stock ubuntu packages
<Sarvatt> so theres not really any harm in trying it
<chek0v> ahh roger
<chek0v> thanks for that
<Sarvatt> ripps: pitti just pushed fbdev through NEW so it should be all set here soon
<jcristau> Sarvatt: the LIBADD part of the libkms patch needs to stay afaict
<Sarvatt> oh you're right, unresolved symbols
<jcristau> let me know when you've fixed that i'll get the package in NEW.
<Sarvatt> ok fixing it up now, just figuring out how i should do it.. add RAOF's changelog entry back?
<Sarvatt> refreshed it here - http://sarvatt.com/downloads/patches/02_build_libkms_against_in_tree_drm.diff
<jcristau> yeah just remove the part about cflags
<jcristau> and it'll be good
<Sarvatt> http://sarvatt.com/downloads/libdrm.patch -- that look good or should I change the release target to experimental?
<jcristau> looks ok
<jcristau> i'm updating the copyright file.  it's a pita.
<Sarvatt> hmm, can't just add Copyright Â© 2009 VMware, Inc., Palo Alto, CA., USA  to it?
<jcristau> there's lots of minimally different versions of the license
<jcristau> including ones with typos.  or ones which say 'copyright marcheu.  va linux systems is not liable.'
<Sarvatt> radeon_bo_int.h radeon_cs_int.h and radeon_cs.c arent even licensed
<jcristau> i love how it says 'this permission notice (including the next paragraph) shall be included' except they reordered them so there's no next paragraph :)
<Sarvatt> lol
<Sarvatt> which one did that?
<jcristau> that's all over the radeon stuff
<Sarvatt> ah why am i not surprised
<Sarvatt> updating the copyrights in mesa/demos is going to be nightmare inducing
<jcristau> Sarvatt: the radeon bof stuff looks like it should be hidden
<jcristau> radeon/bof.h is not installed anywhere
<Sarvatt> oh? i need to read the library packaging guide some more, didn't know that
<jcristau> i'm hacking around it but ideally it should be fixed upstream..
 * ripps is testing a wacom-dkms package
<ripps> woot! it worked
<ripps> uploading to my ppa, so others can use it.
<Sarvatt> nice ripps! the wacom kernel module not supporting any entry level tablets from the last year or so is a pretty common complaint
<ripps> Sarvatt: ppa:ripps818/ppa, I'm going to bed now, so after there done building. Take a look at them.
<ripps> two versions: maverick has a patch that changes usb_buffer_alloc to usb_alloc_coherent and usb_buffer_free to usb_free_coherent, because apparently somebody changed the kernel api with telling anybody. Lucid version is unpatched, and should work with older versions of 2.6.30+ kernels.
<ripps> g'night
<bryceh> nite
#ubuntu-x 2010-06-11
<Sarvatt> how do I get git diff between two branches to show newly added files?
<Sarvatt> trying to backport some nouveau changes in mesa that way and its just creating an empty file
<RAOF> That diff should show newly added files?
<RAOF> Unless they've been added locally but not committed?
<Sarvatt> in the middle of updating this vm to maverick to try building mesa, i was doing git diff HEAD..upstream path/to/directory/ and new files were just empty in the diff, i was on debian-experimental branch
<Sarvatt> will check once its done updating I mean, cant open the diff at the moment
<RAOF> You probably had the missing -- in there locally, I guess.
<Sarvatt> guess i'll have to backport dpkg in edgers to lucid for whats in debian-experimental :D
<RAOF> Or just drop the regexs from the symbols files.
<Sarvatt> it looks like dist-upgrades to maverick work again at least
<bryceh> btw, good work on the merges guys.  I think the versions-current page is closer to 0 than I think I've ever seen it
<Sarvatt> oh yeah speaking of which, need to look at xdm and xterm. will do that while mesa builds :)
<RAOF> Gratias.
<Sarvatt> is there some voodoo to import from a dsc?
<Sarvatt> or should i just make a new branch and import all the ubuntu stuff by hand?
<Sarvatt> looking at http://git.debian.org/?p=pkg-xorg/app/xterm.git;a=summary
<jcristau> there's a git-import-dsc
<Sarvatt> nice, yeah I just found that
<Sarvatt> hmm, looks like i need to create a new ubuntu branch from the 256 tag before importing it
<Sarvatt> git branch ubuntu xterm-256-1 && git-import-dsc --no-merge --debian-branch=ubuntu --upstream-branch=upstream-unstable  ../xterm_256-1ubuntu1.dsc seems to work
<jcristau> cool
<Sarvatt> ah need to make it not tag
<Sarvatt> which doesn't seem possible :)
<jcristau> worst case you can git tag -d $foo afterwards
<Sarvatt> guess it doesn't matter as long as i dont push the tags
<Sarvatt> oh yeah that too
<Sarvatt> hmm dont want to screw this up, looks like our tarballs differ? Switched to a new branch 'upstream-unstable'
<Sarvatt> rm 'vttests/query-fonts.pl'
<Sarvatt> ah because that files new in 259
<Sarvatt> no big deal, just deleted the tags it added and reverted upstream-unstable, this is pretty sweet
<Sarvatt> so all I need to do to push this is git push origin ubuntu and it'll create the branch right?
<RAOF> Yup.
<Sarvatt> i dont like how you cant see the upstream git history this way though
<Sarvatt> ah its svn
<bjsnider> adobe appears to have dropped the 64-bit flash plugin for linux
<RAOF> By âdroppedâ do you mean âreleasedâ, or ânot bothered to releaseâ?
<bjsnider> the download link has been removed. it is not mentioned on the site anymore
<bjsnider> as if it never existed
<bjsnider> ok, the download link for the last known version still works. but it is not mentioned anymore
<bjsnider> at least they haven't taken it off the web server (yet)
<bjsnider> namely: http://download.macromedia.com/pub/labs/flashplayer10/libflashplayer-10.0.45.2.linux-x86_64.so.tar.gz
<Sarvatt> ok pushed xterm
<Sarvatt> yeah it sucks, i was complaining about that in #ubuntu+1 earlier
<Sarvatt> its cus 10 had a security problem and they released 10.1 and there was no 10.1 64 bit i'm sure
<Sarvatt> so i'm stuck using the one with the security problem, yay :)
<Sarvatt> 32 bit isnt an option at this point
<Sarvatt> ok the xterm merge *seems* to be fine
<Sarvatt> http://git.debian.org/?p=pkg-xorg/app/xterm.git;a=shortlog;h=refs/heads/ubuntu
<Sarvatt> oh RAOF, xdm is in universe so you can upload~ \o/
<RAOF> :)
<Sarvatt> not sure whats going on with mesa, i think they're waiting for the glsl2 stuff to do a 7.9 RC snapshot because it looks like -intel and libdrm are almost set for the next quartery release
<Sarvatt> and intel seems to be driving all the major release schedules
<Sarvatt> AH I figured out why git diff was screwing up!
<Sarvatt> lrwxrwxrwx  1 sarvatt sarvatt    51 2010-06-10 20:28 nouveau_class.h -> ../../../../gallium/drivers/nouveau/nouveau_class.h
<Sarvatt> its a symlink to a file outside of the diff path
<RAOF> Funky.
<Sarvatt> looks like we can just add nouveau_class.h to the two directories and it'll work
<Sarvatt> trying with git checkout upstream src/gallium/drivers/nouveau/nouveau_class.h && git checkout upstream src/mesa/drivers/dri/nouveau/nouveau_class.h
<Sarvatt> with upstream being a local branch tracking master
<Sarvatt> i dont think its recommended to use nouveau_vieux from 7.8.x
<Sarvatt> fedora backports it from master to 7.8
<Sarvatt> i have a patch to do that too btw.. http://sarvatt.com/downloads/patches/nouveau-update.patch
<Sarvatt> making that patch was why ii was trying to figure out why nouveau_class.h was empty
<Sarvatt> ping pong back and forth between irc channels, sorry :)
<Sarvatt> i'd like to get our libGL back into /usr/lib
<Sarvatt> it works fine now there, i hacked up nvidia-current to install the alternatives there and it takes priority correctly now that we removed the abi tag from tls from the lib
<Sarvatt> once we get all this stuff fixed up i'll do that
<Sarvatt> http://cgit.freedesktop.org/mesa/mesa/log/src/mesa/drivers/dri/nouveau -- ah everything after march 4th isn't in 7.8 branch
<Sarvatt> RAOF: is this normal?
<Sarvatt> - (regex|optional=mesa internal ASM optimized functions)"^_mesa_.*@Base$" 7.8.1
<Sarvatt> +#MISSING: 7.8.1-3# (regex|optional=mesa internal ASM optimized functions)"^_mesa_.*@Base$" 7.8.1
<RAOF> Sarvatt: Yes; I can tell you're building on i386, which doesn't have those x86-64 optimisations :)
<RAOF> This is why those are marked optional; they're processor-specific.
<RAOF> If I were more awesome I'd have provided a patch to ensure they don't get exported.
<Sarvatt> http://pastebin.com/JjHks0eS ?
<Sarvatt> i have no idea, just ripped off jcristau's libdrm changes :)
<Sarvatt> why have .symbols? libGL doesn't
<RAOF> Because .symbols make it easier to detect accidental ABI breakage.
<Sarvatt> woohoo, she works with my backported cherry-pick commit!
<Sarvatt> needed that nv50_screen.c change on top of the header
<Sarvatt> just tested it on a nouveau machine and its working fine
<Sarvatt> btw I'm going to commit this soon if i dont see any problems with it.. http://sarvatt.com/downloads/patches/mesa-ccache.patch
<Sarvatt> pain in the butt setting up my ccache symlinks on all these other machines i'm test building on :D
<Sarvatt> guess we should wait for libdrm 2.4.21 to clear debian NEW to upload to ubuntu? :)
<Sarvatt> i want to try building master with your spiffy debian/, to see what files actually get built
<RAOF> Yeah.
<lifeless> RAOF: what would you say, if I said closing a full screen wine app hard-locks my machine ?
<RAOF> I'd say that you were lying.  Everyone knows X is perfect.
<RAOF> I might also consider the X crash that we used to have when closing GLX 1.3 apps, but that's *definitely* been fixed by not allowing GLX 1.3 apps.  Unless you're running Maverick.
<lifeless> I'm on lucid, nvidia blob
<RAOF> HAH!
<lifeless> its 'plants vs zombies', if that helps.
<RAOF> That game sounds fun :)
<RAOF> Debugging the binary drivers is unlikely to be very fruitful.
<Sarvatt> lifeless: tried the wine PPA version?
<lifeless> Sarvatt: In case its glue? Not since I upgraded to lucid; can/will do
<Sarvatt> https://edge.launchpad.net/~ubuntu-wine/+archive/ppa
<RAOF> One of our X PPAs has shiny new binary drivers you could try, too.
<Sarvatt> what game/app?
<Sarvatt> more "fullscreen game X crashes the system!" bugs fixed in each of the 1.2-rc changelogs than I can count lol
<Sarvatt> merging debian-experimental into ubuntu locally then gonna try that with mesa master
<lifeless> Sarvatt: 'plants vs zombies'
<Sarvatt> is the machine *completely* dead? can you ssh in at all?
<Sarvatt> anything in /var/log/Xorg.0.log.old when you reboot about it?
<Sarvatt> looks like lots of complaints about resolution problems with that game on winehq unless you disable 3D acceleration inside the game
<Sarvatt> RAOF: building 7.9 with a merged debian/, will send ya the build log and full file list once its done
<m3ga> i have a bootable usb-key with lucid and I'm trying to boot a tablet device. problem is that the kernel (or possibly X) seems to try to switch the vga mode and screws up the graphics.
<m3ga> is there any way to work around this? i just want a console.
<lifeless> RAOF: ^ how do you avoid X coming up ?
<Sarvatt> boot with text or single added to the command line and drop splash, hold shift while booting the livecd and press tab at the boot a live session option to edit the command line
<Sarvatt> most likely you want to add nomodeset also but i have no idea what GPU you have without any more info
<Sarvatt> RAOF: so you're replacing i915_dri.so with the gallium one here?
<lifeless> Sarvatt: thanks :)
<lifeless> Sarvatt: I'll pass that on
<Sarvatt> RAOF: hmm first change is that debian/tmp/usr/glx/ doesn't exist in 7.9 and thats where some things are installing from like openvg
<alf__> Hi all, I just updated maverick and got new X packages that somehow broke fglrx. Is that expected?
<bryceh> yes
<alf__> Any way I can fix it now?
<alf__> The strange thing is that it complains: [atiddxSetup] X version mismatch - detected X.org 7.1.1.901, required 7.5.1.0
<alf__> why is X.org detected as 7.1.1.901?
<bryceh> no there is nothing you can do to fix it
<alf__> great, I 'll just use vesa then :)
<bryceh> if you must have fglrx, either use lucid or wait until maverick beta 1
<Sarvatt> darn net died, anyway looks like some of the problems might just be because i'm not passing --enable-gles-overlay, the es state tracker doesn't exist anymore
<Sarvatt> i dont know why usr/glx/whatever.so is being used instead of usr/lib/glx/whatever.so in the current packaging
<Sarvatt> debian/tmp/usr/lib is OSMesa and debian/tmp/usr/lib/glx is everything from the confflags-dri target
<jcristau> Sarvatt: to avoid conflicts between the dri libGL and the swx11 libGL
<jcristau> at dh_install time
<Sarvatt> does it matter that the .pc's are screwed up?
<Sarvatt> some have libdir pointing at /usr/lib/glx in them I mean, and we're installing gl.pc from osmesa instead of the confflags-dri target one in libgl1-mesa-dev
<Sarvatt> http://paste.ubuntu.com/448160/
<jcristau> the .pc with screwed up libdir is dri.pc where it doesn't matter
<Sarvatt> all of these new .pc's have the messed up libdir's in mesa 7.9 since they're in usr/lib/glx :(
<Sarvatt> http://paste.ubuntu.com/448165/ :(
<Sarvatt> any way to install osmesa/swx11+glu stuff, clean then install dri to reuse usr/lib?
<jcristau> not easily
<Sarvatt> yeah this looks to be a pain in the butt
<Sarvatt> are the .pc files generated at make install time?
<jcristau> no, at compile time
<Sarvatt> cus if not we could just not use --libdir=/usr/lib/glx in confflags-dri, seperate out the dri install and make it install that one to debian/tmp/usr/lib/glx and tell it to install those things into usr/lib in the .installs?
<jcristau> yeah
<jcristau> except that would require dealing with mesa's build system ;)
<jcristau> but if you want to do that, it sounds like a fine plan to me
<Sarvatt> i'll give it a shot
<jcristau> might be easier to set DESTDIR to debian/tmp/dri than install to debian/tmp/usr/lib/glx
<jcristau> but.  whatever works.
<Sarvatt>         set -e; for config in $((filterout dri,$(CONFIGS))); do \
<Sarvatt>                 $(MAKE) -C $(DEB_BUILD_DIR)/$$config DESTDIR=$(CURDIR)/debian/tmp install; \
<Sarvatt>         done
<Sarvatt>         $(MAKE) -C $(DEB_BUILD_DIR)/dri DESTDIR=$(CURDIR)/debian/tmp/dri install;
<Sarvatt> something like that?
<jcristau> looks plausible
<Sarvatt> err set -e; for config in $($(filterout dri,$(CONFIGS))); do \ ?
 * Sarvatt needs to read a make manual
<jcristau> $(filterout dri, $(CONFIGS))
<jcristau> no extra $( )
<Sarvatt> any idea if i can just prefix the paths in the .install's with debian/tmp/dri or debian/tmp?
<Sarvatt> i'll dig through the debhelper docs and figure it out
<jcristau> the paths there are relative to debian/tmp
<jcristau> so 'dri/usr/lib/foo usr/lib' should work
<Sarvatt> oh duh was confusing myself, dri is inside debian/tmp so its no problem, i was thinking i was making DESTDIR outside of debian/tmp
<Sarvatt> ok trying out this - http://sarvatt.com/downloads/patches/mesa-testing.patch
<Sarvatt> + the nouveau patch so it builds against libdrm 2.4.21 but i left that out
<Sarvatt> not a single arm bug on launchpad with any X logs.. sheesh
<Sarvatt> darn, this didn't work
<Sarvatt> set -e; for config in ; do \
<Sarvatt>                 /usr/bin/make -C /home/sarvatt/source/mesa-orig/build/$config DESTDIR=/home/sarvatt/source/mesa-orig/debian/tmp install; \
<Sarvatt>         done
<Sarvatt> /usr/bin/make -C /home/sarvatt/source/mesa-orig/build/dri DESTDIR=/home/sarvatt/source/mesa-orig/debian/tmp/dri install
<Sarvatt> make[1]: Entering directory `/home/sarvatt/source/mesa-orig/build/dri'
<Sarvatt> that variable must have been wrong
<Sarvatt>         set -e; for config in $(filterout dri, $(CONFIGS)); do \
<jcristau> hrm.
<Sarvatt> at least i can test this part without rebuilding it all :D
<Sarvatt> its only doing the dri stuff
<jcristau> it's filter-out
<jcristau> http://www.gnu.org/software/automake/manual/make/Text-Functions.html
 * Sarvatt slaps his forehead
<Sarvatt> yeah i had 3 working directories and pasted it from the first one where i didnt fix that, go me
<Sarvatt> set -e; for config in swx11+glu swx11+glu-static swx11+glu-i386-i686 osmesa osmesa-static osmesa16 osmesa16-static osmesa32 osmesa32-static; do \
<Sarvatt> 		/usr/bin/make -C /home/sarvatt/source/mesa-orig/build/$config DESTDIR=/home/sarvatt/source/mesa-orig/debian/tmp install; \
<Sarvatt> 	done
<Sarvatt> \o/
<Sarvatt> now the question is, are we supposed to use the dri gl.pc or the swx11 one? :)
<jcristau> doesn't matter imo
<jcristau> the only thing it does is give you -lGL
<Sarvatt> the Requires.private and Libs.private aren't important? 
<Sarvatt> Requires.private: libdrm >= 2.4.15 dri2proto >= 2.1 glproto >= 1.4.11 x11 xext xxf86vm xdamage xfixes Libs.private: -lm -lpthread -ldl     vs    Requires.private: x11 xext Libs.private: -lm -lpthread
<Sarvatt> could install one each in libgl1-mesa-dev (that pulls in glx) and libgl1-mesa-swx11-dev and have them conflict? talk about asking for trouble :)
<kenvandine> has anyone seen the mouse jitter problem in maverick?
<kenvandine> trying to search for a bug with that symptom is pretty hard...
<kenvandine> started happening yesterday
<Sarvatt> what type of mouse?
<Sarvatt> you just did a major replacement of every X package yesterday so not surprising it started yesterday :)
<Sarvatt> is it a dell mini?
<Sarvatt> kenvandine: can ya pastebin your /var/log/Xorg.0.log? its possible i screwed up something in the synaptics merge, or you dont have synaptics installed and are using evdev :)
<kenvandine> Sarvatt, actually i did some digging in my dpkg.log and saw that xserver-xorg-input-mouse got removed
<kenvandine> should it have been removed?
<jcristau> yes
<kenvandine> ok... 
<kenvandine> i do have a synaptics touchpad
<kenvandine> but bratsche saw the same thing using vmware
<Sarvatt> no it shouldn't have been removed I dont think, xserver-xorg-input-vmmouse is in xserver-xorg-input-all and depends on xserver-xorg-input-mouse
<kenvandine> http://pastebin.ubuntu.com/448265/
<kenvandine> i am not sure if that got removed for him
<kenvandine> i am not using vmware and seeing the same problem
<Sarvatt> kenvandine: do you have xserver-xorg-input-synaptics installed?
<kenvandine> nope
<Sarvatt> because you're using evdev there
<kenvandine> i just installed it again...
<Sarvatt> yeah thats why, you accepted a partial upgrade and it broke things
<kenvandine> that also got removed yesterday
<kenvandine> damn dist-upgrade!
<Sarvatt> sudo apt-get install xorg xserver-xorg-input-all xserver-xorg-video-all xserver-xorg just incase :)
<Sarvatt> yeah the breaks: on xserver-xorg-core were doing all kinds of nasty things like that for me too, it'd offer upgrading xserver-xorg-dev and xserver-common and stuff while holding back on xserver-xorg-core because of the breaks, but after you did that there was all kinds of breakage
<Sarvatt> lucky you dont have nvidia, you still would have things broken :)
<kenvandine> hehe
<kenvandine> Sarvatt, thx!
<Sarvatt> no worries, sorry about the trouble, neither me nor RAOF can upload to main! :D
<Sarvatt> it took me about 3 hours to do the whole transition in a PPA but that was nonstop uploading and dropping ubuntu changes :)
<jg> Sarvatt, RAOF: https://bugs.freedesktop.org/show_bug.cgi?id=28070 seems to have settled down to a minimal patch. Probably time to try it for real, if you can get me an image.
<ubot4> Freedesktop bug 28070 in Driver/intel "[Arrandale] No output (black) on eDP" [Major,New]
<tseliot> Sarvatt: BTW I don't know if any other driver apart from nvidia 195 works with kernel 2.6.35
<Sarvatt> yeah they dont, but xserver-xorg-core breaks: xserver-xorg-video-6 so peoples package managers are all kinds of screwed up if they have it installed. i dont think nvidia-currrent should be providing an abi even since it works with multiple ones?
<Sarvatt> tseliot: btw wait until you see the fun nvidia had packaging up the 256 series! 
<Sarvatt> everythings in one directory now
<tseliot> Sarvatt: I'm not sure about not providing an ABI with nvidia. It's not guaranteed to work with the new X ABI either
<tseliot> Sarvatt: yes, I know about about the new driver but I've been too busy with my OEM work to even think about packaging it
<Sarvatt> it works with 4 or 5 abi's and its just the package manager stopping people at the moment is all i was thinking
<Sarvatt> tseliot: well its mostly done in x-updates if you ever go to mess with it, could probably use a bit of refinement :)
 * ripps is building new version of wacom-dkms, doesn't require any xorg-dev files to work.
<ripps> uploading to ppa:ripps818/wacom
<Sarvatt> libGL in /usr/bin does work now too, i hacked up a nvidia blob to test it out and am going to try to get the mesa side done
<Sarvatt> ripps: yeah dont ship the X driver from linuxwacom, xf86-input-wacom is what you want to use you just need the kernel module
<tseliot> Sarvatt: to put back the mesa libraries where they used to be?
<tseliot> also it's good to know that there's a package for that driver, I'll have a look at it
<tseliot> (when I have the time)
<ripps> Sarvatt: actually, it just because configure won't finish without them. So, instead, I have all the xorg-dev stuff as build-depends and I run configure while it's building the package on launchpad. When someone installs the package from the ppa, they will only need dkms and linux-headers-generic to build the module
<jcristau> shouldn't the kernel stuff use kconfig instead of configure anyway?
<bjsnider> Sarvatt, a shared lib in /usr/bin?
<Sarvatt> i meant /usr/lib
<bjsnider> ok, that makes more sense
<apw> Sarvatt, hey did you manage to sort out my xorg-edgers membership?
<Sarvatt> apw: yeah fixed ya up right when ya ask, did I not say anything? sorry man!
<apw> Sarvatt, missed it, thanks man
<Sarvatt> oh yeah speaking of membership renewal..
<Sarvatt> bdmurray: any chance I could get my bugcontrol membership renewed? got a mail saying it was expiring soon
<bdmurray> Sarvatt: what is your launchpad id?
<Sarvatt> sarvatt
<Sarvatt> bdmurray: appreciate it!
<Sarvatt> thanks :)
<bdmurray> Sarvatt: thank you for helping out!
<Sarvatt> there has *got* to be a better way to manage 1 silly libGL.so.1 symlink. I have the GL stuff from nvidia-current, nvidia-173 and mesa all installed in /usr/lib at the same time and thats the only conflict
<ripps> I remember somebody here talking about using appmenu in Maverick. Well, according to maverick-changes, someone added just that.
<Sarvatt> probably me the other day, i was trying to run with a mix of ppa and archive packages and not having any luck :D
<ripps> Okay, can someone help me figure this out. There's something wrong with my wacom-dkms packag in ppa:ripps818/wacom. For some reason, it's not adding the module build directory to the make -C called by dkms. It might be because I'm running the ./configure in launchpad, but I can't figure this out.
<ripps> I'm thinking it might be impossible to keep the -dev files out of this. Since it seems that it's required to run configure locally.
<ripps> Hmm.... maybe I could just patche the configure so that it doesn't try to look for the xorg wacom driver dependencies
<alkisg> I've a laptop with intel 945 which is misteriously broken, with Lucid or Vista it's only showing some broken lines in the first 30-40 pixels of the screen. Completely unusable.
<alkisg> It works fine with Intrepid though! And it also works fine with vesa.
<alkisg> Is there any way to use the Intrepid intel module on the Lucid kernel? Or to downgrade the kernel? I wouldn't want to always stick to Intrepid...
<ripps> Okay, I think I see whats wrong with my wacom-dkms. When I build it in pbuilder, it passes kernel source properly to configure. But, on launchpad, even though it install all the linux-headers packages, configure isn't able to find the linux source directory.
<ripps> this dumb, I shouldn't need a bunch of xserver development code just compile a kernel module that doesn't even use it.
<alkisg> Ah, it seems that the older versions (8.10 and 9.04) use the "intelfb" module, while 10.04 uses the "i915" module, and fails.
<alkisg> Can I force the use of the intelfb module on lucid?
<jcristau> you shouldn't ever have used intelfb
<alkisg> jcristau: it's some weird hardware/driver problem
<alkisg> It's also there on vista. But 8.10 and 9.04 work fine
<alkisg> Will passing video=intelfb as a kernel parameter do it?
<alkisg> Ah, it seems that I misread "have used" with "have to use"
<alkisg> lspci -vv on 9.04 tells me that intelfb is used
<Sarvatt> oh yuck, debian/nvidia_supported in that 256.29 doesn't work right and only generates a tiny modalias file
<bjsnider> maybe hte file it scans has changed
<Sarvatt> nope, just checked, it just makes a tiny one with about 15 cards in it
<bjsnider> there's something else that wasn't in the changelog
<Sarvatt> file is right, i did it by hand
<Sarvatt> # This is a nasty kluge, but it seems to work. Better check the output when
<Sarvatt> # upgrading to a new release of the nvidia driver, though.
<Sarvatt> :D
<bjsnider> what is a kluge?
<bjsnider> maybe the file location is different
<Sarvatt> it's not, i'm doing it by hand and its the same as its making at build time
<Sarvatt> http://heh.fi/tmp/nvidia_supported
<Sarvatt> (thats the script)
<alkisg> The difference I see is in lspci -vv: Ubuntu 8.10 and 9.04 report "intelfb" there, and work fine. Ubuntu 9.10 and 10.04 report "i915" there, and do not work.
<alkisg> Is it possible to use the "intelfb" kernel module in Lucid? If not, I'll just uninstall it and install Jaunty instead...
<alkisg> Ugh, google says that "intelfb is blacklisted on lucid"...
<alkisg> Hmm I'll try blacklisting i915 and whitelisting intelfb - if that doesn't work, I'll just install jaunty.
<alkisg> Urm, I don't even see an intelfb module in Lucid. OK, installing Jaunty instead...
<kees> hm, shouldn't Xorg be installable now?
<kees> I can't seem to install 1.8
<kees> The following packages have unmet dependencies:
<kees>   xserver-xorg-core: Breaks: xserver-xorg-video-6
<kees> E: Broken packages
<jcristau> what driver?
<kees> I have intel
<jcristau> should be ok then, afaik..
<kees> I'm trying to sort out apt's clues on this, but it makes no sense.
<kees> dist-upgrade wants to hold everything back.  explicit install of -core fails as above
<ripps> okay, I think I *really* have wacom-dkms working. I made a custom makefile using 'uname -r' instead of the one generated by configure.
<Sarvatt> kees: what do you have providing xserver-xorg-video-6?
<Sarvatt> i'm going to guess virtualbox OSE
<Sarvatt> hmm then again that would be providing input-7 too
<Sarvatt> kees: do you have an nvidia driver maybe? if you open up synaptic you can search for provides: xserver-xorg-video-6, i never could find a way to search from the command line
<kees> Sarvatt: I'll try that.  what's weird is that aptitude can do the dist-upgrade, but doesn't show anything Xish being removed
<Sarvatt> i wouldn't do it, it'll upgrade one of the metapackages and put you in a screwed up state where it thinks everythings broken
<kees> yeah
<Sarvatt> weird though, wonder what you got providing that still
<jcristau> i'm trying to get rid of the need for conflicts/breaks on x upgrades...
<kees> the only thing that shows up is xserver-xorg-video-apm which I don't have installed
<Sarvatt> weird
<kees> if I search for -7, I get lots of hits.
<jcristau> 7 is the current abi
<Sarvatt> how about xserver-xorg-input-7?
<kees> nothing there
<jcristau> that makes no sense..
<jcristau> apt error messages are cryptic sometimes
<Sarvatt> sudo apt-get install xorg xserver-xorg xserver-xorg-video-all xserver-xorg-input-all install anything?
<kees>   xserver-xorg: Depends: xserver-xorg-core (>= 2:1.8) but 2:1.7.6-2ubuntu7 is to be installed
<kees>   xserver-xorg-input-all: Depends: xserver-xorg-input-vmmouse but it is not going to be installed
<kees> etc
<kees> but apt-cache policy shows 1.8 available
<Sarvatt> sudo apt-get install xserver-xorg-input-mouse fix it?
<kees>   xserver-xorg-input-mouse: Depends: xorg-input-abi-9.0
<kees>                             Depends: xserver-xorg-core (>= 2:1.8) but it is not going to be installed
<jcristau> apt-get install xserver-xorg xserver-xorg-video-all xserver-xorg-input-all xserver-xorg-input-vmmouse?
<jcristau> ime if you add the packages it complains about one by one you eventually reach a useful error message
<kees> same error, but I'll try
<jcristau> ah yeah add -core
<kees> yeah, back to square one.
<kees> after this: sudo apt-get install xserver-xorg xserver-xorg-video-all xserver-xorg-input-all xserver-xorg-input-vmmouse xserver-xorg-input-wacom xserver-xorg-input-mouse xserver-xorg-core xserver-xorg-video-ati xserver-xorg-video-nv xserver-xorg-video-tseng xserver-xorg-video-i128 xserver-xorg-video-intel xserver-xorg-video-s3 xserver-xorg-video-mach64 xserver-xorg-video-cirrus xserver-xorg-video-mga xserver-xorg-video-tdfx xserver-xorg-video-r128 xserv
<kees> I get:
<kees> The following packages have unmet dependencies:
<kees>   xserver-xorg-core: Breaks: xserver-xorg-video-6
<kees> E: Broken packages
<kees> and aptitude says it'll do that install ... bug in apt?
<Sarvatt> sudo apt-get purge xserver-xorg-video-cirrus && sudo apt-get dist-upgrade? :)
<Sarvatt> Provides: xserver-xorg-video-6
<Sarvatt> Package: xserver-xorg-video-cirrus
<Sarvatt> Version: 1:1.3.2-1ubuntu1
<kees> that didn't seem to do it, it still wants to hold it back
<jcristau> bad apt.
<jcristau> i blame mvo :)
<Sarvatt> ok last try before i'm stumped
<Sarvatt> purge xserver-xorg-video-all xserver-xorg-input-all
<kees> hehe
<kees> Package xserver-xorg-video-all is not installed, so not removed
<kees> Package xserver-xorg-input-all is not installed, so not removed
<kees> here are all the things I have installed for video-6 currently:
<kees> xserver-xorg-video-v4l xserver-xorg-video-s3virge xserver-xorg-video-openchrome xserver-xorg-video-vmware xserver-xorg-video-radeon xserver-xorg-video-fbdev xserver-xorg-video-tdfx xserver-xorg-video-r128 xserver-xorg-video-mga xserver-xorg-video-i128 xserver-xorg-video-s3 xserver-xorg-video-intel xserver-xorg-video-mach64 xserver-xorg-video-ati xserver-xorg-video-tseng
<kees> based on /var/lib/dpkg/status
<Sarvatt> can you just install video-all? :)
<Sarvatt> openchrome is providing video-6 too, that needs a rebuild :(
<Sarvatt> v4l was dropped
<kees> can't install video-all, going one-by-one in the -6 list now, trying to purge stuff where there's no new version
<Sarvatt> oh man, I was looking at provides: on a lucid machine.... :\
<Sarvatt> all of those you listed are abi 7
<kees> even fbdev.  wtf
<Sarvatt> tried just installing input-all? :)
<Sarvatt> i'm sure that gets stuck on vmmouse
<kees> will try that in a moment, purging all but -intel now
<Sarvatt> did you remove the metapackages on your own before or did you try upgrading when things were broken to get this way?
<Sarvatt> upgrading while it was broken removed video/input all for me every time
<kees> not sure.  the -alls might have gone away for me during lucid.  :P
<kees> ooooh, got to an installable state
<kees> sudo apt-get install xserver-xorg-core xserver-xorg-input-all xserver-xorg-video-all xserver-xorg-video-intel xserver-xorg-video-nv
<kees> that will let me install.
<kees> makes me think this is an apt bug somehow
<kees> purging xserver-xorg-video-nv seemed to do the trick.
<kees> weird.
<kees> thanks for all the help!
<Sarvatt> really?!
<Sarvatt> thats the exact same one that got me stuck 3 times
<Sarvatt> but i thought it was my own packaging fault because I hacked it up locally
<Sarvatt> so something that gets installed when xserver-xorg-core is in a broken has problems with something about nv
<Sarvatt> i think you lucked out that nvidia-current isn't built against the new video abi yet because when i was in that exact situation it kept installing it when i had one that was :)
#ubuntu-x 2010-06-12
<Sarvatt> wonder whats going on with llvm, llvm-dev dropped off the face of the earth
<jcristau> looks like llvm-dev is the 2.6 version and there's a llvm-2.7-dev for the new one?  at least in sid.
<Sarvatt> llvm-dev was 2.7  in maverick and lucid but the package just disappeared, mesa had a build dep on it for llvmpipe. guess i cant complain, it no longer has the oprofile dependency that was broken every few days with new binutils uploads :)
<Sarvatt> anyone see any reason not to drop all of the alternative stuff from mesa, move it back to /usr/lib and just have other packages use ld.so.conf.d and alternatives for their common files? because I haven't been able to break it all day
<Sarvatt> ugh, llvm-2.7-dev isn't the same as llvm-dev was I guess ../../src/gallium/auxiliary/draw/draw_private.h:50:36: error: llvm-c/ExecutionEngine.h: No such file or directory
<Sarvatt> llvm-2.7-dev: /usr/lib/llvm-2.7/include/llvm-c/ExecutionEngine.h
 * Sarvatt squints..
<Sarvatt>   # Use alternatives to make it easier to switch between Mesa and 3rd party modules
<Sarvatt>   update-alternatives --remove gl_conf /usr/lib/GL/ld.so.conf
<Sarvatt> (/usr/lib/GL/ld.so.conf doesn't exist..?)
<Sarvatt> well i got mesa up and running explicitly installing the binaries for libgl1-mesa-glx and libgl1-mesa-swx11 and i made /usr/lib/libGL.so.1 an alternative that other drivers can take higher priority over
<Sarvatt> RAOF: ohh, whats this I see, is the patch you sent to mesa-dev fixing the llvm include path problem?
<cwillu> weird, didn't realize compiz under nouveau was something that had any chance of working these days :)
<cwillu> got frustrated enough with performance issues with nvidia that I was going to revert to nouveaux, but needed edgers to get it working under 2.6.35, and compiz fired right up :)
 * cwillu fires up his regular 20 windows
<cwillu> 02:00.0 VGA compatible controller: nVidia Corporation G73 [GeForce 7300 GT] (rev a2)
<cwillu> working okay
#ubuntu-x 2010-06-13
<Sarvatt> is it normal that the server requires renderproto 0.11 but only advertises 0.10 support?
<Sarvatt>  ... RenderQueryVersion(client-major-version=0, client-minor-version=11) = {major-version=0, minor-version=10}
<Sarvatt> #define SERVER_RENDER_MINOR_VERSION             10
<Sarvatt> ah i guess it doesn't matter because there were no new requests added in 0.11
<jcristau> 0ce42adbf4cff9e7f049d9fc79d588ece5936177 is.. small.
<Sarvatt> its missing BlendMaximum, the only other server side one as far as I can see from the protocol
<Sarvatt> oh no thats that
<Sarvatt> yeah so the server does 0.11, it should be defining it
<Sarvatt> everything between min and max are client side pictops, i added the stuff to this tracing program and was wondering why none of it was getting used
<Sarvatt> hmm i understand hurd failing, but why is kfreebsd failing with the same error
<Sarvatt> os/os_time.c:51:4: error: #error Unsupported OS
<Sarvatt> __FreeBSD__ isn't defined there?
<Sarvatt> the kfreebsd porting guide says otherwise
<jcristau> no __FreeBSD__ is only real freebsd
<jcristau> so src/gallium/include/pipe/p_config.h needs adjusting
<Sarvatt> http://glibc-bsd.alioth.debian.org/porting/PORTING says otherwise :(
<Sarvatt> oh
<Sarvatt> so just needs an  || defined(__FreeBSD_kernel__)
<Sarvatt> i misread
<jcristau> looks like there are 2 places where PIPE_OS_BSD and PIPE_OS_LINUX do different things.  rtasm/rtasm_execmem.c we want the linux path, and util/u_cpu_detect.c we want the bsd path.. :)
<Sarvatt> yeah i just checked that too
<Sarvatt> reading my mind there :)
<Sarvatt> hurd on the other hand..
<jcristau> it's already hard to care about kfreebsd.  hurd is on some other planet ;)
<Sarvatt> exactly, at least kfreebsd is somewhat trivial to fix :)
<Sarvatt> oh yay a fresh batch of Gaetan Nadon updates to make my script rebuild all drivers for trivial updates :)
<Bernardo> hi
<Sarvatt> man, adding dri2 to xtruss is harder than I thought it'd be. something wacky about DRI2SwapBuffers events
<hyperair> Sarvatt: compiz: ../../intel/intel_bufmgr_gem.c:1318: do_bo_emit_reloc: Assertion `!bo_gem->used_as_reloc_target' failed. =O
<Sarvatt> with what versions?
<hyperair> 7.9.0~git20100520.f4905256-0ubuntu0sarvatt2~lucid
<hyperair> that's mesa
<Sarvatt> 520?
<Sarvatt> thats just mesa-utils
<hyperair> er sorry
<Sarvatt> that stopped getting updated then
<hyperair> 7.9.0+git20100611.3eca311b-0ubuntu0sarvatt~lucid 0
<hyperair> this is mesa-common-dev
<hyperair> Sarvatt: the 20100610 one didn't have a problem
<Sarvatt> oh?
<Sarvatt> was going to say it looked like a change on the 7th
<hyperair> D=
<hyperair> [UPGRADE] libgl1-mesa-dri 7.9.0+git20100610.63834285-0ubuntu0sarvatt~lucid -> 7.9.0+git20100611.3eca311b-0ubuntu0sarvatt~lucid
<hyperair> Sarvatt: i've been bisecting my kernel all weekend, so my X has been getting restarted pretty often.
<Sarvatt> what about libdrm, i upgraded that at the same time
<Sarvatt> i'm not surprised if its a 965+ libdrm problem with whats in there recently - http://cgit.freedesktop.org/mesa/drm/commit/?id=f179137f8f5bf272b79266575121c7a04038290c
<hyperair> Sarvatt: nope, no libdrm upgrade recently.
<Sarvatt> huh, what version
<Sarvatt> dont tell me one from may with the epoch bump problem :)
<hyperair> 1:2.4.20+git20100513.a3305b07-0ubuntu0sarvatt~lucid 0
<hyperair> loooool
<Sarvatt> lol
<Sarvatt> i even poked you  on irc about fixing it incase you didn't read the page :)
<hyperair> i guess i'll just upgrade libdrm and it'll sort itself out?
<Sarvatt> yeah
<hyperair> did you?
<hyperair> i must have been out
<hyperair> or rebooting, as i've been doing a lot recently
<hyperair> you running a .35 kernel by any chance?
<Sarvatt> sudo apt-get update && sudo apt-get install libdrm-dev/lucid libdrm2/lucid libdrm-nouveau1/lucid libdrm-radeon1/lucid libdrm-intel1/lucid
<Sarvatt> yeah i am
<Sarvatt> how the heck were you able to use stuff with the old libdrm, haha
 * hyperair shrugs
<Sarvatt> so yeah that probably accounts for a large number of your crashes :)
<Sarvatt> ohh Depends: libc6 (>= 2.4), libdrm-intel1 (>= 2.4.21)
<Sarvatt> the epoch satisfies it :(
<hyperair> see, this is why you shouldn't use epochs unless absolutely necessary
<hyperair> and for unofficial packages, never use epochs >_>
<Sarvatt> it wasn't on purpose!
<hyperair> hahah
<Sarvatt> and only lasted 2 days
<hyperair> i had bad timing eh
<hyperair> Sarvatt: this wouldn't have any relation to my suspending problem, would it?
<Sarvatt> maybe!
<hyperair> ..
<hyperair> if it was, then i wasted my weekend bisecting.
<hyperair> and contributing to local (as opposed to global) warming
<Sarvatt> especially if you use compiz :)
<hyperair> eh i tried suspending from gdm itself
<hyperair> it just hung after switching ttys
<hyperair> Sarvatt: yay my compiz has returned!
<Sarvatt> try suspending :)
<ripps> Is there any way to test radeon gallium in Maverick? I want to test out Unity, but it seems it relies on non_power_of_two textures and that's not supported in default mesa.
<Sarvatt> ripps: xorg-edgers?
<ripps> Sarvatt: I thought it was removed
<Sarvatt> nope
<Sarvatt> libgl1-mesa-dri-gallium
<Sarvatt> RAOF: awesome, your llvm patch for gallium does fix builds with mesa 7.9 \o/
<Sarvatt> funny that its only a problem with non standard llvm include paths
<Sarvatt> because it builds fine with llvm-dev in lucid, llvm-2.7-dev puts the includes in some crazy place in /usr/lib/
<Sarvatt> ripps: you have an r300 dont you? would you be willing to test a driver out  for me sometime? i'm working on that ati ddx patch to allow changing the dri driver name with an xorg.conf option for gallium
<ripps> Sarvatt: okay sure.
<Sarvatt> almost got it done, just one hiccup that i'm fudging around trying to fix
<ripps> tell me when you get it in a ppa
<ripps> Sarvatt: what's the hiccup?
<ripps> Is xserver-1.9 in xorg-edgers now?
<Sarvatt> just trying to work out the right way to add the check for the option in one spot
<Sarvatt> nope
<Sarvatt> still not evem branched
<ripps> I see you've been experimenting with it in your xorg-testing ppa
<ripps> so far 1.8 in Maverick seems to work pretty good. Although, the agp on my mobo seems to give issues. Although, it works better after setting radeon.agpmode=-1. I haven't gotten a system freeze yet
<ripps> My suspend hasn't bee working with xserver1.8 and kernel 2.6.34/35. Although, I haven't tried since disabling agpmode
<Sarvatt> woohoo I think I got it
<Sarvatt> ripps: yeah suspend is broken on radeon for a lot of people with 2.6.35 last i heard from reading on dri-devel
<Sarvatt> ripps: are you using xorg-edgers right now?
<ripps> Sarvatt: no, I switched to maverick in order to make sure it was working.
<ripps> Seems to work about the same as edgers though.
<Sarvatt> can i just give you a patch for -ati to try or do ya want it on a PPA?
<ripps> Sarvatt: I can do a patch
<ripps> If it works, you should put it in a ppa
<Sarvatt> mind grabbing -ati off edgers? it'll work with stock maverick stuff
<Sarvatt> dont need gallium to test, just want to know what happens when you run it even without gallium
<ripps> okay, give me a sec.
<Sarvatt> can just sudo ln -s  /usr/lib/dri/r300_dri.so /usr/lib/dri/radeong_dri.so
<Sarvatt> oh it'll be a few minutes, still compile testing it with different options
<Sarvatt> dget -u -x https://edge.launchpad.net/~xorg-edgers/+archive/ppa/+files/xserver-xorg-video-ati_6.13.99+git20100604.f64bf0de-0ubuntu0sarvatt.dsc
<Sarvatt> \o/ compiles with and without the option
<ripps> does that include the patch?
<ripps> Sarvatt: ^
<Sarvatt> no
<Sarvatt> thats the source the patch applies to
<Sarvatt> http://sarvatt.com/downloads/patches/gallium.patch
<Sarvatt> thats the patch
<Sarvatt> you need to edit debian/rules to pass --enable-gallium to ./configure too
<Sarvatt> play with it a bunch if you dont mind, see how you can break it :)
<Sarvatt> it should enable gallium by default on your GPU, which wont work because /usr/lib/dri/radeong_dri.so doesnt exist, i want to know if it falls back to swrast right in that case
<Sarvatt> and then if you sudo ln -s  /usr/lib/dri/r300_dri.so /usr/lib/dri/radeong_dri.so it should load the classic driver and say its loading radeong_dri.so in the log and such
<ripps> okay, try this first without gallium-dri, than once with?
<Sarvatt> you said you werent using edgers?
<Sarvatt> no gallium-dri
<ripps> I'm not, but I was going to install it... but I'll do it normal maverick
<Sarvatt> yeah normal maverick works
<Sarvatt> mesa needs changing to work with this, i'm trying to get rid of /usr/lib/dri-gallium
<Sarvatt> if this works i'll just modify it to always disable gallium unless Option "Gallium" "True" is in xorg.conf in the device section and ship radeong_dri.so in /usr/lib/dri
<ripps> adding it to debian/patches
<Sarvatt> dont forget --enable-gallium in the rules
<ripps> yep, I got that.
<ripps> building now in pbuilder
<ripps> btw, has anybody tried my wacom-dkms package? I suppose I'll wait until the next kernel release to see if it updates correctly. Than I'll see if upstream ubuntu/debian would like it.
<Sarvatt> i dont have a tablet that needs it, guess i could try it on my tablets that work and see what happens
<Sarvatt> ~ripps818/ppa?
<Sarvatt> oh wacom
<ripps> yesh ripps818/wacom
<Sarvatt> installing now
<ripps> hmm... why does xserver-xorg-video-ati-dbg depend on mach64-dbg and r128-dbg?
<ripps> okay, I've installed the patch ati, hold on while I reset my xserver.
<Sarvatt> why are ya installing -ati-dbg instead of -radeon-dbg?
<Sarvatt> -ati depends on mach64 and -r128, its just a wrapper that loads the right driver
<ripps> Sarvatt: I just did a sudo dpkg -i *.deb
<ripps> Okay, I restarted X, and compiz doesn't work
<ripps> OpenGL renderer string: Software Rasterizer
<ripps> that's what you wanted, right?
<ripps> now, if I symlink r300 to radeong, it will load normal mesa, correct?
<Sarvatt> yeah, can you try linking r300 to radeong?
<Sarvatt> yeah
 * ripps is restarting X again
<Sarvatt> then if that works try adding Option "Gallium" "False" in your xorg.conf and see if it loads r300_dri.so
<Sarvatt> and that'll be all i need to know to go ahead with it
<ripps> Sarvatt: okay, I now have compiz back
<ripps> OpenGL renderer string: Mesa DRI R300 (RV350 4150) 20090101 x86/MMX+/3DNow!+/SSE TCL DRI2
<Sarvatt> pastebin your log?
<ripps> http://pastebin.com/Tr0NecVB
<ripps> RADEON(0): [DRI2]   DRI driver: radeong
 * ripps is restarting X again
<Sarvatt> \o/
<Sarvatt> oh log message is screwed up, whoops [ 10122.293] (II) RADEON(0): Using Gallium for DRI.(II) RADEON(0): KMS Color Tiling: enabled
<ripps> Okay, booted with Gallium=False
<ripps> http://pastebin.com/ep3AHcaH
<ripps> Compiz is working
<Sarvatt> thanks ripps, she works!
<Sarvatt> oh wait that didnt work
<ripps> oops, I misspelled gallium in xorg.conf, let me try that again
<Sarvatt> oh ok
<ripps> it worked
<ripps> AIGLX: Loaded and initialized /usr/lib/dri/r300_dri.so
<Sarvatt> \o/ thanks man!
<ripps> does libgl1-mesa-galluim install radeong.dri?
<Sarvatt> no
<Sarvatt> you need to sudo mv /usr/lib/dri-gallium/r300_dri.so /usr/lib/dri/radeong_dri.so
<ripps> are you gonna update it so it installs radeong?
<Sarvatt> yeah need to work out the best way to patch the ddx up first
<ripps> or are you gonna package galluim by default?
<Sarvatt> not sure
<ripps> and just leave Galluim=False by default
<Sarvatt> making people need the xorg.conf option to use it makes more sense
<Sarvatt> if people dont have the gallium dri driver installed they wont be able to use r300 if its default enabled
<Sarvatt> adding a check to see if it exists before making that the driverName makes sense but i dont know how to do that
<Sarvatt> which do you think i should do?
<ripps> I think just package galluim and mesa together, and just have mesa be default. 
<Sarvatt> could just ship radeong_dri.so in libgl1-mesa-dri :)
<ripps> Nobody will know gallium was added to the package unless they add `Option "Gallium" "True"` to their xorg.conf
<ripps> yeah, that's what I was thinking. Seems the easiest method for everybody
<Sarvatt> yeah but people using libgl1-mesa-dri-gallium wouldn't know what happened
<ripps> don't have to worry about silly package dependecies and symlinks
<Sarvatt> well its a piece of cake to just make libgl1-mesa-dri-gallium ship files in /usr/lib/dri since they dont conflict anymore
<ripps> Can't you just but an entry on the ppa and on mesa-dri's changelog noting it?
<Sarvatt> i need to ditch -gallium anyway since thats not what we're gonna have in ubuntu
<Sarvatt> but i cant update edgers with whats in git right now since it only builds with 7.8 :(
<ripps> not to mention it screws with compiz
<Sarvatt> ripps: oh y eah can you try booting with nomodeset and make sure it works normal?
<Sarvatt> would be interested in what happens with gallium enabled in xorg.conf with dri1
<ripps> okay, Gallium=True?
<Sarvatt> yea
<ripps> GRUB_CMDLINE_LINUX="nomodeset"
<ripps> Sarvatt: hmmm... it still says I'm using dri2...
<ripps> there might be some config somewhere that's overriding my kernel option
<Sarvatt> /etc/modprobe.d/radeon-kms.conf exist?
<Sarvatt> probably does
<Sarvatt> that breaks it
<Sarvatt> sudo update-initramfs -u after deleting it
<ripps> yeah, it says 'option radeon modeset=1'
<Sarvatt> yeah delete it, its not supposed to be there
<Sarvatt> didn't get removed on a package upgrade
<jcristau> i thought that was removed in the ubuntu package
<jcristau> i guess not with edgers
<Sarvatt> its an edgers problem, i'm not editing the maintainer scripts to make it remove the right ones
<jcristau> yeah.
<ripps> yeah, dpkg -S says it came from -radeon
 * ripps is rebooting... again
<Sarvatt> ok refreshed the patch a little - http://sarvatt.com/downloads/patches/radeon-gallium.patch
<Sarvatt> now to make another where its not enabled by default
<ripps> okay, got to gdm, but failed when I tried to login. Failsafe Gnome worked though. So compiz probably crashed my X 
<Sarvatt> got any log of it?
<ripps> OpenGL renderer string: Mesa DRI R300 (RV350 4150) 20090101 AGP 8x x86/MMX+/3DNow!+/SSE TCL
<ripps> Xorg.0.log: ripps@ripps-desktop:~$ cat /var/log/Xorg.0.log |pastebinit 
<ripps> http://pastebin.com/bKLic0Vd
<Sarvatt> i dont see anything wrong there?
<ripps> okay, tried to manually load compiz, and metacity -c. Both failed
<hyperair> -c?
<hyperair> composite?
<ripps> hyperair: yeah
<Sarvatt> does it work without the xorg.conf?
<ripps> Only entry I have in it is Option "Gallium" "True"
<ripps> which should just be a symlink to r300, but I'll try
<Sarvatt> it doesnt use it unless you're using KMS though, and your log showed it loading r300_dri
<Sarvatt> i only added it to the dri2 path since its required for gallium
<ripps> Sarvatt: hmm... it's something else. I managed to get sorta working for a sec, but after it had wiped my settings. the moment I reverted my compiz settings back it crashed.
<ripps> so one of the plugins is causing a problem
<ripps> and when it crashes, it take X with it
<hyperair> Sarvatt: if pm-trace says "drm card0: hash matches", which kernel paths should i filter my bisect to?
<Sarvatt> hyperair: are you compiling your own kernel?
<hyperair> Sarvatt: yes.
<Sarvatt> try the ubuntu kernel?
<Sarvatt> theres a patch thats most likely fixing your problem
<Sarvatt> still not upstream..
<hyperair> Sarvatt: really? what patch is that?
<Sarvatt> https://patchwork.kernel.org/patch/80474/
<hyperair> Sarvatt: it sounds like a different issue.
<hyperair> Sarvatt: my issue happens with/without X, and the system hangs while attempting to suspend.
<hyperair> it locks itself so hard that sysrq won't work.
<ripps> okay, I got metacity -c working, I now have proper terminal transparency
<ripps> okay, and default compiz config works
<ripps> now.. let's see what plugin crashes it.
<Sarvatt> hyperair: wouldn't really hurt to try it before bisecting would it? :) theres tons of other things in there, not like ya cant purge it afterwards
<hyperair> Sarvatt: i'm almost done bisecting =\
<hyperair> also, my boot time is abysmal
<hyperair> it takes 5 minutes to completely boot up
<hyperair> ridiculous. utterly ridiculous.
<ripps> okay, I figured it out. I was the magnifier plugin. I had every other plugin enabled before I got to that one.
<ripps> For some reason it crashes X with radeon dri1
<ripps> and suspend works with dri1
<ripps> hyperair: your suspend issue sounds like mine
<hyperair> ripps: eh?
<hyperair> ripps: brb, tell me more when i get back to compile the next kernel =)
<Sarvatt> hyperair: ureadahead most likely, the second boot wouldnt be anywhere near that
<ripps> hmm... since suspend works wth dri1 radeon, but not dri2. It must be locking with dri2/kms
<bryceh> yay, https://edge.launchpad.net/~ubuntu-x-swat/+patches finally works properly
<bryceh> bdmurray, thanks!
<jcristau> it timed out on me :)
<ripps> Man, I wish dri2/kms radeon still had XV Overlay. I've just realized how fast mplayer XV is here in dri1.
<Sarvatt> it would be nice if i knew where the heck the right place to add the check is, copy and paste only gets you so far and i've spent all day going over other drivers :)
<Sarvatt> oh dang I was making it too complicated, its not that hard at all to do
#ubuntu-x 2011-06-06
<Sarvatt> wow, hd 6770m is one unhappy camper at the moment, all kinds of crashy in stock natty and compiz doesn't work with edgers
<Sarvatt> well this is a firepro m5950 in a precision m4600, same GPU though
<RAOF> Heh.  If only I had such problems :)
<Sarvatt> 240w power brick for it is bigger than a netbook :)
<RAOF> Sorry, *what* ?  That's a 240W power brick for a *laptop* ?
<RAOF> Or should I say âportableâ? :)
<Sarvatt> 10.4lbs with 2 little strips of foam in the box :)
<RAOF> 4.7 kg?  That's pretty heavy.
<Sarvatt> the laptops only 2.8 of that
<Sarvatt> rest is power brick
<tjaalton> ...
<RAOF> Does the laptop not actually have a battery?
<RAOF> :)
<Sarvatt> it's got the 6 cell option, 2 hours :)
<tjaalton> "option"..
<Sarvatt> yeah vs the heavier 9 cell for an extra 20 minutes
<tjaalton> ah
<RAOF> How much power does it draw under full load?
<Sarvatt> i'll let ya know tomorrow when it's working again and not 2 am, needs to sit without a battery for another hour or so to be able to power back on after what I did to it :)
<RAOF> How have you been mistreating the poor box!
<tjaalton> ran unity on it, obviously
<tjaalton> or tried to
<Sarvatt> the GPU is only 25W TDP
<Sarvatt> think they just grabbed a brick from a m6600 and sent that
<RAOF> Well, at least it can charge the battery under full load!
<LLStarks> sarvatt, D:
<LLStarks> i was about to get one
<LLStarks> *the 6770m
<tjaalton> bryceh: I'll merge xorg and drop the drivers that were discussed on the list
<tjaalton> from -video-all
<bryceh> tjaalton, great
<tjaalton> probably need to drop the doc-building stuff from build-deps, unless they are all in main
<tjaalton> which I doubt
<tjaalton> hum, it's only asciidoc now, and it's in main
<bryceh> tjaalton, btw I trimmed down the arm drivers a while back; if there's other architectures we care enough about, might want to do similarly for them
<tjaalton> bryceh: looks like powerpc is supported, I'll check that one too
<tjaalton> and i think -vesa is useless on arm?
<RAOF> That matches my understanding.
<RAOF> VESA only works where there's a video bios, and since arm boards don't have biosesâ¦
<tjaalton> right
<bryceh> tjaalton, yeah I left it only because I couldn't pin down an absolute, "Yes it's definitely not needed on arm" from anyone, and since it's such a trivially tiny driver just left it
<tjaalton> bryceh: indeed it is
<LLStarks> bryceh. fallback in a nutshell: gnome-panel as manual fallback or automatic for gnome-shell. unity-2d as manual and automatic fallback for unity.
<LLStarks> according to didrocks from ayatna/desktop
<LLStarks> gnome-shell pulls in all requisite packages.
<LLStarks> automatic applies to all 3d-less scenarios. failsafex is our judgment call.
<LLStarks> https://lists.ubuntu.com/archives/ubuntu-desktop/2011-June/003079.html
<RAOF> I've also replied to that; I think that whatever fallback session would normally kick in is the right thing to use.
<bryceh> traditionally we've not bothered to fire up a WM at all.  Since we only need to run a single app we just run that as the root application
<bryceh> however nothing says we can't revisit that design
<bryceh> the one trade off is the more things we depend on the less failsafey we become
<RAOF> Yeah.
<tjaalton> aren't we mixing two things here? the one fallback is if the hw can't handle full 3d-unity/gnome-shell, the other is where the normal gdm/lightdm startup failed and so we use some defaults
<RAOF> Hm.  We might be able to kill two birds with one stone.
<RAOF> Since we'd want FailsafeX to *say* it's failsafe, we could pop up, say âFailsafe mode ENGAGE!â and offer a minimal or full session.
<tjaalton> so the other fallback is for the system, the other for the user session
<bryceh> tjaalton, yeah two separate things conceptually
<RAOF> My conception of FailsafeX is that we want to end up with it kicking in when the recovery boot is activated, right?
<bryceh> in situations where the recovery boot is needed due to a graphics failure, that's correct
<bryceh> gdm/lightdm failing to start X would be another situation (probably rare) where failsafex should be popped up
<bryceh> there may be one or two other situations where we might want to tie it in
<bryceh> where I'm a bit fuzzy is if in the recovery boot should xdiagnose or whatever pop itself up, or just be provided as a clickable icon or some such
<tjaalton> "clickable icon" sounds like something that needs X :)
<tjaalton> hmm forgot that it's not just failsafex
<tjaalton> a flowchart from grub to unity, covering all the possible scenarios would be nice :)
<bryceh> tjaalton, ...and as soon as you finish drawing it, someone would immediately introduce a change to render it obsolete ;-)
<bryceh> actually, there is a good description of the sequence listed with one of the kernel troubleshooting docs
<hyperair> Sarvatt: meh. X segfaults. =(
<hyperair> Sarvatt: i guess it's to be expected from an ABI-incompatible X.
<bryceh> tjaalton, https://wiki.ubuntu.com/X/Troubleshooting/BlankScreen
<bryceh> hm, not much of a flow chart
<tjaalton> bryceh: well, one covering the boot-up from X's perspective, that shouldn't change too often :)
<scoundrel50a> Hi, I have a new Acer Aspire 5736Z laptop that I am having problems upgrading to 11.04 on. Have tried upgrading via the Update Manager, fresh install, alternative cd fresh isntall, and I get to reboot and as soon as the screen comes after clicking on the kernal option, the screen goes black, there is no backlight. There is a bug number #759104, has anybody any idea if this will get fixed? I cant upgrade otherwise. Funny thing though, I have
<scoundrel50a>  an Acer Aspire One netbook, and it works ok on there. 
<tjaalton> scoundrel50a: try installing 2.6.39-oneiric from here http://kernel.ubuntu.com/~kernel-ppa/mainline/
<scoundrel50a> oh hello, just noticed this now. Thank you. Will see how far I get. Can that be installed over the top, or on another partition? 
<scoundrel50a> One thing I forgot, I am using 64bit, is there a 64bit version?
<tjaalton> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.39-oneiric/
<tjaalton> yes
<tjaalton> grab the amd64.deb and install it
<scoundrel50a> linux headers, or linux image?
<tjaalton> image
<scoundrel50a> ok, will give it a go, be back soon
<scoundrel50a> thank you
<scoundrel50a> do I just install as I would a normal .deb package, not done it this way before.
<tjaalton> dpkg -i ...deb
<scoundrel50a> ok, will give it a try
<scoundrel50a> daft question I know, but should I close everything down before starting the installation, will be going offline if I do
<scoundrel50a> will trying logging in again on a different pc
<tjaalton> um no
<tjaalton> you can install it from a running session.. then reboot
<scoundrel50a> ok, well, I am about to install
<tjaalton> though if you just have a black screen then you can't install it, right?
<scoundrel50a> it gets to the end of the installation, I click on the kernal and the screen goes blac
<scoundrel50a> too late now its going through it again
<scoundrel50a> ok, installation finished, what do I do now?
<scoundrel50a> reboot?
<tjaalton> how did you install it?
<scoundrel50a> using the command you gave, dpkg -i ....deb
<scoundrel50a> I can see its added an extra kernal
<tjaalton> you said it had a black screen, so I gave you bad advice
<scoundrel50a> ah
<scoundrel50a> well, as its installed, I will try to boot that up, see if anything has changed, one sec
<scoundrel50a> brb
<scoundrel50a> have another pc so will log in with that one
<scoundrel50a_> ok,on different oc
<scoundrel50a_> going to reboot other one now, 
<scoundrel50a_> rebooting, same thing happened, backlight not working, can just see the log in screen, but can not log in as I cant see curser
<scoundrel50a_> tried using ctrl+alt+ > not working either
<tjaalton> scoundrel50a_: "same thing.." that's not the same you described earlier, getting a black screen and nothing else
<scoundrel50a_> um, sorry, I thought I mentioned the backlight didnt work
<tjaalton> so what login screen are you talking about?
<tjaalton> and are you saying it hasn't changed with the new kernel
<scoundrel50a_> the log in box, where it has the logo and choice to pick users, no it hasnt changed, still no backlight
<tjaalton> and you installed the .39 kernel when you had booted using the one from maverick?
<scoundrel50a_> if you check the bug I posted, it should tell you there, and it gives you the xorg and old xorg files
<scoundrel50a_> no, havent installed fromMaverick since the day 11.04 came out, as I got this same problem
<tjaalton> no they don't tell me how you installed the kernel
<tjaalton> I'm just trying to make sure you actually are running it
<tjaalton> on the bug you said that the way to boot natty was to use the previous kernel (=maverick)
<scoundrel50a_> yes
<scoundrel50a_> I could do it that way
<scoundrel50a_> but it looked like windows 98 on a very old machine
<tjaalton> then you could try the 3.0-rc1 kernel from the same url i gave you
<scoundrel50a_> ok, need to reboot again
<scoundrel50a_> how can I uninstall that version? as I dont want loads of kernals showing
<tjaalton> dpkg --purge linux-image-2.6.39-020639-generic
<scoundrel50a_> ok,
<tjaalton> (and it's kernel)
<scoundrel50a_> oh sorry using a netbook, 10 inch, and got big fingers
<scoundrel50a_> purging now
<scoundrel50a_> um, I dont have the url, it went when I rebooted and changed pc, can you give it to me again
<tjaalton> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.0-rc1-oneiric/
<scoundrel50a_> ok, will try that one, thank you
<scoundrel50a_> ok, about to install this version
<scoundrel50a_> about to reboot
<scoundrel50a_> exactly the same, once you chosse the kernel, it starts to boot, the backlight turns off, and that is it, 
<scoundrel50a_> brb, 
<scoundrel50a_> #
<tjaalton> then it would be nice to get the dmesg output of the broken kernel
<tjaalton> attached to the bug
<scoundrel50a_> how do I do that?
<tjaalton> install openssh-server on the system, and log in remotely with ssh
<scoundrel50a_> have to start up, have to tell you, I cant even boot up the rescue bit, that has the same problem, no backlight
<scoundrel50a_> ok, will see if i can do that
<scoundrel50a_> ok, I'm on my netbook, on 11.04, my laptop do I need to boot up to the new kernel, the  try to connect from netbook?
<tjaalton> do you have ssh-access to the laptop?
<scoundrel50a_> well openssh-server is installed on both machines
<scoundrel50a_> how do I connect?
<tjaalton> so that the networking works without the user session running..
<tjaalton> ssh uid@foo
<scoundrel50a_> ok, not done this before, the uid is the id of the laptop yes? What is foo?
<tjaalton> no, username@machinename
<tjaalton> or ip instead of the name
<scoundrel50a_> how do I find out the ip address? and see if both machines are viewable on the network?
<tjaalton> i give up
<tjaalton> sorry
<scoundrel50a_> ok, I'm sorry too
<tjaalton> upstream might be interested, but they need the dmesg output
<tjaalton> though, you can probably parse it from /var/log/kern.log too
<tjaalton> which you can get to with the maverick kernel
<scoundrel50a_> but I cant get that till I can find out if I can get into other machine, thank you anyway,
<tjaalton> no, you use the same method to get it as you used to install the test kernels..
<scoundrel50a_> I'll see if I can work it out, and find out the ip address adn connect
<tjaalton> easier to find the kern.log* which has the information from the bad boot..
<scoundrel50a_> how do I do that then?
<scoundrel50a_> oh just saw
<scoundrel50a_> will go check
<scoundrel50a_> just rebooting other machine
<scoundrel50a_> I found kern.log, would you like to see a copy? See if you find out?
<tjaalton> are there many of them? kern.log.1 etc
<tjaalton> locate the one that has the info about the 3.0-rc1 kernel
<scoundrel50a_> kern.log and kern.log.1
<scoundrel50a_> and I think it is just kern.log that shows the kernels you want, shall I pastebin it?
<tjaalton> for instance
<tjaalton> you know the 'pastebinit' command?
<tjaalton> need to install the package first
<scoundrel50a_> can I do it via ubuntu pastebin it, can copy it
<scoundrel50a_> give you the url
<tjaalton> no, apt-get install pastebinit, then run 'pastebinit /var/log/kern.log'
<tjaalton> then give me the url
<scoundrel50a_> http://paste.ubuntu.com/619840/ sorry took so long, netbook at its limit
<scoundrel50a_> brb
<tjaalton> you could try adding 'GRUB_GFXPAYLOAD_LINUX=text' to /etc/default/grub, then run update-grub
<scoundrel50a_> ok, will give it a go, is that done in Maverick?
<tjaalton> no, it's a new feature in natty
<scoundrel50a_> so how do I GET INTO IT THEN?
<tjaalton> huh?
<scoundrel50a_> oops sorry didnt know I had caps lock on till I sent sorry
<tjaalton> you edit the file, and add that line..
<scoundrel50a_> ok
<tjaalton> then run update-grub, and reboot
<scoundrel50a_> ok, do I need to add the inverted commers or leave them out
<scoundrel50a_> ok, going to reboot into 11.04, after updating
<tjaalton> inverted commers?
<scoundrel50a_> things at beginning and end of text you gave me, dont know what they call them here
<scoundrel50a_> and left them out, ran update rebooted and nothing
<scoundrel50a_> backlight turned off again
<scoundrel50a_> it actually turns off just before the log in page appears, and the drums sound
<scoundrel50a_> why should it turn the light off
<tjaalton> can you ctrl-alt-F1
<tjaalton> to change to the virtual console
<scoundrel50a_> I dont know, tried but no backlight, cant see anything
<scoundrel50a_> I treid to get into recovery mode, a load of script went up the page, then the screen went black and now I cant see anything
<scoundrel50a_> something is turning the light off
<tjaalton> probably when the i915 module is loaded
<scoundrel50a_> is there a way around it? I just tried to log on blind, clicked enter, then entered my password and I get logged in, but no light
<scoundrel50a_> I have to use the on off button to turn off then
<scoundrel50a_> it is loading
<tjaalton> what is?
<scoundrel50a_> Ubuntu
<scoundrel50a_> I get the music
<scoundrel50a_> but black screen
<scoundrel50a_> the backlight needs to turn on
<scoundrel50a_> I wish there was a way foryou to see what was happening
<scoundrel50a_> I honestly think it is as simple as finding out what is turning the backlight off
<scoundrel50a_> if this little netbook, Acer Aspire One can work on 11.04 I dont understand why my Lsptop which is the same make cant work either
<tjaalton> you can blacklist the i915 kernel module, but you'd have a "crippled" system then
<tjaalton> "the same make" != "the same hw"
<scoundrel50a_> but if I have a crippled system that isnt worth using then
<tjaalton> i bet the netbook doesn't have intel GM45 on it
<tjaalton> then stick with maverick
<scoundrel50a_> dont know
<tjaalton> or lucid
<tjaalton> which is lts
<scoundrel50a_> I think I am going to have to. Its Maverick
<scoundrel50a_> thank you I really appreciate the help
<scoundrel50a_> I hope they manage to find out why it keeps turning the backlight off
<tjaalton> an upstream bugreport might help..
<scoundrel50a_> how can I do that?
<tjaalton> sign in on bugs.freedesktop.org and file it under xorg, driver/intel
<scoundrel50a_> ok, not seen that before, will try set up an account an file a report, thank you
<tjaalton> actually, use product DRI and component DRM/Intel
<scoundrel50a_> what version?
<scoundrel50a_> and should I add an attatchment of anything?
<tjaalton> leave the version
<tjaalton> you could boot with adding 'drm.debug=0x02' to the kernel options
<ScottK> RAOF: Is http://wstaw.org/m/2011/06/06/plasma-desktopcs1575.jpg what's supposed to happen when someone reports a bug on xserver-xorg-video-intel?
<tjaalton> either by editing the grub boot entry when selecting the kernel, or add it to GRUB_CMDLINE_LINUX="" in /etc/default/grub
<scoundrel50a_> tjaalton: ok, will try adding that to the grub file, just finishing the bug report
<RAOF> ScottK: In Natty, or in Oneiric?  It is in natty, because the bugs filed post-release are generally of very low quality.
<ScottK> It was natty.
<RAOF> Bryce added that to the apport hook for natty post-release; a lot of the bugs that we get post-release for X *are* support requests, and so aren't well-handled on launchpad.
<jcristau> a non-question with a question mark and yes/no answers?
<ScottK> One of our more technical users was a bit put off by it, but was cool with it once I explained.
<ScottK> In fact, there he is now.
 * ScottK waves to jussi.
<jussi> heya ScottK
<RAOF> jcristau: Hm.  Now that I *read* it more thoroughly, it could do with a bit of a reword :)
<ScottK> I've started using 'convert to a question' more, but you're right, that doesn't really solve the problem.
<RAOF> It went through a couple of revisions; at first it pointed more directly at askubuntu.com, and that resulted in a lot of poor quality questions there :/
<ScottK> That sounds like progress at least.
<ScottK> Poor quality questions in the place for questions beats poor quality questions on the bug tracker.
<jussi> I think it may be useful to reword the second option to include something like "Im sure its a bug" or something, rather than the only options being that it started after an update or I talked to people already. It doesnt leave much room for "I understand what Im doing, I want to report the bug"
<ScottK> The problem is everyone thinks they know what they are doing.
<RAOF> Heh.
<jussi> Hrm
<RAOF> I think it could do with a re-wording, and we'll likely do the same thing once 11.10 ships.  Would you consider sending a mail to ubuntu-x?
<jussi> RAOF: of course I can do that - ubuntu-x@l.u.c? 
<RAOF> Yup.
<jussi> Ok, Ill try send it this afternoon. If you get a chance, please take a look at bug 793487 :) (and scream at me for all the things Ive missed telling you). 
<ubot4`> Launchpad bug 793487 in xserver-xorg-video-intel (Ubuntu) "Kubuntu does not shut down when external monitor attached through displayport (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/793487
<scoundrel50a_> tjaalton: hi I entered a bug, its #37986
<jussi> RAOF: sent. Hope that isnt too log'sy.
<tjaalton> scoundrel50a_: ok, now add the drm.debug=0x02 to the kernel options so the kern.log gets debugging info about the state
<scoundrel50a_> so how do I do that? Would not have a clue
<jussi> bryceh: looks like my message got caught in moderation or rejected. do I need to resend now Im subscribed or can you just accept it? 
<tjaalton> scoundrel50a_: scroll back..
<jussi> bryceh: never mind, I resent. 
<scoundrel50a_> tjaaltonnow you lsot me, if I add that to /etc/default/grub how do I add it to the bug report? I have no clue, sorry, I have not entered a bug report before.
<tjaalton> scoundrel50a_: add it to /etc/default/grub, run update-grub, boot with the bad kernel, then boot with the good one and edit kern.log to only have the bootlog from the bad kernel, attach that to the bugreport...
<tjaalton> that=the edited log
<scoundrel50a_> ok, I know you are going to kill me when I ask this, but how do I edit kern.log to only have bootlog from bad kernel......as I said this is completely new to me.......I am really sorry. :(
<tjaalton> so you have a program you use to edit /etc/default/grub...
<tjaalton> now copy kern.log somewhere and edit it
<tjaalton> ..
<tjaalton> it's big, but you'll find the new stuff at the end
<tjaalton> or just attach the whole file, but remember to mark it as text/plain
<scoundrel50a_> ok, added drm.debug=0x02 to /etc/default/grub ran update-grub and got this error /etc/default/grub: 13: drm.debug=0x02: not found.......it wont update now
<scoundrel50a_> ok, added drm.debug=0x02 to /etc/default/grub ran update-grub and got this error /etc/default/grub: 13: drm.debug=0x02: not found.......it wont update now
<scoundrel50a_> oh, sorry about that, dont know why it posted twice
<tjaalton> you need to add it inside the double quotes in GRUB_CMDLINE_LINUX=""...
<scoundrel50a_> ohhh
<scoundrel50a_> updating now,
<scoundrel50a_> ok done that, now I have opened the kern.log what do I add, to the log?
<tjaalton> not add, delete the stuff that aren't interesting
<tjaalton> which kernel did you boot?
<scoundrel50a_> the broken one, now i am booting the old one, Maverick
<tjaalton> which broken one, natty or 3.0-rc1
<tjaalton> ?
<scoundrel50a_> I see what you mean about editing, if I can work out what we need
<tjaalton> so you can skip everything else, just take what was generated by the previous boot, and why not the current one that's with the known good kernel
<tjaalton> +also
<scoundrel50a_> I dont have natty, I only have 3.0-rc1 I am looking through now, but cant work out when it started from booting to 3.0-rc1, I found something that talks about backlight, trying to look through
<tjaalton> sure you do
<tjaalton> check the timestamps
<tjaalton> and the version string
<scoundrel50a_> even found something about status failed, timestamps are what I found
<hyperair>  /aw
<hyperair> oops
<tjaalton> "Linux version 3.0.0-0300rc1-generic", search for that
<scoundrel50a_> ok, completely lost, can I give you the file in pastebin, so you edit it? I honestly dont know what I am looking for.
<tjaalton> no
<tjaalton> if you can't edit it, then attach the whole file as text/plain mimetype
<scoundrel50a_> I think I will have to do that, as I cant see what I am looking for......
<tjaalton> you can't search for a string?
<tjaalton> what editor are you using?
<scoundrel50a_> sorry I havent got back to you, trying to add the file, but getting an error saying its too big, even though I set it to plain text.....have to pastebin it, by the looks of things.
<tjaalton> it won't stay there forever
<scoundrel50a_> Its times like this I wish I was younger and went to college to learn about computers
<tjaalton> or buy machines that are certified ;)
<scoundrel50a_> kern.log added, edited, but not sure if it is in the right place
<scoundrel50a_> added the kern.log as attachment
<tjaalton> yeah, looks good
<scoundrel50a_> ok, I have to say, that was the most difficult thign i have done in ages, I love Ubuntu, but sometimes it is really confusing using it and the things associated with it. 
<scoundrel50a_> Thank you for your help, I really appreciate it
<tjaalton> scoundrel50a_: can you see a blinking cursor or the "ubuntu" splash-screen when the machine is booting up, and does the backlight turn off right when the login screen appears?
<tjaalton> scoundrel50a_: also, you could try editing /etc/modprobe.d/local.conf, and add a line that says "blacklist acer_wmi", then try booting the 3.0-rc1 kernel
<tjaalton> could be that it's conflicting with the i915 graphics module, both fighting for the acpi backlight control
<tjaalton> at least that's something not loaded with the maverick kernel, so maybe blacklisting it will fix the issue
<tjaalton> scoundrel50a_: I added that to the bug too, update it with what you find out
<tjaalton> gotta run ->
<scoundrel50a_> its booting up now
<tjaalton> scoundrel50a_: booting up, as in working fine or not?
<scoundrel50a_> not working
<tjaalton> is the latest log with the acer_wmi module blacklisted?
<scoundrel50a_> yes
<scoundrel50a_> and still doesnt work
<scoundrel50a_> no, sorry, just got what you meant, i WILL HAVE TO POST THAT NOW. sORRY
<scoundrel50a_> sorry about caps
<tjaalton> thanks :)
<scoundrel50a_> on netbook
<scoundrel50a_> tjaalton: have added the kern.log hope its worked properly
<tjaalton> scoundrel50a_: ok, add to the upstream bug that this was with the acer_wmi module blacklisted
<bjsnider> ricotz, have you noticed anything weird about the numlock key in gnome 3? Mine is chaotic. the key needs to be off for the numpad to work, or something
<ricotz> bjsnider, havent noticed this, works for me as expected
#ubuntu-x 2011-06-07
<LLStarks> sarvatt, is sna enabled on edgers? i want to get some benchmarks.
<hyperair> LLStarks: there's ppa:sarvatt/intel-sna
<hyperair> LLStarks: however, the patch required in X itself is missing.
<hyperair> so it segfaults nicely
<LLStarks> ah
<Sarvatt> it doesn't segfault because the x patch is missing, that just fixes rendering corruption.. :)
<hyperair> Sarvatt: i got a segfault!
<LLStarks> will sna ship with oneiric and is it comparable to exa, uxa, etc?
<Sarvatt> no it wont
<hyperair> =(
<Sarvatt> it's dependent on the xserver 1.12 video abi
<LLStarks> that's alright, we're setting up for PP during the oneiric cycle
<LLStarks> will there be any hiccups similar to the gem/uxa transition? that was harsh.
<Sarvatt> pretty much 100% guaranteed there will be :)
<LLStarks> ouch
<Sarvatt> sorry I didn't update it today, will update it to the latest in the morning
<LLStarks> so, is the sna ppa (now or tomorrow) ready for vm or live testing in the sense that the desktop is usable?
<LLStarks> *live as in actual install runing on actual hardware
<Sarvatt> sure if you want to test it, just avoid chrome/chromium because they dont work
<LLStarks> any benchmarks you'd recommend for showing maximum benefits?
<Sarvatt> that ppa hyperair linked needs to be activated at the same time as xorg-edgers
<LLStarks> if at all possible, i'd like to get a hardware table up and running on the wiki. vga string, commit id, benchmark date, results.
<Sarvatt> i dont think it's anywhere near ready for something like that, it's going to be very volatile for some time yet..
<hyperair> LLStarks: 8086:2a32 -> segfault.
<LLStarks> can you boot to recovery terminal?
<hyperair> LLStarks: ?
<hyperair> recovery terminal? 
<LLStarks> tty
<hyperair> well i can switch to ttys yeah
<LLStarks> then that's not so bad.
<hyperair> in fact, that's how i repaired my X.
<hyperair> mm yeah it's just a normal X segfault
<hyperair> it's not a wedge
<LLStarks> ah ok
<hyperair> i should probably get a proper stack trace 
<Sarvatt> hyperair: http://dpaste.com/551239/ look like that?
<hyperair> Sarvatt: not quite
<hyperair> Sarvatt: it had a few intel_drv.so lines in the middle
<hyperair> and i lost the log. blargh.
<LLStarks> praying that 8086:27a2 works
<LLStarks> taking the sna plunge. i hope my body can take it.
<LLStarks> the laptop loves it. whenever i test something new it's like "awww, you're still thinking of me. sure, i'll give you some more performance. windows stopped driver updates for me years ago."
 * LLStarks crosses fingers
<LLStarks> holy hell
<LLStarks> http://ie.microsoft.com/testdrive/performance/fishietank/
<LLStarks> 2 fps to 40 fps
<LLStarks> can i send a cake to intel?
<LLStarks> let's see if it handles 720p gl output
<LLStarks> ...it didn't choke
<LLStarks> this is amazing.
<LLStarks> smooth 1080p. yup.
<LLStarks> it's almost as if the i945gm no longer needs vaapi
<LLStarks> hyperair, no segfaults yet. just the occasional artifact.
<LLStarks> very rare.
<LLStarks> i'm going to be brave and try chromium
<LLStarks> all seems fine
<tjaalton> bryceh: forgot to push xkeyboard-config changes?
<LLStarks> sarvatt, i've noticed that gl subtitle rendering (is broken on edgers. what component should i file against upstream?
<LLStarks> and has been for a while
<tjaalton> RAOF: moo, you haven't pushed the earlier xkeyboard-config merge to git?-)
<RAOF> Wait, what?
<RAOF> Let me just get that!
<tjaalton> 2.2.1-1u1
<tjaalton> maybe we should get 2.3.1 for oneiric?
<tjaalton> debian didn't put it in unstable yet because they still have gnome2 there and there's some conflict
<RAOF> I don't know of any reason no to grab that.
<tjaalton> but we already have gnome3 for the most part
<tjaalton> in oneiric
<RAOF> Was the conflict just the naming scheme bits, or something more fundamental?
<tjaalton> don't remember the details
<RAOF> Pushed like a jimmyhack.
<tjaalton> 2.1 is "the best for gnome2", nothing more than that
<tjaalton> and we already have 2.2.1 :)
<tjaalton> so yes, should be no blockers for 2.3.x
<tjaalton> s/yes/no/
<RAOF> Right.  I'm pretty sure that refers to the naming stuff.
<tjaalton> the dvorak-stuff?
<RAOF> No - renaming all the profiles $COUNTRY ($MAP) to $LANGUAGE ($MAP).
<tjaalton> as
<tjaalton> ah
<RAOF> So the keyboard indicator here says âEnglish (Dvorak)â rather than âUSA (Dvorak)â.  Etc.
<tjaalton> heh, makes sense
<RAOF> While that was done for GNOME 3, I'm not sure why it's not regarded as appropriate for GNOME 2.
<RAOF> Mmm. Looks like this system's borken enough to no longer boot.
<tjaalton> i should work through installing the sandybrigde system.. finally switching to ssd et al
<RAOF> Maybe I should stop holding out for ivybridge and build a decent desktop system.
<LLStarks> wait for ivy bridge
<LLStarks> :3
<LLStarks> tr-gate. better than sandy bridge.
<LLStarks> sole purpose is to embarrass amd for the next year or so
<tjaalton> and ~8 months away
<RAOF> Right.  There's *always* something cool ~8 months away.
<LLStarks> sandy bridge + x58 is surefine
<tjaalton> x58? that's old
<LLStarks> wait. did i mess up the chipset?
<LLStarks> z68
<RAOF> âAfter this operation, 258 MB disk space will be freed.â  Hm.  That seems rather a lot.  Oh, wait, it's removing xserver-xorg-core and ubuntu-desktop.
<tjaalton> RAOF: heh, which update?
<RAOF> Multiarch'd mesa.
<tjaalton> ah, because there's no xserver update to go with it?
<RAOF> Right.
<RAOF> Also because llvm's not multiarched, so all the i386 drivers are baroque.
<LLStarks> if it ain't baroque, don't fix it
<RAOF> Actually, that's not quite true.  All the i386 gallium drivers are broke.  i965_dri is perfectly happy to run i386 glxinfo and glxgears.  Score.
<LLStarks> can sna be done with stable mesa?
<RAOF> AFAIK sna is largely independent of mesa.  You're very much not allowed to make backward-incompatible DRI2 changes :)
<LLStarks> well, i was wondering if i could test it without a full edgers payload
<RAOF> Probably, but you get to keep all the pieces.
<LLStarks> eh?
<RAOF> âIf it breaks, you get to keep the piecesâ
<hyperair> LLStarks: no fair!
<hyperair> LLStarks: 32-bit or 64-bit?
<LLStarks> 32-bit
<hyperair> maybe it hates 64-bit.
<LLStarks> not that i have a choice
<hyperair> heh
<RAOF> Oh, atom?
<RAOF> That was frequently paired with an i945.
<LLStarks> core duo.
<hyperair> core duo? those support 64-bit, no?
<RAOF> No, the core duo *2* supports 64-bit :)
<hyperair> model name      : Intel(R) Core(TM)2 Duo CPU     T5750  @ 2.00GHz
<hyperair> core 2 duo.
<LLStarks> t2050
<LLStarks> still more powerful than an atom
<LLStarks> despite being 5 years old
 * hyperair wants a sandy bridge.
 * RAOF is fairly sure anything 686-derived is faster than an atom.
<hyperair> lol
<LLStarks> atom is 686
<LLStarks> p3 architechture
<RAOF> No, it's not.  It's an in-order processor.  Which is why performance sucks.
<LLStarks> really?
 * RAOF is pretty sure.
<LLStarks> you're right
<LLStarks> not p6
<RAOF> Why must the mesa build system be constructed entirely of hate?
<tjaalton> heh
<RAOF> Hm, (a) has this worked, and (b) how small are the gallium drivers now?
<RAOF> Win! 3.6M 2011-06-07 15:12 r300_dri.so â 1.3M 2011-06-07 19:29 r300_dri.so, 3.5M 2011-06-07 15:12 r600_dri.so â 843K 2011-06-07 19:29 r600_dri.so
<tjaalton> woohoo
<tjaalton> so a shared gallium core?
<RAOF> Yeah.
<tjaalton> nice
<RAOF> With only the *tiny* problem of 19M 2011-05-27 19:49 /usr/lib/libLLVM-2.9.so.1
<tjaalton> hehe
<Prf_Jakob> Has anybody tried Unity on a git master gallium driver?
<RAOF> Probably some of our intrepid xorg-edgers cadets have?
<tjaalton> probably yeah
<tjaalton> i've only tried swrastg but with 7.10, which lacks tfp support
<RAOF> I happen to have a nice hot ccache here; want me to try?
<tjaalton> you've pulled a snapshot too?
<RAOF> (And a radeon 5450ish)
<RAOF> tjaalton: Mesa build hacking always gets done on master :)
<RAOF> It's not sufficiently fun to do twice :)
<tjaalton> RAOF: naturally, but is it ending up in oneiric soon?-)
<Prf_Jakob> RAOF: no real need I jast wanted to know if there was a known problem with Unity on gallium, I'm guessing the problem is in our driver.
<Prf_Jakob> Unity works pretty well with vmwgfx except a rendering bug.
<RAOF> Cool.
<RAOF> tjaalton: It'll end up in oneiric soon; I just need to finish off the llvm 2.9 mir, which is blocked on actually being able to build openjdk-6b18 on an arm system to check the testsuite.
<ScottK> What mesa is planned for oneiric?
<RAOF> 7.11
<ScottK> Sigh.
<RAOF> Problem for KDE?
<ScottK> Mgraesslin just mentioned on one of the KDE lists he'd done 4.7 to work with 7.10.
<ScottK> Then mentioned if someone was going to use 7.11 with KDE 4.7 they better test it.
<ScottK> So not necessarily a problem, but a combination with undefined results at this point.
<RAOF> Ah, right.  Well, xorg-edgers contains 7.11 snapshots, but we won't be switching until 7.11 gets branched.
<RAOF> Oh!  At what point did libGL start to fallback on swrastg_dri?
<tjaalton> aiui Sarvatt right, it would be 7.11?
<tjaalton> uh
<tjaalton> "iirc what Sarvatt said,..."
<ScottK> RAOF: We didn't get 4.7 beta 1 packaged yet either.
<RAOF> Fun multiarch fact: dpkg --remove mesa-utils won't remove the i386 mesa-utils package; you need dpkg --remove mesa-utils:i386
<RAOF> Wow.  glxgears is curiously messed up.
<jussi> Hrm, Im having an issue where I have the laptop setup with the external screen, and only the external screen in use. However, when powermanagement turns the screen off after a period of inactivity, it doesnt come up again when you become active. the machine seems fine and reponsive, but no screen. 
<tjaalton> jussi: best bet is to try the mainline .39 kernel
<jussi> tjaalton: how would I go about getting that ? is it relatively stable? 
<tjaalton> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.39.1-oneiric/
<tjaalton> certainly stable enough to test that
<jussi> tjaalton: right, however, this machine is on natty
<tjaalton> sure
<tjaalton> just install the deb :)
<jussi> ok :) 
<tjaalton> it doesn't matter if it's built on oneiric tools
<tjaalton> *with
<tjaalton> at least, it shouldn't matter much, and hasn't for the usecases I've had
<jussi> ok, was just unsure. Ill let you know how it goes :)
<tjaalton> good
<tjaalton> which system did you have?
<jussi> is there a chance it will fix my bug also? (bug 793487)
<ubot4> Launchpad bug 793487 in xserver-xorg-video-intel (Ubuntu) "Kubuntu does not shut down when external monitor attached through displayport (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/793487
<jussi> Its a HP probook 5320m
<jussi> also, do I need to install the headers? 
<tjaalton> no need for the headers, unless you have dkms packages
<tjaalton> ah so it's arrandale, yeah .39 might fix that bug
<jussi> dkms packages? 
<tjaalton> .39-rc2 has been tested to fix some bugs concerning external monitors
<tjaalton> dynamic kernel module source, probably don't have them if it's something you don't know :)
<tjaalton> used for binary blobs
<jussi> tjaalton: Unfortunately the kernel did not boot. I installed hte headers also, but still no boot. I pressed esc to see the progress, and it seems to stop after apparmor 
<tjaalton> jussi: dang
<jussi> tjaalton: Im more than happy to try anything else you ahve to offer though. :) (or try troubleshoot the kernel)
<tjaalton> you could try this one, in case the point release broke something http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.39-oneiric/
<tjaalton> at least one person booted that succesfully on natty
 * jussi tries
<jussi> tjaalton: unfortunately no go on that either. it gets a little further, but then dies
<tjaalton> meh
<tjaalton> you could try rc4 from the parent dir next, it's also built on natty if it makes a difference after all..
<tseliot> tjaalton: the blobs won't work with the new kernel as we prevent the module from building against unsupported kernels
<tjaalton> tseliot: right, but is it already in natty too?
<tseliot> tjaalton: yep
<tjaalton> nice
<tseliot> :)
<jussi> hrm, theres also this in the install proceedure:  W: Possible missing firmware /lib/firmware/rtl_nic/rtl8105e-1.fw for module r8169
<tjaalton> well, i was just pointing out when the headers would be useful
<tjaalton> jussi: that shouldn't matter
<jussi> ok, just thought to mention it
<tjaalton> some new nic module i guess
<jussi> right, reboot time. hope this works.
<jussi> right then. (it boots :D ) now let me shut down and see if it fixes that bug, Ill try the initial bug I mentioned in a min. 
<tjaalton> phew, great
<jussi> right, so that bug I mentioned before (793487) is fixed with this kernel. 
<tjaalton> niice
<jussi> kde seems a little slow, not sure whats going on.
<jussi> just seems. 
<jussi> anywya, Ill go away for a bit, and see if the other bug still persists
<tjaalton> ok
<jussi> (and if someone wants to build the newer .1 kernel for natty, I would be happy to try that.)
<tjaalton> the hwe team has a set of patches that'll hopefully get added to the natty kernel, even though there will be no upstream point-releases anymore for .38
<jussi> Im also getting a few artifacts left on the screen. 
<tjaalton> looks like it would fix a bunch of issues
<tjaalton> ah
<tjaalton> well, it has around 90 commits, of which maybe 8 are needed
<tjaalton> rc4 that is, to the drm/i915 code
<jussi> not artefacts per se, but parts of highlighting etc
<tjaalton> RAOF: pushed xserver merge with the fedora pointer-barrier patch added
<tjaalton> now xorg merge finalized so we can start pushing these to oneiric..
<apw> anyone seen X server dumping ?  on intel ?
<apw> [ 25658.288] Segmentation fault at address 0x7f039ec32010
<apw> [ 25658.288] 
<apw> Caught signal 11 (Segmentation fault). Server aborting
<apw> this is natty updated as of this morning
<hyperair> apw: full stack trace?
<apw> hyperair, at the bottom of: http://paste.ubuntu.com/621075/
<Sarvatt> apw: one sec, let me get you the bug number
<Sarvatt> i attached a fix to it, its x-x-i-synaptics
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/774978 comment #25
<ubot4> Launchpad bug 774978 in xserver-xorg-input-synaptics (Ubuntu) "xserver crashes in RecordAReply when XRecord is enabled in syndaemon (affects: 91) (dups: 22) (heat: 444)" [High,Triaged]
<Sarvatt> it just started now though? it happened at random before but amazing you went from release till now and just started hitting it
<apw> yeah first time i've ever seen it
<apw> i right clicked somewhere and boom
<apw> oh ... of course i don't use my touchpad most of the time on this machine as i have external keybaord an mouse
<apw> and i was using the touchpad unusually ... so
<hyperair> weird, i've been using my touchpad though
<hyperair> why would a touchpad cause intel_drv.so to segfault?
<hyperair> i see that in the stack trace somewhere
<LLStarks> hyperair, i've seen it happen in israel due to voltage differences
<hyperair> Sarvatt: IT WORKS.
<LLStarks> my xserver choked whenever i used the touchpad
<hyperair> LLStarks: ah, right voltage differences.
<hyperair> well my xserver never choked due to the touchpad
<hyperair> but the touchpad itself choked.
<LLStarks> btw, all of my observed improvements that i attributed to SNA yesterday were all from the new ddx/mesa/drm WITHOUT SNA
<LLStarks> i don't get it
<LLStarks> what's crippling the stable stack so much?
<tjaalton> Sarvatt: time to sru -synaptics?
<LLStarks> synaptics needs tapbutton2=2
<LLStarks> for two-finger middle click
<LLStarks> right now, it's tapbutton2=3
<LLStarks> that and out-of-the box two-finger scrolling
 * hyperair doesn't observe any improvements to SNA though..
<LLStarks> intel ddx is overrated
<LLStarks> i have no idea what's going on between oneiric's 2.15 and the non-SNA git, but something is slowing me down
<LLStarks> it can't be mesa. this is 2d stuff.
<LLStarks> i wish i could source this slowdown, but xorg log is clean
<LLStarks> can i run -intel master on a stable oneiric stack?
<hyperair> hmm i wonder why 3d activity causes my entire computer to freeze for short periods of time
<hyperair> enough to miss a number of interrupts for psmouse
<hyperair> and enuogh to screw over eth0 transmission
<hyperair> and enough to make iwl4965 trigger a hardware reset
<LLStarks> x is just weird
<hyperair> heh
<hyperair> i think it's more like i915 is doing too much processing in the irq
<LLStarks> i945gm slowdown with the 2.15 ddx confirmed.
<LLStarks> 2.15git is fine.
<LLStarks> there's like zero acceleration in the former
<LLStarks> and this is without SNA
<LLStarks> time for some bisecting
<LLStarks> should be fun
<LLStarks> wait wtf... 2.15-release git is fine. did somebody screw up packaging?
<LLStarks> nvm. i might be wrong.
<Sarvatt> tjaalton: i dont suppose there's any chance you already did any of the mesa lucid backport? :P
<tjaalton> Sarvatt: not sure, probably not
<tjaalton> silly sentence
<Sarvatt> yeah it was a long shot, gonna start throwing it together now since thats the last part
<bjsnider> ricotz, is it possible to change the sound theme in gnome 3? it's not an option with the tweak tool
<ricotz> bjsnider, this can be done with dconf-editor
<ricotz> bjsnider, org/gnome/desktop/sound
<Sarvatt> got it close, http://sarvatt.com/downloads/mesa/
<bryceh> Sarvatt, should I go ahead and upload/sru the fix you posted on #774978?  Or is there more we need to do first?
<Sarvatt> that'd be much appreciated
<tjaalton> Sarvatt: would adding -lrt to LDFLAGS help there?
#ubuntu-x 2011-06-08
<Sarvatt> sorry for the build failure mail spam, obviously only test building on i386 before uploading to the backports ppa's isn't enough
<bryceh> Sarvatt, hey do you know why that xrecord crash bug came to be?  did chase's earlier xrecord fix expose the bug or something?
<bryceh> I'm going through all the recent X crash reports and it appears like 80% of them at least are dupes of this one
<bryceh> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/774978/comments/38
<ubot4> Launchpad bug 774978 in xserver-xorg-input-synaptics (Ubuntu Natty) (and 1 other project) "xserver crashes in RecordAReply when XRecord is enabled in syndaemon (affects: 188) (dups: 34) (heat: 640)" [Undecided,Fix committed]
<bryceh> cnd, Sarvatt, ^^ please review, you might have more to add to the story
<braintorch> Hello. Will there be 270.41.19 nvidia driver for lucid in ubuntu-x repo? Somewhat nasty bug affecting flash video playing was fixed in this version.
<bryceh> braintorch, probably in xorg-edgers, maybe in x-updates.  probably not in natty-updates tho.
<braintorch> I see it was packaged for oneric and for natty in x-updates but not for maveric or lucid. That's why I interested.
<jussi> tjaalton: bah, the original bug I mentioned (about the screen not coming back from sleep) is still there. I guess I didnt wait long enough last time :/
<jussi> also, saving the default settings in kubuntu doesnt actually save it, it always reboots with the same settings.
<tjaalton> jussi: ok, try with .39-rc3 to see if it's fixed there
<cnd> bryceh, wow, that XRecord stuff looks like a festering wound
<cnd> good analysis in the bug comment :)
<cnd> so are we going to patch up g-s-d to not use -R?
<jcristau> do we enable record by default?
<jcristau> maybe that's not such a great idea...
<cnd> jcristau, apparently g-s-d now tells syndaemon to use XRecord instead of polling the keyboard state
<jcristau> record sounds like it makes keyloggers kind of trivial
<cnd> heh
<Sarvatt> syndaemon itself uses record by default if its built with support for it
<Sarvatt> -R doesn't have any affect in that case :(
<Sarvatt> bryceh: http://kernel.ubuntu.com/~sarvatt/sandybridge-10.04-live/ \o/
<tjaalton> yeah, I tested that and it worked here too
<tjaalton> glxgears acted funny though
<tjaalton> when trying to move the window
<Sarvatt> stutters?
<Sarvatt> you should see it with current git if you think thats bad, at least the gears dont flash teal and yellow while it happens
<tjaalton> heh ok
<Sarvatt> tjaalton: oh you're on a GT1, i've got to try it out on that
<Sarvatt> wouldn't be surprised if mesa 7.10.2 is messed up there
<Sarvatt> tjaalton: btw you probably want to use i915.semaphores=1 on that thing..
<Sarvatt> it'll fix the stuttering if thats the problem you had
<tjaalton> seems to be on natty too
<tjaalton> which is hardly surprising
<Sarvatt> http://dl.dropbox.com/u/1117258/VID_20110608_111152.m4v
<Sarvatt> tjaalton: try vblank_mode=0 glxgears if you want some real fun
<tjaalton> riight, ~1000 fps, though it looks like ~2
<Sarvatt> check dmesg
<tjaalton> heh
<Sarvatt> ricotz: i dont think the 3.0 kernel is going to work without a module-init-tools update too so probably not a good idea to copy that to edgers right away
<ricotz> Sarvatt, ok, so the updated module-init-tools package from oneiric isnt working yet? havent tried to building 3.0 myself yet
<ricotz> Sarvatt, looks like the m-i-t update works - ppa:apw/red
<Sarvatt> cool, looks like it went into oneiric directly this morning too
<Sarvatt> https://lists.ubuntu.com/archives/oneiric-changes/2011-June/002607.html
<ricotz> ;)
<apw> Sarvatt, we are still sorting out the numbering... the last bits are being fixed now
<apw> be careful about uploading the meta to the xorg-edgers without it being fixed
 * Sarvatt nods
<ricotz> there will be no meta in edgers anyway
<Sarvatt> haven't been putting meta's in edgers as of yet
<apw> we are hedging our bets right now as to whether to use 3.0 or 3.0.0 for sanity
<apw> and so uploading 3.0 kernel with a 3,0,0 meta as unexpectedly we can switch either way that way going forward
<Sarvatt> i'm probably a little too cautious about keeping things in there stable :P
<ricotz> apw, you are doing an abi bump for stable releases anyway, so perhaps using the stable release version as base?
<apw> ricotz, yeah we simply hedging.  i think we'd like to call it 3.0 but module-init-tools is just the tip of the iceberg on whats fooked by the number change
<ricotz> this would mean using 3.0.0, 3.0.1, ...
<apw> ps all gets angry too
<apw> ricotz, yet a third option indeed
<ricotz> so 3.0.0-0.1, {stable version}-{ubuntu-revision}
<ricotz> just an idea ;)
<apw> that does force us to bump abi whenever we take stable which we don't currently always do
<Sarvatt> ugh
<ricotz> apw, ok, i though it is needed quite everytime
<apw> i know, which is why we are hedging :)
<apw> ricotz, there have been a number of .7 is huge, .8 is one patch to unbreak .7 which is not a bumper
<ricotz> alright
<Sarvatt> it would be nice to have the version number reflect reality even though thats a pain in the butt. i constantly get asked by upstreams what 2.6.38-7 maps to for example :P
<ricotz> Sarvatt, +1, right, using the actual full upstream version in some kind would be nice
<jcristau> Sarvatt: it's never going to map exactly to an upstream version anyway
<jcristau> each distro kernel is patch in its own spethial way
<jcristau> *patched
<Sarvatt> sheesh, mesa tarball is bigger than it was with demos in it now
<ricotz> Sarvatt, switching to 3.0 and using bz2 might be nice ;)
<cnd> bryceh, Sarvatt: I'm trying out oneiric, but every time I log in I get "Oh no! something wrong has happened." message
<cnd> do you know how to get around that?
<Sarvatt> cnd: i've never even heard of that dialog
<Sarvatt> hmm
<cnd> it's this really terrible window that comes up
<Sarvatt> apparently its a gnome 3 one
<cnd> there's no information
<cnd> I have no clue what to do to debug it
<cnd> 0 info
<cnd> I understand the point, but really it's more aggravating than anything
<Sarvatt> looks like it's a gnome-menus problem when it happened in fedora
<cnd> I think it manifests from many different error paths...
<cnd> I just want to get behind it
<cnd> I can relaunch services and stuff if I need
<cnd> and it shouldn't be happening when I try a non-gnome 3 session
<bryceh> I haven't ever seen that either
<Sarvatt> i think this is the longest i've ever gone without updating to the devel release on all any of my systems, not looking forward to gnome 3 pain..
<Sarvatt> but i guess its time, starting an upgrade
<Sarvatt> cnd: 
<Sarvatt> Jun 02 06:24:07 <chrisccoulson>	i did try gnome-shell from our archive last night
<Sarvatt> Jun 03 03:37:15 <chrisccoulson>	so, this silly window that takes up my entire screen when i dock my laptop,and shows a sad face telling me i need to log out is actually from gnome-session
<Sarvatt> Jun 03 04:00:27 <seb128>	chrisccoulson, by reading gnome-session code that screen is displayed when the session fails to respawn something that quited
<Sarvatt> Jun 03 04:03:35 <seb128>	run gnome-session --debug maybe and dock your laptop and look at the session log
<chrisccoulson> we really need to kill that error, it's totally ridiculous
<cnd> yeah
<cnd> Sarvatt, thanks for digging that up!
<cnd> oh wait
<cnd> I get that error at login
<cnd> how do I enable debug for gnome-session like that?
<Sarvatt> is there nothing that stands out in ~/.xsession-errors?
<cnd> Sarvatt, http://paste.ubuntu.com/622020/
<cnd> doesn't look like it :(
<Sarvatt> i'm seriously going to regret this upgrade tomorrow no doubt :)
<cnd> heh
<cnd> I wonder if it's possible to use the natty gnome-session
<cnd> I was able to downgrade
<cnd> lets see if it helps
<cnd> alright, progress
<cnd> but I don't have a window decorator...
<pentarex> hey guys I'm having some issue with HP G62 with two videocards, INTEL and ATI RADEON 5470, I've installed kubuntu 11.04 and now I cant log in - I see the log in sign, then the screen goes black(blank) and the fan goes off
<pentarex> can anyone help me please
<Sarvatt> bryceh, RAOF: they snuck up like ninjas when we were drinking :P http://photos.pixoulphotography.com/Events/UDS-Oneiric/17103699_kzzLF6/1/1296062040_6SsNNkg#1296215224_r26Dfnz
<RAOF> Sarvatt: Yeah, I know.  I look plenty stupid in the UDS photo's I've found of myself :)
#ubuntu-x 2011-06-09
<bryceh> heh
<Sarvatt> argh, all browsers unusable while the oneiric upgrade is in progress :P
<Sarvatt> woohoo upgrade failed, lets see how broken it is on reboot
<Sarvatt> so yeah, somehow added 10 seconds to my bios progress bar time, recovery mode is busted, keyboard/mouse doesn't work with lightdm, unity is usuably ugly and http://sarvatt.com/downloads/wtf.png ...
<bryceh> Sarvatt, :-/
<Sarvatt> think I'm about done with gnome :)
<ScottK> That sounds either good or ominous.
<ScottK> Not sure which it is.
<Sarvatt> ah I see, gnome-shell is the only thing that works atm apparently
<Sarvatt> (yet not installed by default)
 * RAOF as always has the working system.
<Sarvatt> RAOF: screenshot plz? :)
<RAOF> http://cooperteam.net/Screenshot.png :P
<Sarvatt> RAOF: woohoo
<Sarvatt> thanks man, installing gnome-themes-standard fixed things
<Sarvatt> now to figure out why i can't boot the oneiric kernel when the previous oneiric kernels installed under natty work fine
<Sarvatt> udev complaining about not being able to write to /run/udev and it just sits there
<Sarvatt> guessing its a udev problem and those earlier initrd's weren't updated with the broken udev
<bjsnider> RAOF, you're using a lot of ram there
<RAOF> Sarvatt: Odd.  My initramfs complains about that and then boots fine. :)
<RAOF> bjsnider: Oh, yes.
<Sarvatt> RAOF: hrm I waited about 45 seconds before giving up each time
<RAOF> bjsnider: ram/swap: 3.6GB,84% s2.8GB,27%
 * Sarvatt boots in <10
<Sarvatt> RAOF: does lightdm work for you?
<RAOF> Again, yes :)
<bjsnider> RAOF, i gues you have a few virtual machines running?
<Sarvatt> uptime?
<Sarvatt> oh latest lightdm is from may
<RAOF> Uptime ~4hrs.  No VMs; my system just eats ram for no obvious reason.
<Sarvatt> going to have to ssh in and see if i can figure out why keyboard/touchpad/trackpoint dont work, absolutely nothing in the logs
<RAOF> It's not udev being broken and not marking the devices as input?
<bjsnider> RAOF, you have gobbled up that much ram in only 4 hours?
<bjsnider> that's rdiculous
<bjsnider> this is linux
<RAOF> Oh, much less than 4 hours; it's pretty much static :)
<Sarvatt> oh you know that might be it, i didn't boot the oneiric installed kernel with gdm yet
<Sarvatt> RAOF is a mono fan.. :P
<bjsnider> RAOF, you can check in top or whatever which process is using that much
<RAOF> The real killers are firefox at 900MiB res and evolution at 1100 MiB res.
<bjsnider> or are they all high
<RAOF> (As always).
<bjsnider> well, i don't use either, so maybe that's why i don't ever have that much ram usage
<bjsnider> it doesn't even get that high with virtual machines running
<bjsnider> i haven't even bothered to install a swap partition
<Sarvatt> ok stuff is "working", now to see if xorg-edgers "works"
<Sarvatt> getting worried about my mesa packaging fork :)
<Sarvatt> hmm lightdm upstart script stops because of [ ! -f /etc/X11/default-display-manager -o "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/bin/lightdm" ] || { stop; exit 0; }
<Sarvatt>  but the gdm one never starts
<Sarvatt> the udev-fallback-graphics upstart script always fails, i always get a text plugin plymouth splash on the inteldrmfb, moving lightdm out of the way didn't help, definitely some udev bustage here
<RAOF> Yeah.  I'm not sure whether my update intel plymouth integration patch actually works because I don't think that plymouth is working right :).
<Sarvatt> dang I coulda tested it on natty
<RAOF> Well, it doesn't *crash* and I'm pretty sure it doesn't mess up the graphics state; the only question is whether it actually copies the entirety of the framebuffer to the new front buffer before setting setting it as scanout.
<Sarvatt> downgrading to natty udev/libudev fixed it \o/
<Sarvatt> RAOF: downgrading to natty udev also makes plymouth work again if you want to test it
<RAOF> Hm, funky.
<Sarvatt> i've got xorg-edgers going, lemme ppa-purge
<Sarvatt> will let ya know in about 2 minutes if it works
<Sarvatt> oh of course now i see https://bugs.launchpad.net/ubuntu/+source/udev/+bug/787610
<ubot4> Launchpad bug 787610 in udev (Ubuntu) "udevd fails to start: bind failed: Address already in use (affects: 6) (heat: 30)" [Undecided,New]
<Sarvatt> RAOF: works fine and actually makes gdm look 100x better
<Sarvatt> because you get the purple background instead of black
<RAOF> :)
<RAOF> Hurray!
<RAOF> Time to clean up and upstream with a âOriginally-written-by: Someone at Redhatâ :)
<Sarvatt> \o/
<Sarvatt> of course i'm sure its 100% broken with current git
<RAOF> Oh, of course.  sna.
<RAOF> %^#&$
<Sarvatt> I think krh originally wrote it
<RAOF> I'm sure he's on intel-gfx@.  He can pipe up if he wants to :)
<Sarvatt> I hear sna works on !gen6 if you want to try it
<Sarvatt> gen6 for sure needs the xserver stuff :(
<Sarvatt> https://launchpad.net/~sarvatt/+archive/intel-sna
<Sarvatt> if you could tell me if chromium works on yours that'd be much appreciated :)
<Sarvatt> i might enable it for select generations in xorg-edgers
<Sarvatt> would be nice if it was just opt-in with an xorg.conf option actually..
<Sarvatt> lessee if lightdm works with natty udev
<Sarvatt> cnd: looks like you can blame lightdm for your Oh no! error
<cnd> Sarvatt, I was using gdm...
<Sarvatt> cnd: oh sorry, i switched to lightdm and after fixing udev so keyboard/mouse worked i got the fail whale every login with that
<cnd> hmm
<Sarvatt> hmm dri2proto 2.5 was never released, now x-x-v-intel depends on 2.6
<RAOF> Heh.
<RAOF> Hey, ccache!  FASTER!
<tjaalton> took 9min to build mesa on my new box
<LLStarks> cnd: can two-finger middle-click tap be done in ubuntu without causing the problems of two-finger scrolling?
<LLStarks> it's only a tapbutton command
<RAOF> tjaalton: Is that a full package build, or just dri?
<tjaalton> RAOF: full
 * RAOF hates you and your shiny fast system :P
<tjaalton> :P
<tjaalton> just a 4core, 8 thread snb with ssd
<ScottK> Do I want wayland support patches in kwin this cycle?
<ScottK> Upstream is offereing.
<tjaalton> ScottK: we are not going to do anything special with it, but some people might want to test it. what exactly do those patches enable?
<ScottK> tjaalton: Dunno
<tjaalton> ScottK: got a link to a commit?
<ScottK> tjaalton: I asked mgraesslin to join us here (or you can join #kubuntu-devel)
<tjaalton> ScottK: nah that's fine, was just curious
<ScottK> OK.
<bryceh> ScottK, no you probably don't care about having wayland support patches in kwin yet
<bryceh> ScottK, it's nice that upstream is providing them, but it's going to be at least another release or two before there's really enough of interest for you to care about
<bryceh> ScottK, you probably can just wait until they're in your regular kwin release
<ScottK> bryceh: Thanks.
<tjaalton> the "wayland-clients on kwin" news can be found on phoronix
<Sarvatt> gonna have to stop intel updates for a few days, dont trust that dri2proto wont get released as 2.5 yet and would be screwed if i uploaded it as 2.6 :P
#ubuntu-x 2011-06-10
<jussi> tjaalton: Unfortunately the RC3 did not fix it. Is it worth my time to try RC2 and RC1? 
<jussi> (now that I finally got to testing it)
<tjaalton> jussi: nah, rc3 has fixed things for others, so your bug is something else
<jussi> tjaalton: ahh. I seill need to test the sleep bug, but the artifacts are still around
<lool> Sarvatt: Hey
<lool> Sarvatt: xserver-xorg-input-synaptics 1.3.99+git20110116.0e27ce3a-0ubuntu14 you dropped a build-dep to avoid some feature being turned on; I would like to make this a build-conflict instead; is this ok with you?
<lool> Sarvatt: pushed to git
<lool> Sarvatt: uploaded, shoot if that was wrong  :-)
<lool> or shout
<ricotz> Sarvatt, hello :)
<ricotz> Sarvatt, i'd like to upload an updated nvidia driver to edgers perhaps you want to take a look first -- http://people.ubuntu.com/~ricotz/nvidia/275.09.04_update.debdiff
#ubuntu-x 2011-06-11
<bjsnider> ricodoes this update make a difference to gnome-shell or gnome 3?
<bjsnider> oh, he left
#ubuntu-x 2011-06-12
<gord> sna on sandy bridge fixed my unity problems, i was going to go and make the dash faster as well :P 
#ubuntu-x 2012-06-04
<mlankhorst> morning
<tjaalton> same
<RAOF> Good afternoon :)
<mlankhorst> crazy australians and their upside down time ;)
<mlankhorst> bryceh: still awake?
<mlankhorst> RAOF: was thinking of having a weekly small meeting for x where we discuss things, wouldn't have to long :)
<mlankhorst> be*
<RAOF> We're probably getting big enough to make that worthwhile, yeah.
<mlankhorst> Wouldn't need to be big or anything, just so that we're all together to talk for a bit due to being in 3 different timezones
<tjaalton> yeah
<mlankhorst> was thinking the same time as last one at least until timezone shifts, think it was 21.30 utc?
<tjaalton> steam client coming later this year
<tjaalton> hmm, kernel build time.. there are some drm commits that need testing, hoping they'd fix ivybridge instability too
<tjaalton> is ben hutchings the v3.2-stable maintainer now?
<jcristau> yes
<tjaalton> good
<tjaalton> I'll check his tree first
<tjaalton> bryceh (and others): I've built a kernel with three drm/i915 commits on top of the precise-proposed kernel, available here http://kernel.ubuntu.com/~tjaalton/precise-kernel/
<tjaalton> those map to bugs 982415 974830 and 983146
<ubottu> Launchpad bug 982415 in xserver-xorg-video-intel (Ubuntu) "[i915gm] False GPU lockup render.IPEHR: 0x3f800000" [High,In progress] https://launchpad.net/bugs/982415
<tjaalton> only amd64 version though
<cnd> mlankhorst, I saw there was a question about synaptics srus
<cnd> what's up?
<mlankhorst> O_O
<mlankhorst> cnd do you remember the question at least :)
<cnd> mlankhorst, it was in the middle of a couple discussions in my irc backlog, so if you could explain again I would appreciate it :)
<tjaalton> we were discussing sru's, and I guess mlankhorst suggested we should get 1.6.1 in precise :)
<tjaalton> "bugfix microrelease" :P
<mlankhorst> hehehe my backlog is cut off exactly 1 line before that
<mlankhorst> 09:46 < mlankhorst> cnd: ^
<tjaalton> check irclogs.u.c
<cnd> mlankhorst, yes, 1.6.1 needs to get into precise, but we also need a couple patches since then, IIRC
<tjaalton> cnd: speaking of which, is the xserver input code uptodate with current 1.12 fixes?
<cnd> tjaalton, IIRC, jeremyhu just put out 1.12.2 last week?
<cnd> out server is up to date with 1.12.1
<mlankhorst> cnd: Ah k, was just wondering if you felt it was worth pushing entire 1.6.1 or not, and if there have been patches that need to be in X server for it :)
<tjaalton> cnd: yeah, ok good
<cnd> mlankhorst, I don't think there are any patches that must be in the xserver before pushing an update to synaptics
<cnd> mlankhorst, http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/log/?h=synaptics-1.6-branch
<mlankhorst> yeah the quantal has all the commits
<cnd> good
<cnd> but precise needs them all too
<cnd> especially any having to do with touches
<mlankhorst> yeah I just wanted to run it on quantal and look for bugs before sru'ing :)
<cnd> good idea
<cnd> mlankhorst, will you be handling srus for xorg-server too?
<cnd> or is someone else doing that?
<mlankhorst> Not sure who is doing it atm
<cnd> maybe that someone is assumed to be me :)
<mlankhorst> I have no rights but I can poke the others for it I suppose :)
<cnd> bryceh, tjaalton: do we normally do srus for each upstream point release?
<cnd> or only pull patches for bugs that people file
<tjaalton> cnd: heh, that was the point of the discussion..
<cnd> ahh
<cnd> tjaalton, and the outcome was?
<tjaalton> we've not done point-releases because they're nigh impossible to get accepted
<tjaalton> but we'd like to change that
<tjaalton> then again, the new sru policy is actually more strict about the paperwork
<tjaalton> and requirementes
<tjaalton> -e
<cnd> tjaalton, ok
<tjaalton> but, we could always try again..
<mlankhorst> tjaalton: In this case it's a pre-release version so maybe less strict..
<tjaalton> mlankhorst: ..we're updating from, so yep
#ubuntu-x 2012-06-05
<mlankhorst> RAOF: So lets plan a meeting? :>
<tjaalton> propose something on the list?
<mlankhorst> tjaalton: was hoping to keep it small and informal
<mlankhorst> especially since at any given time we use, someone will have just woken up and someone is about to go to bed
<tjaalton> but we're never all here to plan it :)
<mlankhorst> tjaalton: what times do you prefer then? in utc
<tjaalton> mlankhorst: well I'd have to be realistic
<jcristau> tjaalton: that's kind of where mail is better.
<tjaalton> so that's something between 21-22 UTC I think, so that RAOF is able to attend
<tjaalton> late for me
<tjaalton> in any case
<mlankhorst> could be early morning for me too
<tjaalton> for me too, until mid-august or so
<tjaalton> jcristau: planning?
<jcristau> tjaalton: right.  if you need a meeting to set up the meeting there's a bootstrap issue :)
<tjaalton> indeed :)
<mlankhorst> sent mail anyhow
<mlankhorst> aiming for wednesday 21.30 utc
<tjaalton> ugh, keep forgetting that mesa doesn't like overlayfs/sbuild
<RAOF> hardlinks FTL
<tjaalton> yep
<mlankhorst> at second glance core X.org doesn't seem so intimidating after all.
<tjaalton> the code or the merry folks?
<mlankhorst> code
<mlankhorst> awesome..
<mlankhorst> to someone else wondering why wine was acting weirdly with fglrx
<mlankhorst> "maybe fglrx has workarounds if wine is detected? Change glxinfo32 to wine"
<mlankhorst> them: "...sonofa...you're right."
<tjaalton> hah
<mlankhorst> it somehow limited GL_MAX_VERTEX_UNIFORM_COMPONENTS_ARB to 1024 in wine and not anywhere else.. seems ridiculously low though
 * bryceh waves
<mlankhorst> heya
<mlankhorst> not wednesday yet, so bedtime :)
#ubuntu-x 2012-06-06
<tjaalton> bryceh: oh you took the task to send the patches upstream, nice :)
<tjaalton> i just had a brief look at the remaining patches yesterday and spotted these two
<tjaalton> bryceh: btw, you bumped the package revision of xorg-server ;)
<ricotz> Sarvatt, thanks for pushing the driver updates that fast
<bryceh> tjaalton, dch's fault :-)
<tjaalton> don't use -i ;)
<bryceh> tut tut, use -i all the time
<tjaalton> it already increments the version when the previous entry is finalized, so -i is rarely needed
<bryceh> huh
<mlankhorst> morning btw
<tjaalton> bryceh: ahh, you need DEBCHANGE_RELEASE_HEURISTIC="changelog" in .devscripts
<tjaalton> then it works properly
<bryceh> tjaalton, aha thanks
<tjaalton> normally i just edit the changelog directly, but dch adds the multimaint-tags
<bryceh> yeah same
<RAOF> Moshi moshi.
<tjaalton> so the big api change got merged in xserver master, and for 1.13 we might see some of the hotplug/offload functionality too
<tjaalton> anyway, 12,5h until the meeting ;)
<jcristau> tjaalton: i think that's the default in recent devscripts fwiw
<tjaalton> oh
<tjaalton> not on precise anyway
<tjaalton> I tested it now and noticed the difference
<tjaalton>  2.11.6ubuntu1
<tjaalton> but makes sense
<tjaalton> yeah changed in 2.11.7
<jcristau> i've had to put it in .devscripts for years so i'm happy it's finally changed :)
<mvo> could someone check https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1008864 please? it appears that for some users the python equivalent of glxinfo in software-center causes a full X crash on intel: python /usr/share/pyshared/debtagshw/opengl.py is what they run
<ubottu> Launchpad bug 1008864 in software-center (Ubuntu) "software center crashes when clicking pay apps" [High,Triaged]
<tjaalton> mvo: doesn't crash here with sandybridge on 3.4 kernel, will try with the precise one
<mvo> tjaalton: thanks, maybe some odd cnfiguration on the users system?
<tjaalton> mvo: not necessarily, intel drm is in rather bad shape on 3.2 :/
<tjaalton> some fixes in -proposed
<mvo> good to hear
<mvo> (about the fixes, not the bad shape ;)
<tjaalton> :)
<tjaalton> and more being validated
<tjaalton> mvo: still doesn't crash :/
<RAOF> tjaalton: When's the meeting, again?
<tjaalton> RAOF: 21:30 UTC
<tjaalton> so, 10h from now
<tjaalton> bit early for you, late for me ;)
<mlankhorst> slightly late
<tjaalton> no too bad, the other night I was up until 3am+ playing infamous2..
<tjaalton> sweet, intuos5 backport works
<tjaalton> lunch->
<bcurtiswx> in 12.04 i have a Dell U3011 monitor with 2560x1600 resolution, but after fresh install i only see 1600x1024 as max resolution
<bcurtiswx> how do I go about forcing 2560x1600 ?
<tjaalton> which driver?
<bcurtiswx> nvidia
<bcurtiswx> nouveau i think
<bcurtiswx> NVIDIA Quadro NVS 295
<tjaalton> check that it's actually being used and not vesa
<bcurtiswx> tjaalton, how do I do this?
<tjaalton> Xorg.0.log
<bcurtiswx> where at? /etc/X11 ?
<tjaalton> /var/log
<bcurtiswx> /var/log ?
<bcurtiswx> ok
<bcurtiswx> brb
<tjaalton> or 'dmesg|grep nouveau'
<tjaalton> hmm if it's a fresh install then it should be used
<tjaalton> thought there would be remnants of the nvidia blob
<bryceh_> tjaalton, wonder how many reasons we could dream up for why a system would max out at a lower resolution.
<tjaalton> bryceh_: :)
<bryceh_> bet there's at least a couple dozen
<tjaalton> there are many, but let's rule out the obvious ones first..
<tjaalton> like, kms disabled for one reason or another
<bryceh_> tjaalton, most obvious being stray xorg.conf?
<tjaalton> bcurtiswx: are you sure that your card has enough power, in other words it has the extra power cable attached?
<tjaalton> I used to have such issues many times, damn hw builders
<tjaalton> bryceh_: well, not if it's a fresh install, but yeah
<bcurtiswx> tjaalton, not sure about extra power cord, it's a brand new build delivered yesterday from DELL
<bcurtiswx> i don't think it would be underpowered
<bryceh_> ahhhhhh
<bryceh_> bcurtiswx, so it has proper resolution initially, but you wiped the Dell image and reinstalled, and now you don't have it?
<bcurtiswx> tjaalton, i grep dmesg for vesa dn nouveau and VESA comes up with results while nouveau does not
<bcurtiswx> s/dn/in
<bryceh_> tjaalton, should we ask him for the Xorg.0.log, or would that be cheating like looking at the lid on the puzzle box?
<bcurtiswx> i can get that for ya
<tjaalton> heh
<bcurtiswx> is there a way to send a text file to pastebin ?
<bryceh_> pastebinit!
<tjaalton> bcurtiswx: install pastebinit, then run 'pastebinit /var/log/Xorg.0.log'
<bcurtiswx> ok brb
<tjaalton> echo!
<bcurtiswx> +
<bcurtiswx> bryceh_, tjaalton http://paste.ubuntu.com/1027284/
<bryceh_> ah, -nvidia
<bryceh_> use the nvidia graphics config utility thingee
<bcurtiswx> ?
<Sarvatt> bcurtiswx: you have it hooked up via a single link cable it looks like
<Sarvatt> is that dvi or dp?
<bcurtiswx> its a DVI cord plugged into one that looks like HDMI but it's not quite
<Sarvatt> if its dvi you need a dual link cable to use the full resolution
<bryceh_> [    33.660] (--) NVIDIA(0): DELL U3011 (DFP-0): Internal Single Link TMDS
<Sarvatt> ah yeah could be that too
<Sarvatt> you need an actual dual link dvi cable the whole way or to use displayport, cant do it over HDMI either
<bryceh_> huh, that would not have been on my two dozen reasons list
<tjaalton> would've been on mine :)
<tjaalton> and it's using the blob
<tjaalton> so not exactly fresh install
<tjaalton> to the letter :)
<tjaalton> i had a similar monitor for several years, and they're quite picky
<Sarvatt> those 2560x1600 monitors are pains in the butt
<tjaalton> this 27" 25x14 is pretty nice
<tjaalton> :)
<Sarvatt> oh ya got one?
<tjaalton> if only it wouldn't turn off by itself several times a day
<tjaalton> yeah
<tjaalton> for two months now
<tjaalton> samsung sa850t
<Sarvatt> bcurtiswx: err so
<Sarvatt> http://www.nvidia.com/object/product_quadro_nvs_295_us.html
<Sarvatt> says you need to use displayport
<Sarvatt> guess ya can get a displayport to dual link dvi adapter
<tjaalton> or just use a dp cable
<tjaalton> since the monitor has a dp port
<Sarvatt> bcurtiswx: if you're near woodbridge I can give ya a dp cable :P
<bcurtiswx> OK, i hooked up a second cable
<bcurtiswx> its one screen that Ubuntu sees as two
<bcurtiswx> how do I make it work?
<tjaalton> huh?
<bcurtiswx> OK my monitor has TWO DVI hookups
<bcurtiswx> and i have two DVI-DP connections
<tjaalton> don't do that
<bcurtiswx> tjaalton, then what shal I do ?
<Sarvatt> its the dvi-dp adapters that are limiting you to single link bandwidth
<Sarvatt> ya need a displayport cable
<tjaalton> use either a displayport cable, or a dual-link dvi-cable with a dp->dl-dvi adapter
<Sarvatt> the cables like $5 vs a $50 dual link dvi to displayport adapter
<tjaalton> yes, the cheap passive adapters only do single-link
<tjaalton> i know, I have two :)
<bcurtiswx> i have one cord that takes on DVI and splits it into two
<bcurtiswx> one*
<bcurtiswx> that what you mean?
<tjaalton> no
<tjaalton> dl-dvi is a cable that has all the pins connected
<tjaalton> but that won't work either unless you have a proper dp->dl-dvi adapter
<tjaalton> which is an active box with a power source
<tjaalton> and costs money
<tjaalton> well, more than the 15EUR a passive one is
<tjaalton> maybe 50
<Sarvatt> what ya need is something like this http://www.amazon.com/PTC-Premium-Series-DisplayPort-Displayport/dp/B001MIB0SU/ref=sr_1_1?ie=UTF8&qid=1339008125&sr=8-1
<Sarvatt> i'm not sure if you have full sized displayport or mini on the gpu though
<Sarvatt> but ya said it looked like hdmi so probably full sized
<Sarvatt> bcurtiswx: aren't you in fairfax? http://www.microcenter.com/single_product_results.phtml?product_id=0308064 is the only one i can find for sale in a local shop
<bcurtiswx> Sarvatt, yes i'm at GMU in fairfax
<bcurtiswx> what's with that displayport to displayport hookup?
<tjaalton> it's the best you can get
<tjaalton> and cheapest
<bcurtiswx> we have a cord with displayport on both ends
<tjaalton> so use that
<bcurtiswx> how? the card is displayport and monitor is DVI
<Sarvatt> the monitor has displayport
<Sarvatt> dell says it does at least
<bcurtiswx> hmm, maybe i'm blind (wouldn't surprise me)
<bcurtiswx> brb
<tjaalton> it has a dp, two dl-dvi, two hdmi-1.3, vga..
<tjaalton> or it's not U3011 :)
<Sarvatt> bcurtiswx: right next to the orange audio plug
<tjaalton> :)
<bcurtiswx> it's right next to the DVI plug which we couldn't see the DP port without not being lazy
<Sarvatt> http://sarvatt.com/dp.png
<bcurtiswx> thanks, gonna go switch that up
<Sarvatt> cool beans
<Sarvatt> that should "just work"
<mlankhorst> hybrid graphics is fun
<mlankhorst> I keep hitting the hard problems early :D
<bcurtiswx> Sarvatt, bryceh_, Thanks :) I feel dumb, but It works and thats the important part
<bcurtiswx> Sarvatt, I'm in Falls Church now
<tjaalton> meeting time?
<tjaalton> bryceh_, mlankhorst, RAOF, Sarvatt
<tjaalton> uh
<tjaalton> 1h from now
<tjaalton> sorry :)
<tjaalton> didn't realize the uk time isn't utc during summer time
<bryceh_> :-)
<mlankhorst> morning
<mlankhorst> di
<RAOF> Heh.
<RAOF> bryce, mlankhorst, Sarvatt, tjaalton: *Now* it's meeting time :)
<tjaalton> finally
<mlankhorst> wb
<bryceh> so
<mlankhorst> but yeah lets see *checks email*
<bryceh> lts first?
<mlankhorst> sure
<bryceh> mlankhorst, alrighty take it, where we at?
<mlankhorst> well the repository is up so I think at this point we just need to land the stack in Q first :)
<mlankhorst> I have been spending some time on upstream atm, helping airlied with his hybrid graphics work
<bryceh> ok, any outstanding issues aside from the uninstallation problem?
<mlankhorst> it's not going to be supported afaict
<bryceh> ok
<mlankhorst> so it's not that big a deal
<bryceh> we'll need to document it where appropriate, but guess we can consider that good enough
<bryceh> ok, next item was copying nouveau ddx
<bryceh> I think that's fine.  anyone got concerns there?
<mlankhorst> well the support for that is in debian now, will still require 3.4 kernel
<tjaalton> but fine for quantal?
<RAOF> And fine for the LTS backports, too; that's exactly why we depend on the lts kernel backport :)
<bryceh> mlankhorst, does current nouveau ddx *require* 3.4, or just that you don't get the latest functionality unless running 3.4?
<mlankhorst> bryceh: some fermi changes landed that will disable accel for fermi unless you have 3.4
<bryceh> ok so yeah, quantal and ppas which depend on the lts kernel backport.  guess that means not in x-updates ppa though
<mlankhorst> about that, what should be my focus atm? I've been helping airlied with his hybrid work on the nouveau side
<tjaalton> that's fine
<RAOF> That seems valuable to me
<mlankhorst> mostly on the nvidiaside because i know it better :)
<bryceh> yeah, also bug reports filed against precise
<tjaalton> about the backports; maybe drop -backport from the name to follow the kernel name
<bryceh> tjaalton, might wait and see what vanhoof finds out for name suggestions, but  yeah
<RAOF> Has the nomenclature for those packages stabilised?
<tjaalton> mlankhorst: there were some nouveau bugs filed against libdrm that I moved to -nouveau, so if you have some time to take a look that would be great
<tjaalton> bryceh: right
<bryceh> RAOF, I think the kernel team JFDI'd
<tjaalton> -lts-quantal
<tjaalton> is what it has now
<mlankhorst> but hybrid graphics will require at least 3.5
<mlankhorst> maybe 3.6 depending on synch support
<tjaalton> we'll have it
<tjaalton> 3.5-rc1 is already being prepared
<bryceh> ok, so next topic is hybrid gfx
<tjaalton> and hybrid is still ways off :)
<RAOF> We might not have 3.6 :)
<tjaalton> oops
<tjaalton> xserver master now has the api groundwork for the new functionality
<bryceh> mlankhorst, I gather this is the main topic you wanted to see discussion on?
<tjaalton> and airlied sent an email commenting on the 1.13 release schedule and what he might want to see happening this cycle
<mlankhorst> indeed :)
<tjaalton> so, probably not all of it but output slaves (hotplug usb etc) and dri2 offload
<mlankhorst> tjaalton: Yeah I was helping airlied a bit by writing some tests for behavior, showing how nvidia hardware worked and help understand problem a bit later
<mlankhorst> and even fix a firmware bug
<RAOF> My email is being slow; was there a tentative date for 1.13?
<mlankhorst> september-ish
<tjaalton> yeah
<tjaalton> early sep
<tjaalton> 4th
<mlankhorst> but maybe the patches for synching could be cherry picked
<mlankhorst> if it happens not to land in 3.5, it might not be that big depending on what intel hw supports
<tjaalton> yeah cherry-picking is possible, at least if we know what to cherry-pick early on
<RAOF> Or we could feed that request to the kernel team; is 3.6 still looking possible, given appropriate motivation?
<mlankhorst> the specific changes will be small though
<tjaalton> that decision is made mid-august or so?
<mlankhorst> so maybe I should rest a bit on coding on the hybrid stuff for now and only influence the decisions about it still being made
<mlankhorst> the synching will probably be done inside the kernel only
<tjaalton> whatever is the latest is what's best for intel anyway.. has been the case for a long time
<RAOF> I'm sure haswell will work *swimmingly* with 3.5! :)
<mlankhorst> in any case I think apart from input to the linaro guys about this dmabuf stuff
<mlankhorst> that there's not much more I can do here atm
<tjaalton> RAOF: ! :)
<bryceh> mlankhorst, could be, yeah
<bryceh> mlankhorst, do you have hybrid hw?
<mlankhorst> bryceh: just one laptop atm :)
<bryceh> mlankhorst, if not then yeah probably backburner it for time being and just follow discussion
<mlankhorst> but speaking of which I had to ask you about hardware so if you have some that looks interesting and maybe some radeon as well :)
<bryceh> I don't think hybrid is **so** important that it'd warrant doing a franken-drm for it
<mlankhorst> well we should be able to turn it off the proper way at least with the 1.13 changes
<tjaalton> there's not much left in the drm left aiui
<tjaalton> uh
<mlankhorst> i mean, turn off graphics card like raof's
<RAOF> Not much *more* to do in the drm :)
<tjaalton> that
<bryceh> mlankhorst, what I tend to do is have a few PC boxes and random assortment of cards to mix and match.  Especially for nvidia/radeon testing that's what I'd suggest
<mlankhorst> RAOF: Yeah the patches will probably be small though
<mlankhorst> especially since nouveau already has synch code in place
<bryceh> you can get a variety of low end video cards pretty cheaply; for most testing purposes those will be adequate, then once and a while pick up a high end card just for fun
<mlankhorst> bryceh: true, but what about radeon+intel hybrid?
<RAOF> Right. So, likely to be either cherrypickable, or another motivation to use 3.6.
<bryceh> mlankhorst, for that you'll need a laptop, and requisitioning one from pete is probably the least hassly way to do it
<tjaalton> mlankhorst: tseliot should have those, and RAOF has one too I believe
<RAOF> mlankhorst: I'm not sure if the BIOSes support it, but you should be able to do radeon+intel hybrid on a desktop, too?
<mlankhorst> if we can get the synch changes in, it would be nice to have
<mlankhorst> RAOF: All the ones I have seemed to always disable intel. :/
<bryceh> mlankhorst, magic words seem to be "I'm interested in broken hybrid graphics laptops that I can work on fixing"  ;-)
<mlankhorst> hehehhe
<bryceh> mlankhorst, at uds we talked about the feasibility of replicating a hybrid box via a PC with onboard video + pci-e card, and sounded like it might be another thing to try out at least for some testing purposes
<mlankhorst> bryceh: yeah but it seems the card just disappears atm, if i had a less buggy bios.
<bryceh> mlankhorst, so, write up a request to send to pete.  I can proof-read it for you ahead of time if you'd like.
<mlankhorst> sure
<bryceh> mlankhorst, ok anything else on hybrid?
<mlankhorst> nope, next topic?
<bryceh> SNA!
<bryceh> snaaaah snaaaah
<bryceh> RAOF, feel like switching it on now?
<mlankhorst> oh that's needed for hybrid btw
<tjaalton> is upstream enabling it soon?
<bryceh> of course
<mlankhorst> because of Y-major tiling
<RAOF> sna's needed for hybrid?
<bryceh> tjaalton, I think it is already switched on by debian and we're forcing it off
 * bryceh doublechecks
<RAOF> Only in experimental.
 * RAOF merged 2.19 in last week. Or Monday. Or something.
<tjaalton> right
<mlankhorst> RAOF: Probably going to be because of the blitter being braindead and sna actually using the 3d hardware for it
<bryceh>   * No SNA for unstable, it's too fast of a moving target for now.
<tjaalton> yeah I remember airlied mentioning that
<RAOF> The last thing I heard about sna from !ickle was airlied talking about corruption that a fellow RHer was seeing when they tried it.
<tjaalton> he's not going to fix uxa :)
<RAOF> And ickle saying ?yeah, you need at least the very latest everything or I don't care?
<tjaalton> hehe
<tjaalton> "typical"
<bryceh> *sigh*
<bryceh> anyway, I would like to propose we switch it on now and kick the tires on it and make a decision prior to alpha-2
<RAOF> So we could turn it on, and if we need it for hybrid and we *want* hybrid (which I think we do), then we should do so now and ensure we hit as many problems as early as possible.
<mlankhorst> oh btw for nouveau ddx i want to ask darktama first, after that it could probably be copied from experimental
<bryceh> if nothing else we can do the bug-forwarding-to-intel dance for a bit
<tjaalton> not until quantal has 3.5-rc1 though? :)
<bryceh> and by we I mean me :-/
<tjaalton> or any 3.5-rc
<mlankhorst> rc1? optimistic
<tjaalton> no i mean turning sna on
<bryceh> tjaalton, why?
<mlankhorst> oh sure
<tjaalton> bryceh: it's closer to upstream than 3.4
<bryceh> tjaalton, ah you mean for bug forwarding?
<mlankhorst> by the way no guarantee hybrid will be complete this cycle, if not definitely for next though :)
<tjaalton> bryceh: yeah
<mlankhorst> Fortunately the synch changes are kernel only
<tjaalton> mlankhorst: right, but we might get some of the features
<bryceh> tjaalton, *shrug* they always want us to have the user test against -drm-intel-next-experimental-not-yet-maybe anyway
<bryceh> so don't think waiting for 3.5-rc to hit is going to matter much
<tjaalton> well, turn it on only after _some_ initial testing on quantal? :)
<bryceh> tjaalton, so maybe switch it on in edgers for a week and see if anyone cries uncle first?
<tjaalton> sounds good. Sarvatt?
<mlankhorst> lgmt
<mlankhorst> lgtm*
<tjaalton> lgtm?
<tjaalton> ah
<mlankhorst> looks good to me
<tjaalton> <- n00b
<RAOF> I'll give it a bash on my systems, too.
<bryceh> same
<bryceh> RAOF, you want the task of turning it on or shall I?
<tjaalton> i'm still running precise, because of all the bugs
<tjaalton> in precise :)
<RAOF> bryceh: I'll turn it on.
<bryceh> ok sounds good
<bryceh> next topic... speaking of bugs in precise...  8.0.3?
<tjaalton> yeah, Sarvatt pushed the merge to git
<bryceh> last time we talked about it, thinking was we could maybe get the whole thing through SRU?  do we want to try that?
<tjaalton> sure, but it needs to get in quantal first, after alpha1
<bryceh> was thinking if we did piglit runs on precise with and without it, and showed no regressions, it would help
<RAOF> That would indeed help.
<bryceh> I've got systems set up for doing piglit runs on the various drivers, so can take that part of the task
<tjaalton> then maybe a meta-bug with the commit diff explained in detail, in order to dispel fears that it might look too scary
<tjaalton> (damn wifi resetting all the time)
<mlankhorst> i thought the release team hated meta bugs?
<tjaalton> sure they do
<bryceh> they do hate unexplained diff bits more though :-)
<tjaalton> but since there are no other bugs to use..
<RAOF> There are *no* existing launchpad bugs fixed by 8.0.3?
<mlankhorst> speaking of which can we SRU synaptics soon?
<bryceh> although based on past experience I tend to have low grokkage of mesa changelogs.  would someone else be able to write that part up?
<tjaalton> RAOF: probably yes, but don't think there are _verified_ bugs
<bryceh> tjaalton, is what sarvatt put in git good to go?  Could I slap it in a ppa and expect it to build?
<RAOF> I would probably be able to do the metabug part, but I'm not sure if I'm the best person to do that.
<bryceh> if so, I could spam likely looking bugs to test it.
<RAOF> That sounds like a winner.
<tjaalton> bryceh: it builds
<mlankhorst> It didn't crash when I logged in to desktop
<mlankhorst> (I didn't say anything about misrenders)
<tjaalton> RAOF: heh, being on the sru team
<bryceh> RAOF, in the sense that you'd be the reviewer?
<RAOF> mlankhorst: That's not *quite* the level of testing we're hoping for on SRUs :)
<mlankhorst> RAOF: if you do it right you can do that with synaptics currently
<mlankhorst> :D
<bryceh> RAOF, in which case maybe it'd be better to have you write the meta bug and another SRU reviewer do the review?
<RAOF> bryceh: That would work.
<bryceh> RAOF, effectively giving the whole a double SRU review :-)
<RAOF> For added freshness!
<bryceh> okie doke, sounds like a plan
<bryceh> last topic, a few patches I noticed that need some actions
<bryceh> https://bugs.launchpad.net/~ubuntu-x-swat/+patches
<bryceh> #993427 - fglrx breakage with the kernel
<mlankhorst> oh do we care about vdpau? It's just going to excarbate the flash problem..
<bryceh> basically needs tseliot to look at that one.  I would do it myself but I'm not sure how we're doing git packaging stuff for fglrx now.  anyone clue me in?
<tjaalton> no idea
<tjaalton> it's on github maybe
<bryceh> mlankhorst, bug #1002224 suggests we do care
<ubottu> Launchpad bug 1002224 in mesa (Ubuntu) "Please include gallium vdpau and xvmc driver support" [Wishlist,Triaged] https://launchpad.net/bugs/1002224
<RAOF> nvidia & fglrx was on github last time I touched it.
<mlankhorst> bryceh: I mean, I understand vdpau and xvmc, and it's not that big of a win without hardware acceleration
<bryceh> mlankhorst, I +1'd it, and it looks good to me for sponsoring it, but wanted to run it by everyone else for sanity checking?
<tjaalton> should we drop patch 610206 as silly?
<tjaalton> i mean close bug 610206
<ubottu> Launchpad bug 610206 in xorg-server (Ubuntu) "Build in input drivers for speed" [Wishlist,Triaged] https://launchpad.net/bugs/610206
<bryceh> tjaalton, yeah go for it
<bryceh> RAOF, is tseliot cool with just having stuff pushed there, or does he actually want to review everything first?
<RAOF> I think we should, yes.
<mlankhorst> bryceh: I mean, it's not going to benefit anything yet. :/
<RAOF> bryceh: I proposed a merge when I touched it, that seemed to work well.
<bryceh> mlankhorst, ah.  is there risks for having it turned on?
<RAOF> mlankhorst: Doesn't r300/r600 have shader-based acceleration for at least some of vdpau?
<bryceh> RAOF, ok thanks, I'll give that a try
<mlankhorst> RAOF: for mpeg2.. in which case your cpu is fast enough to do everything
<RAOF> Heh. Of course!
<mlankhorst> and the bitstream processing is still done on software
<RAOF> I don't object to vdpau being turned on, though. If it breaks something it's simple to turn off.
<mlankhorst> i guess it could be turned on on the simple fact nvidia is even buggier because it's using overlays
<RAOF> Although obviously it should be wrapped by VAAPI 
<RAOF> ?
<mlankhorst> RAOF: va-api is insane :P
<bryceh> maybe this would be another one to switch on post alpha-1 and evaluate pre alpha-2?
<RAOF> Yup.
<bryceh> alrighty
<RAOF> Also should see if Debian's interested.
<bryceh> RAOF, do you mean aside from the discussion on the linked bug?
<bryceh> ok, last patch question, bug #996250 - it's a security issue but marked low priority.  Should we be taking action on that, or will the security team handle it?
<ubottu> Launchpad bug 996250 in xorg-server (Ubuntu Quantal) "input device names used in logging format strings" [Low,Confirmed] https://launchpad.net/bugs/996250
<bryceh> kees, ^^
<mlankhorst> oh hey could anyone look at that other security bug btw
<tjaalton> oh, speaking of mesa. I'd like it to only build the 32bit libosmesa. would speed up the build quite a bit, and besides debian and us no other distro is building 8 & 16bit libs as well..
<tjaalton> maybe this was discussed already at some point
<RAOF> Ah, missed that.
<RAOF> In other mesa cleaning - is there any reason at all to build libgl1-mesa-swx11?
<tjaalton> no
<mlankhorst> to prevent apt-get install .*quantal with renamed stack from building
<mlankhorst> :-)
<mlankhorst> working*
<bryceh> mlankhorst, haha
<RAOF> Ok. I'm happy to drop < 32bit osmesa, and swx11; tjaalton, have you discussed with debian-x at all?
<bryceh> so yeah, maybe another thing to drop post alpha1 and evaluate before alpha2?
<tjaalton> RAOF: yes, a bit. I'll propose these two but they could be post-wheezy material anyway
<RAOF> To experimental!
<tjaalton> yeah
<RAOF> Yeah, what with the incoming freeze and all.
<RAOF> We can drop them sooner; post-A1 seems fine.
<tjaalton> right
<tjaalton> i have a branch that reworks the osmesa builds
<mlankhorst> will the swx11 be a transitional package that depends on proper gl please?
<tjaalton> from last fall, did some build benchmarking
<tjaalton> mlankhorst: why would that be needed? proper gl gets installed anyway
<RAOF> Does dropping the package entirely make -lts-quantal harder?
<tjaalton> s/gets/is/
<mlankhorst> maybe
<mlankhorst> i never tried with swx11 so i cant say with 100% certainty, but wouldn't surprise me.
<bryceh> shall we give it a go anyway, and make that part of the pre-alpha2 eval?
<mlankhorst> sure
<bryceh> guessing it'll become pretty evident if it makes -lts-quantal harder
<tjaalton> libgl1-mesa-swx11 has one non-mesa rdepends
<mlankhorst> i could always add the rules to the proper gl in that case
<bryceh> alright.  I'll draft up the tasks from all the above into the blueprint for us.
<mlankhorst> pyglet..
<tjaalton> and python-pyglet has 'libgl | libgl1-mesa-swx11'
<bryceh> ok, any other topics?
<tjaalton> *libgl1
<tjaalton> uh, so python-pyglet needs fixing
<tjaalton> hum no
<mlankhorst> tjaalton: not necessarily for backport quantal at least
<RAOF> Everything that we care about Provides: libgl1, though.
<mlankhorst> since it's not using versioned provides
<tjaalton> libgl1-mesa-glx provides libgl1
<mlankhorst> tjaalton: right so for backports ill just let it provide libgl1-mesa-swx11 and replaces too
<tjaalton> bryceh: well, I've been going through the intel hang bugs, since I moved on to using the ivybridge machine a few weeks ago, and current precise is not working too well with it
<tjaalton> mlankhorst: replaces is needed only if it replaces files
<tjaalton> and there are no other reverse deps so meh :)
<mlankhorst> like libGL1
<bryceh> tjaalton, ok
<mlankhorst> that's the whole reason we need them
<tjaalton> anyway.. the merge window for the next precise kernel update closes late next week
<tjaalton> so there are still some days to find and verify backportable fixes to drm
<bryceh> tjaalton, what are your thoughts on the ivy bridge freezes?
<tjaalton> but I'm only looking at i915
<tjaalton> bryceh: works with 3.4, buggy with 3.3.6, haven't tried 3.3.7 which someone said would fix the rest. but mesa 8.0.3 might help as well
<mlankhorst> is there anything else on the agenda?
<tjaalton> impossible to tell since it's a hard freeze and I get no data out of it
<mlankhorst> else I'd really like to get some sleep now :)
<bryceh> mlankhorst, no other items after gpu freezes, unless anyone else has anything?
<bryceh> tjaalton, can you ssh in while its frozen?
<bryceh> tjaalton, https://wiki.ubuntu.com/X/Debugging/WirelessWithoutX, or ethernet
<tjaalton> bryceh: no, it's completely dead
<RAOF> I think I was seeing that hard-freeze, too.
<bryceh> tjaalton, so maybe more than just drm falling over?
<bryceh> netconsole?
<tjaalton> it had other freezes where you could chvt and restart X, which really didn't work out that well. but those are now fixed by the -proposed kernel and mesa update
<tjaalton> I'll test some combinations first before going too deep :)
<bryceh> sounds good
<tjaalton> I could reproduce some of the bugs on my snb laptop too
<tjaalton> so should be able to verify the proposed fixes too
<bryceh> sounds good.  I stopped looking at gpu lockups after the release, although I know there were still some that never got figured out.
<bryceh> I've had a few freezes on my own intel boxes since the release, but nothing I could reproduce
<bryceh> ok, let's wrap the meeting up.  mlankhorst go get some sleep :-)
<tjaalton> there's one verified fix, one that I can repro, and one that still needs the reporter to check
<tjaalton> hmm i should probably get afk as well
<mlankhorst> night :)
<tjaalton> zzz ->
<RAOF> To the showers!
<bryceh> new WI's â https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-xorg-general
<RAOF> Ok. SNA is not *totally* crackful.
<RAOF> Just a little bit.
<RAOF> Oh, ARSE. Did I really run ?git clean? without having committed those files to git?
<RAOF> Dej? D?p to the rescue!
#ubuntu-x 2012-06-07
<bryceh> RAOF, why do I see my â but not your smart quotes or Ã¡/Ã /Ãº/Ã¹ ?
<RAOF> I don't know. I don't see your ???s, either.
<bryceh> RAOF, to me you are full of ?'s
<bryceh> hum
<RAOF> ?!
<bryceh> â½
<bryceh> Â¿
<bryceh> Â¡
<bryceh> RAOF, I want my â¬ back :-)
<RAOF> ?
<bryceh> RAOF, what keyboard layout do you use?
<RAOF> en(dvorak)
<Azelphur> ÊÉÉq â¬ s!á¡ sÊuÉÊ Óá¡
<Azelphur> RAOF: that's interesting, I use en(colemak)
<RAOF> It's most likely to be encoding related.
<RAOF> Also likely: that my smuix-server hasn't got the right encoding set :)
<bryceh> RAOF, http://www.bryceharrington.org/files/xchat_raof_q.png
<RAOF> That's likely my fault.
<bryceh> RAOF, aha yeah could be filtering things out
<Azelphur> I see exactly the same as bryceh in pidgin
<RAOF> Let me restart stuff...
<bryceh> Azelphur, thanks
<Azelphur> hehe :)
<bryceh> minutes posted
<bryceh> betting is now open for how long until a summary + something rude appears on phoronix.
<RAOF> bryceh: Does this shÃ³w Ã¼p Ã§Ãµrrectlyâ¢?
<Azelphur> does for me
<bryceh> yes!
<bryceh> <RAOF> bryceh: Does this shÃ³w Ã¼p Ã§Ãµrrectlyâ¢?
<RAOF> Also roundtrips correctly
<bryceh> yay
<Sarvatt> SNA is actually selectable in xorg.conf now and is still breaking daily, i'll turn it on by default and put a note about how to go back to uxa for people that want to actually use intel in tomorrow's upload
<Sarvatt> sorry I missed the meeting earlier, didn't know it was happening!
<RAOF> Sarvatt: !!! It was in ubuntu-x@, and we've talked about it a couple of times here :)
<RAOF> Sarvatt: SNA on 2.19 seems to be *reasonably* usable here.
<RAOF> (Says the gen7 user)
<Sarvatt> yeah 2.19 is good, it gets fixed up decently just before releases :)
<RAOF> Apart from some missing rendering.
<Sarvatt> ubuntu-x posts get lost in the hundreds of ubuntu-x-swat mails that come in, need to fix my darn filter rules it
<bryceh> Sarvatt, :-(  what mail client?
<bryceh> Sarvatt, as in, got procmail?
<Sarvatt> gmail, i just had it set up stupid
<Sarvatt> i got it all fixed up now, wont miss the next one!
<bryceh> :-)
<bryceh> Sarvatt, I posted a summary to ubuntu-x and ubuntu-desktop, feel free to reply with any feedback you have
<hyperair> Sarvatt: SNA is selectable in xorg.conf?
<Sarvatt> hyperair: as of sometime last week yeah
<Sarvatt> hyperair: except you need to enable SNA then make UXA the default via configure flags and I haven't made that change in edgers yet, but i just made a hook so tomorrow's update will support it
<Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=e45629135065d0cc73c285f8df35ab4e1d07c6dc
<Sarvatt> guess its time to package up glamor too
<RAOF> Does anyone have any objections to moving to xserver 1.12 post A1? It'll make system-compositoring easier, as xwayland's based on 1.12.
<Sarvatt> none at all here, i'd like to do it just in case 1.13 doesn't pan out actually
<bryceh> RAOF, since we have some other things planned to switch with A1, maybe give a week or so beforehand, so we have a gap to isolate bugs against?
<hyperair> Sarvatt: i see. i haven't been using edgers recently though.
<bryceh> I don't feel super strongly about that though, so if you're anxious to get it in immediately post-A1, I'm amenable
<hyperair> glamor sounds interesting. =p
<RAOF> but still slower than UXA :)
<RAOF> bryceh: I can wait a bit, but it'll make it much easier for robert_ancell to start on the lightdm work if it's easy to get at.
<bryceh> well we've not seen very much in terms of bug reports up til now, and based on history I really don't expect to see much feedback until after A2.
<bryceh> RAOF, so, use your judgment.  If there's definite value plugging it in right after A1, go for it.
<RAOF> Actually, doing all the work and dumping it in a PPA would be just as useful to me. Uploading to quantal-proposed and then copying to quantal can be done at leisure, then.
<tjaalton> no objections to 1.12
<mlankhorst> morning
<mlankhorst> RAOF: No objections here :)
<tjaalton> i'm fed up with apport not being able to collect the relevat info when asked to do so
<tjaalton> relevant too
<seb128> tjaalton, like?
<mlankhorst> I should give my trees names, 3 trees called linux aren't helping matters much :)
<tjaalton> seb128: like on bug 1008864
<ubottu> Launchpad bug 1008864 in software-center (Ubuntu) "software center crashes when clicking pay apps" [High,Triaged] https://launchpad.net/bugs/1008864
<seb128> tjaalton, what info did it fail to collect?
<tjaalton> seb128: whatever ubuntu-bug xorg would collect
<tjaalton> a lot of stuff
<seb128> tjaalton, the bug was reported against s-c not xorg
<seb128> why would it collect xorg infos?
<tjaalton> uh, right. so no way to force it to collec the right one
<tjaalton> it has xorg component opened too
<tjaalton> at least it's some hybrid setup with nvidia, so probably just a nouveau bug
<tjaalton> anyway, that was a bad example, there have been other bugs too like that :)
<tjaalton> would be nice if apport-collect could allow a package argument in addition to the bugnum
<seb128> tjaalton, apport-collect -p xorg ?
<tjaalton> seb128: the manpage at least has no such thing
<seb128> tjaalton, apport-collect --help is what I used
<tjaalton> sigh, the manpage should be updated then
<mlankhorst> then launchpad died underneath me, sigh :P
<seb128> tjaalton, patches are welcome I guess
<seb128> mlankhorst, they do inline update, that's usally around 10am and for a minute or so
<mlankhorst> ah k
<mlankhorst> yep you're righ,t, back up
<tjaalton> seb128: just filed a bug for now
<seb128> tjaalton, k
<tjaalton> seb128: thanks for pointing that out though, wonder how many times it would've been helpful in the past to know that :)
<mlankhorst> tjaalton: oh hey can I get a patch in kernel 3.4? Upstream commit a6a17859f1bdf607650ee055101f54c5f207762b
<tjaalton> mlankhorst: quantal will have 3.5 soon anywa?
<tjaalton> +y
<tjaalton> don't think they'll even do 3.4 uploads anymore
<tjaalton> would this be good for 3.2 too?
<tjaalton> sounds like it would
<mlankhorst> tjaalton: was a regression in 3.4 i think
<tjaalton> ah
<mlankhorst> so many changes between 3.2 and 3.3 i dont know what fixed it for nouveau
<mlankhorst> I'm guessing those 3 for v3.2: 6322175530c89ab719cea28202f96a3660491727, c8435362f2211086b34ce871fa9c3fcc7ca79ff9, a6a17859f1bdf607650ee055101f54c5f207762b
<tjaalton> if you have fixes for nouveau that'd be great
<mlankhorst> I could pick those to v3.2 and see
<tjaalton> the first one is quite old, but not in 3.2?
<tjaalton> doesn't look like it
<tjaalton> https://wiki.ubuntu.com/KernelTeam/KernelUpdates
<tjaalton> and
<tjaalton> https://wiki.ubuntu.com/Kernel/Dev/StablePatchFormat
<tjaalton> the procedure for getting fixes in
<mlankhorst> thanks
<tjaalton> might be easier to get them via v3.2-stable
<mlankhorst> true
<tjaalton> you can see what's been proposed already http://git.kernel.org/?p=linux/kernel/git/bwh/linux-3.2.y-queue.git;a=summary
<tjaalton> hah http://git.kernel.org/?p=linux/kernel/git/bwh/linux-3.2.y-queue.git;a=commitdiff;h=443b53442f77382a0de81d58154ec2187a21279a#patch10'
<tjaalton> that's going to help a lot
<jcristau> i sent that in after bugs.debian.org/675022
<tjaalton> ah, ok
<mlankhorst> tjaalton: Yeah I'll try upstream first. :-)
<tjaalton> mlankhorst: if you have bug refs that would make it easier to get accepted, i guess
<tjaalton> and after that, it's a walk in the park getting pulled in precise :)
<tjaalton> without all the paperwork
<mlankhorst> We'll see, I never had to refer someone else's patches for stable though.
<mlankhorst> if this works i might try to get some other nouveau fixes through -stable too
<tjaalton> hmm, disabling fbc should be possible to get in the current -proposed kernel
<tjaalton> it's a oneliner and no fear of regressions..
<mlankhorst> like all one liners
<tjaalton> hehe
<tjaalton> s/fear/end/
<mlankhorst> :D
<mlankhorst> I think after another exa patch gets in I'll probably push the ddx
<seb128> tjaalton, I'm unsure if apport-collect look at the launchpad package or the Package: in the reported bug, but you get at least an Xorg.0.log.old which shows an intel Xorg segfault in the bug you pointed earlier
<tjaalton> seb128: ah, fun
<Azelphur> So, who wants to play ridiculous / borderline insane x.org config? I'm trying to set up 4 monitors, 2 screens, one on GTX 570 nvidia proprietary, one on AMD 5870 (Radeon)
<Azelphur> http://collabedit.com/pqyaj is what I have so far, the nvidia stuff works, but the AMD stuff isn't doing so well
<Azelphur> it's only pulling up one monitor, and compiz/xfce don't start properly :(
<mlankhorst> Azelphur: You'll have more luck to pull that off with nouveau
<Azelphur> I could start off with nouveau, but I like playing games under wine and nouveau doesn't do too well at that
<mlankhorst> I mean nvidia makes you unable to use other drivers at the same time
<Azelphur> oh wow, that's annoying
<Azelphur> but then how is the radeon even up, the radeon is up and has one display running
<Azelphur> just not very well
<mlankhorst> any gl to it will probably fail
<Azelphur> yep, that's pretty much what I'm getting
<Azelphur> compiz is just falling over and dieing
<mlankhorst> :-)
<Azelphur> ok so I'll try with nouveau :)
<mlankhorst> I'm guessing ati card was using r600?
<Azelphur> I dunnod
<Azelphur> haha, changed nvidia to nouveau now I have ATI up (mirrored) and no nvidia
<Azelphur> or is the driver name for nouveau nv?
<mlankhorst> erm no, nv should die off. :p
<Azelphur> ah :)
<mlankhorst> is the nouveau module loadedÂ¿
<Azelphur> in lsmod? nope :(
<mlankhorst> probably have to reboot after removing nvidia
<Azelphur> used jockey to remove the nvidia driver and rebooting now :)
<mlankhorst> brb
<Azelphur> still the same, mirrors on the AMD and nothing on nvidia, http://pastebin.com/kNHMiqcz is my xorg.conf atm
<Azelphur> oh hey but opengl stopped failing
<tjaalton> a great way to gpu-hang ivybridge; open the session menu from lightdm login screen...
<tjaalton> no need to open either, just hovering over the icon is enough
<tjaalton> fixed in 3.4 at least
<tjaalton> 3.3.7 too
<tjaalton> but it's slow to navigate the menu.. laggy as hell
<tjaalton> db099c8f963fe656108e0a068274c5580a17f69b drm/i915: gen7: work around a system hang on IVB
<tjaalton> why yes
<cnd> mlankhorst, it looks like you forgot to push the changes to the synaptics ubuntu branch when you uploaded the last release to quantal
<cnd> let me see if I can figure out how to sync
<cnd> looks like the only change was the bump from UNRELEASED to quantal
<cnd> mlankhorst, ok, I fixed it up :)
<cnd> nm
<mlankhorst> cnd: I don't have push rights, so wasn't me :)
<cnd> oh?
<cnd> it says you're the committer
<mlankhorst> I mean i did the branch, but I didn't upload
<cnd> ok
<cnd> I see
<cnd> who uploaded it?
<Azelphur> mlankhorst, so, I've got radeon up with opengl, but the nvidias arn't coming up, and the radeon is just in mirror mode
<seb128> cnd, Signed-By: Bryce Harrington
<seb128> cnd, from the -changes email
<mlankhorst> Azelphur: nouveau module loaded to kernel at least?
<cnd> right
<Azelphur> mlankhorst, doesn't show up in lsmod, but Xorg.0.log says it loaded it
<cnd> well, it wasn't difficult to sync this time at least :)
<cnd> I've left things in worse states before
<mlankhorst> Azelphur: grep -r blacklist.*nouveau /etc/modprobe.d
<Azelphur> /etc/modprobe.d/nvidia-current_hybrid.conf:blacklist nouveau
<Azelphur> /etc/modprobe.d/nvidia-current_hybrid.conf:blacklist lbm-nouveau
<mlankhorst> remove that file, then restart
<Azelphur> both of them?
<mlankhorst> it's one file
<Azelphur> oh yea, silly me I just realised that
<Azelphur> rebooting now \o/
<Azelphur> progress :D
<Azelphur> both cards are now mirroring
<mlankhorst> so just have fun with xrandr now
<Azelphur> nice, can i make xrandr settings perm somehow?
<bryceh> Azelphur, either in xorg.conf or .gnomerc or the like
<Azelphur> fun
<mlankhorst> personally i stuff it in krandrrc but that's for kde only
<Azelphur> hehe
<Azelphur> https://dl.dropbox.com/u/3832397/Photos/2012/June/IMG_20120607_181951.jpg
<Azelphur> I think I broke it :(
<tjaalton> '5d031e5b633 drm/i915: Remove use of the autoreported ringbuffer HEAD position' fixed the lightdm menu hang
<mlankhorst> bryceh/raof: i still have to see if i can get some upload rights this cycle, is it possible I help out with the X 1.12 upload?
<bryceh> mlankhorst, don't worry about rushing to get upload rights this cycle; there's plenty of us who can do uploads for you.  but most of the work is getting packages ready for upload, as you've been doing
<mlankhorst> bryceh: ok so I'll just continue on that and maybe put up a ppa?
<bryceh> mlankhorst, yep that's a great idea
<mlankhorst> perfect have something to work on tomorrow then :)
<bryceh> mlankhorst, if you get bored, there are plenty of bugs that need looked at, or if you'd rather look at code, you could go through the proposed patches and give your opinion - https://bugs.launchpad.net/~ubuntu-x-swat/+patches
<mlankhorst> bryceh: I'll probably just enable vdpau for the ppa so I can verify mplayer won't break at least
<mlankhorst> bryceh: but when I get bored I sometimes just spend some more time on nouveau vdpau for fun, I'm trying to get some patches for nouveau in linux stable. :)
<bryceh> there are also a lot of bugs needing triaged
<bryceh> in fact I'm wondering if we ought to switch to a team model for triaging (i.e. everyone spend N hrs / week triaging)
<mlankhorst> bryceh: Problem is that sadly a whole lot of bugs are hardware specific :(
<jcristau> a whole lot of bugs are probably pebcak
<bryceh> mlankhorst, triage != fix
<bryceh> jcristau, extraordinarily true
<mlankhorst> pebcak?
<bryceh> 50% of bugs reported to X aren't X bugs
<jcristau> mlankhorst: user doing something wrong.
<mlankhorst> jcristau: or user wants to uninstall nvidia :-)
<bryceh> another quarter are inane junk like not knowing how to configure things
<mlankhorst> I'm so tempted to write something that tests it
<mlankhorst> load glxinfo -> results sane? load glxinfo32 -> results sane?
<mlankhorst> grep blacklist.*nouveau /etc/modprobe.d/*
<mlankhorst> etc
<bryceh> then there's 24% which may be legitimate bugs but the user hasn't reported them properly.  So we have to coach them through some debugging
<mlankhorst> and the 1% that's so insane but with a hint of truth that you can't help but wonder what's going on in their minds? ;)
<bryceh> mlankhorst, if you dummy up a script, I may be able to transliterate that into our apport hook to run during bug reporting.
<mlankhorst> bryceh: the problem is getting glxinfo and glxinfo32 at the same time
<mlankhorst> but I spend some time in #nouveau figuring out bugs, sometimes it helps figuring out bugs filed against nouveau early. :)
<tjaalton> sweet, fbc disabled for snb in precise master-next
<tjaalton> that was quick
<bdmurray> bryceh: can you provide some insight regarding bug 924909?
<ubottu> Launchpad bug 924909 in ubiquity (Ubuntu) "Windows have grey traces in Ubiquity" [Medium,Confirmed] https://launchpad.net/bugs/924909
<bryceh> bdmurray, only occurs through VM?
<bdmurray> bryceh: looks like hardware to me
<bryceh> bdmurray, I would guess cjwatson's right that it's a window manager compositing issue.
<bryceh> bdmurray, are all the commenters using metacity's compositing functionality?
<bdmurray> bryceh: yes they are either at the try screen or did choose install ubuntu so not a full desktop
<bryceh> bdmurray, so metacity compositor update bug probably.
<bdmurray> bryceh: so a metacity task then?
<bryceh> I'd seen something similar with remote desktop not repainting a while back with compositing enabled, but that affected the whole screen not just the background
<bryceh> bdmurray, yup
<bryceh> bdmurray, well, make sure to confirm they're all running metacity as the window manager.  I *think* that's what xfce uses but am not 100% certain.
<jcristau> xfce uses xfwm
<jcristau> metacity was gnome2
<bryceh> bdmurray, there you go.
<bdmurray> what does composting get you if you are just installing anyway?
<jcristau> trouble, probably
<bryceh> heh
#ubuntu-x 2012-06-08
<tjaalton> uptime over 12h with that single fix on top of precise next, niice
<mlankhorst> RAOF: Shall I just create a xorg 1.12 ppa in xorg-edgers for quantal first?
<tjaalton> what for?
<mlankhorst> I have no rights to upload to quantal so I need to make a ppa :)
<tjaalton> there are ppa's already
<RAOF> So that he can (a) upload to it, and (b) we can stage stuff there for a week or so to let mesa et al settle down.
<tjaalton> why not use the same ppa as last time?
<RAOF> Yeah, use the one from last time :)
<tjaalton> -staging or such
<tjaalton> can't remember, didn't touch it <whistle>
<tjaalton> funny how much of 3.3 drm is in 3.2.x
<mlankhorst> seems to be dead
<mlankhorst> https://launchpad.net/~ubuntu-x-swat/+archive/x-staging ?
<tjaalton> it was used for getting the packages ready, then binary copied to the main archive
<mlankhorst> should i empty it and resurrect it?
<tjaalton> feel free i guess
<mlankhorst> ok :)
<RAOF> You don't even need to empty it; everything in it is lower than the version in quantal, and we'll be replacing everything in it with a new version anyway.
<tjaalton> note that ppa's can have packages for multiple releases, so uploading quantal ones would live next to the old ones, but there's no need for the precise packages anymore since the main archive has moved on
<tjaalton> well, the precise builds would remain there if not cleaned
<tjaalton> but yeah they wouldn't interfere in any way
<mlankhorst> i know
<mlankhorst> RAOF: is there some easy way to trigger a rebuild of all the various packages that may need updating due to new abi?
<mlankhorst> oh seems the rebuild driver does what I want :-)
<tjaalton> hm?
<mlankhorst> rebuild-all-drivers.sh
<tjaalton> ah
<mlankhorst> but looks like I can skip the input drivers
<tjaalton> yes
<tjaalton> mlankhorst: hum, you've changed upstream-ubuntu?
<tjaalton> on xorg-server
<tjaalton> it was used on precise because of the frankenserver
<tjaalton> but normally we don't need that
<mlankhorst> tjaalton: ok, I just synched it with debian, I guess you're right :-)
<tjaalton> actually, might want to reset that to the previous state so that cnd can backport input fixes from 1.12.2 ;)
<mlankhorst> ..?
<tjaalton> that's what it had, 1.11 + input from 1.12
<mlankhorst> tjaalton: wasn't that branched off to precise already?
<tjaalton> oh it's not the same branch
<tjaalton> upstream-1.11+input
<tjaalton> sorry
<tjaalton> carry on
<tjaalton> :)
<mlankhorst> tjaalton: hm looks like the script is based on old version, I'll probably be fine by just rebuilding everything
<tjaalton> mlankhorst: just make sure it appends 'build1' to the debian version if there are no ubuntu changes
<tjaalton> so -1 -> -1build1, -1ubuntu1 -> -1ubuntu2
<mlankhorst> dch --rebuild will do that?
<tjaalton> not a huge deal, but allows autosyncs
<tjaalton> dunno
<mlankhorst> ill try
<tjaalton> ah, looks like it
<mlankhorst>        sed -i -r "s/xserver-xorg-dev([[:space:]]*\(>=? 2:1(\.[[:digit:]]*)*([~+]git[[:digit:]]*(\.(.){8})?)?~?(-[[:digit:]]+(ubuntu[[:digit:]]+)?~?)?\))?/xserver-xorg-dev (>= $1)/g" debian/control
<tjaalton> ..ok
<mlankhorst> I felt the same way :-)
<jcristau> ouch.
<mlankhorst> yeah looks like I'll have to grab a whole bunch of packages from debian unstable :/
<tjaalton> yep, since you can't sync them to a ppa, which would be too easy
<mlankhorst> i can abuse syncpackage it seems
<tjaalton> ah
<mlankhorst> I'll see if more fail first, seems a lot will build at least :)
<mlankhorst> 1.13 otoh
<tjaalton> apart from openchrome and vmware they're all fixed already :)
<tjaalton> and those just need the fixes committed
<mlankhorst> I mean, it will need dri2proto, randrproto xrandr/libXrandr, + a refresh of all video drivers
<jcristau> openchrome in sid is broken with 1.12 still
<jcristau> i think that's the last one
<tjaalton> oh
<mlankhorst> oh hey, why aren't we having modesetting in our list?
<tjaalton> it's not published yet
<jcristau> i do need to sponsor that into debian don't i?
<tjaalton> yep :)
<mlankhorst> jcristau: Please do :-)
<mlankhorst> I could package though
<tjaalton> it's packaged
<tjaalton> in git
<mlankhorst> ah^^
<mlankhorst> but yeah I probably get to update all the fun things to 1.13
<jcristau> didn't have so much time or motivation the last few weeks...
<tjaalton> mlankhorst: don't worry about it.. usually we'll push the devel series to -experimental and sync from there
<mlankhorst> tjaalton: I know :)
<tjaalton> though it means that jcristau/kibi would need to upload them :)
<tjaalton> my AM has now been silent for two weeks
<jcristau> ha
<jcristau> was going to say "or you can finish NM"
<jcristau> :)
<tjaalton> yeah..
<tjaalton> reading through license gibberish was hard, so took a while to reply to the first set of questions 
<mlankhorst> would be so much easier if ubuntu synced x from unstable
<tjaalton> it does?
<tjaalton> normally
<tjaalton> but what difference does it make when we manually sync the packages anyway
<jcristau> tjaalton: after a couple weeks you can probably ping him to ask what's up
 * mlankhorst lacking the capability, mostly
<tjaalton> jcristau: yeah, maybe I could
<jcristau> looks like he uploaded a package on tuesday so he's around
<mlankhorst> plus even if i had the capability I wouldn't trust myself to do it yet..
<tjaalton> ok I pinged gwolf
<mlankhorst> tjaalton: oh the failing packages have a ubuntu version, I'll fix -ati
<tjaalton> mlankhorst: yeah you can merge from debian and push the updated one there
<tjaalton> there=ppa
<tjaalton> there are probably others. intel got updated though
<mlankhorst> I think it had some small changes
<mlankhorst> it prevents install from debian/radeon-kms.conf which adds 'options modeset=1' to radeon
<tjaalton> yeah, kms is enabled already
<jcristau> we can drop that change in debian post wheezy
<mlankhorst> tjaalton: can we just synch to debian for now? :-)
<mlankhorst> having that file would probably be a noop
<jcristau> (it's necessary with squeeze's kernel so we keep it for upgrades)
<tjaalton> mlankhorst: -ati from debian? nah, keep that change
<mlankhorst> ok
<mlankhorst> then I'll just merge
<mlankhorst> +# Plymouth wants libdrm-intel1, even on architectures where it's guaranteed
<mlankhorst> +# to be useless.  Satisfy it's depraved yearnings.
<mlankhorst> :D
<mlankhorst> +      + Add patch series to reenable building libdrm-intel1 on !i386/amd64,
<mlankhorst> +        (drop when plymouth is updated to 0.8.4.)
<mlankhorst> +
<mlankhorst> does that mean it could be dropped now?
<jcristau> yep, should
<mlankhorst> I'll check plymouth first just in case
 * mlankhorst doesn't trust 'should'
<mlankhorst> yeah it adds a disable for it, so libdrm has to be uploaded from unstable again
<mlankhorst> https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/1010460 :D
<ubottu> Launchpad bug 1010460 in libdrm (Ubuntu) "Sync libdrm 2.4.33-1 (main) from Debian unstable (main)" [Undecided,New]
<mlankhorst> just had to try requestsynch to see what would happen
<tjaalton> synced :)
<mlankhorst> hehe ty
<mlankhorst> tjaalton: can xserver-xorg-video-rendition be synched too?
<jcristau> oh yay kibi just fixed openchrome
#ubuntu-x 2012-06-09
<scientes> does the alpha have the new nouveau driver?
<scientes> (sub-drver i guess)
<scientes> for the nv40 class of cards
<scientes> **nv30, mesa driver
<scientes> the 2d stuff is working fine, but nvidia prob broken, and i've been waiting for the new nouveau driver
<bjsnider> why do you think nvidia is broken?
<scientes> *propietary---1 sec
<bjsnider> i know what you're referring to, i just would like to know why you think it's broken
<scientes> https://bugs.launchpad.net/nvidia-drivers-ubuntu/+bug/964275
<ubottu> Launchpad bug 964275 in gnome-shell (Ubuntu) "gnome-shell crashed with SIGSEGV in cogl_texture_set_region_from_bitmap_EXP()" [Medium,Confirmed]
<scientes> nothing 3d works if i install nvidia
<scientes> which was a regression during precise near the end of the cycle, after beta 2
<bjsnider> gnome-shell works fine in precise on nvidia
<scientes> not with this card
<bjsnider> there was a regression on old hardware
<scientes> and many others have this card
<scientes> and while "old' its not THAT old
<scientes> and its nv30, which is why i ask about the new nouveau driver
<scientes> bjsnider, yes i know the problem is in the driver
<scientes> its just that is the way the crash handler does its blaming
<bjsnider> if you say so, sir
<scientes> or rather that, gnome-shell works on some hardware still
<bjsnider> works great here, but i've got a fermi card
<scientes> since wine 3d broke at exACTLY the same time, as did unity-3d, etc............
<scientes> oh , looks like new version finially got uploaded to xorg-edgers i might install and reboot and see how it goes
<scientes> running unit-2d atm
<scientes> w/ nouveau--no point in nvidia w/o 3d
<scientes>                             
<scientes> Get:23 http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu/ precise/main linux-libc-dev amd64 3.4.0-3.7 [930 kB]     
<scientes> wow, why does xorg-edgers need to ship linux-libc-dev?
<scientes> oh-cause it against newer (back compat) kernels
#ubuntu-x 2012-06-10
<scotty^> Hi all.
<scotty^> Will the xserver-xorg-video-ati package in Quantal be updated soon to one based on at least 6.14.4, and preferably 6.14.5?
<scotty^> This will allow for testing of AMD "Trinity" APU's.
#ubuntu-x 2013-06-03
<mlankhorst> morning
<tjaalton> yo
<tjaalton> hum, gtk-window-decorator died, doesn't bother that much really :)
<mlankhorst> always fun!
 * mlankhorst is having fun with the nvd7 on nouveau
<mlankhorst> genuine fun this time
<tseliot> is it fun or pain? ;)
<mlankhorst> bit of both
<mlankhorst> ah there we go, almost there now!
<mlankhorst> [   12.294846] nouveau  [     PFB][0000:01:00.0] RAM type: DDR3
<mlankhorst> [   12.294849] nouveau  [     PFB][0000:01:00.0] RAM size: 2048 MiB
<tseliot> nice
<mlankhorst> and a simple nouveau fifo test worked, I'm slowly getting there
<mlankhorst> using glxgears is an instant lockup ;)
<tseliot> mlankhorst: software or hardware rendering?
<mlankhorst> tseliot: hardware rendering, the 3d setup stuff is slightly different, I think I'll push what I have now.
<mlankhorst> it's a bunch of hardcoded writes to certain registers
<tseliot> it sounds like fun ;)
<mlankhorst> if you miss 1 reg the card probably locks up in some difficult way, but you can copy them from a mmiotrace
<tseliot> yes, it's all about reverse engineering
<mlankhorst> that's the only hard part, the rest appears to work afaict
<tseliot> sweet, we have a wiki page about it: https://wiki.ubuntu.com/X/MMIOTracing
<tseliot> I had no idea
<mlankhorst> ddx needed some fixes to work without a display, mesa appears to work without any changes
<mlankhorst> so the remaining change is fixup a bunch of opaque writes, and then pray glxgears works :)
<mlankhorst> tseliot: http://people.freedesktop.org/~mlankhorst/mmiotrace-nvidia.sh for the lazy people like me
<tseliot> mlankhorst: that's nice
<Sarvatt> Dandel: fixing up piglit now (hopefully)
<Sarvatt> just need to test this to be sure it works, http://paste.ubuntu.com/5729697/
<Dandel> Sarvatt, that should be enough... the only other bit would be to make sure that starting and resuming tests are working from the user home directory.
<Sarvatt> Dandel: holy crap, the packaging got totally screwed up in all these months since its been auto building
<Sarvatt> /usr/tests/ ? seriously? :P
<mlankhorst> wow
<Sarvatt> got it fixed up but that was a mess
<Sarvatt> it installed 2 copies of all the tests too
<mlankhorst> autopkgtest for xorg-integration-tests is evil too :P
<Dandel> Sarvatt, it's also missing opencl tests on precise.
<Dandel> nvidia and amd/ati drivers support opencl ICD's
#ubuntu-x 2013-06-06
<seb128> hey xorg guys
<seb128> is that a known issue with -intel on saucy?
<seb128> http://paste.ubuntu.com/5738268/
<seb128> #9  <signal handler called>
<seb128> #10 region_subsumes_damage (damage=0x0, region=0xbf87b824)
<seb128>     at ../../../src/sna/sna.h:569
<seb128> #11 sna_drawable_use_bo (drawable=drawable@entry=0xb850d320, 
<seb128> abort of xorg
<seb128> seems to happen when starting software-center
<seb128> it happens here and didrocks confirmed it
<seb128> tjaalton, mlankhorst: ^
<tjaalton> I'll try
<tjaalton> doesn't crash when using nvidia optimus too
<tjaalton> I'll try just -intel
<seb128> it doesn't happen every time
<seb128> but I just got it twice in 5 minutes of playing in test sessions
<seb128> and didrocks got it on first try
<tjaalton> meh, stupid SDP... fails to boot (uefi) after powering it down post-installation
<tjaalton> ok another machine then..
<mlankhorst> hm
<mlankhorst> seb128: valgrind it? :>
<tjaalton> ..which has no working touchpad or wifi.. so can't upgrade it to current saucy without reinstalling it :P
<seb128> mlankhorst, how do I do this? valgrind X :1 from a vt?
<tjaalton> intel driver it has is the same as on raring, saucy has .7
<seb128> tjaalton, I can try downgrading the driver if that helps
<tjaalton> seb128: yeah that would help confirming it's the ddx at fault
<mlankhorst> I'm trying to run nouveau in real optimus mode, I keep hitting funny bugs atm. Most of the nouveau ddx expects that a display is attached for some reason :-)
<tjaalton> I know there's some regression with 2.21.8 which is fixed upstream
<tjaalton> but we don't have that
<mlankhorst> seb128: install xserver.*dbg, libdrm.*dbg, valgrind
<mlankhorst> then see https://bugs.freedesktop.org/show_bug.cgi?id=56578#c54 for how to start a normal lightdm session
<ubottu> Freedesktop bug 56578 in Server/Input/Core "race condition with active/passive grabs when opening menus with touch" [Normal,Assigned]
<tjaalton> ickle confirmed it's fixed upstream
<seb128> tjaalton, seems to not happen with .6
<tjaalton> lp:1186573
<mlankhorst> ok
<tjaalton> we'll have 2.21.9 in a few hours :)
<mlankhorst> I'll upload that to saucy
<tjaalton> .9?
<tjaalton> not released yet
<seb128> tjaalton, is there any version I can try?
<mlankhorst> few hours :
<tjaalton> seb128: not yet
<jcristau> well
<jcristau> you could try git
<tjaalton> right
<tjaalton> but no package
<mlankhorst> ugh backlight is off
<seb128> tjaalton, any commit I can try to backport?
<tjaalton> checking
<tjaalton> maybe c4ad7b14ca71b95
<seb128> tjaalton, http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=c4ad7b14ca71b95af83864b05793ea357f48bb88 ?
<tjaalton> seb128: yep
<tjaalton> mlankhorst: do you have the bug graphs somewhere yet+
<tjaalton> ?
<mlankhorst> no it doesn't work yet for some reason, I don't know why
<mlankhorst> you have some clickable links but there is no plot
<mlankhorst> http://people.canonical.com/~mlankhorst/arsenal/ubuntu-x-swat/Reports/totals-saucy.svg
<mlankhorst> hm maybe it does work after all
<tjaalton> graph looks fine apart from the scaling :)
<tjaalton> on x-axis
<mlankhorst> yeah
<mlankhorst> I thought it wasn't working, guess i was wrong
<tjaalton> and doesn't show the bug count
<mlankhorst> grrrr I'm hitting some random memory corruption >:(
<tjaalton> pulling the hsw pci-id fixes for libdrm
<mlankhorst> yay
<mlankhorst> optimus mode nouveau working, I think
<mlankhorst> yeah
<mlankhorst> $ nfs/glxspheres 
<mlankhorst> Polygons in scene: 62464
<mlankhorst> Visual ID of window: 0x1cb
<mlankhorst> Context is Direct
<mlankhorst> OpenGL Renderer: Gallium 0.4 on NVD7
<mlankhorst> 81.425963 frames/sec - 90.871375 Mpixels/sec
<jcristau> oh, look, a 2.21.9
<jcristau> :)
<tjaalton> finally :)
<mlankhorst> race you to it!
<tjaalton> haha
<mlankhorst> jcristau: now just enable sna for intel, and we can copy from debian next time :-)
<tjaalton> oh you really started merging it
<tjaalton> just make sure to close all the bugs, like 1175533 :)
<mlankhorst> kk
<tjaalton> and 1188123
<tjaalton> and we probably need to add the mesa revert back
<jcristau> mlankhorst: or we can get your key into the dm keyring and you do it yourself
<jcristau> (queue evil laugh)
<mlankhorst> that seems to be going slowly atm, nobody replied to my mail :P
<mlankhorst> tjaalton: any others?
<tjaalton> also, remove test/tearing.mp4 :)
<mlankhorst> yeah
<tjaalton> well I think lp:1186573 could just be duped to the newer bug
<tjaalton> the saucy queue at least is empty after those
<mlankhorst> ah good
<tjaalton> wait, that guy filed the same bug three times
<tjaalton> -> duping
<tjaalton> done, those two should be enough for now
<tjaalton> since .7 is what added the regressions, saucy only
<mlankhorst> ok I'll do a quick test build locally, then upload to saucy
<tjaalton> k
<tjaalton> seb128: ^
<seb128> tjaalton, great ;-)
<tjaalton> mlankhorst: well, -intel did have support for haswell, but this one added new pci-id's ;)
<tjaalton> and the other bug# is too short :)
<mlankhorst> ugh :P
<mlankhorst> ah yeah indeed
<mlankhorst> my room is reaching insane temperatures
<mlankhorst> -> break
<tjaalton> only 27C here
<tjaalton> eod->
<tjaalton> 32C on the terrace, let's see..
<mlankhorst> worst part was that the bug # did look too short, but on visual verification it looked fine, it's definitely too warm for me to think straight now :-)
<mlankhorst> I bet it's warmer in my room
<tjaalton> it's getting cooler here
<bjsnider> it's so cool here the furnace would be running if we hadn't turned it off
<bjsnider> this is supposed to be summer
<tjaalton> hehe
<tjaalton> so I'm told
<mlankhorst> ah no wonder
<mlankhorst> if i put the thermometer on my curtains it reaches 38Â°c and higher
<mlankhorst> and it's radiating that onto me, no wonder i always feel warm working
<tjaalton> yep, you need proper shades
<mlankhorst> indeed, or a different working room :-)
<tjaalton> that could work
<bjsnider> a/c?
<tjaalton> typical, just throw new tech at the problem ;)
<mlankhorst> a/c? do you want me to catch a cold >:O
<tjaalton> an awning blind would be cheaper to operate
<tjaalton> awling
<tjaalton> hum, both are the same
<mlankhorst> I can just tilt the window, put water on top and have water cooling :-)
<tjaalton> now I'm blind
<mdeslaur> does anybody have any hardware that uses the openchrome driver?
<mlankhorst> i don't even know what that hardware would look like
<jcristau> it'd look like a motherboard
<Sarvatt> mlankhorst: absolute crappiest/cheapest athlon xp motherboards you could buy at the time  :P
<mlankhorst> haha
<mdeslaur> so that would be a no I guess? :)
<jcristau> testing security fixes is overrated anyway
 * jcristau hides
<mdeslaur> haha
<mdeslaur> testing security fixes for hardware nobody uses is overrated :)
<jcristau> though i think raphael has openchrome hw and tested the packages before we shipped
 * mdeslaur looks at powerpc
<Sarvatt> thought i might have had one in the box of old boards but its SIS, ah well
<mdeslaur> I'll just mail a $10 to whoever reports a regression so they can buy a better computer
<jcristau> fwiw i didn't hear anything
<jcristau> after the first libxvmc screwup
<mdeslaur> jcristau: ok, thanks
#ubuntu-x 2013-06-07
<tjaalton> hrm, need to revert moar stuff to make blur nice and quick again
<tjaalton> there
<mlankhorst> ok, can you upload to raring too? :-)
<tjaalton> sure
<ricotz> tjaalton, hi :)
<ricotz> tjaalton, be aware mesa needs an rebuild agains the new wayland package layout, but the synced wayland package doesnt have sufficient breaks against the old libwayland0
<tjaalton> ricotz: laney fixed that
<tjaalton> and mesa already got uploaded, ftbfs due to llvm
<ricotz> tjaalton, alright :)
#ubuntu-x 2013-06-09
<maxiaojun> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1066599
<ubottu> Launchpad bug 1066599 in mesa (Ubuntu) "Wine is unable to detect OSMesa correctly when compiling from source" [Undecided,Confirmed]
<maxiaojun> i guess this bug is related to the way we compile Mesa? i still get this bug even on Saucy
<mlankhorst> fwiw, wine1.5 seems to work with libosmesa :/
<mlankhorst> $ strings /usr/lib/i386-linux-gnu/wine/gdi32.dll.so |grep -i osmesa
<mlankhorst> libOSMesa.so.6
#ubuntu-x 2014-06-05
<work_alkisg> linux-generic-lts-trusty is available, when are we going to see xserver-xorg-lts-trusty in the repositories?
<mlankhorst> already there..
<mlankhorst> alkisg: enable -proposed
<alkisg> mlankhorst: thanks, so I'm guessing in a few days it'll become available outside -proposed... cool
#ubuntu-x 2015-06-01
<furkan> tjaalton: on Ubuntu 15.04 i'm still having major problems with changing my desktop resolution
<furkan> with both displays connected, when i change my screen resolution the desktop just turns black with only the mouse cursor visible
<furkan> and it doesn't recover until i switch to a VT and restart lightdm
<tjaalton> file a bug
<tjaalton> try newer kernels
<tjaalton> bisect if fixed
<furkan> not a kernel issue, i've tried older and newer
<furkan> i've also tried older and newer ddx
<furkan> and mesa
<furkan> i think that only leaves xorg and lightdm
<tjaalton> lightdm has nothing to do with it
<tjaalton> 04:52 < MrCooper> it's more likely a driver issue than an xserver issue
<tjaalton> missed that one?
<tjaalton> file a bug on bugs.freedesktop.org
<furkan> driver doesn't seem to make a difference
<tjaalton> uh
<tjaalton> meaning it's not fixed yet
<tjaalton> the driver is in kernel
<tjaalton> that does modesetting
<tjaalton> anyway, I'm off
<furkan> tjaalton: issue isn't present in 14.04 though (i have a separate partition set up) so it seems like a regression
<tjaalton> nothing new
<tjaalton> things happen
<tjaalton> file a bug
<furkan> oh i'm not throwing blame anywhere, just looking for a way to narrow down what caused it
<tjaalton> probably not finding it here I'm afraid :/
<furkan> np, i'll file one on freedesktop and see if they have suggestions for debugging
<furkan> i figure there's more  of a chance it'll get fixed if i do some debugging work, but i just don't know what to try
<tjaalton> they'll know more
<furkan> tjaalton: crazy as it may sound, it just occured to me to log out of unity, log in with xfce, and turns out i can change my desktop resolution without issue
<furkan> does that indicate that it could be an issue with unity, or still a driver problem?
<furkan> with unity, this is the error i get in Xorg.log, after changing the resolution: http://pastebin.com/ZW6akHf9
<furkan> didn't notice it before, as it takes some time to come up
<tjaalton> trying to run it non-root?
<tjaalton> sounds like you broke it
<furkan> non-root?
<furkan> can't remember changing that
<furkan> root      5926  7.2  0.8 654248 131936 tty7    Ssl+ 15:33   2:54 /usr/bin/X -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
<furkan> seems to me like it's running as root?
<tjaalton> seems so
<tjaalton> try #radeon then
<furkan> alright, i'll also make sure i can reproduce it from a live USB to make sure i didn't break anything..
#ubuntu-x 2016-06-06
<tseliot> mamarley, ricotz: change of plans, we need to revert the change for snaps in the nvidia packages
<mamarley> tseliot: Already done. :)
<tseliot> mamarley: great :)
<mamarley> (For the PPA packages, anyway.)  I reverted it as soon as the reports of X not starting came in.
<tseliot> yes, they're going with a better solution that shouldn't cause LP: #1589006
<ubottu> Launchpad bug 1589006 in snapd (Ubuntu) "Failed unmounting Mount unit for nvidia support in snappy" [Critical,In progress] https://launchpad.net/bugs/1589006
<mamarley> tseliot: What is the new solution?  I don't see anything about it in that bug.
<tseliot> mamarley: "mvo: we just discussed the bind mount of libgl in our snappy standup and we would like to revert the bind mount unit again, sorry for the trouble, but the issues that croped up are too servere and we will use a different strategy (bind mount in the launcher in a private mount namespace to isolate all of this from the real system)"
<mamarley> OK, so something that doesn't involve the NVIDIA package at all.
<tseliot> yes, and that's the way I like it :P
 * mamarley too :)
<mamarley> To be honest, I had a bad feeling about that patch anyway.
<ricotz> mamarley, note, next time when introducing pre/post/inst/rm changes let them sit for a while before porting to other series
<ricotz> ;)
<mamarley> I had already decided that :)
<ricotz> this really created mayhem for some users
<mamarley> I have given a detailed explanation of how to correct the problem for everyone who has asked.
<ricotz> even Mark shouldn't demand it to be fixed without real testing ;P
<ricotz> mamarley, thanks for that, just noticed another message on the list
<mamarley> I also think maybe there should be an argument for dpkg that causes it to ignore errors in prerm/postrm scripts.
<ricotz> absolutely not, those script should have been tested more careful
<ricotz> or have it swallow errors with || true
<mamarley> Anyway, I will definitely wait for the -proposed testing to be done before applying non-critical patches like that in the future.
<ricotz> +1
#ubuntu-x 2016-06-10
<givello> Hey there, I'm having an issue updating the nvidia driver using the graphics driver ppa
<givello> Here is the output of apt-get 
<givello> https://gist.github.com/LMG/8c323e0a7a2999b8cffcb76b56cdf772#file-gistfile1-txt-L4
<jcastro> http://askubuntu.com/questions/783093/cannot-remove-nvidia-opencl-icd-367
<jcastro> I was able to find this
<givello> I did try that before I think, I'll re-read it carefully to make sure I didn't skip any steps but I'm sure stopping gdm didn't do anything
<givello> I even tried starting in the mode where only apt runs, forgot the name
<jcastro> sudo touch /lib/systemd/system/var-lib-snapd-lib-gl.mount && sudo systemctl daemon-reload before attempting to repeat the upgrade. After the upgrade is complete, run sudo touch /lib/systemd/system/var-lib-snapd-lib-gl.mount to clean up.
<givello> ... Yep just saw that when re-reading it
<givello> I must have been tired
<givello> Thanks for the help :)
<givello> well, I'll try to reboot in 367 now. Here's hoping I don't have to come back ! 
<givello> Cheers
<ogra_> he should also make sure to have snapd 2.0.7, that has the fix for the mountpoint issue
<ogra_> (or bigger than 2.0.7)
<ogra_> oh ... 
 * ogra_ just notices that that hasnt made it out of proposed yet
#ubuntu-x 2017-06-07
<soee> mamarley: nvidida driver works with kernel 4.12 ?
<mamarley> soee: I haven't tried.  I don't normally try the RC kernel until at least RC5 or RC6 or so.
<soee> i think i will try :)
#ubuntu-x 2017-06-08
<alkisg> Hi, I'm getting this crash [http://termbin.com/jkzj] on this CPU [Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz]
<alkisg> Running Ubuntu MATE 16.04.2 fully updated. Can I try some newer version of some of the involved components, to see if it's solved there?
<tjaalton> yes, ppa:canonical-x/x-staging
<alkisg> tjaalton: thank you; I'll add that and just apt-get update
<tjaalton> yup
<soee> nvidia driver works with kernel 4.12 rc4
<mamarley> soee: The 381 series?
<soee> mamarley: yes
<mamarley> soee: Awesome, thanks for testing. :)
<soee> mamarley: np :)
#ubuntu-x 2017-06-09
<Sarvatt|2> err why does my bouncer I haven't been on in months still have a canonical cloak.. gotta fix that.
#ubuntu-x 2017-06-10
<mamarley> soee: I have just uploaded a new Vulkan development driver, 381.26.03, to my staging PPA if you are interested. :)
<mamarley> It works fine on my laptop but fails to read the EDID of the second monitor on my desktop, causing it to operate at 1024x768 instead of 3840x2160.
<soee> mamarley: this is driver that only supports Vlukan ?
<soee> what are the differences from normal driver ?
<mamarley> soee: It supports a new version of Vulkan, but it seems to still do everything else 381.22 does as well.  Beyond the new Vulkan support, there doesn't seem to be a changelog.
<soee> mamarley: right but does it do anything more than normal driver for us users ?
<mamarley> No idea; they didn't provide a changelog.
<mamarley> Obviously there are other changes than just the Vulkan stuff otherwise my second monitor wouldn't have stopped working correctly.
#ubuntu-x 2018-06-05
<mamarley> ricotz: 390.67 is out.  I can handle it.
<mamarley> ricotz: All done: https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages
<ricotz> mamarley, thanks
#ubuntu-x 2018-06-09
<tomreyn> this looks rather old, do you still support this repository for 16.04 (the text states you do): https://launchpad.net/~xorg-edgers/+archive/ubuntu/ppa?field.series_filter=xenial
<tomreyn> one person in #ubuntu were asking about how to get newer nouveau on 16.04)
<tjaalton> tomreyn: ricotz isn't here atm
<tomreyn> good morning, ricotz. do you still provide updates on this PPA for 16.04? https://launchpad.net/~xorg-edgers/+archive/ubuntu/ppa?field.series_filter=xenial - some of these packages seem a little aged.
<tomreyn> (but maybe that's how it should be since 16.04 is, too? i could not really tell.)
<ricotz> tomreyn, hi, there were some glvnd decisions I was waiting for, so there will be updates again
<ricotz> official mesa 18.0.5 backports are already available iirc
<tomreyn> not on this repository for xenial, but maybe elsewhere?
<tomreyn> thanks for the heads up.
<tomreyn> i meant to say 'thanks for your reply and the info you provided' there ;-).
#ubuntu-x 2020-06-04
<alkisg> Hi guys. Many schools report black screen with ryzen-based computers, on 18.04 with either xorg or xorg-hwe, but only on i386.
<tjaalton> best to try #radeon
<alkisg> (pidgin crash). Example system: 38:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] [1002:15dd] (rev c8)
<alkisg>         Subsystem: Hewlett-Packard Company Vega [Radeon Vega 8 Mobile] [103c:8434]        Kernel modules: amdgpu
<alkisg> Unfortunately I have no access to any of those schools, as we're buying intels in all nearby schools
<alkisg> So I'm at a loss on what to do, leave it unreported as I can't give feedback, or somehow ping someone that has such a system to test...
<alkisg> I waited for 3-4 months in case I had access somewhere, but... no :/
<alkisg> Thank you tjaalton, I'll try on #radeon
<tjaalton> though it sounds like you have a solution already.. ;)
<alkisg> To ditch 32bit? Fortunately we got new PCs, so from September, 90% of the schools will be on 20.04 64bit, yey!
<JanC> any Ryzen can't be old...
<alkisg> We use a system where all PCs get the same image, so if they have some pentium4's, then all images are 32 bit (its' called ltsp.org)
<JanC> might be useful if you could make the image depend on the hardware it seems...
<JanC> or make a dual boot image that detects the hardware & boots the right one...  ;)
