#ubuntu-x 2006-09-04
<Ubugtu> New bug: #58785 in linux-restricted-modules-2.6.17 "add lsb support for /etc/init.d/atieventsd" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58785
<Ubugtu> New bug: #58821 in xorg-server (main) "[edgy]  livecd (amd64) won't boot into graphical interface" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58821
<Mithrandir> hi rodarvus 
<rodarvus> hi Mithrandir!
<Mithrandir> https://launchpad.net/distros/ubuntu/+source/libxdmcp/+bug/55052 ; any thoughts on that?
<Ubugtu> Malone bug 55052 in libxdmcp "XdmcpWrap missing in current dapper version (1:1.0.0-0ubuntu2)" [Untriaged,Unconfirmed]  
<Mithrandir> I'm inclined to not backport it since it affects a very small number of our users
<rodarvus> agreed
<rodarvus> don't think we should even support anything xdmcp related actually :)
<Mithrandir> why not?
<rodarvus> I'm just babbling, don't worry :)
<fabbione> hmmm
<fabbione> why does he want * to be recompiled?
<Mithrandir> unsure
<fabbione> oh actually.. he might be right
<fabbione> the flag set something to true
<fabbione> and other stuff might be checking for that too to enable the feature
<Ubugtu> New bug: #58809 in xserver-xorg-video-ati (main) "tty doesn't work" [Untriaged,Needs info]  http://launchpad.net/bugs/58809
<Ubugtu> New bug: #58868 in xorg-server "x server dosent start" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58868
<Ubug2> New bug: #58872 in xorg "Mouse skips every few seconds" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58872
<fabbione> hmmm
<fabbione> something is not right with xinerama/randr
<Ubugtu> New bug: #58925 in xorg "Edgy Knot: Black screen with via driver" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58925
<Ubugtu> New bug: #58929 in xserver-xorg-video-i810 "3D driver claims to not support visual 0x5b" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58929
#ubuntu-x 2006-09-05
<Ubugtu> New bug: #59019 in linux-restricted-modules-2.6.17 "[EdgyEft]  the nvidia-glx package doesnt work" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59019
<Ubugtu> New bug: #59019 in linux-restricted-modules-2.6.17 "[EdgyEft]  the nvidia-glx package doesnt work" [Untriaged,Rejected]  http://launchpad.net/bugs/59019
<rodarvus> just for reference. I've sent mdz and Kamion UVF requests for Mesa and xserver-xorg-video-ati
<rodarvus> the mesa one is due to various fixes on i9x5 DRI support, while for ati, the UVF would mean stability for r200 and 3D stability for r300 boards
<rodarvus> partly related to that, I'll make uploads of xorg-server and a few drivers this week
<rodarvus> xorg-server will (likely) get two new patches for aiglx
<rodarvus> and the drivers (at least nv, i810, savage, via and vesa) will get various fixes
<rodarvus> xserver-xorg-video-amd_2.7.6.5~20060905-0ubuntu1 uploaded into NEW
<rodarvus> (this is the video driver used on the OLPC prototypes)
<rodarvus> xserver-xorg-input-vmmouse_12.4.0-0ubuntu1 uploaded as NEW
<Ubugtu> New bug: #59052 in xserver-xorg-video-sis "Blank screen on xorg initialization" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59052
<Ubugtu> New bug: #59055 in xserver-xorg-driver-ati "X windows fails to create new windows after hibernating (somtimes)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59055
#ubuntu-x 2006-09-06
<Mithrandir> I found the "Cannot open X input method" bug now.  Trivial to fix, really.
<Mithrandir> and it's a pain when Debian aren't pushing their fixes upstream.
<Mithrandir> 12:15 < Mithrandir> I found the "Cannot open X input method" bug now.  Trivial to fix, really.
<Mithrandir> 12:15 < Mithrandir> and it's a pain when Debian aren't pushing their fixes upstream.
<Mithrandir> rodarvus: ^^ FYI
<rodarvus> oh
<rodarvus> so it was fixed on debian, but not propagated?
<Mithrandir> yeah
<Mithrandir> it looks like it.
<Mithrandir> rodarvus: I'll do an upload of xorg-server with kdrive enabled, unless you protest.
<rodarvus> no, I was scheduled to do it Friday, please feel free to do it yourself :)
<rodarvus> by kdrive you mean Xephyr, right?
<rodarvus> (hmm, but friday would be after FF)
<rodarvus> dude, I need more hours on my days.
<Mithrandir> yes, Xephyr is the one I'd want.
<rodarvus> nice
<rodarvus> I'd like to have xserver-kdrive-i810, xserver-kdrive-sis,  ... etc, too, but its more work involved
<rodarvus> (don't worry doing them now, though)
<Mithrandir> there aren't i810 or sis kdrive servers, though?
<rodarvus> err, there are at least a full hand of them
<Mithrandir> hmm, true
<rodarvus> (let me check which ones)
<Mithrandir> : tfheen@thosu ..rg-server-1.1.1/hw/kdrive > ls
<Mithrandir> ati/    epson/  i810/    Makefile.am  neomagic/  r128/    smi/   via/
<Mithrandir> chips/  fake/   linux/   Makefile.in  nvidia/    sdl/     src/
<Mithrandir> ephyr/  fbdev/  mach64/  mga/         pm2/       sis300/  vesa/
<Mithrandir> at least
<Mithrandir> we can do those later, if we want ; Xephyr is the one people seem to be most interested in.
<rodarvus> ati chips epson (?) fake fbdev i810 mach64 mga neomagic nvidia pm2 (?) r128 sdl sis300 smi vesa and via
<rodarvus> I've tested Xi810 here, and it at least works :)
<rodarvus> (ie, boots)
<Ubugtu> New bug: #59209 in xorg-server "gnome-terminal transparency doesn't work in compiz/AIGLX" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59209
<Ubugtu> New bug: #59213 in xorg "No vmmouse package for VMware mouse device" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59213
<Ubugtu> New bug: #59220 in xkeyboard-config "Falsely claims it can be safely removed" [High,Confirmed]  http://launchpad.net/bugs/59220
#ubuntu-x 2006-09-07
<Ubugtu> New bug: #59278 in xorg-server "Edgy: X fails with "module requirement mismatch"" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59278
<Ubugtu> New bug: #59298 in xresprobe "xresprobe fails to detect some modes: ati radeon2 se + dell 2405FPW" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59298
<Ubug2> New bug: #59314 in xserver-xorg-video-ati (main) "Knot2 Desktop CD Blank Screen / Hangs" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59314
<Ubug2> New bug: #59349 in xorg (main) "Getting resolution 640x480@60Hz only" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59349
<Ubug2> New bug: #59383 in xserver-xorg-video-ati "Please put xserver-xorg-video-ati version 6.6.2 in Edgy" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59383
<Ubug2> New bug: #59402 in libxxf86vm "Cant't build against libxxf86vm-dev" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59402
<Ubugtu> New bug: #59417 in xkeyboard-config "Scroll lock does not work in X" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59417
#ubuntu-x 2006-09-08
<Ubugtu> New bug: #59421 in xserver-xorg-driver-i810 "After suspend/resume, rendering is a mess" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59421
<Ubugtu> New bug: #59433 in linux-restricted-modules-2.6.17 "breaks display" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59433
<Ubugtu> New bug: #59434 in linux-restricted-modules-2.6.17 "Restart and Shutdown don;'t work in Kubuntu" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59434
<Ubugtu> New bug: #59438 in linux-restricted-modules-2.6.17 "Root Window Does Not Redraw and Hard Lock w/ fglrx" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59438
<Ubugtu> New bug: #59476 in xkeyboard-config "xkb/symbols/inet: XF86AudioRaiseVolume is defined twice for Logitech keyboards" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59476
<Ubugtu> New bug: #59480 in xorg "Monitor resolution is only probed on boot" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59480
<Ubugtu> New bug: #59481 in xorg "OpenGL broken on many applications" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59481
<Ubugtu> New bug: #59522 in xserver-xorg-input-keyboard "X crashes if volume control moved on Logitech LX700 keyboard" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59522
<Ubugtu> New bug: #59526 in xorg "xorg update problem" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59526
<Ubugtu> New bug: #59539 in Ubuntu "Video playback colour is wrong" [Untriaged,Needs info]  http://launchpad.net/bugs/59539
<Ubugtu> New bug: #59572 in xkeyboard-config "German keymap has no way of typing low double quotation marks" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59572
#ubuntu-x 2006-09-09
<Ubugtu> New bug: #59598 in xorg "xorg.conf in user home directory erroneously read on boot" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59598
<Ubugtu> New bug: #59613 in xserver-xorg-input-mouse "No side scrool in Mighty mouse..." [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59613
<Ubugtu> New bug: #59656 in xserver-xorg-driver-i810 "Rendering borken on mz mom|s machine" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59656
<AnAnt> anyone here ?
#ubuntu-x 2006-09-10
<Ubugtu> New bug: #59752 in linux-restricted-modules-2.6.17 "Binary Nvidia driver does not allow optimal resolution on x86_64" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59752
<Ubugtu> New bug: #59770 in linux-restricted-modules-2.6.17 "apply the package fails" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59770
<Ubugtu> New bug: #59797 in xorg "libfx86config is missing in xorg-dev package" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59797
<Ubugtu> New bug: #58193 in linux-restricted-modules-2.6.17 "fglrx driver can't find AGP => disables DRI..." [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58193
#ubuntu-x 2007-09-03
<ubotu> New bug: #136881 in xterm (main) "resizing xterm creates junk text" [Undecided,New]  https://launchpad.net/bugs/136881
<ubotu> New bug: #83043 in xkeyboard-config (main) "my keyboard is missing caracters" [Undecided,Incomplete]  https://launchpad.net/bugs/83043
<Q-FUNK> hurray!
<Q-FUNK> we have a broken xserver-xgl, it seems
<tepsipakki> I thought it was broken by design :)
<Q-FUNK> heh
<Q-FUNK> well, it does realy weird things to the libgtk2 that was pushed at the end of last week.
<Q-FUNK> but I just noticed an even weirder bug:  remote X sessions via SSH forwarding no longer work.
<Q-FUNK> however, they work to my debian hosts.
<mvo> hey bryce! bulletproofX was covered on slashot (I'm sure you know that already) :)
<tepsipakki> yep, he posted the link here earlier
<ubotu> New bug: #72915 in mesa (main) "error loading libgl1-mesa-dri modules" [Undecided,Incomplete]  https://launchpad.net/bugs/72915
<Q-FUNK> for bug #136947
<ubotu> Launchpad bug 136947 in openssh "no longer honors X11 forwarding" [Undecided,New]  https://launchpad.net/bugs/136947
<Q-FUNK> could this be cause by an xauth version not matching the X core version?
<jcristau> non
<jcristau> bah, s/n$//
<Q-FUNK> ok
<Q-FUNK> any other idea what could cause this?
<jcristau> pebcak
<ubotu> New bug: #136958 in xserver-xorg-video-i810 (main) "After upgrade, moving or scrolling windows or playing videos, take 100% CPU" [Undecided,New]  https://launchpad.net/bugs/136958
<Q-FUNK> I don't see how.  the configuration hasn't changed.
<Q-FUNK> and connecting to other hosts works as expected.  only this Gutsy host fails and that happened sometimes during the weekend.
<ubotu> New bug: #136963 in xorg (main) "Gutsy Gibbon Tribe-5 broken vesa yet" [Undecided,New]  https://launchpad.net/bugs/136963
<tormod> bryce, are we getting xorg...12ubuntu4 in Tribe 6?
<tormod> or 12ubuntu3 at least?
<ubotu> New bug: #131462 in xorg-server (main) "Xorg crashed with SIGSEGV with enabling desktop effects" [Undecided,New]  https://launchpad.net/bugs/131462
<Q-FUNK> my guess is that he's still asleep for another 3 hours or so.
<ubotu> New bug: #136981 in xorg (main) "monitor detection causes xorg to crash" [Undecided,New]  https://launchpad.net/bugs/136981
<ubotu> New bug: #136982 in xserver-xorg-driver-i810 (main) "[gutsy]  xserver sluggish after upgrade " [Undecided,New]  https://launchpad.net/bugs/136982
<Q-FUNK> re
<ubotu> New bug: #136859 in xorg (main) "odd screen flashing and black screen upon session startup" [Undecided,New]  https://launchpad.net/bugs/136859
<bryce> tormod: I've put 12ubuntu3 in for upload with keescook
<tormod> bryce, good. I understand there will be no tribe6 release?
<bryce> after that I hope to get 12ubuntu4 in, but I also have a 12ubuntu5 in the wings, just one build issue to sort out
<bryce> it sounds unlikely
<bryce> I've not checked mail today, but friday there was talk of skipping it
<tormod> ok. gotta go.  cu later.
<bryce> tepsipakki: if you're around, I'd love to discuss if we want to up -ati to 6.7.x?
<Q-FUNK> bryce: we have a first regular upstream -amd release uploaded to debian, btw.  
<tepsipakki> bryce: sure, in 20min
<tepsipakki> ok, make that 40 :)
<tepsipakki> but I'm here now
<tepsipakki> ..for awhile
* bryce back
<bryce> tepsipakki: I haven't checked my email yet today, but I think we need to make a decision about if we're going to move to -ati 6.7.192 and if so, get it uploaded soonish
<bryce> soonish == in the next 2-3 days
<bryce> how do you feel about it?  From the testers I'm sensing sort of mixed but generally favorable results, esp. with the xserver backports
<tepsipakki> there hasn't been much happening upstream for the past couple of days, but I guess they need to rest too :)
<tepsipakki> so, I'm for it
<bryce> cool, do you want to handle the upload for it?
<tepsipakki> yes, I can do it
<bryce> cool
<bryce> btw, I'm still having one build issue with xserver
<tepsipakki> but I wonder if dexconf should be changed for ati (and intel?) because of randr-1.2 -goodness?
<bryce> make[4] : Entering directory `/tmp/buildd/xorg-server-1.3.0.0.dfsg/obj-i486-linux-gnu/GL/mesa/X'
<bryce> make[4] : *** No rule to make target `xf86glx.lo', needed by `libX.la'.  Stop.
<bryce> it seems patches 133-135 remove the files in that dir, but leave the makefile in place.  How did you solve this?
<bryce> tepsipakki: I can update dexconf; what changes are needed?
<tepsipakki> I didn't try to build it.. just made sure the patches applied
<bryce> ah
<bryce> fwiw there were a few more patches that turned up unnecessary as I started working through builds
<bryce> not sure why they even applied...
<tepsipakki> the Screen section, maybe the Modes shouldn't be listed there, but I'm not sure. They shouldn't do any harm, though
<tepsipakki> bryce: do you have the xserver somewhere? I could take a look tomorrow
<tepsipakki> still haven't looked at the patches list
<bryce> yeah I can copy over my current working dir, one sec
<tormod> bryce: re 6.7.192, I have a bad bug: https://bugs.freedesktop.org/show_bug.cgi?id=12245 (possible patch)
<ubotu> Freedesktop bug 12245 in Driver/Radeon "system freeze with hufo_tunnel and moving mouse" [Normal,New]  
<bryce> tepsipakki: http://bryceharrington.org/Ubuntu/
<tepsipakki> that's one hefty list of patches :)
<bryce> no kidding
<bryce> and there's still more
<bryce> but some we can drop too
<tepsipakki> I'll check out the situation in the morning and work from there
<bryce> I've not yet looked at the changes for 1.3.99.2
<bryce> I'll poke at it more through the day today as I have time; I sense this may be the last issue before it builds
<bryce> I think I just need to disable make in that dir
<bryce> that list of patches in /var/www/Ubuntu is deceptive - that's just all the patches from fedora.  I've already weeded out about half
<bryce> er, s/fedora/xorg 1.3.99/
<bryce> the fedora patches are in Fedora
<tepsipakki>  /var/www/Ubuntu?
<bryce> sorry...  http://bryceharrington.org/Ubuntu/
<tepsipakki> ah
<tepsipakki> anyway, I'll grab whatever you have there in 9h ;)
<bryce> cool
<tepsipakki> now bed, g'night ->
<bryce> night!
<ubotu> New bug: #137149 in xserver-xorg-video-intel (main) "intel driver uses less than 24 bits on the laptop LCD" [Undecided,New]  https://launchpad.net/bugs/137149
#ubuntu-x 2007-09-04
<ubotu> New bug: #95411 in ubuntu "ubuntu feisty beta, no screens found on macbook pro (dup-of: 89853)" [Undecided,Confirmed]  https://launchpad.net/bugs/95411
<tepsipakki> bryce: ok, I'll grab the xserver now
<ubotu> New bug: #135142 in linux-restricted-modules-2.6.22 (restricted) "[nvidia-glx]  Any glx application make X server crash when compiz is runing [Gutsy] [aiglx]  (dup-of: 130325)" [High,Invalid]  https://launchpad.net/bugs/135142
<ubotu> New bug: #137225 in xorg (main) "[gutsy]  [regression]  xorg crashes with segfault after having used displayconfig-gtk to set up a second display (new "intel" driver)" [Undecided,New]  https://launchpad.net/bugs/137225
<mvo_> has anyone here used the xserver-xorg-core-dbg package yet? and give me a quick intro how to use it so that gdb knows about the symbols :) ?
<ubotu> New bug: #137234 in xorg (main) "[gutsy]  Second display not enabled with "intel" video driver" [Undecided,New]  https://launchpad.net/bugs/137234
* mvo_ discovered that symbole-file seems to do the job
<tepsipakki> bryce: it still doesn't build, I get the same error with patch 399 ("*** No rule to make target `xf86glx.lo', needed by `libX.la'.  Stop.")
<jcristau> mvo_: gdb should find the symbols on its own
<ubotu> New bug: #110208 in gtk+2.0 (main) "Tomboy and Dvorak (dup-of: 23244)" [Low,Invalid]  https://launchpad.net/bugs/110208
<bryce> tepsipakki: yeah, that's the issue I'm still working on
<tepsipakki> bryce: here is the debdiff from the changes I made: http://users.tkk.fi/~tjaalton/dpkg/xserver/xserver.debdiff
<tepsipakki> disabled a bunch of fedora patches..
<bryce> ok thanks
<tepsipakki> hopefully the explanations make sense .)
<tepsipakki> :)
<tepsipakki> now telly ->
<bryce> tepsipakki: ok I've incorporated those changes
<mvo_> I'm hunting the nvidia+compiz+glx crash issue currently and have some more backtraces: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/130325/comments/34 now I wonder if this is somehow releated to the patches we appy to the xserver
<ubotu> Launchpad bug 130325 in xorg "[nvidia-glx-new]  glxgears, 3d apps crash X when using compiz-fusion (gutsy)" [Undecided,Confirmed]  
<mvo_> is there a "easy" way to build xserver-xorg-core wit only a minimal patch set? it seems like quite a few are required so that it builds at all
<bryce> hmm, I've not tried building a patch-less xserver yet
<bryce> mvo, fwiw, there is a 12ubuntu3 out just now
<bryce> I did not see any fixes in that which would address this issue, but several fixes are for low level things like linked list bounds in mesa, etc. which I could imagine might have an effect
<bryce> also, I am working on a 12ubuntu4 which will have much, much improved mesa support and a lot of fixes to help you with compiz stuff, that are cherrypicked from fedora
<bryce> I am hoping the 12ubuntu3 shows at least some improvements for you with compiz; I had an eye out especially for compiz-related fixes
<bryce> mvo, one issue with your backtraces is that it looks like you don't have debug symbols turned on
<jcristau> debug symbols for nvidia_drv.so? hahaha
<jcristau> :)
<bryce> ah, heh true
<bryce> ugh
<ubotu> New bug: #137331 in xserver-xorg-input-mouse (main) "X mouse cursor missing in Gutsy Tribe 5" [Undecided,New]  https://launchpad.net/bugs/137331
<mvo_> bryce: thanks! I will give ubuntu3 a go tomorrow and I'm happy to test ubuntu4 when its available. I have xserver-xorg-core-dbg installed, but it of course does not really help with nvidia :)
<ubotu> New bug: #119559 in compiz (main) "Totem screen where the video shows kind of acts wierd with desktop effects enabled (dup-of: 122979)" [Undecided,Confirmed]  https://launchpad.net/bugs/119559
<mvo_> bryce: I managed to contact one of their engeniers and send some debug information
<bryce> hopefully we'll hear a fix
<bryce> mvo, btw, did you and glatzor talk about doing a displayconfig-gtk release?
<mvo_> no, not yet
<jcristau> tepsipakki: hmm, why did you mark patch #343 as "doesn't concern us"?
#ubuntu-x 2007-09-05
<bryce> tepsipakki: hmm, I solved the earlier mesa makefile problem.  Now just to sort out a linker error in xvfb...
<bryce> hrm
<bryce> well I'm out of brainpower on this one for the day.  Timo, if you care to poke at it, I've copied my current work to http://bryceharrington.org/Ubuntu/
<bryce> it looks sort of like the stuff xvfb depends on was removed by patch 133
<bryce> I haven't been able to find an explanation of why the GL/mesa/X/* stuff was dropped with this patch
<bryce> I suspect perhaps in this case fedora did not care about xvfb so didn't notice the breakage?  not sure
<jcristau> fedora probably updated the glx stuff to whatever it looks like in HEAD
<jcristau> and only changed hw/xfree86/ to cope
<bryce> whoohoo, I think I finally solved that gdm issue with the failsafe mode :-)
<bryce> I decided to just kill off gdm after getting xinit up, and lo and behold, problem solved.
<tepsipakki> jcristau: well, according to the changelog the problem was triggered by trying to install via parallels desktop on osx
<tepsipakki> and it was marked as "RH specific", so I thought it wasn't worth it
<bryce> bedtime for me.  g'nite!
<mvo> joy! x does not even start anymore now with nvidia+comiz with the latest xserver-xorg-core
<tepsipakki> finally :)
<tepsipakki> then we can mark all those bugs as invalid :)
<mvo> and file a request-for-removal for nvidia-glx-*
<tepsipakki> yeah
<tepsipakki> mvo: does the logfile show anything useful?
<mvo> tepsipakki: it seems to die when LIBGL_ALWAYS_INDIRECT=1 glxinfo is run
<mvo> then it segfaults
<tepsipakki> the server?
<mvo> somewhere in XMEsaDestroyVidual
<mvo> yes
<tepsipakki> hmm, 12ubuntu3 has five more patches than the WIP 12ubuntu5
<tepsipakki> backported from 1.3.99
<mvo> http://paste.ubuntu.com/49/http://paste.ubuntu.com/49/
<mvo> http://paste.ubuntu.com/49/
<tepsipakki> oh, they were superseded by the fedora mesa/exa-patches
<mvo> I would really like to test a xserver-core with minimal patching, I guess you do not have a idea what patches are absolutely required to build it?
<mvo> and which are "just" fixes/tweaks etc
<mvo> I want to avoid that nvidia comes back to us and says: if you take out your patches, all works fine :)
<tepsipakki> I'm not sure if any of those are absolutely required
<mvo> I tried without any and it does not build (fails somewhere in mesa)
<tepsipakki> ah
<mvo> then I tried to apply some that looked like mesa patches and tried again and it failed at a different spot
<mvo> then I gave up for the day
<tepsipakki> right, you need patches 125-7
<tepsipakki> at least
* mvo gives it another go
<mvo> thanks
<tepsipakki> although to make the minimal xorg.conf work you need also patches 05, 94, 119
<mvo> aha, the login problem seems to be just on my system, that is good
<mvo> now the build dies in rensize.c and complains about missing GL_DEPTH_STENCIL_MESA
* mvo investigates
<ubotu> New bug: #137465 in xorg (main) "control alt backspace reboots pc sometimes" [Undecided,New]  https://launchpad.net/bugs/137465
<mvo> holly cow, after a lot of struggling I made xserver-xorg work nearly without patches and compiz+glxgears does *not* crash
<mvo> its freaking slow though
<tepsipakki> yep
<mvo> ^--- bryce (when you wake up :)
<mvo> tepsipakki: I guess it will not be easy to figure *what* exactly makes it break
<tepsipakki> that would be patches 107, 110, 120
<tepsipakki> to make it speedier
<tepsipakki> right..
<ubotu> New bug: #137376 in xorg (main) "[gutsy]  Logging into Gnome makes xorg restart" [Undecided,New]  https://launchpad.net/bugs/137376
<jcristau> tepsipakki: i think it's the same as http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commitdiff;h=1afdf8b0a92437dffe84fa98b6083b3d8fd55e27
* Starting logfile irclogs/ubuntu-x.log
<ubotu> New bug: #137515 in xorg (main) "[gutsy]  I upgrade from Test Tribe 4 to Test Tribe 5 and my monitor get in stand-by" [Undecided,New]  https://launchpad.net/bugs/137515
<bryce> morning
<mvo> hey bryce! bad news (or good ones, depending on the POV). it seems like our patches are responsible for the nvidia+compiz+glx breakage
<bryce> yup, I saw the discussion
<bryce> mvo, my guess would be since you also report performance reduction, that in this process some accelerator got disabled, and it's in that that the bug is
<bryce> like maybe it's switched to software rendering or something
<mvo> don't put to much into my performance reduction thing, its the first time that reidrected rending works, so it may well be caused by redirected direct rending and not by some missing patch 
<mvo> (works for me on nvidia that is)
<mvo> its much faster than software rendinging, I don't think that is the reason
<mvo> but it does sometime feel like it takes a 1sec break from time to time
<bryce> hmm
<mvo> the sky is falling: http://lwn.net/Articles/248227/
<bryce> hehe
<ubotu> New bug: #137561 in xserver-xorg-video-mga (main) "Ubuntu Feisty & Gutsy : mga driver can't display video with 2d acceleration (xv)" [Undecided,New]  https://launchpad.net/bugs/137561
<tepsipakki> mvo: try enabling patch 120, that should boost performance.. then you'd also see if it breaks the blob
<mvo> tepsipakki: I will try to find time for this today, its not easy as there are some other tribe-6 bugs assigned to me :/
<ubotu> New bug: #137563 in xorg (main) "[gutsy]  [regression]  After suspend-to-ram, the pen on a toshiba tabled pc does not work" [Undecided,New]  https://launchpad.net/bugs/137563
<ubotu> New bug: #137604 in xorg (main) "Black Bar Across Screen with latest Xorg Update" [Undecided,New]  https://launchpad.net/bugs/137604
<ubotu> New bug: #137522 in ubuntu "[Gutsy]  Incorrent refresh rates with nvidia driver by default (Twinview issue) (dup-of: 92599)" [Undecided,Incomplete]  https://launchpad.net/bugs/137522
<ubotu> New bug: #137471 in crack-attack (universe) "Crack attack crashes my session (dup-of: 130325)" [Undecided,Invalid]  https://launchpad.net/bugs/137471
<ubotu> New bug: #137626 in xserver-xorg-video-ati "6.7.192 resolution not correctly detected" [Undecided,New]  https://launchpad.net/bugs/137626
<ubotu> New bug: #137627 in xserver-xorg-video-ati "6.7.192 movie output only on the primary screen" [Undecided,New]  https://launchpad.net/bugs/137627
#ubuntu-x 2007-09-06
<ubotu> New bug: #137634 in xorg-server (main) "mtrr registers not set for video memory" [Undecided,New]  https://launchpad.net/bugs/137634
<ubotu> New bug: #137652 in xorg (main) "[gutsty]  xserver-xorg now fails to start " [Undecided,New]  https://launchpad.net/bugs/137652
<ubotu> New bug: #137672 in xserver-xorg-video-amd (universe) "please sync -amd from Debian unstable to Gutsy (main)" [Medium,Confirmed]  https://launchpad.net/bugs/137672
<ubotu> New bug: #137650 in xorg (main) ""Test" from graphical configuration tool for X fails on a Presario Laptop" [Undecided,New]  https://launchpad.net/bugs/137650
<ubotu> New bug: #79023 in xorg (main) "X won't start every other reboot (video mode change problem?) - Kubuntu Edgy" [Undecided,New]  https://launchpad.net/bugs/79023
<ubotu> New bug: #84460 in xorg (main) "feisty log out xserver crash-system crash" [Undecided,New]  https://launchpad.net/bugs/84460
<ubotu> New bug: #95356 in xorg (main) "funny screen on x restart" [Undecided,New]  https://launchpad.net/bugs/95356
<tepsipakki> I've built a new ati package, it includes all upstream commits on top of 6.7.192
<tepsipakki> http://users.tkk.fi/~tjaalton/dpkg/ati
<tormod> why does some driver packages build a -dbg and some not? And with the -dbg, is it equivalent to DEB_BUILD_OPTIONS="debug nostrip" (without "noopt")?
<tormod> tepsipakki: thanks I'll test it tonight, and build a feisty deb as well.
<jcristau> first question: because some drivers have users, and some not; second question: pretty much, except that the -dbg package has the debug symbols split in another file
<tormod> jcristau: so for instance ati has users and intel not?
<jcristau> uh?
<jcristau> both build a -dbg package
<tormod> there's no -dbg in resulting binaries here: https://launchpad.net/ubuntu/+source/xserver-xorg-video-intel/2:2.1.1-0ubuntu2/+build/376986
<jcristau> well iirc ubuntu has ddebs, which i think make -dbg packages useless
<tormod> tepsipakki: nitpicking: shouldn't you call that 6.7.192+gitsomething-0ubuntu1?
<tormod> jcristau: so the ubuntu intel has been correctly modified to not make -dbg, while ati would need the same modification?
<tepsipakki> tormod: maybe so, but hey, I'm lazy today :)
<tepsipakki> I didn't change the tarball
<tepsipakki> so the changes are in diff.gz
<tormod> tepsipakki: I see :)
<jcristau> tormod: i don't know, and i'm not sure that's important anyway
<tormod> jcristau: it is just apropos an intel bug report where I would like to ask the reporter to get debug symbols. I thought he could just install -dbg...
<jcristau> ah, i see
<tormod> jcristau: I am pretty sure that works for ati though.
<tormod> jcristau: "ddebs" is that a separate repository with -dbg packages?
<jcristau> http://people.ubuntu.com/~ubuntu-archive/ddebs/
<tormod> jcristau: got it! thanks
<ubotu> New bug: #137745 in xorg (main) "compiz can only used by one user" [Undecided,New]  https://launchpad.net/bugs/137745
<ubotu> New bug: #137396 in compiz "[gutsy]   after dist-upgrade from feisty,the xserver-xorg-video-ati 1:6.6.193-1ubuntu1 give me a freeze black screen (dup-of: 132716)" [Undecided,New]  https://launchpad.net/bugs/137396
<ubotu> New bug: #137781 in xserver-xorg-video-intel (main) "Regression: display artifacts in X11 (intel driver)" [Undecided,New]  https://launchpad.net/bugs/137781
<ubotu> New bug: #137777 in ubuntu "nvidia-glx-new: Missing lib thats needed on my new system (dup-of: 98641)" [Undecided,Invalid]  https://launchpad.net/bugs/137777
<bryce> tepsipakki: cool to see the new ati package.  Think we can get it uploaded today?
<Q-FUNK> hiya
<tepsipakki> bryce: that's possible yes
<tepsipakki> but maybe after another round of testing
<bryce> heya Q-FUNK
<bryce> Q-FUNK, I put in a sync request for -amd yesterday but haven't checked back on it this morning
<Q-FUNK> ok
<bryce> tepsipakki: agreed
<bryce> tepsipakki: iirc, tomorrow is cut-off for gutsy beta
<tepsipakki> ah, right
<tepsipakki> so no new packages after that? or new upstreams?
<bryce> I'm not sure... probably emergency uploads only
<tepsipakki> heh, so we are covered
<bryce> I think if we get -ati 6.7 in now, we still have time for additional bug fixes
<bryce> btw, I'm going to be gone next week to XDS2007
<tepsipakki> yeah, meant just that
<tepsipakki> yep
<tepsipakki> stay close to Dave/Alex :)
<bryce> hehe
<tepsipakki> I'm struggling what to do about UDS.. it overlaps with the Rush concert I've been waiting for quite some time :/
<bryce> heh
<jcristau> skip uds, and come to debconf instead :p
<tepsipakki> jcristau: that's next summer :)
<tepsipakki> ooh, argentina
<tepsipakki> been there in 2003
<tepsipakki> bryce: I'll start a new thread on the Dev Link forum about the ATI driver
<bryce> awesome, thanks
<tepsipakki> there it is
<tepsipakki> ..finally
<ubotu> New bug: #137803 in compiz (main) "X crashes when a try to run Google earth when Compiz is enabled (dup-of: 130325)" [Undecided,Invalid]  https://launchpad.net/bugs/137803
<ubotu> New bug: #134458 in ubuntu "system randomly halt while shutting down (dup-of: 127101)" [Undecided,New]  https://launchpad.net/bugs/134458
#ubuntu-x 2007-09-07
<bryce> -amd is sync'd
<bryce> tepsipakki: since the fedora mesa7/exa/etc. patches aren't compiling easily, I'm thinking about just doing a 12ubuntu4 tomorrow with as many valid patches as I've got, but omitting those particular bits.
<tepsipakki> sounds reasonable.. remember to enable the old patches
<mvo> patch 132 is the one that breaks compiz+nvidia+glx
<tepsipakki> yes
<tepsipakki> but it was added because of ubuntu-mobile?
<seb128> and it makes gdk_window_set_composited() work correctly
<tepsipakki> right
<tepsipakki> is that patch upstream by now?
<tepsipakki> does anyone know?
<seb128> I think it is
<tepsipakki> actually, I recall someone saying that the blob doesn't work with xserver-1.4
<tepsipakki> & compiz
<seb128> mvo: ^
<mvo> tepsipakki: do you know if the 132 patch is part of xserver-1.4?  I can't easily check myself as git.f.o seems to have issues
<tepsipakki> mvo: not offhand, but I can check that later
<mvo> that would be much appreciated
<mvo> aha, macslow just confirmed that it will be part of 1.4
<mvo> yeah :)
<tepsipakki> "will be"?-) it was released yesterday :)
<tepsipakki> or maybe he meant 1.4.x
<mvo> *cough*
<tepsipakki> but anyway, it's nvidias problem now :)
* mvo is so outdated
<mvo> I think I will test 1.4 for the bug too, just to double check 
<tepsipakki> cool, you can get debs from here: http://pkg-xorg.alioth.debian.org/debian
<tepsipakki> video and input ABI has changed, so you need to update those too
<seb128> tepsipakki: why do you think that desktop-file-utils should be changed to use ooo-calc?
<seb128> tepsipakki: I'm not sure why gnumeric is used, I think that the idea was to use gnumeric if it's installed, so the default installation uses ooo-calc but if people install gnumeric that's probably to get it used
<tepsipakki> seb128: right, I didn't recall how the fallback mechanism works
<seb128> I'm not sure now if people with both installed should have ooo-calc or gnumeric used
<tepsipakki> yep, that's a tough one
<tepsipakki> here some people want to have gnumeric available, but some expect OO.o to open certain documents
<tepsipakki> I guess there really is no silver bullet to the problem
<seb128> I'll make ooo-calc the default since that's what we ship on the desktop and users can change it
<tepsipakki> yep, thanks
<tepsipakki> it's a bit confusing since some apps use /etc/mailcap and others don't :)
<ubotu> New bug: #36319 in xorg-server (main) "xorg uses all CPU power." [Medium,Confirmed]  https://launchpad.net/bugs/36319
<ubotu> New bug: #134772 in ubuntu "[gutsy tribe 5]  live cd fails to start, black screen after installation screen on ati mobility radeon x700" [Undecided,Confirmed]  https://launchpad.net/bugs/134772
<ubotu> New bug: #138087 in xserver-xorg-video-ati (main) "[gutsy tribe 5]  Changing screen resolution garbles display" [Undecided,New]  https://launchpad.net/bugs/138087
#ubuntu-x 2007-09-08
<ubotu> New bug: #138131 in xkeyboard-config (main) "[xkb-data]  missing geometry for Dell Latitude D620 keyboard" [Undecided,New]  https://launchpad.net/bugs/138131
<ubotu> New bug: #138244 in xserver-xorg-driver-nv (main) "fatal server error, signal 11" [Undecided,New]  https://launchpad.net/bugs/138244
<ubotu> New bug: #138248 in xorg (main) "XQuickCheck: 2007-09-08 avilella" [Undecided,New]  https://launchpad.net/bugs/138248
<ubotu> New bug: #138256 in xserver-xorg-video-intel (main) "xserver-xorg-video-intel hangs the system when laptop lid is closed" [Undecided,New]  https://launchpad.net/bugs/138256
<ubotu> New bug: #138319 in xorg (main) "X w/ "nvidia" fails to start on Geforce 8800 GTS" [Undecided,New]  https://launchpad.net/bugs/138319
<ubotu> New bug: #138321 in ubuntu "black horizontal stripe across screen in X (dup-of: 137604)" [Undecided,New]  https://launchpad.net/bugs/138321
<tepsipakki> bryce: sorry.. i should push the ati update soon.. if not now
<joumetal> It would be nice if anyone would give comment about bug 137604.
<ubotu> Launchpad bug 137604 in xorg "Black Bar Across Screen with latest Xorg Update" [Undecided,Confirmed]  https://launchpad.net/bugs/137604
<joumetal> it happens with i810 cards (also with intel driver)  and workaround is to use older xserver-xorg-core.
#ubuntu-x 2007-09-09
<ubotu> New bug: #35330 in xfontsel (main) "Warning: Missing charsets in String to FontSet conversion Unable to load any usable fontset" [Medium,Fix released]  https://launchpad.net/bugs/35330
<ubotu> New bug: #136783 in xserver-xorg-video-intel (main) "not using whole widescreen" [High,Triaged]  https://launchpad.net/bugs/136783
<ubotu> New bug: #138391 in xorg (main) "Touchpad lost after xorg update (gusty tribe 5)" [Undecided,New]  https://launchpad.net/bugs/138391
<ubotu> New bug: #54576 in xorg-server (main) "FontPath in xorg.conf not completely honoured" [Low,Incomplete]  https://launchpad.net/bugs/54576
<ubotu> New bug: #54724 in xkeyboard-config (main) "AltGr+Shift not the same as Shift+AltGR" [Low,Incomplete]  https://launchpad.net/bugs/54724
<ubotu> New bug: #54553 in linux-restricted-modules-2.6.15 (restricted) "Firmware for full-featured Technotrend/Hauppage DVB-card missing" [Medium,Incomplete]  https://launchpad.net/bugs/54553
<ubotu> New bug: #55303 in linux-restricted-modules-2.6.15 (restricted) "fglrx gamma correction Radeon 9200" [Low,Incomplete]  https://launchpad.net/bugs/55303
<ubotu> New bug: #138415 in xserver-xorg-video-ati (main) "Radeon 9250 DRI locks up while using acceleration" [Undecided,New]  https://launchpad.net/bugs/138415
<tormod> matir, did you try the xset trick?
<ubotu> New bug: #138431 in xorg (main) "[gutsy]  daily-live xorg bad screen visualization hp pavillion 421.it" [Undecided,New]  https://launchpad.net/bugs/138431
<ubotu> New bug: #138432 in xorg (main) "[gutsy tribe 4]  screen get's blank when using a dummy driver" [Undecided,New]  https://launchpad.net/bugs/138432
<keescook> jcristau, bryce: do either of you have backported patches for CVE-2007-4730?  (http://bugs.freedesktop.org/show_bug.cgi?id=7447)
<ubotu> Freedesktop bug 7447 in Server/general "X crashes when 32-bit windows are resized on a 16-bit desktop" [Normal,Resolved: fixed]  
<ubotu> New bug: #138461 in xorg (main) "wrong dimensions reported to window managers" [Undecided,New]  https://launchpad.net/bugs/138461
<jcristau> keescook: the patch i applied for etch is at http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=blob;f=debian/patches/46_security_fdo-bug-7447.diff;h=503556c729314100b51648eb3e593b81ce72702e;hb=b48a241405c2a3056d11c9747f47afa90ef236ca
<jcristau> (yay gitweb urls)
<tepsipakki> bryce: I've not done the ati-update since there was one crasher that apparently is now fixed, so I'll get that tested and then upload. that should happen tomorrow
<tormod> Matir: re bug #132716, can you try this package: http://tormod.freeshell.org/linux/ati/xserver-xorg-video-ati_6.7.192-1ubuntu2feisty4_i386.deb and then attach the resulting Xorg.0.log to the bug report.
<ubotu> Launchpad bug 132716 in xserver-xorg-video-ati "ATI Driver Gets Black Screen on Radeon 7500 Mobile (Regression)" [Undecided,Confirmed]  https://launchpad.net/bugs/132716
<tormod> Matir: the package won't change anything, it just writes more debugging information to the log
<tormod> Matir: as seen from the version naming, I built it for Feisty, but it should work ok on Gutsy.
<tormod> tepsipakki: are you talking about https://bugs.freedesktop.org/show_bug.cgi?id=12245 ?
<ubotu> Freedesktop bug 12245 in Driver/Radeon "system freeze with hufo_tunnel and moving mouse" [Normal,Resolved: fixed]  
#ubuntu-x 2008-09-01
<wgrant> bryce: What do you think of my proposed fixes for bug #207781?
<ubottu> Launchpad bug 207781 in gnome-settings-daemon "gnome-control-center and gnome-settings-daemon hardcode "Synaptics Touchpad", which breaks without xorg.conf" [Low,Confirmed] https://launchpad.net/bugs/207781
<Q-FUNK> howdy!
<Q-FUNK> is there any temporary freeze on syncs from Debian?
<tjaalton> yes, until intrepid is released :)
<tjaalton> has been in effect for some time now..
<Q-FUNK> hm
<tjaalton> if you mean automatic syncs
<Q-FUNK> the sync for -geode was approved a while back, but still hasn't happened
<Q-FUNK> no, manual ones too
<Q-FUNK> would need to be synced from experimental
<tjaalton> we are in feature freeze, so new upstream versions need more paperwork
<Q-FUNK> this is a bugfix release.  same 2.10, but .1 
<tjaalton> still
<Q-FUNK> but again, the sync was approved before the feature freeze
<tjaalton> ok, then it should be fine. still, no archive admins here
<tjaalton> wgrant: oh, so you've hacked g-s-d support for synaptics properties+
<tjaalton> ?
<Q-FUNK> ah, cjwatson just synced it :)
<tseliot> federico1: I'm trying to apply some settings (loaded from my own xml file) as soon as I launch the Screen capplet (without having to click on the Apply button). Wouldn't it be enough to set the members of app->current_configuration and call XSendEvent ?
<tseliot> currently the screen flashes but my settings are not applied
<federico1> tseliot: hmmm, I think the event just tells gnome-settings-daemon to reread .config/monitors.xml and apply *that* configuration
<federico1> tseliot: i.e. the "apply" button re-saves that file, and then sends the event
<tseliot> federico1: is there no way to force the setting daemon to use my xml file (with a different name)?
<tseliot> federico1: ah, maybe I should save the settings to the official xml file
<federico1> tseliot: I'm not sure what you are trying to do, but yeah, having two files with different configurations sounds weird :)
<tseliot> federico1: if the virtual resolution is checked and it's not set and the framebuffer is not enough
<tseliot> the settings won't be saved to the xml file
<tseliot> therefore I would like the program to save such settings to another xml file
<tseliot> which can then be loaded on next login by launching gnome-display-properties --load-desired-settings
<tseliot> this should make the program load the settings from the other xml file and apply them
<federico1> tseliot: oh, I see
<federico1> hmmmm
<federico1> but how would the user run g-d-p with that option?
<tseliot> federico1: the first time the user tries to set up the multiple screens layout he will see a dialog which asks him whether he wants to have the virtual resolution set automatically in the xorg.conf. Then he is told to log out and log in again.
<tseliot> a .desktop file will make sure that on next login the capplet is called with that parameter
<tseliot> so that when he logs in the program will show app and apply the settings
<tseliot> provided that the connected outputs are the same
<tseliot> federico1: of course the .desktop file is added to the gnome-session
<federico1> hmmmmm
<federico1> tseliot: so you assume that the configuration *will* work once you reboot?
<tseliot> federico1: no, therefore both the other xml and the .desktop file are removed as soon as the application starts with the parameter
<tseliot> federico1: the only advantage would be that the user wouldn't have to set up the screens again after adding the virtual resolution and restarting X
<tseliot> but it shouldn't break anything
<federico1> tseliot: sounds good.  One thing that I'd like is, if you start g-d-p again before rebooting, then it should tell you that your settings don't match the current state because you haven't rebooted yet
<federico1> with a cute "!" icon or something :)
<tseliot> federico1: yes, this is definitely a good idea and it was part of the plan ;)
<federico1> tseliot: cool
<federico1> tseliot: hmmm, to have less moving parts (the desktop file, etc.) could you simply do this:
<federico1> 1. user hits Apply
<federico1> 2. we detect that the configuration can't be applied.  We save it anyway, with a "pending" flag or something.
<federico1> 3. If the user starts g-d-p again before rebooting, he gets a warning message
<federico1> 4. during relogin, we try to apply the saved configuration.  If it had the "pending" flag and it succeeds, we just clear the flag.  If it had the flag and it fails, we pop up an error box.  If it didn't have the flag, we do whatever we currently do
<federico1> would that work?
<federico1> (hmmm, I guess you *do* need to save a "known good" configuration somewhere in case it fails after reboot)
<federico1> then you don't need a "pending" flag at all; you could use the presence of that "known good" backup as the flag itself
 * federico1 wonders if he's talking out of his ass or if this makes sense
<tseliot> federico1: it does make sense
<federico1> tseliot: nice - generally I prefer to rely on as little "external" processes as possible, and the new gnome-session scares me :)
<tseliot> in any case we could check the framebuffer size (among other things) before we try to apply the settings
<federico1> yeah
<federico1> tseliot: the X folks at Red Hat are working on making the drivers support on-the-fly configuration of the virtual size, so hopefully this code will be less necessary in the future
<tseliot> federico1: BTW it looks like gnome_rr_config(save) only pretends to save my settings...
<federico1> I need to poke suse's X guys to see if we can do the same for radeonhd on time
<tseliot> federico1: framebuffer reallocation would be nice but I don't know when it will be available
<tseliot> but yes, I agree with you on this
<tseliot> oh, I guess I forgot to set the several output->on to TRUE
 * tseliot tries to build it again
<tseliot> federico1: I was right: I forgot to output->on to TRUE. It works well now.
<bryce> james_w, tseliot: it's a very interesting idea to include EDID in the Screen Resolution GUI, however it'd be a lot of work for (IMHO) relatively modest benefit compared with using read-edid.
<bryce> james_w, tseliot: so I'd definitely take a patch to implement it, but wouldn't work on it myself
<tseliot> bryce: I would like to take a look at it for Intrepid+1
<bryce> james_w, tseliot: my immediate thougth would be to steal code from read-edid, however as we looked into the other day, it only works on i386.  There's also EDID parsing code in the X server that might be usable.  
<tseliot> bryce: can't we steal code from nvidia-settings?
<tseliot> so as to extract the bin file and then specify the path to the edid file in the xorg.conf?
<tseliot> I haven't read the code yet though
<bryce> wgrant: the patches for 207781 look good to me
 * tseliot > dinner. bbl
<bryce> tseliot: oh maybe, I'm not familiar with the nvidia-settings internals.  It's FOSS?
<jcristau> the server exposes the edid string as a randr output property, if available, so you'd just have to parse that
<bryce> jcristau: ah even better
<tjaalton> tseliot: "nvidia: Multiple versions in DKMS. Unsure what to do. Resolve manually.
<tjaalton> tseliot: that's what I get when reinstalling the kernel
<tjaalton> tseliot: and the driver manager doesn't list any prop. drivers in use
<bryce> heya tjaalton
<tjaalton> hi bryce
<bryce> tjaalton: btw I've committed the change to replace displayconfig-gtk
<bryce> tjaalton: this introduces a simple new menu (using zenity) to allow the user to select from some troubleshooting/configuration steps.  It's just some simple bash stuff, but if you have time to review it I'd appreciate your thoughts on it.
<tjaalton> bryce: ok, cool. I'll have a look
<tjaalton> btw, the commit included adding xinput to xorg deps, and nothing on the changelog about the zenity stuff :)
<bryce> you can safely execute the failsafeXinit as non-root to see how it looks
<tjaalton> in X?
<bryce> yes
<bryce> I noticed I forgot the changelog and just added it
<tjaalton> ah, ok
<bryce> oh yeah wanted to ask about xinput as a dep, vs. adding to seeds (which I'm not sure how to do)
<tjaalton> closed a bunch of synaptics bugs today because of the properties support
<tjaalton> this will do
<bryce> cool
<bryce> yeah I sent in a patch to add some man page entries for the properties stuff for xinput
<tjaalton> xinput might be a candidate in some x11- bundle
<bryce> however I've not yet been able to get those routines to work on my system, just give X errors, not sure why
<tseliot> bryce: yes, nvidia-settings is GPL
<bryce> tseliot: see jcristau's comment above - libXrandr provides the parsed edid info
<bryce> tseliot: although I'm not certain if the bug report wishes the parsed or raw edid.  But in the latter case I'm sure we could just tap it in.
<bryce> er, s/we/whomever works on this/  ;-)
<tseliot> tjaalton: read this: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bug/263528/comments/1
<ubottu> Launchpad bug 263528 in nvidia-graphics-drivers-177 "Intrepid: Latest update destroys X server configuration on MacBook Pro (Nvidia GeForce 8600M GT, nvidia-glx-177)" [Undecided,New] 
<tseliot> bryce: I think I saw something about edid in the gnome control panel. I think it uses randr. I'll have a look at it
 * bryce grumbles at git
<bryce> heh, it seems like every time I fiddle with the xorg-server git I end up having to toss my tree and recheckout from scratch
<bryce> sometimes it seems like using git makes it all more work than not using any vcs
<tjaalton> tseliot: umm, kernel-* is a symlink to 177.70/<kver>, should I remove that as well?
<tjaalton> tseliot: ok. now the directory is empty, even after reinstalling the source
<tjaalton> no errors from dkms
<tseliot> tjaalton: try manually with
<tseliot> sudo dkms build -m nvidia -v 177.70 -k $(uname -r)
<tseliot> sudo dkms install -m nvidia -v 177.70 -k $(uname -r)
<tseliot> oh and make sure that the headers for your kernel are installer
<tseliot> installed
<tjaalton> headers are installed, no errors from the build but no modules in /lib/modules or /var/lib/dkms
<bryce> $ git clone ssh://bryce-guest@alioth.debian.org/git/pkg-xorg/xserver/xorg-server.git
<bryce> Initialized empty Git repository in /home/bryce/src/xorg-server/xorg-server/.git/
<bryce> ssh: connect to host alioth.debian.org port 22: Connection timed out
<bryce> fatal: The remote end hung up unexpectedly
<bryce> fetch-pack from 'ssh://bryce-guest@alioth.debian.org/git/pkg-xorg/xserver/xorg-server.git' failed.
<tjaalton> tseliot: oh wait, now I got the modules after all (forgot 'install')
<tjaalton> bryce: do you always clone the repo? git fetch would be faster
<tjaalton> I mean when updating the local copy
<tseliot> tjaalton: ok. The problem shouldn't happen any more with new updates of the driver
<bryce> tjaalton: yeah I always try that first, but git always messes it up
<tjaalton> git fetch; git rebase origin/ubuntu
<bryce> usually I remember to update only after I've made some minor change, and git can't handle having uncommitted changes, tries to do a merge, etc.
<bryce> yeah tried all that, ended up getting 2 screenfuls of error messages
<bryce> well, s/fetch/push/
<bryce> I think I'm spending more time futzing with git than it actually took to make the patch :-P
<tjaalton> sure you get conflicts if you have local changes and upstream has moved on
<jcristau> you need commit your local changes before rebasing
<tjaalton> but that should normally involve only the changelog
<jcristau> or stash them
<bryce> jcristau: yep did that
<bryce> the git commit -a seemed to work correctly
<tjaalton> tseliot: so the package was faulty?
<bryce> then I did a 'git rebase' and it said
<bryce> fatal: Needed a single revision
<bryce> invalid upstream 
<bryce> so then I did ` git rebase origin ubuntu`
<tjaalton> +/
<bryce> and then it did a lot of work, and then spewed out several screenfuls
<bryce> error: patch failed: configure.ac:1032, etc.
<bryce> so I gave up at that point and tried doing a new git clone
<bryce> which is timing out
<bryce> er, the syntax for push is 'git push origin ubuntu' - why would you need a / sometimes, and sometimes not?
<jcristau> because push wants a remote
<tjaalton> you are pushing the local ubuntu to remote called 'origin'
<jcristau> rebase wants a branch
<jcristau> 'origin' in push means git.debian.org:/git/pkg-xorg/whatever, 'origin/ubuntu' in rebase is 'the local copy of origin's ubuntu branch'
<bryce> in any case, it still doesn't work
<bryce> xorg-server-ubuntu-git-broken$ git rebase origin/ubuntu
<bryce> mkdir: cannot create directory `.dotest': File exists
<jcristau> right, because you're in the middle a failed rebase
<tjaalton> rebase --abort
<bryce> I remove that directory and rerun it, and it shows a bunch of things "need merge" which I didn't change
<tjaalton> then start over
<bryce> $ git rebase --abort
<bryce> No rebase in progress?
<tjaalton> hmm, would git reset --hard <id> work?
<tjaalton> <id> being the commit-id of last clean commit
<jcristau> yeah removing .dotest would have confused it
<jcristau> so, 'git reset --hard HEAD', i guess
<tjaalton> oh, HEAD works too
<bryce> hrm, git rebase origin/ubuntu is still erroring
<jcristau> what does it say?
<bryce> ok tell you what, I'll just email you the patches
<tjaalton> don't give up :)
<bryce> jcristau: trailing whitespace errors, couple conflicts, etc.
<jcristau> trailing whitespace is just a warning
<jcristau> conflicts need to be fixed up anyway
<jcristau> if some files were modified locally and remotely
<tjaalton> bryce: also, make sure to always clean up after using the tree for building debs :)
<bryce> oh I didn't know you couldn't do that...  that's like my principle use for it
<tjaalton> debuild clean works
<tjaalton> or equivalent
<bryce> ohh, no I don't use it for building debs, just dsc's
<bryce> I use pbuilder for making the debs, so that all should be fine.
<tjaalton> right
<bryce> but if you have to do cleanups after making a .dsc, that'd be irritating
<tjaalton> nope, it cleans before building dsc
<jcristau> dpkg-source -S runs clean first, so no
<jcristau> err
<jcristau> i mean dpkg-buildpackage -S
<tjaalton> bryce: failsafeXinit looks nice. some functions unimplemented, but still
<tseliot> tjaalton: yes, it was. It didn't clean the DKMS tree when the driver was updated. The current release is no longer affected by the problem however the DKMS has to be cleaned manually
<tjaalton> tseliot: sounds like the package should clean those up in the preinst..
<tseliot> tjaalton: this might break the modules of other kernels. I'll think about a sensible way to do it
<tjaalton> remove everything <177.70
<tjaalton> strange that it didn't complain before. I had four or five different versions there
<tseliot> tjaalton: yes, something like that
<bryce> tjaalton: I've done up a simple patch for #247195
<bryce> tjaalton: assuming we don't want to just disable the code entirely for now
<wgrant> tjaalton: I have. My first significant adventure into Xlib, but I think I got it right.
<wgrant> bryce: Shall I poke somebody else to upload those patches now you've given your +1?
<bryce> wgrant: seb128 would be a good guy to ask.  If he's busy but thinks they're ok too, I can do the upload.
<wgrant> bryce: I asked him last night, and he told me he didn't know much about it and to ask you.
<wgrant> But I suppose now I've your ack he should be OK with uploading it.
<bryce> ok great
<pwnguin> xorg.conf should still work, correct?
<bryce> yes
<pwnguin> okie. someone in +1 is complaining that it doesn't work; thought i'd check it wasn't intended behavior
<bryce> "doesn't work" is such a vague symptom
<pwnguin> "changes have no effect" seems specific to me
<bryce> yes, but you didn't say that ;-)
<bryce> also, which changes?  some changes certainly should work, others (like input device settings) might not
<bryce> also there are various things that can override some settings like preferred resolutions
<pwnguin> im torturing that information out right now
<bryce> some options are no longer provided as user modifyable, so those could also seem to have no effect
<bryce> modifiable
#ubuntu-x 2008-09-02
<tjaalton> pwnguin: if you have input-hotplug, evdev steals the input devices (if they have mouse/kbd capabilities) unless other drivers have fdi files for them, so yes, input devices in xorg.conf is generally not working anymore
<tjaalton> dexconf might need an update
<tjaalton> um, should
<wgrant> Shouldn't dexconf go away?
<tjaalton> there are some quirks left
<tjaalton> kvm/ps3 stuff
<wgrant> Ah.
<wgrant> Is there currently a way to make input-device properties persistent besides hacking support into g-s-d?
<tjaalton> bryce: ajax said that the server shouldn't poke acpid at all anymore :)
<tjaalton> wgrant: not that I know of
<wgrant> Unfortunate.
<bryce> tjaalton: then how is it that the server is issuing warnings when acpid isn't present?
<wgrant> But I guess it should all be exposed in capplets eventually.
<tjaalton> bryce: I mean that the code should be removed altogether.. "shouldn't poke acpid in the future" :)
<bryce> tjaalton: ahh.  Is there an easy way to disable it without requiring major surgery, or should we leave it 'til intrepid+1?
<tjaalton> wgrant: well, xrandr isn't persistent either
<wgrant> tjaalton: True.
<wgrant> g-s-d handles that now, doesn't it?
<tjaalton> bryce: I haven't had a look.. upstream would like patches, so if it makes in 1.6..
<tjaalton> wgrant: yep
<bryce> tjaalton: ah ok.  well let's go with my patch in the meantime.
<tjaalton> yep, sure
<bryce> I forgot I had today off
<tjaalton> how unfortunate :)
<bryce> so all that git fussing wasn't needed until tomorrow ;-)
<bryce> but on the plus side I got all my alpha-5 stuff in (well, xorg still needs uploaded)
<bryce> and I implemented a quirk system for -ati for AGPMode quirking
<tjaalton> really? how?
<bryce> I used the same approach as -intel, but made it also account for the hostbridge's PCI ID.  airlied and alex said it depends on both
<tjaalton> ah, right
<bryce> there's other factors that play into it though, so maybe more should be accounted for, but it's a start
<bryce> probably should be ok for laptops that don't have involved BIOS options
<bryce> which I'm guessing is going to be like 95% of the cases ;-)
<tjaalton> yeah
<tjaalton> bryce: what about applying xserver commit 5e847c1d4fc30a0d263a?
<tjaalton> it would at least fix bug 261977
<ubottu> Launchpad bug 261977 in xorg-server "nv is chosen even if it doesn't support the card" [Undecided,Confirmed] https://launchpad.net/bugs/261977
<tjaalton> and make the failsafe-stuff simpler
<tjaalton> then we could also add patches to first try nvidia/fglrx if they are installed (but maybe this needs TB ack?)
 * bryce looks
<tjaalton> the last fallback would be vesa for x86 etc
<bryce> hmm
<bryce> yeah I can see how this'll help when patched for nvidia/fglrx.  I am not sure I see how this helps in general though... but upstream obviously accepted it, so...
<tjaalton> if the "optimal" driver fails, it'll try the next one, and finally the fallback
<bryce> will it?  I don't see the failure handler
<tjaalton> it has been there AFAIK, but not working
<bryce> well in any case I can see that better fallback handling is the direction this goes
<bryce> it looks like something else is needed in addition to this to do that
<bryce> anyway, +1 for including this patch.
<tjaalton> ok, I'll add it and test how it goes
<tjaalton> the fallback thing
<bryce> I don't think we need a TB ack to add something to load nvidia/fglrx if they're installed - I think it's a general principle that if the user installs something, then it's safe to assume that they want it, and to go ahead and "just work" from there
<bryce> however obviously we should get working fglrx and nvidia before that ;-)
<tjaalton> I'm just thinking about if it has negative PR implications
<tjaalton> basically it would claim that we support the drivers, while we can't
<tjaalton> or maybe we can draw the line somewhere between "we'll allow it to autoconfigure" and "you should report your crashers upstream" :)
<bryce> would we accept that patch if fglrx and nvidia* were demoted to universe because the foss drivers were good enough?
<tjaalton> dunno.. it's problematic since the free driver is always installed
<tjaalton> so if you want to use the nonfree one, it should be on top of the driver stack to try
<wgrant> s/universe/multiverse/, I hope.
<tjaalton> yes
<tjaalton> they could be demoted, because they're no longer part of lrm
<pwnguin> plus, it doesn't mean anything special anymore like it used to
<pwnguin> you previously had to enable universe repos
<tjaalton> yep
<wgrant> You still have to enable multiverse, don't you?
<wgrant> I hope...
<tjaalton> also, tseliot would be able to upload directly :)
<pwnguin> it does mean that any joe motu can upload
<tjaalton> that rarely happens
<pwnguin> something that's basically in use everywhere and affects everything
<wgrant> tseliot it's a MOTU.
<wgrant> *isn't
<tjaalton> oh, duh
<wgrant> How'd I manage that, I wonder.
<tjaalton> well, not yet anywya
<tjaalton> -way
<tjaalton> every motu should know to stay away from nvidia* :)
<pwnguin> i can imagine one of two scenarios
<wgrant> If we have MOTU who touch it inappropriately, they shouldn't be MOTU.
<tjaalton> right
<pwnguin> i guess theres already a few kernels in universe
<wgrant> This is proving to be unfortunately common, but that's another story.
<pwnguin> but nvidia is more popular than say -rt
<wgrant> I don't think main exists just to keep some packages out of our reach.
<pwnguin> well, it's supposed to denote some level of canonical annointing
<pwnguin> annointedness?
<bryce> essentially, we say we provide ongoing security fixes for stuff in main, but not universe
<wgrant> That's all it means, right.
<wgrant> Can Canonical guarantee updates for blobs? No.
<bryce> right
<pwnguin> would canonical refuse to update a blob found to be insecure and fixed?
<tjaalton> so, I'd say that by not hardcoding the driver in xorg.conf would be better in the end, since then the fallback has a chance of working, which is more useful for the blobs anyway
<bryce> tjaalton: sounds good
<bryce> pwnguin: generally what I've been told is that doing SRU's of fglrx/nvidia is hardly ever going to be acceptable since we can't verify the source changes
<pwnguin> how about
<pwnguin> we put nouveau on the top of the stack
<tjaalton> the only setting the nvidia's have in xorg.conf is NoLogo.. (71/96 has some AIGLX-stuff too)
<pwnguin> then nvidia
<pwnguin> then nv
<pwnguin> PR solved
<tjaalton> pwnguin: there is no usable nouveau
<bryce> a security fix *might* be ok, but generally the blogs are released with a bunch of fixes, not just one cherry picked thing
<tjaalton> release
<tjaalton> if there were, I'd be all for it
<pwnguin> bryce: oh right, you werent around for the last time nvidia had a remote exploit
<tjaalton> pwnguin: it was fixed
<pwnguin> tjaalton: yes it was
<tjaalton> after edgy I think
<tjaalton> or was it breezy
<bryce> sounds nasty
<pwnguin> javascript crafted to exploit a video driver?
<pwnguin> nasty doesn't begin to describe the horror
<tjaalton> heh
<pwnguin> in such a situation, if canonical can't provide a fix, i'd almost say upload a new package that just removes it
<pwnguin> tjaalton: there's no usable nouveau, or no usable nouveau in Ubuntu proper?
<tjaalton> pwnguin: both. debian-experimental has, but they also have a libdrm snapshot
<pwnguin> my laptop power cable is inthe mail
<pwnguin> tjaalton: rihgt
<pwnguin> RAOF has a ppa
<tjaalton> yes, he's co-maintaining the d-e stuff
<pwnguin> i havent tested it it recently, but it seems like it'd at least be a statement of support and cooperation
<tjaalton> I don't think we have the manpower to support it.. upstream wont, that's known :)
<tjaalton> they don't want users yet, developers are fine
<pwnguin> nouveau, or d-e?
<tjaalton> nouveau
<tjaalton> when they can use stable drm interfaces and put out a release, the situation changes
<pwnguin> of course
<tjaalton> now that the drm release management has been reshaped, there's hope that nouveau will catch up too
<tjaalton> my words
<tjaalton> the GEM/TTM mess didn't really help either
<tjaalton> but that's mostly done now I guess
<pwnguin> does something bad happen if nouveau driver isn't found? i thought it'd fall back to the next available driver
<tjaalton> right, it should
<tjaalton> note that I haven't tried it yet
<pwnguin> heh
<pwnguin> it just seems like a token nod to their efforts that costs nothing, gets them a little, and gives you something to say when people ask why nvidia is picked over nv
<tjaalton> yes, but when nouveau is better than nv, it'll be installed in favour of nv, and we are facing the same problem
<pwnguin> oh. hrm
<tjaalton> you install nvidia by yourself so you'd expect it to work
<tjaalton> by the next LTS we'll hopefully have good FOSS drivers so we can kick nvidia/fglrx out of the door completely :)
<pwnguin> the only reasonable option is order of quality, but nobody wants to hear that
<tjaalton> intrepid+1 could have 3D support for all the latest ATI chips
<pwnguin> im not so hopeful about 3D on nvidia. there's a plan and like one dude last i looked
<tjaalton> yes it's more problematic
 * bryce squints and wishes real hard for nVidia to disappear
<pwnguin> from my interactions with fedora users, apparently Canonical just needs to spend money to make it disappear, like Red Hat does
<bryce> haha
<pwnguin> i wish i was joking
<tjaalton> they should just open up
<pwnguin> damn 7.0B market cap
<pwnguin> 51 percent will be hard to buy
<jcristau> pwnguin: well, RH does a lot of work on X upstream. can't say that's true of canonical.
<pwnguin> what?
<pwnguin> well,
<pwnguin> dave left, seemingly on not great terms
<pwnguin> err
<pwnguin> daniel
<tjaalton> and about to leave nokia for...
<pwnguin> oh?
<tjaalton> later this fall
<tjaalton> going back down under, don't know what to work on
<pwnguin> hmm. tough one to guess. intel, or RH
<pwnguin> maybe he can finish his degree ;)
<tjaalton> another PhD on XI?
<tjaalton> :)
<pwnguin> bachelors
<tjaalton> ah :)
<pwnguin> his resume lists like a year of college
<tjaalton> you know him personally?
<pwnguin> nope
<pwnguin> but i can read his website
<tjaalton> heh
<tjaalton> I know one australian chick that was at our school as an exchange student in -94/95, do you happen to know her?-)
<pwnguin> look
<pwnguin> im awake during the aussie time zone
<pwnguin> but thats a personal failing, not an indication of where i live
<tjaalton> oh damn, sorry :)
<bryce> hehe
<pwnguin> last i checked, kansas wasnt an australian province
 * wgrant annexes pwnguin.
<pwnguin> wgrant: from what i hear, it wouldn't be much different
<pwnguin> its gotta be a hell of a move, from australia to finland
<tjaalton> hmm so when alice fell through the hole, she ended up in brisbane?
<bryce> kangaroos and wallabies for instance
<tjaalton> well we have polar bears running wild
<tjaalton> (not)
<bryce> tjaalton: I think you mean dorothy and a tornado
<pwnguin> heh
<pwnguin> his mastery of american culture is still better than my mastery of finnish
<pwnguin> but thank you for the translation
<bryce> just put on a steel helmet with horns, you'll fit in fine
<pwnguin> well, parts of my family came from denmark and russia
<tjaalton> man, I thought alice was the one who said "I think we are not in Kansas anymore" :)
<pwnguin> alice was british
<tjaalton> duh
<pwnguin> or at least european
<bryce> and she had a rabbit fetish
<pwnguin> i dont think "kansas" existed when it was written
<tjaalton> that's what you get for not seeing old classics
<pwnguin> you've missed nothing
<tjaalton> that line is so familiar to me because of Rainbow'
<tjaalton> 's Finyl Vinyl
<tjaalton> not because I saw the movie :)
<bryce> kansas existed - had just finished sparking off the civil war or some such
<bryce> ok I'll shut up now
<tjaalton> oh and climate wise it's getting better here, local warming and such
<tjaalton> or was it global
<pwnguin> heh
<pwnguin> well, john brown did raid a union armory
<tjaalton> too bad that the winters are just wet
<pwnguin> to attack the south
<pwnguin> he's memorialized in our capital building
<pwnguin> bible in one hand, rifle in the other
<tjaalton> that's so modern
<pwnguin> http://images.google.com/images?q=john%20brown%20mural
<tjaalton> moses!
<pwnguin> heh, it beats the time they put an indian on the top of the dome, and used a noose to hoist it
<tjaalton> heh
<tjaalton> uploaded xorg-server to my ppa to test the autoconf stuff
<Hobbsee> hey there - have people reported regressions with compiz and the intel driver, with locking the screen making the computer freeze, and never bringing up a password dialogue?
<tjaalton> Hobbsee: that's a kernel problem
<tjaalton> and yes, I've seen that myself
 * wgrant solved it by using metacity.
<Hobbsee> tjaalton: ahhh, thanks.
<Hobbsee> tjaalton: do you know if people are looking into it, or?
<tjaalton> but with .27-2-generic, it seems to work
<Hobbsee> that was what i had, and it definetly wasn't working for me.
<tjaalton> what chip do you have?
<tjaalton> bryce: your acpi patch is broken :) http://launchpadlibrarian.net/17229928/buildlog_ubuntu-intrepid-amd64.xorg-server_2%3A1.4.99.906-2ubuntu3.1_FAILEDTOBUILD.txt.gz
<tjaalton> maybe it's easier to just not log anything
<Hobbsee> tjaalton: Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
<tjaalton> Hobbsee: ok, mine is 965 and it works fine now, even after a suspend cycle
<bryce> oh, s/acpi_warning_msg_time/acpi_warning_msg_timer/.  guess I should have compiled that one ;-)
<Hobbsee> tjaalton: ah, it's https://bugs.edge.launchpad.net/bugs/262605 apparently.
<ubottu> Launchpad bug 262605 in xserver-xorg-video-intel "[intrepid] X locks up or crashes when screensaver activates" [Undecided,New] 
<tjaalton> bryce: ok, will do
<tjaalton> Hobbsee: yes, I'll reassign it to kernel
<Hobbsee> tjaalton: thanks.  didn't want to fiddle with it myself, and get the wrath of the kernel guys in my direction.
<tjaalton> I'll point ogra to that bug
<tjaalton> probably some drm funkiness
<wgrant> Isn't DRM implicitly funky? Isn't that why it's being killed?
<tjaalton> depends what DRM you mean :)
<bryce> X11, the land of overloaded acronyms  :-P
<wgrant> The kernelly Xy thing.
<tjaalton> direct rendering manager, yes
<tjaalton> didn't know it was being killed though :)
<tjaalton> reworked maybe, but it'll always be too complex for me to grog
<wgrant> Where do TTM and co come into the equation?
<bryce> TTM -> GEM
<tjaalton> the memory manager is a part of drm
<wgrant> Ah.
<bryce> we *might* have GEM for intrepid.  I was helping benc with it earlier but don't know the current state of things
<Ng> tjaalton: interesting that the new kernel fixes it for you
<Ng> Hobbsee: do you see that too?
<Ng> I can't test for a while, my laptop just left for a trip to Scotland to be repaired :(
 * wgrant tests.
<wgrant> (i915 here)
<Hobbsee> Ng: where new kernel == -2?
<Ng> Hobbsee: yeah
<Hobbsee> Ng: that's the first place i see it, but i went straight from .25 to .27
<Ng> oh
<Ng> fail ;(
<Hobbsee> (so i don't know if -1 had the problem)
<tjaalton> I'll try to reproduce with -1
<tjaalton> also, usplash works with .27
<Hobbsee> yes, surprisingly!
<Hobbsee> it's nice to see it agai
<Hobbsee> n
<tjaalton> maybe they added v86d to the initrd
<Ng> I manually install v86d and it updated the initrd and all that changed was that X refused to start
<Ng> saying that it couldn't operate in framebuffer mode
<wgrant> Well, that failed.
<wgrant> -2 from 12 hours ago doesn't even suspend on i915 when compiz is running.
<tjaalton> well, can't reproduce with -1 either
<tjaalton> compiz was updated recently..
<tjaalton> nope, not the compiz update. it only un-blacklisted mobile ati
<tjaalton> wow, now it blanked again
<tjaalton> with -2
<tjaalton> Ng: do you think bug 258923 is fixed now with .27?
<ubottu> Launchpad bug 258923 in xserver-xorg-video-intel "Black VGA output on Intel G45 (aka x4500hd)" [Undecided,New] https://launchpad.net/bugs/258923
<Ng> tjaalton: I've never plugged anything into the VGA output on mine. I could dig around for a VGA cable and try, I'm pretty sure my TV has such an input
<Ng> (I literally own zero monitors at this point ;)
<Ng> laptops and digital TVs for the win :)
 * tjaalton <3's the 24" benq :)
<tjaalton> Ng: oh and thanks for trying it out
<tjaalton> Ng: what about bug 258925?-)
<ubottu> Launchpad bug 258925 in xserver-xorg-video-intel "Horizontal lines on Intel G45 (aka x4500hd) output" [Undecided,Incomplete] https://launchpad.net/bugs/258925
 * Ng looks
<Ng> I think I know what that is
<Ng> ok the mouse jumping thing mentioned in that is not related, I see that on everything, and it happens to a lesser extent on login on hardy afair
<Ng> but the black lines thing I think is kernel dependent
<Ng> if I booted my X300 on hardy's kernel with intrepid userspace, I got loads of inch-long horizontal black lines on the screen
<tjaalton> the mouse-jumping is soon fixed, with the same patch that should fix flickering
<Ng> nice
<wgrant> Is this mouse jumping the thing where the cursor freezes and jumps to the bottom right by a few cursor-heights, then recovers?
<tjaalton> recovers when you touch the mouse, yes
<tjaalton> annoying as hell
<wgrant> Hmm.
<wgrant> Maybe not identical to what I see, then.
<wgrant> Mine will continously jump.
<wgrant> Until it has finished logging in.
<tjaalton> jcristau: looks like the autoconfig patch didn't work right, no fallback-mechanism or something missing: bug 261977
<ubottu> Launchpad bug 261977 in xorg-server "nv is chosen even if it doesn't support the card" [Medium,Incomplete] https://launchpad.net/bugs/261977
<wgrant> It used to just do it once while gdm was starting.
<tjaalton> it does it every time a gtk app starts
<wgrant> Right.
<wgrant> That sounds plausible.
<tjaalton> so you can demonstrate it yourself by running xrandr -q
<tjaalton> and then touch the mouse
<wgrant> That doesn't affect my mouse.
<wgrant> It just shows some apparently uninitialized textures for a frame or two.
<tjaalton> ah
<tedg> It is a known bug to have X start up and not have a keyboard/mouse?  Then if I restart X it's all happy.
<tedg> I'm guessing that it's not finding HAL on first start.
<tjaalton> right
<tjaalton> known
<tedg> Okay, then I'll be quiet :)
<tjaalton> hal should be started earlier..
<tedg> Well, yes, but X should detect when HAL starts also.  That's easy to do with DBus.
<tjaalton> I've never seen that though, but there are bugs about that
<tedg> It happens to me on every clean boot.  I'm not sure if there's anymore debugging I could provide, but if so, I'm all for it :)
<jcristau> pretty sure patches to detect when hal starts would be accepted
 * tedg has fear of X, he always makes sure there's at least 2 levels of abstraction between him and X at all times :)
<jcristau> i just do that for xkb
<bryce> tedg, chicken!
<bryce> tedg: actually X code is just plain C and fairly well documented.  Easier than Inkscape ;-)
<bryce> well, "fairly well" might be a stretch.  But more documented than Inkscape's code ;-)
<tedg> bryce: I think it comes down to: "What happens when I mess up?" -- "Can't draw" vs. "at a terminal prompt"
<bryce> bawk bawk bawk
<tedg> bryce: Why don't you just go do the patch I want and show me up :)
<bryce> ah, but then we miss the valuable learning experience for you
<tedg> How much work have you done with DBus?  I'd really like you to learn more about "the future" (tm).
#ubuntu-x 2008-09-03
<pwnguin> the only x code ive ever looked at has been xkb, and im scarred for life
#ubuntu-x 2008-09-04
<bryce> yay xserver 1.5 is out
<pwnguin> relevant to intrepid?
<bryce> the changes are fairly modest, I think once the alpha-5 freeze is over it'd worth including, just for officialness
<pwnguin> heh
<pwnguin> well, im all for new
<bryce> I suspect it's mostly bugfixes but only skimmed the changelog
<pwnguin> but mdz did get a bit loud when the kernel team decided .27 was the future
<bryce> ah, but the decision to do xserver 1.5 was made way back at UDS Prague well before Intrepid began
<bryce> we've just been waiting for it to officially release
<bryce> plus, the change from 1.4.99.906 to 1.5.0.0 is quite minor
<bryce> we've been running with the xserver beta for quite some time.  Whereas with the kernel they were running with the stable .26 version and the jump to .27 is pretty significant (but still a good idea imho)
<pwnguin> alrighty then. remember this when the mdz arrives ;)
<pwnguin> i wonder why the kernel wasn't .27 from the start
<Awsoonn> to take advantage to the restriced drivers / duelhead will I still need an Xorg.conf? I see in teh log that it detected and loaded the nv module, but appears to not be using it....
<pwnguin> nv or nvidia?
<Awsoonn> xorg isreporting loading nv
<jcristau> it's not the blob, then
<Awsoonn> so will I need the 'ol xorg.conf afterall then?
<pwnguin> theres' been consideration of a patch that will load nvidia over nv (when nvidia is installed)
<jcristau> that's only sensible if the fallback is fixed
<jcristau> right now, it isn't, so nv is the safe bet
<Awsoonn> should jockey detect my nvidia card and install the nvidia driver for me in intrepid after an upgrade? or is it not working just yet?
<tjaalton> of course we'll get 1.5.0 in intrepid.. it's nice for a change to have an actual release in the distro >:P
<tjaalton> that reminds me.. it should be fine to merge with lenny to get a proper release in hardy too
<bryce> evenin' tjaalton
<tjaalton> hey bryce
<tjaalton> <sneeze>
<bryce> not feeling well?  sorry to hear
<tjaalton> yeah, well my chair at work is pretty comfortable.. but smells bad
<tjaalton> should only get there first ;)
<tjaalton> hum, so videoabiver has been bumped again, rebuild madness it is then :)
<bryce> erf
<bryce> tjaalton: btw I wrote up a page to document quirks (only one detailed so far):  https://wiki.ubuntu.com/X/Quirks
<tjaalton> ah thats good.. I've looked at intel a couple of times and there seemed to be some obvious quirk-cabable bugs
<tjaalton> but didn't know how to write one
<tjaalton> Awsoonn: depends on your chip. if it's old enough jockey won't offer the blob because the old versions don't work with the new xserver
<tjaalton> so no point in breaking your system
<bryce> tjaalton: yeah I've got it on my todo list to document each of the intel quirks.  There's only 2-3 I actually understand currently
<bryce> well, "totally understand".  Most of them I can guess what they do, but just not what situations they apply to exactly.
<bryce> tjaalton: don't remember if I mentioned already that I did up a patch to add quirking logic to -ati  for AGP incompatibilities, so we can set AGPMode to specific values on a hw-specific basis
<bryce> looking through our bug tracker I think a huge proportion of our -ati bugs might be fixable with this quirk
<tjaalton> yeah that could be
<tjaalton> is $2 fed to $foo.postinst the version being replaced?
<jcristau> if $1 is configure, yes
<tjaalton> ok thanks
<tjaalton> need to clean up /etc/X11/Xsession.d/*xorg-common* in x11-common.postinst..
<tjaalton> used to be in xinit on dapper
<tjaalton> maybe comparing versions is overkill.. just check if the files are there and remove
<jcristau> ideally you'd check whether they're modified
<tjaalton> how to do that?
<jcristau> remove_conffile_* in xsfbs.sh
<tjaalton> ah
<jcristau> or http://wiki.debian.org/DpkgConffileHandling
<jcristau> that said, these files are so old it might be ok to just remove them..
<jcristau> not sure
<tjaalton> the md5sums aren't available, so I guess remove_conffile doesn't work then? just removing should be fine, yes
<jcristau> weird. dpkg is supposed to keep the md5sums in its status db until the package is purged/
<jcristau> s,/,.
<tjaalton> in $pkg.md5sums?
<jcristau> in /var/lib/dpkg/status
<tjaalton> oh, status db
<tjaalton> yeah, there they are
<tjaalton> ok so I'll use that
<tjaalton> maybe
<tjaalton> yes, because it's simple
<jcristau> xutils uses that if you want an example. remove_conffile_lookup in preinst install|upgrade, _rollback in postrm abort-*, _commit in postinst configure
<tjaalton> ok so in this case r_c_l xinit "foo", since it was in xinit
<jcristau> right
<tjaalton> oh you have to run all three.. ok
<tjaalton> hmm, I don't think in this case the rollback is needed
<tjaalton> unless it's backported to the hardy package
<tjaalton> ok I think it's ready
<tjaalton> fixed the package versions and pushed it for testing on my PPA
<Awsoonn> tjaalton: I guess old is relitive, my card is a 6800GT, is this goign to be broken in the new X server by chance?
<tjaalton> Awsoonn: no, the latest driver should support that
<Awsoonn> tjaalton, so would you happen to know hwo I can debug jockey to see why it thinks I don't want the blob?
<tjaalton> Awsoonn: I think tseliot is your man for the job :)
<Awsoonn> will ping~ Thanksl
<soren> Remind me again: Why is it that the default Display "Virtual" setting isn't 10000x10000 so that side-by-side monitor things are just an xrandr call away?
<pwnguin> if i were to hazard a guess
<tjaalton> because otherwise you'd have a large desktop to scroll around?
<pwnguin> it'd be related to the amount of video ram such insanity would allocate?
<soren> tjaalton: Erm.. no?
<tjaalton> ok :)
<soren> tjaalton: That's the viewport setting, surely?
<jcristau> soren: because otherwise you wouldn't have 3d
<jcristau> software gl is slow
<jcristau> plus, that would use a massive amount of memory
<tjaalton> soren: right..
<soren> jcristau: Wouldn't that only become a problem when I actually start using the extra virtual space?
<jcristau> soren: no
<soren> jcristau: Ok.
<soren> jcristau: Just curious: Is this considered a bug? I mean... I would seem better to me if adding an extra monitor and being able to just extend your desktop onto it with xrandr would be possible, but perhaps I'm missing something.
<soren> s/I would/It would/
<jcristau> yes, it's considered a bug
<soren> Ok.
<jcristau> it's also hard
<soren> Oh, no doubt.
<soren> I'm deeply impressed by what xrandr does already.
<soren> Err..
<soren> XRANDR, that is.
<jcristau> http://lists.freedesktop.org/pipermail/xorg/2008-September/038180.html
<soren> xrandr isn't so spectacular in itself :)
<jcristau> if you're interested
<soren> I wouldn't mind sacrificing 3D capabilites on the altar of dual-head setups.
<tseliot> soren: thanks to the work which I'm doing with bryce on the gnome-control-center all you will have to do is apply your settings, let it set the virtual resolution for you (if you wish so), log out and log in.
<tseliot> of course you will still lose direct rendering
<tjaalton> but only if the size is bigger than the chip supports?
<tseliot> tjaalton: yes, of course
<soren> tseliot: Lovely.
<tseliot> tjaalton: i.e. bigger than the current framebuffer
<tjaalton> bryce: http://lists.freedesktop.org/archives/xorg/2008-April/034582.html
<bdmurray> bryce: I think I'm reading to validate a series of xorg.conf files.  Is there a package with a small number of bugs I could test with?
<tjaalton> bryce: so if we drop xorg.conf it should work
<tjaalton> or at least the driver section..
<bdmurray> I got impatient and I'm checking all the xserver-xorg-video-mga bugs
<tseliot1> bdmurray: you might find a lot of interesting stuff in the reports assigned to nvidia-glx
<tseliot1> maybe too much stuff
<bdmurray> I wanted to test a package with a small number of bugs first to make sure everything is working right
<bdmurray> Then I'll get crazy!
<tseliot1> ah ok
<bryce> bdmurray: xserver-xorg-video-nv probably doesn't have an overwhelming number
<bdmurray> bryce: would also checking "closed" bug be helpful?
<bryce> bdmurray: nope, only open ones
<bdmurray> bryce: so looking at bug 5801 - which as an invalid xorg.conf - I'm not certain the best way to establish a relationship between my comment and the problematic xorg.conf
<ubottu> Launchpad bug 5801 in xserver-xorg-video-nv "(NVidia only) Wrong default and maximum resolution on widescreen monitor (stretched 1024x768) on GeForce 6200" [Wishlist,Confirmed] https://launchpad.net/bugs/5801
<bryce> looking
<bdmurray> The problem deals with the fact that 2 attachments could have the same name and the attachments aren't easily distinguishable
<bdmurray> There are some numbers in the librarian url and in the edit url for the attachment but those are easy to find etc....
<bryce> maybe just list the URL to it?  Or refer to the comment# that it was associated with
<bdmurray> Got it, I'll just add an additional link to the librarian url
<bryce> cool
<bdmurray> in the comment I add - sound good?
<tjaalton> bryce: yay, driver fallbacks do indeed work
<bryce> awesome
<tjaalton> http://launchpadlibrarian.net/17291373/Xorg.0.log (from bug 261977
<ubottu> Launchpad bug 261977 in xorg-server "nv is chosen even if it doesn't support the card" [Medium,Incomplete] https://launchpad.net/bugs/261977
<tjaalton> it's kinda built in the xserver already.. no new magic needed, if the conf had multiple driver sections it would try them one by one until it works
<tjaalton> so.. this should make failsafe quite a bit more straightforward
<bryce> awesome
<bryce> wait I said that already
<tjaalton> hehe
<bryce> is there any additional work you see we need to do to polish it up?
<tjaalton> well I'd like to make sure if it's enough to just not have any Device-sections in xorg.conf
<tjaalton> if not, there should be another way to feed options
<tjaalton> like NoLogo for nvidia, Virtual for dualhead etc
<tjaalton> maybe if there would be xorg.conf.d/ with files that are sourced, so that they could replace or add stuff to the default, generated configuration
<tjaalton> (that's not a new idea)
 * bryce nods
<bryce> hmm
<bryce> however on the other hand, Virtual will be going away sooner or later
<tjaalton> well yes
<bryce> also alberto's x-kit will be handling flipping on/off options
<tjaalton> but if there's xorg.conf this fallback-stuff won't work
<tjaalton> at least that's what I fear
<tjaalton> a really hacky way would be to modify dexconf to add all the device sections
<tjaalton> but that's... ugly
<tjaalton> going back to the 90's
<bryce> hmm
<tjaalton> heck, I'll try the deb myself
<tjaalton> hrm, gotta love (un)reliable power management with .27
<bryce> :-/
<bryce> yeah my laptop has started hanging on suspend/resume again
<bryce> for a while there it was working reasonably reliably
<tjaalton> yeah for me too
<bryce> honestly I've been having a LOT of problems since about alpha-3/4
<bryce> jumpy mouse pointer, flickering on starting/stopping gnome apps, boots successfully only 50% of time, strange screen corruptions, suspend/resume issues...
<bryce> it's a bit disheartening
<bryce> but... gives me something to do for the next month ;-)
<tjaalton> sounds familiar.. the flickering/mouse jumping are related, somehow 945/965 are on other sides of the fence; fix one and the other breaks
<tjaalton> although I haven't seen the flickering on 965, but mouse jumping stopped after applying the latest patch. although that made the mouse jump on 945
<bryce> mm, yeah I last updated it friday so maybe there's a fix
<bryce> oh, also I'm seeing the screensaver failing to come on again
<bryce> I also can't say I'm a fan of the new power switch, where you have to go back to the gdm screen in order to shut the system off
<bryce> since suspend/resume doesn't work, it adds extra work to shutting down the machine
<tjaalton> yeah that sucks big time
<tjaalton> but the new user-switch applet has an option to shutdown directly
<bryce> oh does it?  I played with that only briefly, I'll look closer
<tseliot1> bryce: if you click on the User Switcher in the gnome panel you can select shutdown. This should save you some time
<tjaalton> ok, verified that the server doesn't use built-in configuration if it can find the system xorg.conf
<tjaalton> and I think there's a simple way to use the failsafe even if you had an xorg.conf that has issues for whatever the reason.. just move it aside like now, but don't generate a stub file but use the server defaults like normally
#ubuntu-x 2008-09-05
<bryce> man, this AGPMode bug is pervasive
<bryce> tjaalton: looks like we have a choice between stable 2.4.2 or gem-enabled 2.4.97.0
<jcristau> for a flickering value of stable ;)
<pwnguin> heh
<pwnguin> a bit of bugmail
<pwnguin> apparently none of the bugs against wacom have invalid xorg.conf
<tjaalton> every time you find the phrase "exact same problem" in a bugmail, stop reading..
<tjaalton> you'll just get annoyed at people
<tjaalton> bryce: you mean they won't support 2.4.2 anymore?
<tjaalton> btw, what is the intel vblank-support supposed to do?
<tjaalton> (in drm)
<bryce> not sure about the vblank
<bryce> but yeah sounds like 2.4.2 is the last in the 2.4.x series
<bryce> "exact same problem, except..."
<bryce> or my favorite, "making it completely unusable"
<tjaalton> hehe, yeah
<wgrant> Fix it now or I'm going back to Windows.
<bryce> ooh, nice wgrant
<crevette> :)
<bryce> futile attempts to extort a bugfix really wins points
<bryce> another good one is "I did foo, and then X didn't work"
<tjaalton> mvo: so you've been running the evdev snapshot for some time?
<tjaalton> mvo: any issues with it?
<mvo> hey tjaalton
<mvo> no, works fine for me
<mvo> i run in on my two main machines
<tjaalton> mvo: ok cool. I'm just wondering if we should go for the snapshot or pull stuff on top of 2.0.4
<mvo> is there a release planned soon?
<tjaalton> but looking at the commit diff, it's pretty clear that master doesn't have anything suspicious, mostly more properties supported etc
<tjaalton> I'm not sure
<tjaalton> I'll ask..
<tjaalton> maybe I'll just cheat in the meantime and pull master on top of 2.0.3 so there's no paperwork needed :P
<tjaalton> or bump the version to 2.0.99
<mvo__> tjaalton: sorry, network trouble - what was the last bit you said?
<tjaalton> 10:44 < mvo> is there a release planned soon?
<tjaalton> 10:44 < tjaalton> I'm not sure
<tjaalton> 10:44 < tjaalton> I'll ask..
<tjaalton> 10:46 < tjaalton> maybe I'll just cheat in the meantime and pull master on top of 2.0.3 so there's no paperwork needed :P
<tjaalton> 10:50 < tjaalton> or bump the version to 2.0.99
<Ng> tjaalton: yes please, do want newer evdev so I can do mvo's emulatescrollwheel trick :)
<tjaalton> right, I need to sync the upload of hal/evdev/gnome-settings-daemon/xkb-data to make sure the keyboard rules/model mess is sorted out once and for all
<tjaalton> since currently the model is forced as evdev, but that has problems with some exotic layouts.. so the solution is to force rules=evdev instead
<tjaalton> then the patch from g-s-d can be dropped, and people can change the kb model again
<tjaalton> and the evdev rule should be modified to support the exotic layouts etc
<tjaalton> uh, somehow git utterly failed merging xkeyboard-config master
<tjaalton> every changed file in conflict
<bryce> <3 git
<jcristau> you need to merge 1.3 first
<tjaalton> jcristau: isn't that merged already?
 * jcristau doesn't remember
<jcristau> i think not
<jcristau> it was still using cvs at the time
<tjaalton> ah, ok
<tjaalton> wonder if Mohammed would mind me merging this in experimental too
<jcristau> cvs keywords ftl though, they conflict the merge
<jcristau> but iirc other than that it's trivial
<tjaalton> yeah it looked trivial, simple substitutions and nothing else
<tjaalton> k, merge done
<tjaalton> guess all the .cvsignore files can be replaced with .gitignore
<tjaalton> lunch ->
<tjaalton> sigh, what a mess in xkeyboard-config.. I have no idea how these patches could apply before
<tseliot> tjaalton: I have fixed nvidia-kernel-common a bit (lintian doesn't complain any more) and added didrocks' patch. Would you like to have a look at the new source?
<tjaalton> tseliot: sure
<tseliot> tjaalton: ok, here's a text file with the links: http://albertomilone.com/ubuntu/newlrm/nvk.txt
<tjaalton> tseliot: anything specific I should be looking at?
<tseliot> I have changed the debian/rules, control and removed some files
<tjaalton> debdiff would probably be easier :)
<tseliot> tjaalton: if you do a diff with the current version in ubuntu you will see all the changes
<tseliot> yes
<tjaalton> oh wait, I can do tha t myself
<tjaalton> why didn't you merge with debian, they did most of the stuff already
<tseliot> tjaalton: merge or sync?
<tjaalton> merge
<tseliot> I had a look at the debian package but I wasn't sure as to whether I wanted all the changes
<tjaalton> well there is the debian version mentioned in preinst
<tjaalton>  if dpkg --compare-versions "$2" lt-nl '20051028+1+nmu2'; then
<tseliot> yes, right
<tseliot> it's not finished
<tseliot> I have to go for lunch now. See you later
<tjaalton> ok, ask again when it's finished :)
<tjaalton> I don't see why it couldn't be merged first
<tjaalton> there xkb-data pushed to git..
<tjaalton> +,
<tjaalton> didn't feel like autoreconf'ing it
<jcristau> tjaalton: haha. you got to discover the xkb-data disaster :)
<jcristau> tjaalton: deleting the generated files from the source package and generating them cleanly on build would probably help
<tseliot> tjaalton: I did the merge: http://albertomilone.com/ubuntu/newlrm/nvidia-kernel-common_20051028+1+nmu2ubuntu1.debdiff
<tseliot> but I haven't attached the debdiff to the bugreport yet
<tseliot> federico1: how do you suggest that I apply the settings with the capplet with a .desktop file on login?
<tseliot> BTW I have implemented this new feature even though my patches still need some polish
<federico1> tseliot: do you actually need a .desktop file?  if you set a flag somewhere, gnome-settings-daemon could notice that flag at startup and reconfigure the screens
<tseliot> federico1: ok, I could modify the gnome-settings-daemon but I don't know if I can check that the outputs haven't changed in the settings daemon
<tseliot> and we don't want it to apply the settings if the outputs have changed (e.g. if in the meantime you have swapped the external monitor with another,etc.)
<federico1> tseliot: you may need to change the API in gnome-desktop a bit so that it can save without applying.  Then you can compare the loaded configuration with the current one, with gnome_rr_config_match()
<tseliot> federico1: yes, that's what I did in xrandr-capplet.c and libgnome-desktop/gnome-rr-config.c
<tseliot> federico1: but currently I make it save the settings to another xml file if the capplet can't apply the settings
<federico1> tseliot: ah, ok
<federico1> tseliot: then you can make gnome-settings-daemon see if that file exists.  If it does, match() it to the current screens and see if it's possible to use it
<tseliot> federico1: do you know which file I should modify in the gnome-settings-daemon?
<federico1> tseliot: gsd-xrandr-manager.c
<federico1> gnome-settings-daemon/plugins/xrandr/gsd-xrandr-manager.c
<tseliot> federico1: aah, it's in plugins. Thanks
<tseliot> federico1: ok, I guess I'll have to play a bit with gnome_rr_config_apply_stored() in gsd_xrandr_manager_start(). I should get something working soon
<federico1> tseliot: yeah, it shouldn't be hard... g-s-d is a bit of a PITA to debug, but that's like any startup program
<tseliot> heh, right
 * tseliot > dinner. bbl
<tjaalton> jcristau: yeah, I wonder why anything with xkb in the name is shite
<tjaalton> tseliot: that's more like it. ready to go :)
<tseliot> tjaalton: great
<jcristau> tjaalton: btw, feel free to revert my videoabiver bump, it's not like the abi has actually changed, and i guess it would be a pita for you
<Awsoonn_> I am having issues with an ATI Radeon 7000, it has duel heads; the screen resolution tool can detect both of my monitors, but when I apply nothing useful happens
<Awsoonn_> It is using the opensource driver, and there are no appernt options to use the blob
<tjaalton> jcristau: ok, although soon we should be able to just sync them from experimental ;)
<tjaalton> Awsoonn: there are some issues in the tool on intrepid
<tjaalton> with
<bryce> Awsoonn: probably you need to adjust your Virtual setting in xorg.conf
<bryce> Awsoonn: are you on Intrepid?
<tjaalton> ah, that incarnation left already
<tjaalton> 22:29 -!- Awsoonn_ [n=dereck@oscar.lssu.edu] has quit ["Lost terminal"]
<bryce> I've put the AGPMode quirking patch into our -ati for testing - http://bryceharrington.org/ubuntu/Ati/
<bryce> I need to refresh my ati test box to test it.  If anyone else has a system they could check it on too it'd be appreciated
<tjaalton> I'll probably upgrade my VDR box later this year, and it could end up being an AMD box.. so can't test just yet ;)
<bdmurray> bryce: I've finished tagging xorg.conf files
<bdmurray> I checked every package at https://bugs.launchpad.net/~ubuntu-x-swat/+packagebugs
<bryce> bdmurray: excellent, thanks
<bdmurray> only 8 invalid though :(
<bryce> still good to know.  I'll go through those 8 when I get some time
<bdmurray> hunh
<bdmurray> might have missed a few
<bdmurray> There are 67 files that end with 'org.conf' for example 'fglx_xorg.conf'
<bryce> ahh
<bdmurray> and 'working-xorg.conf'
<bdmurray> I guess I'll get back to you ;)
<bdmurray> heh - diff.xorg.conf seems to be a false positive
<bdmurray> bryce: Maybe I should check compiz bugs too?
#ubuntu-x 2008-09-06
<bryce> bdmurray: couldn't hurt
<bryce> bdmurray: bugs-without-a-package might be worth looking at as well
<bdmurray> bryce: oh, that'd be sweet
<bdmurray> It might help assign packages to them too
<bdmurray> bryce: bug 266959 might be important
<ubottu> Launchpad bug 266959 in ubuntu "remove_conffile_commit(" [Undecided,New] https://launchpad.net/bugs/266959
<bryce> hmm
<bryce> tjaalton:  266959 is for xorg 1:7.4~1ubuntu1.1 
<bryce> hrm, but apt-cache madison is showing only 1:7.4~1ubuntu1 available
<bryce> bdmurray: thanks for pointing that one out; I wonder where that .1 comes from though (I've done an upgrade just now and don't see it)
<bdmurray> that's what someone else said too
<bdmurray> er, that it didn't affect them
<bryce> tjaalton: I noticed you did a merge with xorg.  The changes I have queued there are good to go if you're waiting on that for doing a release.
<bryce> tjaalton: or let me know and I can push the release Monday.
<bryce> tjaalton: also I got the -ati sync in, but found it FTBS on my system due to mismatched build-deps requirements.  I've fixed that, as well as uploaded the quirks system patch
<wgrant> bryce: Do you know why the alpha 5 desktop CD would be losing knowledge of most of my keys often?
<bryce> wgrant: not offhand, but that bug sounds familiar
<wgrant> Soon after restarting X, I will be able to type alpha-numerics, Ctrl, Alt, Backspace, and that's about it.
<wgrant> Anything I can do to debug?
<bryce> it sounds very familiar - look in launchpad to see if there's a matching existing bug
<wgrant> Against which package?
<bryce> my bet is that it's something hal-related
<wgrant> evdev, or the server?
<wgrant> Right, that's what I thought.
<bryce> yeah, evdev, xkeyboard-config, xorg, or xorg-server would be most likely
<wgrant> Bug #254939 looks relevant.
<ubottu> Launchpad bug 254939 in xserver-xorg-input-evdev "No Mouse/Keyboard since update and restart on  evening of 4th August." [Undecided,Fix released] https://launchpad.net/bugs/254939
<wgrant> (particularly one of the comments)
<wgrant> I'll file a new one, as that is closed and really for another issue.
<bryce> sounds good; I'm looking through some lp bugs to see if I can find the one I was thinking of
<wgrant> Huh.
<wgrant> Left arrow is Alt_R.
<wgrant> Down arrow is Super_R.
<wgrant> Somethings really broken.
<bryce> anything happen if you unplug your keyboard and plug it back in?
<wgrant> It's a laptop.
<wgrant> Aha.
<bryce> oh :-)
<wgrant> Works fine if I force the model through g-s-d.
<wgrant> And it works even if I now force it back to evdev.
<bryce> mmmm, could it be #225643 then?
<wgrant> I don't think so.
<wgrant> I don't get that error, and it works for a while.
<wgrant> And I have a minimal (live CD) xorg.conf.
<bryce> okay, this is the one I was remembering - bug 255008
<ubottu> Launchpad bug 255008 in xorg-server "Up arrow key mapped to Print [screen]" [High,Fix released] https://launchpad.net/bugs/255008
<wgrant> That's it.
<wgrant> Same symptom, at least.
<bryce> looks like it's marked as fixed though
<wgrant> mdz seemed unsure.
<bryce> 257855 was marked as a dupe
<bryce> tjaalton will probably have a better clue than I on this one; he's been focusing on keyboard stuff lately. 
<bryce> I do have a keyboard troubleshooting page (mostly outdated now with input-hotplug tho)
<wgrant> The strange thing is that it worked for me on a 48-hour old Intrepid installation on the same hardware.
<wgrant> And alpha 5 is a similar age.
<bryce> https://wiki.ubuntu.com/X/Troubleshooting
<bryce> there's some steps for checking if the keys are being mapped by the kernel
<bryce> so I'd suggest your debugging should start by looking showkey to see if the kernel is reporting the keycodes, and then if so, use xev to see if X sees them
<wgrant> X and tty1 see different keycodes for Up.
<wgrant> But it all seems to be working now :(
<bryce> hmm
<bryce> well keep an eye out for it - sounds like the sort of issue that'd reoccur periodically
<bryce> but it sounds like X is getting confused about the keyboard layout and isn't in sync with what the kernel is using
<bryce> so "basic" keys probably just happen to have the same mappings for both of them, which is why those work
<wgrant> Yep.
<bryce> I'll bet gnome is involved in this at some level
<wgrant> Most likely.
<wgrant> The keycode is 111 whether or not things are working, but the keysym changes (at least as xev sees them).
<wgrant> (for up arrow)
<bryce> bdmurray: hey if you feel like going on a WONTFIX rampage, as of bug #262491 xserver-xgl is no longer a Ubuntu package, and all of its (many) bugs can be WONTFIX'ed
<ubottu> Launchpad bug 262491 in xserver-xgl "Please remove xserver-xgl (universe) from the archives" [Low,Fix released] https://launchpad.net/bugs/262491
<tjaalton> wgrant, bryce: the keyboard-changes I talked about should fix this for everyone
<tjaalton> now you need to force the model to be evdev, but that breaks exotic layouts (ABNT2, jp106). so the solution is to force the rules instead
<tjaalton> that's been changed upstream a couple of weeks ago when I had a chat with svu (xkeyboard-config maintainer) and daniels
<tjaalton> bryce: yeah that bug is about the cleanup commit I made, but apparently it's not quite right yet
<tjaalton> bryce: did you notice that the failsafeXinit doesn't have all the functions in it, or they are misnamed?
<tjaalton> view_log should probably be view_xorg_log, and view_errors -> view_gdm_log
<tjaalton> mm, banshee taking 9999% of cpu
<tjaalton> bryce, bdmurray: I closed all xgl bugs already, needed the karma boost ;)
<bryce> tjaalton: heh
<bryce> tjaalton: ah good catch; I've pushed those fixes
<tjaalton> cool
<tjaalton> what about the fallback patch for xserver? if we applied that, we could drop failsafeDexconf and let the failsafe-mode run without xorg.conf
<tjaalton> s/fallback/autoconfig/
<bryce> sounds good to me
<tjaalton> ok, good
<tjaalton> also, as jcristau pointed out, the videoabiver has been bumped on debian (2.9->4) which would mean rebuilding all the video drivers if we uploaded current xorg/xorg-server from git
<tjaalton> but since the ABI hasn't really been changed, we could revert those changes for now
<tjaalton> and deal with the bump when intrepid+1 opens
<tjaalton> or, do it now and sync most of the drivers from experimental
<bryce> why was videoabiver bumped if the ABI hasn't really changed?
<tjaalton> to match the source
<bryce> ah
<tjaalton> it has been 4 since March i guess
<bryce> well, I don't have a problem with rebuilding all the video drivers at this point.  Still plenty of time before release.
<tjaalton> yeah, I can deal with that on Monday
<bryce> sounds good
<tjaalton> or tomorrow if I'm bored
<bryce> tomorrow for me is going to involve a whole lot of pruning shrubs in the backyard
<bryce> and digging stuff up
<bryce> (I'm getting a deck put in a couple weeks from now so we gotta do some landscaping to make room)
<tjaalton> hehe, sounds nice
<tseliot> tjaalton: we'll have to rebuild the nvidia drivers too
<tjaalton> tseliot: sure
<tjaalton> I've got a couple of concerts to perform on.. that said, I'm running late.. seeya ->
<johanbr> Hmm. After the latest Intrepid updates (X, among many other things, but not kernel) my touchpad only functions in "dumb mouse emulation" mode and Xorg.log says "(WW) AlpsPS/2 ALPS GlidePoint can't grab event device, errno=16"
<johanbr> Downgrading xserver-xorg-input-synaptics from 0.15.0+git20080820-1ubuntu5 to 0.14.7~git20070706-2.1ubuntu3 made my ALPS touchpad work again.
<bryce> morning
<tseliot> good morning
<Adri2000> is it intended that nvidia-kernel-common recommends the actual drivers?
<Adri2000> nvidia-kernel-common being a dependency of linux-restricted-modules, every machine using a non-free driver will also get the nvidia non-free driver installed, even if it has no nvidia card
#ubuntu-x 2008-09-07
<xerosis> hi, I wonder if anyone has a spare moment to help me pointpoint the source of a bug?
<tseliot1> Adri2000: as regards nvidia-kernel-common, I'm working on it.
<Adri2000> ok
<johanbr> Hi. After the latest updates, my ALPS touchpad stopped working (only dumb mouse emulation mode). But downgrading xserver-xorg-input-synaptics from 0.15.0+git20080820-1ubuntu5 to 0.14.7~git20070706-2.1ubuntu3 made the touchpad work again.
<tjaalton> johanbr: file a bug and attach the logfile
<tjaalton> johanbr: /var/log/Xorg.0.log
<johanbr> tjaalton: Alright, will do. Thanks.
#ubuntu-x 2009-09-01
<jbarnes> bryce: ping
<jbarnes> bryce: nm, emailed you
<bryce> ok
<tormod> bryce, we are doing lp hacking in #ubuntu-classroom now :)
<bryce> tormod, ok
<tormod> bryce, well now it's about apport hooks
<bryce> tormod, I've been working on an apport symptom hook script thingee for xorg
<bryce> I need to get that checked in before I go on paternity leave... hrm
<tormod> well congratulations :)
<tormod> although libdrm 2.4.13 is out, I know suokko is cooking on some optimizations, so I would hold off using our FFe a bit :)
<bryce> tormod, alright, I was wondering about that
<tormod> and I guess xserver 1.7 is out of question, although we now know it will come this month :)
<jcristau> "know"
<tormod> jcristau, I was thinking adding those quotes, lol
<bryce> is an rc out on it?
<tormod> not yet
<bryce> yeah then the quotes are definitely required ;-)
<tormod> I don't think the software itself is not solid, it just that dependencies and APIs are changing all the time...
<tormod> sarvatt was making 1.7 packages, but I think he had a lot of work
<tormod> once it's settling, we'll push it to xorg-edgers I guess
<bryce> yes, sounds good
<tormod> bryce, your "apport symptom hook script thingee" is that interactively asking the reporter like totem does?
<bryce> right
<tormod> cool
<tormod> bryce could for instance you do this bzr merge/upload: https://code.edge.launchpad.net/~tormodvolden/ubuntu/karmic/googleearth-package/karmic-bugs/+merge/11016
<tormod> it's crucial for mesa testing :)
<bryce> tormod, sure, I'll upload that in a bit
<tormod> bryce, thanks!
<tormod> could we have an FFe for a -radeonhd snapshot since this package is mostly for testing anyway?
<tormod> bryce, hold on, I screwed up the version on that googleearth package :/
<tormod> I am not sure what's correct, it's a native debian package with ubuntu delta
<bryce> ok
<tormod> I have been looking through the wiki to find the rules
#ubuntu-x 2009-09-02
<tormod> hmm https://lists.ubuntu.com/archives/ubuntu-devel/2008-May/025471.html indicates 1.2.3ubuntu1 is fine
<tormod> bryce, ok then the version was fine already (was also what dch -i gave me)
<bryce> ah ok
<bryce> needs update-maintainer run
<bryce> tormod, uploaded
<Ng> anyone else seeing odd resume crashes in karmic atm?
<Ng> X sort of comes back a bit, but windows don't render properly and it'll lock up shortly after, although sysrq still works
<d6g> I feel the performance of compiz and cairo-related software is a bit sluggish in karmic, anyone knows where should i start to figure out what is the problem? (i'm using ati mobility x300 with kernel 2.6.31-8-generic & radeon driver)
<Ng> bah, crash
<Ng> http://paste2.org/p/410429
<Ng> what should I do with that? kernel bug?
<kees> Ng: that's where I'd file it.  it's kernel, but it's intel drivers driver.  kernel team should be able to redirect correctly.
<Ng> kees: yeah that's what I was thinking. I even started filing it, but ubuntu-bug seems to be able to make firefox crash, and I got sidetracked finding the bug for that and subscribing to it ;)
<kees> urgh, it'd be funny if it weren't so sad.  :P
<Ng> hehe
<Ng> it's such a weird bug, it spawns a firefox process to take you to LP and most of the time that spawned firefox gets an X error and dies, which triggers an apport request for that
<Ng> but it's known and mdz reported it, so I feel safe in not doing anything else about that ;)
<kees> heh
<mac_v> anyone knows about the radeon driver and the slow FPS? is this the bug related to this issue> http://bugs.freedesktop.org/show_bug.cgi?id=21508 
<ubottu> Freedesktop bug 21508 in Driver/Radeon "low fps with radeon driver" [Normal,New]
<mac_v> just had a doubt since comments mention "radeon-rewrite"
<bryce> mac_v, the radeon-rewrite stuff is in place now in karmic
<mac_v> bryce:  i'v been using the radeon.modeset=1 , kms since the kernel -7, but i get half of the FPS i get without the kms :(
<mac_v> its ~500 with kms but without its ~1000
<mac_v> bryce: is there an upstream bug , you could direct me to regarding this? or is it the above bug ?
<bryce> mac_v, hard to say, the reporters did not give much solid info
<bryce> mac_v, but I do know that kms on -ati is known to have a performance regression, but I don't know the bug #.
<mac_v> oh :(
<Ng> ok, getting unusable X after every suspend now
<hyperair> at least you're not getting random panics after every other suspend/hibernate
<Ng> is that better than having to restart after every suspend? ;)
<bryce> Ng, bug #?
<hyperair> Ng: how is your X unusable anyway? all i need to do is restart compiz after every suspend.
<Ng> bryce: just waiting for the 3g network to upload it
<bryce> hyperair, did you test the kernel patch proposed for the compiz freeze bug yet?
<Ng> hyperair: it might be that, I didn't actually try that. it just doesn't seem to draw windows/borders
<hyperair> bryce: no i didn't. what patch is that?
<hyperair> Ng: that's the exact problem. restarting compiz should do the trick. just blindly alt+f2 and type compiz ;-)
<Ng> heh
<hyperair> that's what i do. ended up sending compiz to a few friends if the run dialog didn't focus properly
<bryce> hyperair, search lp for the "compiz 100% cpu" bug
<bryce> hyperair, filed against linux
<bryce> anyway, I think both of you have that same bug
<hyperair> bryce: but my compiz doesn't take 100% cpu
<hyperair> at least, i don't think it does.
<bryce> hyperair, which is why you ought to test the patch ;-)
<hyperair> heh yeah, considering i'm already running a patched kernel
<bryce> 100% cpu is just one symptom, the patch fixes a number of situations where the new mesa causes failures
<bryce> you can also try downgrading to the x-retro ppa's mesa 7.5, but that's just a workaround
 * bryce back to bugz
<Ng> epic 3g speed fail aside, I'm up for trying a patch
<hyperair> bryce: i'm running a git kernel and the said patch is already in the kernel i think
<Ng> hyperair: out of interest, what hardware are you seeing this on?
<hyperair> Ng: i965 8086:2032
<hyperair> 2a03 i mean
<Ng> I'm assuming bryce meant bug 419264, and it just strikes me a little bit that people there are seeing it all over the place, I'm only seeing it on resume
<ubottu> Launchpad bug 419264 in linux "Uses 100% CPU with latest mesa/libdrm update" [High,In progress] https://launchpad.net/bugs/419264
<hyperair> yeah i saw that too
<hyperair> the last comment has a commit hash
<hyperair> which is in my git tree of the kernel
<bryce> jbarnes, http://people.canonical.com/~bryce/Graphs/drivers.svg
<jbarnes> woo
<jbarnes> beating ati finally :)
<jbarnes> looks like nvidia will be higher soon too
<bryce> yep
<ScislaC> 9.04? Who uses /that/? ;)
<bryce> I wish nouveau would develop faster, I hate putting time into triaging -nvidia bugs, always seems like a waste
<bryce> ScislaC, ;-)
* bryce changed the topic of #ubuntu-x to: https://wiki.ubuntu.com/X
<ScislaC> :P
<hyperair> what was it before?
<ScislaC> Ubuntu 9.04 released! | https://wiki.ubuntu.com/X
<hyperair> ah
<Ng> hyperair: yeah restarting compiz seems to do the trick
#ubuntu-x 2009-09-03
<pwnguin> damn bryce
<pwnguin> i guess tagmail is my punishment for ignoring wacom
<tjaalton> pwnguin: nonsense, those bugs are assigned to me ;)
<tjaalton> two exams left this week, hopefully I'll be able to update wacom to support intuos4 after that..
<Ng> bryce: downgrading mesa did indeed get me working compiz after resume, as you suggested :)
<seb128> Ng, you got compiz to freeze after resume?
<seb128> I'm wondering if I didn't get the same issue, my xorg was frozen after resume yesterday
<Ng> seb128: yes, I tried several suspends over the course of the last couple of days and it happened every time
<Ng> I've had one crash where X was completely dead after resume, but the other times it was just compiz and restarting it blindly with alt-f2 (at the suggestion of hyperair) resurrected things
<seb128> I got it twice so far but I didn't suspend a lot since I upgraded
<Ng> I suspend at least twice a day ;)
<seb128> thanks for the hint in any case
<seb128> I suspend often but I just came back from vac
<seb128> and I had alt-tab freezing compiz issues so I downgraded thing for a while
<seb128> until a fixed linux deb came to test which fixes that
<tseliot> Ng: did you file a bug report about the regression in mesa?
<seb128> and yesterday I noticed the suspend issue
<Ng> yeah that stuff is weird, I've not seen any other compiz hangs from alt-tab or whatever, it was just resume
<Ng> tseliot: bryce seemed to think it was one that's already filed, but I'll happily file another
<tseliot> Ng: ok, if bryce said so, I'm sure it was already filed ;)
<Ng> I hope it's an easy fix somewhere, X has been almost perfectly stable in karmic otherwise for me. I think I've had maybe 3 actual real hangs since I upgraded weeks and weeks ago, until this mesa thing
<tormod> bryce: I wonder if ati KMS is fscked in stock Karmic, see bug 410058
<ubottu> Launchpad bug 410058 in xserver-xorg-video-ati "Black screen with radeon KMS" [High,Fix committed] https://launchpad.net/bugs/410058
<tormod> maybe we need to push a new libdrm anyway and rebuild the -ati. see xorg-edgers for a libdrm 2.4.13.
<tseliot> tormod: do you refer only to libdrm-radeon1 or also to the drm in the kernel?
<tormod> in the kernel?
<tseliot> yes
<tseliot> so you were referring to the user space component
<tormod> gotta run!
<Q-FUNK> would anyone remember which file in X server core defines PCI manufacturers with individual video drivers?
<Q-FUNK> Ã¶Ã¶.. defines the match between ID and driver
<jcristau> hw/xfree86/common/xf86<mumble>.c
<jcristau> also, grep.
<Q-FUNK> jcristau: would you have a minute to examine a patch?  my C skills *are* limited and your guidance would be appreciated.
<jcristau> not right now, sorry
<Q-FUNK> ok
<jcristau> but, email works.
<Q-FUNK> ok, I'll do that
<Q-FUNK> jcristau: sent.
<jcristau> Q-FUNK: not sure what's the point of including amd in there
<Q-FUNK> mostly for backward-compatibility.
<jcristau> looks fine otherwise
<Q-FUNK> not essential, though, indeed
<jcristau> backwards compat with what? a driver that doesn't support current servers? :)
<Q-FUNK> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/423866
<ubottu> Launchpad bug 423866 in xorg-server "AutoConfigure support for older Geodes" [Undecided,New]
<Q-FUNK> hmm.. good point :)
<Q-FUNK> I've attached a simpler patch for X 1.4 there, also
<Q-FUNK> and a slightly cleaner version of what I mailed you
<Q-FUNK> bug #423866
<ubottu> Launchpad bug 423866 in xorg-server "AutoConfigure support for older Geodes" [Undecided,New] https://launchpad.net/bugs/423866
<Q-FUNK> erm... right
<Q-FUNK> jcristau: I also just noticed that cyrix and nsc no longer ship with ubuntu.  we'd probably need to skip that part of the changes.
<Q-FUNK> do I assume that whatever wasn't matched by a specific driver in that file falls back to vesa?
<jcristau> yeah
<Q-FUNK> right, so in that case we'd only need the GX2 part added
<mac_v> bryce: for Bug 397839 , you added the ATI in the description , is it because it is *now* not fixed in ATI alone ?
<ubottu> Launchpad bug 397839 in gnome-power-manager "Screen randomly goes off in karmic" [Critical,Fix released] https://launchpad.net/bugs/397839
<CShadowRun> hi, my friend told me that he configured his multi display setup with ubuntu's built in config, on an nvidia card, i assume that means nvidia and xrandr play nice in karmic?
<bryce> mac_v, no it's an automatic script that adds that stuff to bug descriptions.  No particular significance to that.
<mac_v> oh ;) ... thanks
<mac_v>  i have a doubt about the $xset command.... i was using $xset s 300 for the screensaver problem , now i'm not sure how to reset the time to default , $xset reset is for something different, do i just to an $xset s 600 ?
<tormod> mac_v it is reset if you log out
<mac_v> tormod: hmm... but previously the screen blanking bug was occurring at 10 mins but after i used the xset command it started happening at 5mins , so i thought this was the cause...
<mac_v> good to know i didnt mess up ;)
<mac_v> thanks
<bryce> yeah the blanking (or non-blanking) bug still persists.  power management seems really screwed up on my hardware
 * mac_v started having burn-ins :(
<tormod> power management is spread out between way too many packages and independent developers...
<Q-FUNK> bryce: do you think that we could get the patches at bug #423866 merged for at least karmic?
<ubottu> Launchpad bug 423866 in xorg-server "AutoConfigure support for older Geodes" [Undecided,New] https://launchpad.net/bugs/423866
<bryce> Q-FUNK, comment #5 implies the patch was updated but isn't attached.
<Q-FUNK> bryce: erm. right. correct.  any tool you can recommend to refresh the patch in a more efficient manner than copying the original all over again, patching that, removing the extraneous content, then diffing again?
<bryce> that sounds like about how I'd have to do it
<Q-FUNK> quilt seems ot be able to perform all sorts of backflips on patches, but I haven't quite figured out how to use it.
 * bryce nods
<hyperair> man quilt!
<hyperair> i only ever use push, pop and refresh though
<hyperair> and add
<Q-FUNK> bryce: updated
<Q-FUNK> bryce: I might still add nsc and cyrix to the 1.4 patch for Hardy, but the 1.6 patch can pretty much go as-is for karmic.   for jaunty, it can go too, but it would have to go in at the same time as a geode with cherry-picked GX2 fixes.
<Q-FUNK> I'm currently narrowing down what could be the bare minimum changes we'll need to apply to -geode in jaunty before we can safely apply that X server patch.  
<Q-FUNK> in karmic, though, we already have the latest upstream geode, which no longer crashes on GX2 hardware.
#ubuntu-x 2009-09-04
<Bigshot_> my xserver is trying to start but fails i see ubuntu logo mouse cursor but then it goes black screen then again the same ubuntu logo and then black screen any solutions?
<Bigshot_> i am using alpha5
<Bigshot_> Xorg.0.log says it is loading ati_drv, radeon_drv, vesa_drv,fbdev_drv and then unloading vesa_drv, fbdev_drv
<Bigshot_> aiglx : enabled glx_texture form pixmap with driver support
<Bigshot_> ok i started with vesa and it worked
<Ng> Bigshot_: it would probably be useful to have /var/log/Xorg.0.log from one of the failed starts
<Bigshot_> it is loading ati_drv, radeon_drv, vesa_drv,fbdev_drv and then unloading vesa_drv, fbdev_drv
<Bigshot_> i can't copy the Xorg.0.log as i don't have internet on that puter
<Bigshot_> Ng right now i am running it on vesa
<Bigshot_> how can i make it run on 3200 ati radeon?
<Ng> I'm afraid I'm not sure, I've almost no exposure to ati hardware and linux
<jcristau> Bigshot_: without seeing the X log there's not much we can tell you..
<Bigshot_> k
<CShadowRun> Does anyone know if the new version of ubuntu has shared graphics memory for nvidia, so i can have a proper extended desktop across multiple cards?
#ubuntu-x 2009-09-05
<bryce> [ubuntu/karmic] fglrx-installer 2:8.660-0ubuntu1 (Accepted)
#ubuntu-x 2009-09-06
<dzibo> hello
<dzibo> can someone help me start x srever
<billybigrigger> any video gurus around?
<billybigrigger> i've been trying to get my webcam working since 2.6.30-rc1 i still can't get anything but a green screen in cheese
<billybigrigger> Bus 004 Device 002: ID 045e:00f7 Microsoft Corp. LifeCam VX-1000
<billybigrigger> uses the sonixj gspca module, and i've seen numerous kernel fixes for this module but still with 30-9 nothing seems to be working
#ubuntu-x 2010-09-06
<RAOF> intrader: Could you try a Maverick LiveCD?  We've just released the beta.
<JanC> I guess it would also be useful to know what hardware it is
<RAOF> It would appear to be nvidia-something-old.
<RAOF> Man, a full piglit run takes a good long while.
<RAOF> (When it doesn't hang the GPU)
<RAOF> Yay!  A bug that is reproducible on hardware I own.  I love those!
<RAOF> Anyone around who feels like sponsoring xserver-xorg-video-ati from git?
<RAOF> It's just sitting there innocently in pkg-xorg git, waiting to fix an xserver crash.
<tseliot> RAOF: sure
<tseliot> RAOF: you prepended a "d" to xserver-xorg-video-ati in the changelog. I'll correct that and upload
<RAOF> Thanks
<tseliot> RAOF: also I made a diff between revision ubuntu4 and ubuntu5 and it seems a bit excessive (compared with the description in the changelog): http://pastebin.ubuntu.com/489168/
<tseliot> any ideas?
<tseliot> (it's not just the aclocal changes)
<RAOF> tseliot: Hm, it's a bit late here.  Can I check that in the morning and see if I can work out why the diff is so big for you?
<tseliot> RAOF: sure, no hurry
<apw> anyone see the X-server wedging on i915_gem_throttle_ioctl ?
<apw> s/on/in
<jonasfa> Hello guys. As Maverick supports multitouch devices, I'm willing to develop an Android app to use the device as a multitouch mouse.
<jonasfa> where can I find any docs to help me?
<jonasfa> where can I find docs on how to simulate a MT device?
<ScottK> RAOF: How is ATI + Maverick these days?  Need to set expectations from someone who's about to try it.
<RAOF> ScottK: Not cutting-edge cards (up to r700, which is Radeon 4xxx) should have decent 3D and 2D, and should run Unity properly once we get mesa 7.9.  The newest evergreen cards (Radeon 5xxx I believe) have modesetting support, but no acceleration in Maverick.
<RAOF> ScottK: fglrx doesn't work at the moment in Maverick, but should (AMD willing!) work by release.
<ajmitch> RAOF: by 'decent 3D', how well does it work?
#ubuntu-x 2010-09-07
<RAOF> My r700 likes compiz just fine.
<RAOF> And, with mesa 7.9, is pretty happy with Unity.
<RAOF> It doesn't run Civ 4 under wine, though.
<ajmitch> mobility radeon HD 4850, I'm wondering how well it'll go with games instead of using fglrx :)
<ajmitch> namely WoW under wine, of course 
<RAOF> :P
<ajmitch> civ iv looks a bit funny even with fglrx
<RAOF> I'd give it a go; it's possible that the driver doesn't implement something that wine wants, though.
<ajmitch> quite probably :)
<ajmitch> I geuss we should be hoping for fglrx to still work by release
<RAOF> It works now?
<ajmitch> I mean it works in lucid, having it break for people upgrading could be bad
<RAOF> Ah.  Yeah.
<RAOF> apw: Is that wedge in mutex_lock_slowpath?  There seems to be a deadlock somewhere you can hit, and hit it much more frequently with two monitors.
<ScottK> RAOF: Thanks.
<JanC> I'll try my Radeon HD 4350 one of the next days...  âº
<apw> RAOF yes its trying to get the dev struct_mutex, from the minimal analysis I did I cannot find anyone holding it and doing anything
<apw> that one is going to bite us hard after release, do you have a bug open on it?
<RAOF> apw: I think this is it: https://bugs.freedesktop.org/show_bug.cgi?id=28805
<ubot4> Freedesktop bug 28805 in Driver/intel "[Arrandale] Intermittent freezes - missed interrupt?" [Normal,Resolved: fixed]
<RAOF> apw: Launchpad bug #568138
<ubot4> Launchpad bug 568138 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "[arrandale] deadlock in i915_gem_madvise_ioctl (affects: 11) (dups: 1) (heat: 60)" [Medium,Confirmed] https://launchpad.net/bugs/568138
<apw> RAOF, interesting, then its not arrandale specific
<RAOF> apw: Yeah, I think the bug is mis-titled.
<apw> mine is certainly something older ... thanks for the ptr
<RAOF> Hm.  I need to re-check my upstream bugmail filtering; I should have noticed that getting marked as resolved.
<RAOF> I could reproduce it relatively frequently (~1/day) when I plugged in my second monitor.
<RAOF> I should try the 2.6.36-rc3 kernel to see if it resolves it.
<seb128> hey there
<seb128> is there any known bug about external monitor on dock stations not activating since recently?
<seb128> on intel card
<seb128> on a dell latitude serie
<seb128> what would be buggy? xorg? intel driver?
<seb128> it started a few days ago and it doesn't seem to be the linux version in use
<RAOF> It's likely to be either the intel driver or the kernel; most likely the kernel.
<RAOF> We haven't had an -intel upload for a while, so I'd guess at kernel.
<apw> RAOF, i can reproduce it pretty much once a day as well with just single screen
<apw> RAOF, and thats with maverick kernel on lucid userspace
<RAOF> apw: Ah, well.  That might be a different bug to mine, then.
<RAOF> apw: Or it could be exactly the same bug, and it just gets triggered much more infrequently on gm45
<apw> RAOF, hard to say isn't it, sounds very similar
<RAOF> Yeah.
<RAOF> The kernel PPA has a build of 2.6.36-rc3, right?
<apw> RAOF, should do yes
<apw> RAOF, it does indeed
<RAOF> Man, my arms are so much better after pushups this week than last week.
<RAOF> But still enervated.
<RAOF> tseliot: I've investigated the xserver-xorg-video-ati diff.  That's the removal of a copy of the XRandR modes code that was added to the -ati in order to build properly against xserver 1.2, but it actually has never been built (as it's conditional on XRandR 1.2 support, which xserver 1.2 didn't have).
<RAOF> tseliot: It's in upstream git; I haven't found where we've picked up that commit, but it's entirely benign.
<tseliot> RAOF: can you add it to the changelog, please?
<RAOF> It wasn't introduced in that change; I can hunt down when it _was_ introduced if you like.
<RAOF> git is being remarkably unhelpful at working this out.
<tseliot> RAOF: it would suffice to mention the change in the changelog
<tseliot> a one line explanation would be fine
<tseliot> for example what you wrote here on irc
<ricotz> tseliot, hello, do you still expierencing the docky freeze on application starts?
<tseliot> ricotz: yes, shall I update my system?
<ricotz> tseliot, are you using 2.0.6-2 now?
<RAOF> tseliot: Pushed to pkg-xorg git.
<tseliot> ricotz: no, I'm using 2.0.5-1
<tseliot> RAOF: ok, thanks, I'll have a look at it and upload your changes
<RAOF> Thanks muchly.
<ricotz> tseliot, the newer version should be available, i didnt ran into this bug myself, and i thought it might be some glib problem
<tseliot> ricotz: ok, let me check
<tseliot> ricotz: yes, I can still reproduce the problem with 2.0.6-2. Let me update the whole system and see if anything changes
<ricotz> tseliot, this must be related to some dependency and it is only affecting maverick
<tseliot> ricotz: yes and I recall an update of glib just before the breakage
<ricotz> tseliot, you are now on glib2.0 2.25.15?
<tseliot> ricotz: 2.25.14-1ubuntu2 but I'm about to upgrade to 2.25.15-0ubuntu2
<ricotz> ok
<tseliot> I'll let you know how it goes
<ricotz> tseliot, thanks
<tseliot> ricotz: same problem with the new glib
<tseliot> let me know if you need further information
<tseliot> the last few comments are interesting though: https://bugs.launchpad.net/ubuntu/+source/docky/+bug/628372
<ubot4> Launchpad bug 628372 in docky (Ubuntu) (and 1 other project) "Docky freezes when launching application (affects: 10) (dups: 1) (heat: 52)" [Undecided,Confirmed]
<tseliot> ricotz: if you tell me how to try the latest code, I'll tests it here
<tseliot> s/tests/test/
<ricotz> tseliot, you can try the trunk version with this ppa https://launchpad.net/~docky-core/+archive/ppa
<tseliot> ricotz: shall I update gio-sharp too?
<ricotz> tseliot, if should be the same as maverick ships now
<tseliot> ah, right
<tseliot> ricotz: same problem again. Maybe something in the handler of the ButtonReleaseEvent triggers a bug somewhere e.g. in gtk# ?
<ricotz> tseliot, ok, this really needs some more investigation, thanks for your time, too bad i can't reproduce this
<tseliot> ricotz: np
<Sarvatt> hmm I can't reproduce that docky problem on nouveau nvidia or intel on maverick
<Sarvatt> maybe I need to enable all those plugins and helpers
<ricotz> i am suspecting nvidia-blob, but didnt want to say it
<tseliot> ricotz: wait a second, I purged the packages from the PPA, ran docky in debug mode and I can't reproduce the problem any more now. Maybe some cached content (or configuration file in /etc ) was removed
<Sarvatt> well I didn't test the blob very well, the machine i tested it on can't use the blob because the board is failing and graphics are corrupted all over the place but i didn't see any freeze through all of the corruption
<tseliot> oh, and I'm using radeon
<Sarvatt> oh just read the bug
<Sarvatt> i'm using 2.1.0~bzr1623-0ubuntu1~10.10~dockycore1
<Sarvatt> Revision 1622 fixed it on kernel version 2.6.35.19. Thanks! -- Well then 1624 will break it again because I reverted 1622.
<ricotz> tseliot, could you add a comment to the bug for this purge?
<ricotz> Sarvatt, yeah someone got motivated doing things
<tseliot> ricotz: sure
<Sarvatt> ricotz: wait, so its fixed again in 1625? lol
<Sarvatt> fixed in 1622, reverted in 1624, revert reverted in 1625?
<tseliot> it's fixed here with:
<tseliot> [Info  15:06:51.480] Docky version: 2.0.6 Release
<tseliot> [Info  15:06:51.486] Kernel version: 2.6.35.20
<tseliot> [Info  15:06:51.486] CLR version: 2.0.50727.1433
<tseliot> maybe try purging docky?
<Sarvatt> oh guess it's not related to that then
<ricotz> tseliot, i cant imaging what a purge could cause to our config, it is all saved in the user dirs, it is pretty weird
 * tseliot nods
<ScottK> Sarvatt: Did you get my ping on intel stuff from over the weekend?
<Sarvatt> ScottK: I just got up and haven't read the scrollback yet, checking now
<ScottK> Sarvatt: OK.  Thanks.
<Sarvatt> ScottK: #dri-devel is where all of the mesa developers are and I've never seen a kde dev in there. Is it just intel thats broken or everyone using mesa like it sounds like? It looks like phoronix picked up on the story giving it a lot more exposure and some mesa devs have replied in here - http://www.phoronix.com/forums/showthread.php?t=25907
<ScottK> Sarvatt: It's hard for me to tell what's accurate and what's complete crack from that thread.  I know the stuff about trolltech  controlling KDE development is complete crap.
<Sarvatt> just the posts from marek and airlied and bridgman basically
<ScottK> Sarvatt: The feeling among the KDE devs is that the Intel people can't be communicated with.  I suspect that's not accurate and would like to find a way to fix the social disconnect.
<ScottK> Reading it again (knowing who to pay attention to)
<Sarvatt> ScottK: Intel specifically? They are around every day pretty much all of the time in #intel-gfx and #dri-devel
<ScottK> I'm not saying they are right, just that's the perception.
<ScottK> As is usual when people are pissed off, I'm sure it's not so bad as that, just it takes some work to bridge the gap.
<ScottK> Sarvatt: Do any of the right people come to UDS?
<Dr_Jakob> ScottK: I only know of Jesse Barnes (from intel) going to UDS.
<Sarvatt> jbarnes has in the past but not recently, perhaps you can speak to RAOF about bringing it up at the XDS coming up soon?
<Dr_Jakob> So what is the actuall problem?
<Sarvatt> <ScottK> Sarvatt: What would be the way to communicate the following to Intel developers in a way that would be constructive and useful (re the ongoing kwin mess):
<Sarvatt> <ScottK> <ScottK> mgraesslin: While I'm waiting for kdebase-workspace to compile, it would help a lot if I could get a list of the capabilities Intel is misreporting (or some idea how to figure it out).  Canonical does have people that can talk to Intel if I can tell them what needs to be communicated.
<Sarvatt> <ScottK> <mgraesslin> the list is rather short: we need framebuffer objects and shaders and in inderict rendering mode the unsupported (impossible) extensions should be removed. That's nothing I can provide as that's something only the driver developers can know
<Sarvatt> <ScottK> Additionally:
<Sarvatt> <ScottK> <mgraesslin> ScottK: if they need a reference: https://bugs.kde.org/show_bug.cgi?id=173556#c41
<Sarvatt> <ScottK> <mgraesslin> that's how NVIDIA does it
<ubot4> KDE bug 173556 in compositing "Shader support not detected on various systems" [Normal,Resolved: fixed]
<Sarvatt> the impression that I get is that GL compositing in KDE is designed around the nvidia binary drivers and is messed up with mesa because of extensions being reported that only partially work
<Sarvatt> which is largely based on hardware limitations..
<Dr_Jakob> Well and a totaly crap GLSL compiler.
<Dr_Jakob> Which intel fixed in 7.9
 * Sarvatt nods
<Dr_Jakob> Heh, that bug you posted is just some guy who can't get direct rendering work :)
<Dr_Jakob> But yeah, bug reports from people having problems would be nice.
 * ScottK has several systems with problems.
<ScottK> FWIW, mgraesslin was trying yesterday (and failing, AFAIK) to get ATI working.
<ScottK> The one Intel system he has access to seems to actually work.
<Dr_Jakob> ATI prop or ATI mesa?
<ScottK> IIRC mesa.
<Dr_Jakob> driver?
<ScottK> Dunni
<Dr_Jakob> ok
<ScottK> Dunno
<Sarvatt> ScottK: maybe you can suggest to him to just make it so blur/lanczos are never used with mesa by default so a huge blacklist doesn't need to be maintained?
<ScottK> Having read the thread again it seems like a communication issue primarily.
<Dr_Jakob> 7.9 will hopefully be a really nice release.
<Sarvatt> yeah I'm hoping there will be a RC release soon so we can try to get it in maverick, putting a git snapshot is sketchy. it's supposed to branch from master this week at least
<Dr_Jakob> http://www.x.org/wiki/Events/XDS2010/Program
<Dr_Jakob> Somebody is going to talk about what is there.
<Dr_Jakob> "Which functions can app developers rely on ?"
<Sarvatt> oh nice - Which functions can app developers rely on ?
<Sarvatt> yeah, thanks for the heads up!
<Sarvatt> RAOF and cnd are going
<Dr_Jakob> Ok, I'll say hi
<ScottK> Sarvatt: No blur plus the new mesa isn't too bad.
<Sarvatt> I dont get that because your 945GME doesn't support GLSL so it shouldn't be trying to use blur anyway
<Sarvatt> oh ok looks like theres a non GLSL version in there too, I thought I read there wasn't in that blog..
<cnd> RAOF, have you had a chance to take a look at my xorg-server and synaptics changes for maverick?
<Sarvatt> ScottK: can you try new mesa, install driconf, and disable the "Enable limited ARB_fragment_shader support on 915/945" option and see if blur works?
<ScottK> Sure
<Sarvatt> actually you can just put this as ~/.drirc and restart if driconf pulls in too much gtk stuff - http://sarvatt.com/downloads/drirc.txt
<ScottK> First I have to purge the patched kwin.
<ScottK> It won't let me activate blur.
<Sarvatt> it should switch to the GL_ARB_fragment_program blur implementation with that and that might actually work, 7.9 enabled that ARB_fragment_shader option by default which was disabled on 7.8.x and it looks like that's the extension it checks to use the GLSL shader variant instead
<ScottK> I see.
<Sarvatt> I don't know enough about this to know whats wrong with the actual shader it compiles if that doesn't work
<ScottK> Sarvatt: Odd result.  Started with effects enabled (inclulding blur).
<Sarvatt> any problems?
<ScottK> Not so far (on 30 seconds of using)
<Sarvatt> so 7.9 is better but that option was making it bad :)
<Sarvatt> i'm not sure if you can just use fragment_shader=0 in the env when launching kwin to fix that, hmm
<ScottK> Keeping in mind I know little about this part of the system (and hope to keep it that way), can we suggest a different way to detect to use GLSL that would be more reliable?
<Sarvatt> ScottK: I'm sorry, got something else that needs my attention ASAP and I need to step away from it for a bit, there are a few ways we can work around it though
<ScottK> Sarvatt: OK.  Let me know when you can chat.
<Sarvatt> ScottK: sorry, got caught up in some intel sandybridge stuff. I think the first step is to rebase that mesa to the mesa 7.9 branch as soon as it opens any day now and get the output from launching kwin with MESA_GLSL=dump,nopt env variable set to get a good upstreamable bug report. it may already be fixed in git, they've been fixing it crazy amounts since that 0825 snapshot. we can disable that option by default in mesa easily or kwin can export
<Sarvatt>  fragment_shader=false into the env on 915/945 possibly to work around it?
<ScottK> Sarvatt: I've got roughly 60 seconds until I have to leave for the next 10 hours or so.  If the extension isn't working reliably why don't we just globally disable it?
<ScottK> Let me know when there's an updated package for me to test.
<Sarvatt> that's a question best asked in #dri-devel, I assume they enable it because it does work for some situations and the benefits outweigh the negatives but I'm not sure :) things like cairo-gl are reliant on that option being enabled or they don't work on this old class of hardware
<Sarvatt> will do!
<Sarvatt> i'll patch it to disable by default anyhow
<Sarvatt> really, convince that guy to discuss this in #dri-devel with the mesa devs somehow if you can instead of just saying its broken, it might be easily fixed but they dont use KDE or something
<Sarvatt> jcristau: how would you say the results with the legacy 2.12 have been in squeeze? looks quite negative from a quick glance
<jcristau> Sarvatt: yeah ums is all broken
<jcristau> my 945 crashes X with a lockup message on startup, and 855 just get hard hangs
<ScottK> Sarvatt: Kwin upstream doesn't have the right hardware to make it fall over, so it's a little hard for him to report bugs.
<ScottK> I'd be willing to help, but don't exactly know what to provide.
#ubuntu-x 2010-09-08
<RAOF> Sarvatt: You still up?  Have any opinions on the fbdev vs vesa for i8xx conundrum?
<ScottK> RAOF: Is fbdev what we had for Lucid/currently in Maverick?
<RAOF> For Lucid we had intel + UMS.
<RAOF> With all the GPU hangs / crashes that entails.
<ScottK> That was mostly 845/855, right?
<RAOF> Yeah.  865 isn't in the blacklist.
<RAOF> i830, i845g, i855
<ScottK> OK.
<ScottK> Every time I see 8xx, I get nervous.
<ScottK> My 865 isn't doing too badly.
<RAOF> That's good.  Intel obviously had got some of the hardware bugs out of the system by then :)
<ScottK> New Mesa plus fragment_shader=false looks like a big win on the one 945 box I've tested it on so far.
<RAOF> I've got your bug down for bug #631413
<ubot4> Launchpad bug 631413 in mesa (Ubuntu) "[FFe] Mesa 7.9 (affects: 2) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/631413
<ScottK> I have two others and a 965 box (plus the 865) yet to test it on.
<ScottK> Cool.
<soreau> Hello, I was wondering if you can bisect packages with xorg-edgers repo or are the packages kept around or constantly discarded
<bjsnider> Sarvatt, major new beta blob: http://www.nvnews.net/vbulletin/showthread.php?p=2314331
<bjsnider> they've removed all OpenGL, VDPAU, CUDA, and OpenCL header files
<soreau> ie. if you find any bug in x or driver, can you bisect using the repo somehow or is this information overwritten
<bjsnider> is nvidia-current-dev even going to be necessary now?
<RAOF> soreau: You can sometimes grab older packages out of xorg-edgers, but they get culled pretty ruthelessly.
<EagleScreen_> hello
<EagleScreen_> has this channel relation to xorg-edgers?
<EagleScreen_> xserver-xorg-video-intel driver 2.12.0 give crashes in some hardwares
<kklimonda> EagleScreen_: xorg-edgers tend to do things like that ;)
<EagleScreen_> a build of version 2.9.1 for maverick would be nice for that people
<EagleScreen_> it could be renamed to xserver-xorg-video-intel-legacy
<EagleScreen_> so people in maverick could be happy
<EagleScreen_> i have tried to upload a rebuild for maverick in my ppa, buit it does not build
<EagleScreen_> ../../uxa/uxa-render.c:456: error: too few arguments to function 'image_from_pict'
<EagleScreen_> I have taken this idea from openSUSE, which has two driver versions in the repository, the 2.12.0 and the 2.9.1
<EagleScreen_> some people need the 2.9.1 and some people prefers the 2.12.0
<RAOF> There are a couple of legacy options - there's the actual legacy branch in a PPA, and the newer shadow branch in another PPA.
<RAOF> The 2.9.1 driver with UMS isn't enough of a stability win for me to bother with it.
<EagleScreen_> RAOF: 2.9.1 works well with KMS
<RAOF> And 2.12 doesn't?
<RAOF> Can you point to a bug report?  All that I've seen suggest that 2.12 is a pretty much unqualified win over 2.9 + KMS.
<EagleScreen_> 2.12 doesnt
<RAOF> On what hardware does 2.12 not work where 2.9 did?
<RAOF> Is there a bug report?
<EagleScreen_> yes
<EagleScreen_> RAOF: take a look at this https://bugs.freedesktop.org/show_bug.cgi?id=26937
<ubot4> Freedesktop bug 26937 in Driver/intel "X server freezes when watching flash videos in Firefox in full screen mode" [Normal,Reopened]
<RAOF> EagleScreen_: And that works on 2.9.1?  There doesn't seem to be any indication of when that bug first appeared, except that it âalso occurs on 2.10â
<EagleScreen_> RAOF: yes it works with 2.9.1
<RAOF> That would be something very useful to add to that bug report; even more useful would be identifying which commit broke it by running a git bisect.
<EagleScreen_> ops
<EagleScreen_> I'll mention it
<doko> bryce: any idea about bug #632594? (btw, difficult to catch if you're not on #ubuntu-devel or #distro)
<ubot4> Launchpad bug 632594 in xorg-server (Ubuntu) (and 1 other project) "xvfb 1.9 and/or metacity not working on the buildds (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/632594
<ScottK> Sarvatt: mesa from your PPA looks good on i865.  I've got all the default effects except blur (no suprise there) after I manually enable effects.
<Sarvatt> ScottK: thanks for the feedback! 965 + KDE is what I'm worried about with it, whipping up a patch to disable fragment shaders by default on gen3 intel right now
<ScottK> Sarvatt: Sure, but I figure additional test results that show now regression are helpful.
<Sarvatt> yeah they are, thats why I thanked ya! :)
<Sarvatt> RAOF: I mentioned it in #ubuntu-kernel yesterday but I really think KMS + fbdev is the way to go instead of blacklisting KMS so vesa can be used. I haven't gotten a single report that fbdev didn't work when vesa did and it has the bonus of working at native resolution on more machines. not to mention opting in to intel buggyness is just an xorg.conf option away instead of forcing on KMS and using the xorg.conf. plus we can maintain that outside 
<Sarvatt> of the kernel :)
<jcristau> i've got at least one report of kms not working on a 830
<Sarvatt> failing before X?
<jcristau> iirc yes
<Sarvatt> hmm, that stinks. I haven't seen any that weren't just KMS+intel being busted
<jcristau> hmm, or maybe not
<jcristau> the pointer he gave me was https://bugzilla.kernel.org/show_bug.cgi?id=15070
<ubot4> bugzilla.kernel.org bug 15070 in Video(DRI - Intel) "kernel mode switching broken on i830" [Normal,Needinfo]
<Sarvatt> our plymouth crap might screw with it up too since it talks directly to drm
<Sarvatt> I see why it goes black in that bug though
<Sarvatt> [   14.612773] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
<Sarvatt> [   14.614920] Console: switching to colour dummy device 80x25
<jcristau> ugh yeah, vga=0x305
<jcristau> thanks for pointing that out
<Sarvatt> vga= breaks the drmfb handoff?
<jcristau> vga= gets vesafb loaded
<jcristau> i'm not sure handoff works reliably
<Sarvatt> we always have vesafb loading in ubuntu and grub2 is using it, handoff works fine here but i've seen some bugs where it isn't but I'm not sure if initramfs-tools is doing something wacky when vga= is passed. I saw something in the changelog recently about it
 * jcristau doesn't know
<Sarvatt> first thing i do on every machine in ubuntu is pass vesafb=sucks to stop it from loading :D
<jcristau> heh
<Neko> swing!
<Neko> is there a readily available tool on maverick to trace X server behavior, calls, time spent doing whatever? I have an X server here (on top of fbdev) which is acting weird and soaking up 90% CPU time just in a terminal
<Neko> I think I'm seeing 629910 or 617994
<Neko> but this is armel.. no nvidia or ati proprietary drivers (yet :)
<Sarvatt> Neko: you've got xrestop and xtrace, but the problem is most likely above X and a normal system profiler like sysprof, perf or oprofile would be the best place to start looking. have you tried different gtk themes out?
<Sarvatt> disabling font smoothing/hinting might help a bunch as well, what color depth are you running at? does xterm have the same problems?
<Neko> 16 bit for now but I am going for 32
<Neko> oprofile sounds like the best solution then
<Neko> don't have perf, still on 2.6.31 :(
<Sarvatt> ScottK: here's where the fragment_shader option was enabled by default on 915/945 with some rationale btw - http://cgit.freedesktop.org/mesa/mesa/commit/?id=a58514cc9c5cc5867f9140700462c5ac5749550d
<Sarvatt> sounds quite probably it may be working by release time, will have to check when we get a more recent snapshot/RC but reverting that in a patch is easy enough if not
<bjsnider> Sarvatt, are you planning on updating nvidia-current to the 260 beta  in x-updates or waiting for a stable 260 blob?
<Sarvatt> bjsnider: I still haven't looked at it, yeah I'll update it
<ScottK> Sarvatt: I can retest if it's working at release time.
<ScottK> Sarvatt: I'm slowly working through all my Intel boxes to see how we do with the new mesa.
<Sarvatt> I plan on testing too, got the same 945GME but it's my main work machine :)
<ScottK> That's what live sessions are for.
<Sarvatt> yeah but disappearing from IRC isn't an option so I gotta set up another machine while I do it which is why I was bugging you (sorry and thanks btw) :)
<Sarvatt> crazy how much nvidia has been extending glx in the blob, wish open source drivers could take advantage of some of this stuff like GLSL over glx
<seb128> Sarvatt, hey
<Sarvatt> heyo, whats up?
<seb128> Sarvatt, will you update pixman in maverick?
<seb128> cairo 1.10 wants pixman 1.18.4
<Neko> if possible pls bump to 1.19.x :]
<Sarvatt> seb128: I'm not a core dev but I bumped it in debian and jcristau just uploaded it if you can sync it? it's a bug-fix only update
<seb128> we have 1.18.2 currently but I've read on IRC that debian updated your work
<seb128> Sarvatt, we had a diff it seems
<seb128> pixman (0.18.2-1ubuntu1) maverick; urgency=low
<seb128>   * Add 100_check_read_accessor.patch: Fixes corruption seen in firefox
<seb128>     due to REPEAT_NONE for a XRGB source fallback being triggered in a
<seb128>     composite operation. (LP: #608613)
<Sarvatt> the diff is upstream in 0.18.4
<Sarvatt> it was just backported
<seb128> Sarvatt, I'm happy to sponsor your upload
<seb128> oh ok
<seb128> so let me sync
<seb128> thanks!
<Neko> I have an interest in some of the new neon stuff.. 
<Sarvatt> thanks seb128!
<Sarvatt> Neko: there's only one new neon fastpath in 0.19 over 0.18 I believe?
<jcristau> slomo asked for 0.18.4 for cairo
<Sarvatt> Neko: I have 0.19.x packages in the xorg-edgers PPA if you want to test local builds
<ricotz> seb128, https://bugs.edge.launchpad.net/ubuntu/+source/pixman/+bug/633194
<ubot4> Launchpad bug 633194 in pixman (Ubuntu) "FFe: Sync pixman 0.18.4-1 (main) from Debian experimental (main) (affects: 1) (heat: 8)" [Undecided,New]
<seb128> ricotz, thanks
<bjsnider> Sarvatt, emailed you the updated packaging scripts for the 260 blob
<Neko> Sarvatt, well, one in 0.19.x release but two in master which will end up there
<Sarvatt> bjsnider: awesome, thanks!
<Neko> I dunno if pixman manages versions like even stable odd unstable?
<jcristau> Neko: it does
<Neko> if it's "unstable" then don't bother, but I wonder if those fast paths can be patched in
<Sarvatt> Neko: the latest master is what I've got a snapshot of in xorg-edgers
<Neko> I really need to figure out why those are being added though, there must be a user somewhere which relies on this particular compositing operation that is slow
<Neko> 32-bit pixmap with a seperate 8 bit alpha channel being rendered down to 16-bit.. it's probably highly common to convert 32->16 but a seperate alpha channel? maybe font rendering on 16bit or do?
<jcristau> ask the people adding them?
<Neko> just did :]
<Neko> I was hoping not to annoy
<Neko> "off-list" as it were
<Sarvatt> sounds like the 0.18.4 pixman requirement on cairo is bogus since it doesn't even contain the fixes they needed to pass the test suite anyway - http://cgit.freedesktop.org/pixman/commit/?id=de0320258167c24fc652d28f4aeca8713243323e and http://cgit.freedesktop.org/pixman/commit/?h=0.18&id=13951851cbbd81f9850d8ba132e155e3196ab522
<Sarvatt> apw: btw if you didn't hear, anholt no longer maintains the intel git trees so the drm-intel-next mainline kernel is dead
<Sarvatt> http://lists.freedesktop.org/archives/intel-gfx/2010-September/008018.html
<ScottK> Sarvatt: With the new mesa (and the .drirc), the HP Mini 110-1000 has lovely kwin effects (including blur), but effects are disabled by default (not just temporarily suspended).  The details of the system are in Bug #630632.  Could you have a look and see what bits I need to push on to get it to enable by default?  I assume there's a blacklist somewhere that it can be removed from.
<ubot4> Launchpad bug 630632 in xserver-xorg-video-intel (Ubuntu Maverick) (and 1 other project) "[i945GME] Kwin compositing fail on maverick (affects: 1) (heat: 1161)" [High,New] https://launchpad.net/bugs/630632
<ScottK> Shoot.  Wrong bug.
<ScottK> Nope.  Right bug after all.
<ScottK> (sorry, I've got about five different ones for tracking different systems)
<Sarvatt> thats odd, because its the same system basically as the other 945gme you were testing
<ScottK> Yep.
<ScottK> It's not different because it's in a live CD session is it?
<Sarvatt> it's most likely something in one of the kwin fallback mechanisms automatically disabling it, I don't see anything that would be causing that outside of there
<Sarvatt> maybe it saw it was broken with the old mesa and remembered that the next boot?
<Sarvatt> we need a livecd with the mesa package with the fragment_shader option disabled by default for testing
<ScottK> No.  I deleted the entire .kde between boot.
<ScottK> boot/restart
<ScottK> sudo stop kdm, switch to vt1, rm -rf ~/.kde, sudo start kdm
<ScottK> That should be sufficiently thorough
<Sarvatt> there were other ways it disabled the effects like if it sees they are too slow, could that have happened maybe?
<Sarvatt> anything in ~/.xsession-errors?
<ScottK> Already dumped the session.
<Sarvatt> ah darn, it looked like it would be verbose in there if it saw any problems when I was looking at the code
<ScottK> I've got one more 945gme system to test (Latitude D430).
<ScottK> It is probably similar.
<ScottK> If it doesn't fail to start automatically, I'll fire up the HP again.
<Sarvatt> about to upload a mesa to ppa:sarvatt/mesa with fragment_shaders disabled by default btw
<ScottK> Cool.
<ScottK> Please let me know when it's built so I can quit messing with config files
<Sarvatt> will do, should be about 45 minutes or so
<ScottK> Sarvatt: Here's the relevant .xsession-errors bits from one that doesn't start effects by default: http://paste.ubuntu.com/490436/
<Sarvatt> hmm thats a 945GM, it's not blacklisted and now that I look again nothing will match the blacklist since the version string is different
<ScottK> Here's the one that works http://paste.ubuntu.com/490441/
<Sarvatt> i'm really stumped, can't think of any reason outside of kwin why that might happen and I'm not having any luck looking at the kwin source finding where it might be going wrong
<ScottK> OK.  Thanks for looking.  I'll ask mgraesslin the next time he appears then.
<Sarvatt> there are so many ways it can decide to not use effects, hopefully it's something easy
<Sarvatt> be sure to mention it fails on one machine and works on another identical machine
<Sarvatt> the two 945GME's not that dell d430
<ScottK> OK
<apw> Sarvatt, i didn't hear.  not much point in building them anymore (mainline kernels from there)
<ScottK> Sarvatt: No need to tell me.  I got it.
<Sarvatt> ScottK: sorry, was just mentioning that because I had a feeling his first response would be that the drivers are screwed up and it doesn't happen on nvidia but that emphasizes something else is going on :)
<ScottK> Sarvatt: I was referring to the new mesa package.  Sorry.
<ScottK> He said he didn't know.
<Sarvatt> oh! I'm eating lunch, didn't see it was built yet
<ScottK> Sarvatt: I got word your .drirc helped someone on gentoo running tip of the latest everything, so I doubt we'll be re-enabling it.
<Sarvatt> yeah seems like the right thing to do for now, will have to keep an eye on it though because things will be dependant on it in the future and a lot of work is being done to make it work right.
 * ScottK nods
<era> i'd like to apologize if i came off a bit strong with my mailing list post this morning, but it had to be said.
<ScottK> Sarvatt and RAOF: How close are you to being ready to upload mesa?  I don't think it's fair for me to put my release team hat on and approve it (I'm hardly neutral), but I think sooner is better than later (with additional smaller updates as needed) and I'm willing to push it in the release team for someone else to review.
<era> mesa 7.9?
<ScottK> Git snapshot leading up to it probably.
<Sarvatt> ScottK: we could have it ready by tomorrow most likely if you really think its better that way instead of waiting for a RC or rebasing it on the stable branch when they push that, I'm about to head out for the day. we just need to move the nouveau classic mesa driver for old cards over to libgl1-mesa-dri-experimental and fix up the changelog to be more informative
<ScottK> OK.  I'll start grumbling about it.
#ubuntu-x 2010-09-09
<cnd> RAOF, have you had a chance to look at the new xorg-server and synaptics packages?
<RAOF> I have, and I've committed them to git.  I need to incorporate the changes which have occurred out of git, and get them sponsored.
<cnd> ok
<cnd> thanks for looking into it
<cnd> they're very important, so I want to be sure they get into the RC
<cnd> very important for the multitouch stuff that is :)
<cnd> not that they'll keep your computer from booting :)
<RAOF> :)
<RAOF> Thinking of multitouch stuff, when are you getting into XDS?
<cnd> RAOF, I'll be there on Sunday Sept 12th
<RAOF> Nice and early!
<cnd> there's some pre-xds stuff between some of the multitouch devs
<RAOF> Awesome.
<cnd> RAOF, when do you get in?
<RAOF> Wednesday morning.
<cnd> ok
<bjsnider> Sarvatt, you should also update nvidia-settings because the changelog for the blob says new features have been added and whatnot
<Sarvatt> theres no nvidia settings release to update
<Sarvatt> trust me i'm refreshing the git repo like a hawk :)
<bjsnider> nvidia-settings 260 i mean
<Sarvatt> there's no nvidia-settings 260 release yet
<Sarvatt> just the precompiled one with the driver
<Sarvatt> http://cgit.freedesktop.org/~aplattner/nvidia-settings/
<bjsnider> ftp://download.nvidia.com/XFree86/nvidia-settings/nvidia-settings-260.19.04.tar.bz2
<bjsnider> that's where i always get the tarballs
<Sarvatt> okie uploaded
<Sarvatt> thanks, i always do it from git
<Sarvatt> crazy how many bugs this mesa changelog is closing :)
<Sarvatt> RAOF: http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=shortlog;h=refs/heads/ubuntu-maverick
<Sarvatt> uploaded it to ppa:sarvatt/mesa as wel
<Sarvatt> l
<ScottK> Sarvatt: You made the config changes so I don't need to mess with .drirc anymore, right?
<Sarvatt> yeah http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=commit;h=90006b22f2a0f363f4b87b36a6940ad634f5fcd7
<ScottK> OK.
<ScottK> You might want to issue a call for wider testing.
<ScottK> The feedback I got from the release team is mesa updates make them nervous.
<Sarvatt> very much rightly so at that, we have a long track record of updating mesa *right* before release too so I'm surprised no one has had a nervous breakdown yet :)
<Sarvatt> ok I've gotta pass out now to be up for work again in 6 hours, darn virginia power giving me 12 hours notice my power would be down for a full day.. will try to get some more exposure for these mesa packages after going over it with RAOF to see if there's any issues
<bjsnider> Sarvatt, in the nvidia-current changelog, what was the error in the rules file?
<Sarvatt> bjsnider: I needed to fix it up to build on maverick, yours were based on lucid thats pretty different
<bjsnider> it is?
<Sarvatt> and i left a - from a local patch I use to convert the maverick package to lucid
<bjsnider> didn't know that
<Sarvatt> cut and pasted from the patch I use to convert it and forgot to remove the - at the start of one of the lines
<Sarvatt> its just this - http://sarvatt.com/downloads/patches/nvidia-graphics-drivers-lucid-backport.patch
<Sarvatt> we couldn't get xserver 1.7.6.901+ in lucid in time for release and it's made backporting a PITA
<bjsnider> doesn't look like those changes would affect any other package
<Sarvatt> any X package
<Sarvatt> tseliot ripped those lines out of xsfbs all of the pkg-xorg stuff uses
<bjsnider> well as long as they don't affect any non-x package i'm not worried about it
<Sarvatt> well just the X drivers I should say
<Sarvatt> argh, osmesa patch needed refreshing, pushed to git
<RAOF> I need to push my local work up to git more often, damnit.
<econdudeawesome> Hi all. I've been sent here to beg for help from crashes. penguin42 or kklimonda can fill you in
<kklimonda> wow
<kklimonda> I didn't expect *that*
<kklimonda> RAOF: if intel driver blacklists a card shouldn't X fall ack to vesa (and fbdev)?
<RAOF> kklimonda: Yes, it should.
<kklimonda> I have seen a second person with Xorg.0.log like that: http://pastebin.com/zn8XqvEJ
<kklimonda> and dmesg: 
<kklimonda> http://pastebin.com/3S9EYtGx
<penguin42> kklimonda: The problem is it's trying to fall back but there is no /dev/fb0
<RAOF> Actually, I think the problem might be that the intel driver has claimed the card, then bailed.
<econdudeawesome> RAOF: I have the computer here if you want any more info pastebin'ed
<econdudeawesome> I'm going to have to catch a bus soon... is there any more info you need from me, or is this beyond my worry now and I should wait for the update to hit the repos?
<RAOF> I don't think there's any more info I need from you.
<econdudeawesome> Thanks RAOF
<econdudeawesome> I'll be back later then, adieu
<econdudeawesome> RAOF -- booting from the older kernel (2.6.35-19 generic) resolved the issue
<econdudeawesome> thanks!
#ubuntu-x 2010-09-10
<RAOF> Roh row! -898035712 object bytes!
<RAOF> Sarvatt: You haven't happened to see a gem object leak again?
<Sarvatt> I have but I don't remember what set of packages explicitly I noticed it on, it wasn't in stock maverick or xorg-edgers
<RAOF> Could it be mesa 7.9~git20100909, perchance? :(
<RAOF> I guess it could also be 2.6.36-rc3
<Sarvatt> will find out, I think it was the kernel though
<Sarvatt> yeah
<Sarvatt> almost positive it was 2.6.32-rc2-sarvatt that I built
<RAOF> Time for me to reboot into a stock Ubuntu kernel, then.
<Sarvatt> what system are you seeing that on?
<RAOF> GM45
<RAOF> Would you believe that my system isn't very responsive with multiple GB of memory stolen by the kernel? :)
<Sarvatt> hah, imagine how I felt on an atom with 1.5gb ram! :)
<Sarvatt> it wasn't there in rc1, was something added in that huge intel patch bomb right before rc2
<ginggs> g'day - is anyone willing to sponsor a lucid SRU for https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/553415 please?
<ubot4> Launchpad bug 553415 in xorg-server (Ubuntu Maverick) (and 6 other projects) "mouse trapped in box for Open Motif (affects: 27) (dups: 4) (heat: 127)" [Undecided,Fix released]
<tseliot> ginggs: can you also attach the .dsc file, please?
<ginggs> will do now
<tseliot> thanks
<ginggs> done
<jcristau> i thought timo wanted to get a few more bugfixes in there
<tseliot> ginggs, jcristau: let's wait for tjaalton's reply then
<jcristau> that was a while ago though, so i don't know the status
<tjaalton> hey ho
<jcristau> hi timo
<tjaalton> haven't had any time to work on that..
<tjaalton> I'd like to see 1.7.7 in lucid, but think that's a stretch
<jcristau> but it's only good stuff!
<jcristau> :)
<tjaalton> I'm sure it is :)
<Sarvatt> RAOF: well, I give up because it does look buried deep down in the kernel. I wrapped drmmode_copy_fb behind a if (!IS_GEN6(intel)) and things work on sandybridge. still need to figure out where other generations are screwing up next but I have some ideas on that one
<tjaalton> so there's a ubuntu-lucid branch but it's somewhat stale
<tjaalton> for xorg-server, that is
<popey> hullo! I appear to be suffering from bug 619663 which is upstream x bug 28515
<ubot4> Launchpad bug 619663 in xserver-xorg-video-intel (Ubuntu) "[maverick] Non-mirrored dual-screen gives narrow display on secondary monitor (affects: 1) (heat: 163)" [Undecided,Confirmed] https://launchpad.net/bugs/619663
<ubot4> Launchpad bug 28515 in nautilus (Ubuntu) "Nautilus locks up on switching desktops w/ FTP link open (heat: 1)" [Medium,Invalid] https://launchpad.net/bugs/28515
<popey> Is it possible to get the fix into ubuntu?
<jcristau> http://bugs.freedesktop.org/28515
<jcristau> hrm, doesn't work.  stupid ubot4.
<seb128> fdb bug #28515
<ubot4> Launchpad bug 28515 in nautilus (Ubuntu) "Nautilus locks up on switching desktops w/ FTP link open (heat: 1)" [Medium,Invalid] https://launchpad.net/bugs/28515
<seb128> fdo bug #28515
<seb128> doesn't work? ;-)
<jcristau> freedesktop.org bug 28515
<jcristau> damn.
<seb128> it probably doesn't know about his bugzilla
<seb128> it works for gnome
<jcristau> it used to.
<ScottK> popey: We are trying to get an updated mesa into Maverick.  Not sure if that might help or not.  You can try it in the sarvatt/mesa ppa and see.
<popey> ok, great
<popey> another thing.. it looks like the new xorg has broken "ffmpeg -i x11grab" but I'm unable to tell if it's broken ffmpeg or broken xorg. Suggestions?
<popey> will try with that ppa too and file bug appropriately
<popey> sorry, ffmpeg -f x11grab, not -i
<jcristau> what does that option do?
<popey> grabs the x desktop so you can screencast it
<ScottK> popey: Please document the results of your test (including exactly which video you have) in  bug 631413.
<ubot4> Launchpad bug 631413 in mesa (Ubuntu) "[FFe] Mesa 7.9 (affects: 4) (heat: 26)" [Undecided,New] https://launchpad.net/bugs/631413
<popey> will do
<ScottK> Great.
<popey> ScottK: sorry to be dim, which specific ppa should I use on this machine?
<ScottK> popey: sarvatt/mesa
<ScottK> popey: sudo apt-add-repository ppa:sarvatt/mesa
<popey> oh, it was as obvious as that, sorry. Thanks.
<ScottK> No problem.
<tjaalton> ginggs: please ping me about that bug on monday..
<ginggs> will do - have a good weekend!
<ScottK> I understand from seb128 that there is a pending fix for Bug 628077 in a PPA that needs testing.  Please point me at the relevant PPA and I'll test.
<ubot4> Launchpad bug 628077 in xserver-xorg-video-intel (Ubuntu Maverick) (and 1 other project) "[i865] Crash on logout with KDM (affects: 1) (heat: 585)" [High,Confirmed] https://launchpad.net/bugs/628077
<seb128> ScottK, comment #5 on the bug?
<ScottK> seb128: Those weren't archive ready.
<seb128> comment #6 said you tried it?
<seb128> I will we should ask when Sarvatt is there
<ScottK> I did, but it needed work.  Last I heard he wasn't done.
<penguin42> ScottK: I mentioned a patch I asked to pull into our Mesa packages a few days ago and I think you told me to check some PPAs first to see if those fixed it; was it just xorg-edgers or is there something more appropriate for what's likely to go into Maverick (or maybe it wasn't you)
<ScottK> penguin42: For mesa, it's sarvatt/mesa.
<penguin42> ok, will go and grab that now
<penguin42> ScottK: Yeh sarvatt/mesa also fixes that bug
 * penguin42 will add a note to the bug
<penguin42> bug 626943
<ubot4> Launchpad bug 626943 in mesa (Ubuntu) "[Maverick] Flickering on Radeon - please cherry pick646d2e9fbc41bf49075013009e9583bec4a51168 (affects: 4) (heat: 404)" [Undecided,New] https://launchpad.net/bugs/626943
<ScottK> penguin42: Also please mention this in Bug #631413.
<ubot4> Launchpad bug 631413 in mesa (Ubuntu) "[FFe] Mesa 7.9 (affects: 4) (heat: 28)" [High,New] https://launchpad.net/bugs/631413
<penguin42> ScottK: Done
<ScottK> penguin42: Thanks.
<penguin42> hmm, which reminds me, I need to submit a bug somewhere to say there needs to be a ppa way to regen ia32-libs - google-earth needs the 32bit mesa libs
<apw> penguin42, thanks for pointing me to that fbcon fix
<apw> and good work spotting it, that had been reviewed and was missed
<penguin42> apw: Hey no problem
<apw> and do feel free to come find us on #ubuntu-kernel and point things like that out, most helpful
 * apw would have said something earlier, if he wasn't rebooting cause of a damn X hang
<apw> which always happens when i click on the task bar at the bottom, whatever operation showing a window uses its not good
<penguin42> apw: One thing that confused me was I tried to get the git repo that apt-get source suggested but that doesn't seem to contain any of the maverick changes
<apw> which one does it point to ?
<apw> i thought i fixed the link relativly recently (a couple of uploads back)
<penguin42> apw: http://kernel.ubuntu.com/git-repos/ubuntu/ubuntu-maverick.git is the one in the .dsc
<apw> that looks to be the http one for it
<apw> perhaps the server info isn't being updated
<penguin42> yeh I did a git clone from that
<apw> does that one seem better git://kernel.ubuntu.com/ubuntu/ubuntu-maverick.git
 * penguin42 clones
<apw> penguin42, yeah looks like the server info was not being auto-updated, if you have the b/w you could re-try the http one too
<apw> clearly none of us use it :/
<penguin42> apw: I may try after the git repo finishes cloning; probably just best to make the .dsc point to the git one
<apw> i think the http one should be ok now, but yes perhaps so
<apw> or list both
<apw> penguin42, do you know about --reference, if you have a linus virgin tree you can reference that and speed up your clone mightily
<penguin42> ooh, no I didn't
<jcristau> or you can just add a remote in the same repo and fetch the delta
<apw> that too
<alkisg> Hi, is there any graphical way to tell the lucid live cd to boot with vesa? Manually specifying "xforcevesa" worked, but I wonder why the F6 > safe graphics mode was removed...
<popey> ScottK: i tried that mesa ppa, but it didnt resolve the issue that I reported in bug 619663, do you still want me to comment on bug 631413
<popey> ?
<ubot4> Launchpad bug 619663 in xserver-xorg-video-intel (Ubuntu) "[maverick] Non-mirrored dual-screen gives narrow display on secondary monitor (affects: 1) (heat: 163)" [Undecided,Confirmed] https://launchpad.net/bugs/619663
<ubot4> Launchpad bug 631413 in mesa (Ubuntu) "[FFe] Mesa 7.9 (affects: 4) (heat: 28)" [High,New] https://launchpad.net/bugs/631413
<ScottK> popey: If it didn't affect your performance, it's not critical, but even "I tried it on XYZ and it was the same" reports have value for the FFe.
<popey> ok
<popey> ScottK: would this be a good point for me to try xorg-edgers ppa?
<ScottK> popey: No idea.  I'm not an expert in this area, just trying to get mesa fixed ...
<popey> ok, thanks! Good luck with that
<popey> woop woop, xorg-edgers fixes my bug
<popey> and introduces others! :D
#ubuntu-x 2010-09-11
<ricotz> alf__, hello, did you already ported the new packaging of clutter 1.2 to clutter 1.3/1.4?
<ahamino> Hi, my AMD Turion X2 ultra overheats under normal stress load, it has been doing that since ubuntu 9.04 -> 10.04 (runs fine on windows 7) .. I'm wondering if that got solved in 10.10 .. Checked lp .. and found a bug that looks similar to the problem I'm having ... but there are no indication of it's status : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/370173?comments=all
<ubot4> Launchpad bug 370173 in linux (Ubuntu) "laptop overheats and suddenly shuts down/off (affects: 56) (dups: 9) (heat: 391)" [High,In progress]
<ahamino> ping
<ahamino> anybody here?
<vish> !weekend | ahamino
<ubot4> ahamino: It's a weekend. Often on weekends the paid developers and a lot of the community may not be around to answer your question. Please be patient, wait longer than you normally would or try again during the working week.
#ubuntu-x 2010-09-12
<era> hi, is radeonhd still in the universe?
<era> also, what is the diff between -ati and -radeon?
<jcristau> no, and ati is a wrapper that loads radeon, mach64 or r128 depending on your hw
<era> ok. thanks.
<pavpanchekha> I have an nVidia issue on Maverick
<pavpanchekha> who should I ask?
<pavpanchekha> ping?
<Neko> hi guys
<Neko> http://lists.freedesktop.org/archives/xorg-devel/2010-August/012280.html
<Neko> is this in the maverick xorg yet?
<Neko> I don't see it in the bzr but I figure I might be blind. it seems to fix this 100% CPU bug I had with xfce terminal..
<Neko> about to test it against yesterday's xorg-xserver..
#ubuntu-x 2011-09-05
 * RAOF is surprised that nobody has yet noticed that the Khronos EGL headers are broken on Win64.
<bjsnider> ricotz, what is the preferred way to store preferences in gnome 3, is it gsettings/dconf?
<ricotz> bjsnider, yes, i would say so
<ricotz> but iirc not all gnome-apps switched yet
<bjsnider> is that possible in natty, with libdconf0 instead of dconf-gsettings-backend?
<ricotz> yes
<bjsnider> cool
<ricotz> bjsnider, do you proposed your gnome-mplayer change?
<bjsnider> i proposed it
<bjsnider> not officially but in the channel
<bjsnider> but actually i'm creating a ppa bot to do my own packages
<bjsnider> and the developer says the ubuntu packages are screwed up
<bjsnider> nobody has been paying attention to it because they forgot to add libpulse-dev as a dependency, so no pulseaudio
<bjsnider> that's mind-boggling
<bjsnider> a media player, with no pulseaudio support
<bjsnider> i suppose it's screwed up in debian too
<ricotz> bjsnider, so make a debdiff and send it to the maintainer or ping them if possible
<ricotz> where is its debian packaging branch again?
<ricotz> nvm found
<ricotz> it
<ricotz> i was hoping to be able to commit to it
<bjsnider> can you?
<bjsnider> there are a couple of other changes that need to be made
<bjsnider> let's switch this conversation to #debian-multimedia, since we're both in that channel
#ubuntu-x 2011-09-07
<Sarvatt> ricotz: hopefully wayland should be working by the morning, just uploaded mesa to build against that new wayland checkout
<Sarvatt> fighting 8 hour build queues
<Sarvatt> bryceh: ok to mark wayland in edgers work item done now if you know where it is, i think it was assigned to someone else because i'm not seeing it
<Sarvatt> got a wayland-demos ready to upload but it needs new mesa built first
<ricotz> Sarvatt, nice
<Sarvatt> added it to my daily update script too
<Sarvatt> but cant really run it out of there since it has to build before mesa..
<ricotz> perhaps you can ping a friendly archive-admin to bump the priority
<ricotz> if mesa isnt using new api bit right away it should work
<bryceh> Sarvatt, ok will do
<ScottK> Sarvatt: Does bug 839808 (on Natty) look like anything you've seen before?
<bjsnider> i can never seem to understand what these mesa build failure logs mean. i can usually understand other build failures but not the mesa ones
<tjaalton> bryceh: hey, do you know if the apport hooks in natty had bugs, like running apport-collect xxxx for a bug against -evdev only collects Dependencies.txt and nothing else?
<bryceh> tjaalton, nope
<bryceh> tjaalton, ubuntu-bug xserver-xorg-input-evdev seems to work (just re-confirmed it), so theoretically the hook should work for apport-collect as well
<bryceh> there are a couple apport bugs I'm aware of that could result in that behavior
<bryceh> for instance, if a bug report was filed against multiple packages, and -evdev wasn't the original thing it was filed against, apport-collect will try to use the hook from whatever the first target was.  (Or something like that...)
<bryceh> so, the Dependencies.txt is because apport is using an apport hook for some other package (which evidently doesn't have a hook defined)
<bryceh> the other bug is that if a package has differing binary and source package names, apport only works if you give it a binary name (so no ubuntu-bug xorg-server)
<bryceh> but that second bug it'll error out before even filing the bug
<tjaalton> yeah this one was against unity originally
<tjaalton> but has only -evdev as the package
<bryceh> yeah, I'd guess apport-collect is trying to use unity's package hook
<bryceh> *yawn* night
<tjaalton> heh, night
<cnd> bryceh, fyi, Carlos Garnacho sent me three patches for fixing some touch grab issues
<cnd> I'm testing them out now, but I hope to push them to the packaging repo soon
<cnd> bryceh, the patches look good, I've pushed them to the ubuntu branch
<cnd> do you know when the next release will be uploaded?
<bryceh> cnd, of xserver?  no I don't; assuming raof and tjaalton have some plans
<cnd> ok
<tjaalton> if we can just upload without an ffe, then I can test it locally tomorrow and upload if no issues pop up?
<bryceh> tjaalton, sounds good
<cnd> tjaalton, that was something I was wondering about
<cnd> since there's an upstream micro version bump
<tjaalton> yeah it's a stable update, so shouldn't need any paperwork
<cnd> cool
<bjsnider> that's a build failure i understand
<Sarvatt> bjsnider: welcome to my world of fun, by the time i get one part of the build system fixed another change is introduced upstream making it fail again :P
<Sarvatt> fixed one uploaded and i test built it locally to be sure
<bjsnider> fixing a problem like the one i just saw is easy enough, but what about the log from last night?
<bjsnider> that was a completely meaningless failure message
<Sarvatt> i filed https://bugs.freedesktop.org/show_bug.cgi?id=40668 about that
<ubot4> Freedesktop bug 40668 in Other "Mesa compilation failure with wayland master" [Normal,Resolved: duplicate]
<Sarvatt> it wasn't compiling with wayland master or the wayland checkout we had in oneiric
#ubuntu-x 2011-09-08
<ricotz> Sarvatt, i just uploaded a wayland update to follow the api change for demos
<Sarvatt> ricotz: thank you thank you for looking at it, i really am just uploading it on blind faith it'll work because i just want mesa to build :)
<Sarvatt> it took so long for mesa to build against wayland master that the wayland master checkout went out of date, sheesh
<ricotz> Sarvatt, i would really like to change the auto-git script to use the real commit date in the version
<ricotz> taking the upload date has its advantages too, but it doesnt really reflect how old this version is
<tjaalton> ooh, a possible patch for hd6450
<ricotz> Sarvatt, could you push the wayland-demo changes to the branch if there are some?
<Sarvatt> ricotz: crap, 0.1~git20110908.9c4eecb5-0ubuntu0sarvatt
<ricotz> yes ;)
<ricotz> that why i am asking
<Sarvatt> can only upload 1 source package a day with that versioning :(
<Sarvatt> 0.1~FFFFFFFFFFF wont override 0.1~git20110908.9c4eecb5-0ubuntu0sarvatt
<Sarvatt> or 0.1~ZZZZZZZZ even
<Sarvatt> i missed it by 30 minutes
<ricotz> not everytime
<Sarvatt> its 2:18 am here and i uploaded 0908 at 00:30 so cant reupload until tomorrow
<ricotz> the version should be 0.1.0~ anyway
<ricotz> which will override it
<Sarvatt> oh good point
<ricotz> but wait for wayland
<Sarvatt> i'm about to pass out though, 2:21 AM and all.. will upload in the morning if ya dont end up doing it, it just needs the exact same hook thats in in hooks-sarvatt/wayland.prebuild to bump it to 0.1.0 added to hooks-sarvatt/wayland-demos.prebuild
<ricotz> Sarvatt, ok
<Sarvatt> if [ -z "$PACKAGE_VERSION" ]; then
<Sarvatt>     eval `grep PACKAGE_VERSION= configure`
<Sarvatt>     if [ "$BRANCH" = master ] && [ "$PACKAGE_VERSION" = 0.1 ]; then
<Sarvatt>        PACKAGE_VERSION=0.1.0
<Sarvatt>     fi
<Sarvatt> fi
<Sarvatt> CHANGES+=("hook: Bump version to $PACKAGE_VERSION")
<ricotz> yeah, i figured that, thanks
<Sarvatt> really should push hooks-sarvatt/ to just hooks/ but i dont want to screw with tormod's hooks..
<ricotz> Sarvatt, to make it even more unstable -- we could add cairo git ;)
<Sarvatt> cairo git is easy though!
<Sarvatt> i'm all for that
<ricotz> yeah, but risky ;)
<Sarvatt> go wild man
<ricotz> last time i checked, i got a lot of problems
<Sarvatt> dont add it to natty right away at least
<Sarvatt> if you want to be safe :)
<Sarvatt> people use xorg-edgers expecting it to be stable on the current release for some reason
<ricotz> using cairo git cant be "safe" ;)
<Sarvatt> i try to make that happen at least
<Sarvatt> ricotz: i did that for a long time with 1.10 before it became 1.10 :P granted who the heck knows when 1.11 is going to be released and i knew 1.10 would be released soo when i did that
<Sarvatt> soon being 6 months or so
<ricotz> grr, fail-missing on wayland
#ubuntu-x 2011-09-09
<tjaalton> ok time to tackle xserver 1.10.4
<tjaalton> totally forgot it yesterday
<tjaalton> while testing kernel patches for my radeon..
<tjaalton> bryceh: did you test the build after the xvfb-run test change? it doesn't seem to build here, trying to figure out why
<tjaalton> doesn't work even when I run it locally
<tjaalton> xvfb-run: error: Xvfb failed to start
<tjaalton> but the build error was: /bin/sh: debian/tmp/main/usr/bin/xvfb-run: not found
<tjaalton> well, of course it doesn't find Xvfb..
<tjaalton> xvfb-run needs to be modified to add an option for an optional path to Xvfb
<tjaalton> can't figure out another way to do it
<jcristau> why do you run xvfb-run at build time?
<tjaalton> to test that it works
<tjaalton> there's been some package build failures that depend on xvfb
<jcristau> ok...
<tjaalton> though can't remember what the last one was that triggered adding the test
<tjaalton> hmm just adding debian/tmp/main/usr/bin to PATH would suffice
<tjaalton> seb128: do you remember which package depends on a working xvfb during build?
<seb128> tjaalton, http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.oneiric/rdepends/xorg-server/xvfb
<seb128> ?
<tjaalton> oh, it lists build-deps too.. thanks
<jcristau> i use 'grep-dctrl -FBuild-Depends -sPackage xvfb < /var/lib/apt/lists/*_Sources'
<tjaalton> hmm need to alias that :)
<tjaalton> i guess it was pygtk last time
<seb128> likely
<tjaalton> it was bug 829470 in fakeroot
<ubot4> Launchpad bug 829470 in fakeroot (Debian) (and 4 other projects) "Xvfb fails with empty /var/lib/xkb, causing build failures (affects: 1) (heat: 10)" [Unknown,Fix released] https://launchpad.net/bugs/829470
<tjaalton> which then made the pygtk build fail
<tjaalton> the subject isn't accurate
<tjaalton> or maybe it is, but caused due to the fakeroot bug
<jcristau> yeah it's not so much empty /var/lib/xkb than "/var/lib/xkb where access() tells us we can write, but open(O_WRONLY) fails"
<tjaalton> ngh, manually running debian/rules check works fine, but not in debuild
<tjaalton> ahaha
<tjaalton> binaries are not yet installed when check is run
<tjaalton> yeah, works now
<tjaalton> I'll reward myself with a steak :) ->
<kklimonda> hey, I've got a weird problem when gnome-terminal doesn't refresh properly when I use nvidia blob on oneiric
<kklimonda> it definitely happens under mutter, I also think I got the same problem running compiz - it doesn't happen with metacity though, so it's something shiney 3d related ;)
<soreau> kklimonda: Possibly a bug in that version of the nvidia driver
<soreau> and pretty likely since it wouldn't be the first time
#ubuntu-x 2011-09-10
<bryce2> hmm
<Sarvatt> hmm ccab5c82759e2ace74b2e84f82d1e0eedd932571 introduced pretty frequent MCE errors in dmesg at the expense of a 20% performance increase on intel with turbo boost.. how long until someone complains about that
<Sarvatt> way back in 2.6.39-rc1
 * Sarvatt has 17 errors in dmesg from 4 days uptime because of it on an e6420
<bjsnider> Sarvatt, did you read this: http://netsplit.com/2011/09/08/new-ubuntu-release-process/
<Sarvatt> yeah, can't say i agree, he very obviously has the perspective the thing he cares about will get updated easier with that development model ignoring the rest of the world that is *buntu that doesnt fit that model at all :)
<Sarvatt> i'd much rather see something like debian unstable with opt in to things you care about updates
<bjsnider> i think he's taken everything into account
<bjsnider> his way would work
<bjsnider> it's possible that ubuntu 11.10 and 11.11 would be exactly the same though
<Sarvatt> linaro is already doing it
<bjsnider> if no new software was ready
<Sarvatt> cutting monthly ubuntu releases
<Sarvatt> as a user, honestly all i care about is getting X and driver updates and having a stable desktop, and getting select app updates when i want
<Sarvatt> worst part about development releases to me is the desktop breaking up weekly up until 2 weeks before final release
<bjsnider> his way nothing would be updated unless it was ready
<bjsnider> maybe it would also cut down on all of the meetings
<bjsnider> it sounds like you guys spend a lot of time talking about things
<bjsnider> under the current system
<bjsnider> Sarvatt, do you want to keep the current system?
<Sarvatt> obviously not, i'm hoping to discuss the idea of backporting drivers from +1/+2/+3 to the LTS via opt in pockets at 12.04 UDS because thats what I care about and feel we're lacking in support for when the LTS isn't viable on newer hardware 6 months later because of SRU policies but I still don't think the chrome model would work in the world where you go through 6 months of fixing up universe to work with a gcc change like we just did and I think we'd
<Sarvatt> do
<Sarvatt> what do ya see a lot of time spent talking on?
<Sarvatt> and who's us btw, you're us too :)
<Sarvatt> your nvidia updates in x-updates are now going to distro users if you didn't notice :)
<Sarvatt> jockey pulls from the PPA now
<bjsnider> what?
<bjsnider> jockey pulls from the what now?
<Sarvatt> in oneiric it offers nvidia-current-updates and if they pick that it pulls from x-updates ppa
<Sarvatt> not sure if that got SRUed to natty or not
<bjsnider> oneiric is currently beta though
<Sarvatt> 6 months a year where drivers can be updated because of freezes is not enough, thats for sure
<Sarvatt> bjsnider: yer prolly talking to the wrong guy, i get paid to make prerelease hardware work in the distro thats out when the hardware comes out (which is usually 3-4 months into the next dev cycle), then work in that release+1 out of the box so it can get certified. the 6 month cycle works decently for that even if i wouldn't personally want to use that and i see lots of complications with every kind of change :) all I care about is the drivers, you pr
<Sarvatt> faster but i'd prefer slower
<Sarvatt> anything i care about updating faster i just update myself anyway
<ScottK> Given how painful Testing transitions in Debian (which are easier than what he's talking about), I think he substantially underestimates the complexity of what he's proposed.
<ScottK> I agree with the problem statement, but not his solution.
<ScottK> Works for Chromium (one package) doesn't tell you it'll scale to 20,000.
<ScottK> Sarvatt: Are you still interested in E6320 bugs or is that now "old"?
<Sarvatt> ScottK: definitely, I did look at your bug but I'm a bit stumped at it. the kwin backtrace was because DRI got ripped out from under it when the GPU reset and disabled acceleration which mesa couldn't cope with (that specific kwin segfault is fixed in mesa 7.12 but was a bit too big to backport when i looked)
<ScottK> Sarvatt: OK.  Cool.  Thanks for looking at it.
<ScottK> I'll mark that in the bug then.
<Sarvatt> it definitely was a driver problem and not kwin, you were right there
<ScottK> That was mgraesslin.
<ScottK> He told me.
<tjaalton> Sarvatt: i think we decided on the lts backport strategy already :)
<Sarvatt> they fixed the app segfaulting when acceleration gets ripped out from underneath it in mesa, but its still a kernel bug that caused the GPU reset in the first place
<Sarvatt> going to need to upstream this bug and they are going to ask you to do some crazy stuff to reproduce it, and it seems like a very transient bug that happens a long time after a suspend/resume cycle under intense memory pressure from chromium so that might be a pain in the butt
<Sarvatt> or just mark the dang thing fix released because the segfault is fixed in mesa 7.12 :(
<Sarvatt> ScottK: hopefully i can reproduce it locally so dont have to put you through all the headache installing xorg-edgers and stuff it should reproduce on an e6420
<ScottK> We don't have 7.12, though, do we?
<Sarvatt> nope its not released until january
<ScottK> rmadison told me 7.11.
<ScottK> I milestoned it for "P".
<ScottK> I'm glad to help, but this is my primary laptop, so I can't go breaking it.
<Sarvatt> its a kernel problem already fixed in 3.0, i haven't used 2.6.38-11's i915 since UDS-O so thats probably why I haven't hit it
<ScottK> K.  Thanks for looking into it.
<Sarvatt> but i've got it going now
<Sarvatt> tjaalton: the kernel part is the sketchiest part, we need some serious discussion on it
<Sarvatt> you potentially regress a lot less upgrading x-x-v-intel on your intel than you do upgrading the kernel
<Sarvatt> they already do LTS backport kernels though I guess
<Sarvatt> its how it would possibly work with the archives thats way beyond me
<Sarvatt> ScottK: thanks for milestoning it to P because realistically it might not be backported to N before O comes out with how tricky it looks to be to reproduce.. I really hope its not as common as the 10.10 issues your daughter had
<Sarvatt> (didn't manage to reproduce it today, I suspended/resumed and used chromium all day on stock packages and haven't hit it yet)
<tjaalton> Sarvatt: yes, kernel backports are already happening
<tjaalton> though with bugs like https://bugs.launchpad.net/ubuntu/+bug/824913
<tjaalton> (archive fail)
<Sarvatt> we're hitting some annoying stuff using lts-backport-natty in the OEM project we're working on, bluez userspace in lucid doesnt work on the lts backport kernel
<tjaalton> so opting in would mean installing the linux-lts-backport-foo for the pocket, and enabling the ppa for that release
<tjaalton> sure, that's a concern
<Sarvatt> i dont care about bluez userspace, do you? :P
<tjaalton> no, but it's not just bluez that might break :)
<Sarvatt> yeah exactly
<Sarvatt> tjaalton: that was only a problem with linux-lts-backports-maverick
<Sarvatt> when we first did the natty backport i poked the kernel guys about the header problem and they fixed up natty but maverick got released without that fix
<tjaalton> ah
<Sarvatt> yeah its fixed in git http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=bff6b282d69e7a909d672ef24236b455449558d1
<Sarvatt> looks like it was released in 3 updates since that bug too, closing that bug
<Sarvatt> oh the meta hasn't been pushed yet
<Sarvatt> https://bugs.launchpad.net/bugs/839595 really stinks, dont have a single machine here that didnt get +2 minutes boot time from yesterdays update :(
 * Sarvatt must be installing wrong or something
<tjaalton> i've not seen that
<ScottK> Sarvatt: Me too.  So far I think I've had that particular problem only once.  X on this E6320 has gotten noticeably more reliable since Natty's release, so something is going right.
<Sarvatt> yeah it sucks it took so long for 2.6.38-11 to come out, the patches in there to make sandybridge stable were floating around in april but the kernel kernel update got held up until august :(
<Sarvatt> tjaalton: are you interested in setting that up?
<Sarvatt> i sure as heck can't keep up with 2 xorg-edgers like PPAs
<Sarvatt> but it would be really good if we started staging things for release+1 on git.debian.org and would even make xorg-edgers that much easier to do, i'm already doing lots of it just rewriting the packaging in current git and efforts get duplicated when the next release comes around because its not in git
<Sarvatt> btw, I dont care if proprietary drivers break, I was just mentioning that nvidia's supposedly xserver 1.11 supporting release doesn't work with xserver 1.11 because of the extension abi snafu
<Sarvatt> (well it does as long as you have IgnoreABI in xorg.conf)
<bryce2> Shocking news!  http://www.phoronix.com/scan.php?page=news_item&px=OTg5Mg  3D interfaces use up more power than 2D!  And Michael Larabel has PROOF.
<debfx> fascinating
#ubuntu-x 2011-09-11
<tjaalton> Sarvatt: yes, i'm willing to spend time for the ppa
<tjaalton> we can work it out
<tjaalton> :)
<tjaalton> +some
<Sarvatt> bryce2: there are some commits that increase power usage a lot at the expense of making things perform better on intel too, damned if you damned if you dont if we reverted it though
<Sarvatt> like commit ccab5c82759e2ace74b2e84f82d1e0eedd932571
<Sarvatt> Author: Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx>
<Sarvatt> Date: Tue Jan 18 15:49:25 2011 -0800
<Sarvatt> drm/i915: tune Sandy Bridge DRPS constants
<Sarvatt> that one is killer and even triggers machine check exceptions in dmesg constantly
<Sarvatt> 20% performance win on sandybridge though..
<bryce2> wonder if it has to be a power vs. performance trade, or if things could be done more cleverly?
<bjsnider> why does ubuntu use more power than osx when both use composited desktops?
<RAOF> bryceh: Yo yo!
<bryceh> heya RAOF!
<bryceh> just arrived, I'm in rm 640
<RAOF> Aha! Practically next door!
<RAOF> I'm in 643.
<bryceh> wow
<bryceh> that'll be convenient
<RAOF> Yeah.
<bjsnider> you guys are 40 feet apart and you're talking on irc
<RAOF> Yeah, well.  We've only just *discovered* we're 10 metres apart.
<RAOF> Also, my laptop needs to recover electrons after the flight :)
<bryceh> was your flight as uneventful as mine, raof?
<RAOF> Probably.  Mine was pretty uneventful.
<RAOF> But started strangely early for a 9am flight.
<RAOF> Or, rather, I started my day strangely early.
<Sarvatt> were there actually other people on the flight at 9 am on 9/11?
<bryceh> mine was packed to the gills
<RAOF> Mmm.  This wireless is not the most stable network known to man.
<bryceh> mine seems to be ok, although I haven't been on it very much yet; feel free to pop down if you'd like... perhaps I'm closer to the ap
<RAOF> Maybe I shall, once I'm sure that an extra disconnect won't break context for other conversations. :)
<RAOF> And, actually, it's pretty close to dinner/lunch time.
<bryceh> yep
<RAOF> bryceh: Dinner time?
<bryceh> RAOF, sounds good
<RAOF> I'll wander down to you.
<bryceh> ok
#ubuntu-x 2012-09-03
<alkisg> Hi, is support for xvideo on s3virge supposed to be broken in 12.04, or could it be some bad configuration? It worked fine in 10.04...
<alkisg> Xorg.7.log: http://paste.ubuntu.com/1183234/
<alkisg> [    52.898] (WW) Warning, couldn't open module s3virge
<alkisg> Do I need to manually install xserver-xorg-video-s3virge?
<alkisg> Installing xserver-xorg-video-s3virge allowed my card to have xvideo. Any reason why it's not preinstalled like it was in previous versions?
<tjaalton> alkisg: https://lists.ubuntu.com/archives/ubuntu-x/2011-May/001076.html
<jcristau> something along the lines of: because it has about 5 users, no maintainer, and so is no longer in ubuntu main
<tjaalton> -s3virge is now gone from the archive too, starting from quantal
<alkisg> Thank you guys, so I _can_ put it in the Recommends: of my "greek-schools-installer" package (LTS only) without breaking anything
<alkisg> We have more than 1000 of s3virge cards here, not sure about exact numbers though
<tjaalton> stubborn machines ;)
<alkisg> So far we had 10 year old PCs in schools... now with the crisis we're going to have 20 year old PCs in the future :D
<tjaalton> :)
<seb128> tjaalton, could you look at https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1032251 ?
<ubottu> Launchpad bug 1032251 in xserver-xorg-video-intel (Ubuntu) "EOG hangs in Ubuntu 12.04" [Undecided,New]
<seb128> tjaalton, is that a known issue?
<tjaalton> seb128: 855GM, support for those older chips can be somewhat lacking, dunno if it's known elsewhere or not
<seb128> tjaalton, ok, not something we should care too much about then? (I hate all those "eog freezes xorg" bugs, it's not cool when the image viewer can take your session down)
<tjaalton> seb128: well, would be nice to know if it's fixed/broken with a more recent stack
<seb128> tjaalton, can you ask on the bug? :-)
<tjaalton> sure
<apw> tjaalton, i am seeing some reports of validation failures in nouveau, suspicious its mesa passing in junk ... ring any bells ?
<tjaalton> apw: huh, no.. wouldn't surprise me though, we've had plenty of issues since nvidia users were forced to use nouveau on quantal, before the blob worked
<apw> so we are not recommending nouveau on quantal
<tjaalton> but I've had no time to look at those bugs in more detail. I'm preparing a newer mesa snapshot atm
<apw> tjaalton, sounds good with luck it will fix my issues and theirs :)
<tjaalton> it probably has more issues on certain hw generations, my gf8600 was quite happy with it
<tjaalton> apw: any bug reports out there?
<apw> bug 1045077 is the one i was asked about
<ubottu> Launchpad bug 1045077 in linux (Ubuntu) "[drm] nouveau 0000:00:05.0: fail ttm_validate" [Undecided,Confirmed] https://launchpad.net/bugs/1045077
<tjaalton> ugh, thanks
<tjaalton> libdrm 2.4.39 uploaded, prereq for the newer mesa snapshot..
<Lee_Sharp> Anyone her with time for a sanity check?
<Lee_Sharp> Must be a holiday.  I spelled "here" wrong... :)
#ubuntu-x 2012-09-04
<stgraber> heya, just changed laptop last week and upgraded to quantal. Now trying to have the shiny new hd4000 to drive 3 monitors at once and failing quite miserably
<stgraber> getting any two displays to work is fine, getting the third to work at the same time, not so much
<stgraber> looking around, I found http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg12877.html which may be related
<stgraber> so far I'm trying with two 1920x1080 external monitor (one over HDMI, other over VGA) + laptop's 1366x768
<stgraber> will receive an adapter this week to get both external monitors on DVI (mini-DP => two separate single-link DVI)
<tjaalton> stgraber: so it only has the intel, no hybrid?
<stgraber> right, it's a new ivy bridge laptop with an hd4000
<stgraber> the hd4000 has 3 CRTC
<tjaalton> yup
<stgraber> so is supposed to be able to drive 3 screens, as long as two of them share the same clock (should be the case here, with two 1920x1080 screens)
<tjaalton> those patches will hit 3.7 at the earliest
<stgraber> I may try to rebuild a kernel with http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg12880.html applied as it seems to match my current setup (one of the two external being on VGA, likely getting CRTC2)
<stgraber> hopefully everything will just work once I move to DVI for both screens. TBH runing a full-hd screen over VGA is usually quite bad, so I can't think of anyone who'd stick with that setup ;)
<tjaalton> only the first patch is in the drm queue
<dupondje> Somebody around that could help me to solve HDMI output not working with nouveau?
<tjaalton> dupondje: better luck with #nouveau i guess
<bjsnider> dupondje, what card is that?
<dupondje> Nvidia GeForce GT 540M
<dupondje> I can get HDMI output 'working' when I manually add the device in xorg.conf
<dupondje> the image is a bit disorted
<dupondje> but xrandr for example shows HDMI1 disconnected
<bjsnider> if dvi works you can use an adapter
<bjsnider> won't carry sound though
<dupondje> have no DVI output :)
<dupondje> HDMI & displayport
<bjsnider> neat
<bjsnider> obviously you could use the blob
<bjsnider> you don't have to use nouveau
<dupondje> the blob can't even read the resolution of my laptop screen ... :)
<bjsnider> which blob is this?
<dupondje> nvidia-current in quantal
<dupondje> must say I haven't looked into fixing the blob really :)
<dupondje> nouveau works near to perfect, except the HDMI output which seems partly broken
<tjaalton> try 3.6-rc
<dupondje> I guess if xrandr can see the HDMI output connected, its working fine
<dupondje> tjaalton: tried daily kernel already
<tjaalton> ok
<dupondje> as I saw alot of new nouveau stuff was in it :)
<dupondje> http://dupondje.be/dmesg.txt => is my dmesg with drm.debug=0x4
<dupondje> you can see it correctly finds the HDMI screen, even its supported resolutions etc
<dupondje> [   49.248709] [drm:output_poll_execute], [CONNECTOR:17:HDMI-A-1] status updated from 1 to 1
<dupondje> here I pulled the HDMI cable
<dupondje> (last line)
<dupondje> any idea's ? :)
<tjaalton> dupondje: like I said, #nouveau would be better for such questions ;)
<dupondje> its quite dead there :(
<dupondje> i'll try harder :p
<tjaalton> ah, saw that now
<tjaalton> well, yesterday was a holiday in the US
<tjaalton> dunno if that matters
<seb128> tjaalton, bryce, RAOF: hey guys, xorg still has lit of items on http://status.ubuntu.com/ubuntu-quantal/canonical-desktop-team-ubuntu-12.10-beta-1.html ... can we get them postponed, moved to beta2, closed, etc as appropriate?
<seb128> desktop-q-xorg-general 	15 todo for beta1
<seb128> and some still on desktop-p-libxrandr-utils and desktop-q-hybrid-graphics
<LLStarks> there's a prime ppa now? inb4 front page of phoronix
<tjaalton> hmm, maybe should just delete that task
<tjaalton> no separate ppa, we have what is released
<tjaalton> seb128: checked most of my tasks
<LLStarks> tjaalton, if there was to be a ppa, it would need i915-uxa, nouveau, and xrandr 1.4
<tjaalton> one remains, probably need to postpone it
<tjaalton> quantal has xrandr 1.4
<tjaalton> some ddx patches are missing, might make it in, dunno
<bryce> seb128, will so do
<seb128> tjaalton, bryce: thanks
<LLStarks> will i915 be sna or uxa as default? i know both will be built
<tjaalton> hmm, not sure about xrandr anymore :)
<tjaalton> LLStarks: likely uxa
<LLStarks> airlied's patches are just starting to land for both ddx
<tjaalton> right, so we don't have xrandr 1.4 yet
<tjaalton> meh, I'll decide tomorrow if the ppa is really needed or not
<LLStarks> mesa should be ready if the 8/21 build included the DRI_PRIME cherrypick
<LLStarks> err merge
<LLStarks> looks like it got in
<LLStarks> tjaalton, if you're interested in prime QA for the quantal stack (plus the patched ddx's), i'd be happy to help. very encouraging results so far.
<tjaalton> LLStarks: ok, cool
<tjaalton> mesa snapshot updated as of yesterday, sitting in git waiting for the beta freeze to end (and libdrm update to enter the archive..)
<LLStarks> dri2proto, xserver, randproto, libxrandr are all landed. i'm pretty sure libdrm 2.4.38 landed with the needed changes as well.
<LLStarks> xrandr 1.4 is needed to manually set the provider
<LLStarks> prime with nouveau is nice though, it already outperforms bumblebee with the nvidia blob: http://pastebin.com/j1CQBsdB
<dupondje> #nouveau seems really silent :
<bjsnider> dupondje, that is because nouveau has no problems or bugs or missing features at all, so no one complains
<dupondje> right :D
<dupondje> anyway, opened a bug https://bugs.freedesktop.org/show_bug.cgi?id=54512 :)
<ubottu> Freedesktop bug 54512 in Driver/nouveau "xrandr does not detect screen" [Normal,New]
<bjsnider> don't believe that one, huh?
<bjsnider> ;
#ubuntu-x 2012-09-05
<RAOF> Oh, fun. mesa FTBFS with -j5.
<tjaalton> yeah it can have those issues.. though haven't seen it fail in quite a while
<tjaalton> RAOF: building the unreleased git version?
<RAOF> tjaalton: Both that and the archive version fail in the same way.
<tjaalton> ah
<RAOF> Trying to generate radeonsi source files.
<tjaalton> huh, built it several times yesterday and they were all fine (-j8 though)
<RAOF> tjaalton: Hah. And now git fails to build in the final stage because glu.h exists in debian/tmp. What?!
<RAOF> Oh, that reminds me. Who wants to review apitrace? It's ready in git, I think we should have it in Ubuntu, and we don't need to wait for Debian. jcristau's obviously too busy to review it there.
<tjaalton> RAOF: that's.. weird, don't see it here
<tjaalton> I can have a look at apitrace today
<tjaalton> hmm, wonder why cloning it drops it in a nonexistant master branch
<tjaalton> oh right
<tjaalton> since there's no debian-unstable branch :)
<tjaalton> which is where HEAD is pointing at
<RAOF> Heh.
<tjaalton> which one should be fixed, the remote HEAD or the branch name(s)?
<tjaalton> s/fixed/changed/
<RAOF> tjaalton: Are you talking about apitrace or mesa here?
<tjaalton> apitrace?
<tjaalton> uh
<tjaalton> -?
<tjaalton> the convention has been to add -unstable(/-experimental) there, that's why setup-repository made apitrace.git/HEAD look like that
<RAOF> Ah, sorry.
<tjaalton> no worries, easy to change either way :)
<RAOF> Ah.
<RAOF> Right. And I didn't notice because I don't clone that!
<tjaalton> exactly
<tjaalton> been there, done that..
<RAOF> I guess it should follow pkg-xorg convention and be named debian-unstable.
<tjaalton> ok, so I renamed refs/heads/{debian,upstream}
<tjaalton> now when you fetch you have both the old and new branches under as origin/*
<tjaalton> -under
<RAOF> Cool
<tjaalton> just reset the local branch to follow the correct one
<tjaalton> dunno what is the best way to remove the old remote branches
<tjaalton> ah, git branch -r -d origin/foo
<RAOF> Already done that.
<tjaalton> cool :)
<tjaalton> so we're set
<RAOF> tjaalton: Mesa build confusion resolved! I was gentarball-ing with a seriously out of date upstream-experimental.
<tjaalton> hah :)
<tjaalton> that would explain glu.h, yes
<RAOF> Yeah, I was wondering about that, given the damn thing has been deleted from the mesa tree!
<dupondje> next Xorg version will support Optimus?
<dupondje> Any roadmap available? thats for 13.04 ?
<ml|vacation> dupondje: kernel support is missing
<dupondje> what do we need exactly for it in kernel?
<ml|vacation> sure you can share buffers, but for it to be actually useful you need to synchronize them to
<ml|vacation> too*
<dupondje> Optimus seems to be a mess to handle :(
<dupondje> things on the roadmap for it in kernel?
<ml|vacation> so that is what I've been working on, kernel tree is somewhere but i wont restart until next monday :p
<tjaalton> dupondje: hm, I thought I asked if it was a hybrid setup.. noticed the bug discussion now
<dupondje> ml|vacation: its planned for 13.04 or will it still make in 12.10 ?
<tjaalton> 13.04
<dupondje> or xorg-edgers ^^
<tjaalton> well the userspace bits are nearly there
<tjaalton> so you can just use a mainline kernel in addition to 12.10
<dupondje> can I follow the status somewhere? So I'm up-to-date ? :)
<tjaalton> https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-hybrid-graphics probably
<tjaalton> it's missing some detail though
<dupondje> subscribed :)
<tjaalton> RAOF: apitrace doesn't have a gentarball target, shouldn't it?
<ml|vacation> dupondje: I'll try to get the upstream pieces inside quantal, but it's less useful without the kernel parts
<dupondje> using a daily kernel isnt an issue :)
<RAOF> tjaalton: It's got a pristine-tar branch
<RAOF> tjaalton: I guess it could also have a gentarball target, though.
<tjaalton> RAOF: oh right, it does
<RAOF> git-buildpackage. It's pretty good :)
<tjaalton> debian/gbp.conf needs an update :)
<tjaalton> oh you fixed it
<tjaalton> hmm, why is the lintian warning suppressed? for backports?
<RAOF> Hm. Does that no longer apply?
<RAOF> It's there because when I first packaged it that warning showed up; is debhelper 9 stable now?
<tjaalton> yeah
<tjaalton> so you can bump it to >= 9
<dupondje> nouveau bug followup is sweet :)
<dupondje> in less then 24h issue is closed :)
<dupondje> the reason we love open source!
<tjaalton> I should probably forward some..
<tjaalton> RAOF: policy is at 3.9.3
<dupondje> try it out :) Ben does a great job!
<tjaalton> I should probably try quantal on my hybrid t420s soon..
<tjaalton> precise finally getting stable on it :)
<dupondje> then its getting boring ;)
<tjaalton> dang, didn't forward the compiz gpu-hungness yet
<tjaalton> RAOF: don't know how to run the beast, but it builds and looks clean, so I'm ok with uploading it to quantal
<RAOF> tjaalton: Install the frontend package and you can run qapitrace (it'll be in the dash), which allows you to trace stuff, or you can run âapitrace trace $appâ to generate a trace.
<RAOF> But given that I've built it in a clean chroot here, and it works, you probably don't have to do much testing :)
<tjaalton> RAOF: yeah, I'll give it a whirl at some point
<tjaalton> oh right, quantal laptop still gpu-hung, hehe..
<RAOF> With the multiarch fixes in there you should even be able to trace wine apps reasonably!
<tjaalton> hope I never need to go down that path..
<tjaalton> but actually, would this help with the gpu hang I have? or is it more for debugging performance issues?
<tjaalton> ah, read the description now :)
<RAOF> Yeah.
<RAOF> If you have some app that triggers the hang you could trace that, then the trace can be replayed on a dev box.
<RAOF> ...which should reproduce the hang, making it easy to test :)
<tjaalton> oh cool
<tjaalton> I'll try it out then
<tjaalton> hmm, should have a way to reproduce it more quickly
<dupondje> [ 9560.052783] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
<dupondje> [ 9560.052788] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state
<dupondje> outch
<tjaalton> dupondje: so file a bug and attach it there
<tjaalton> i915_error_state
<dupondje> on what package?
<tjaalton> ubuntu-bug xorg
<dupondje> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1046505
<ubottu> Launchpad bug 1046505 in xorg (Ubuntu) "i915_hangcheck_hung" [Undecided,New]
<dupondje> there :)
<tjaalton> thanks
<tjaalton> dupondje: can you reproduce it?
<dupondje> tjaalton: nope, unable to reproduce it
<dupondje> never had it before afaik
#ubuntu-x 2012-09-06
<tjaalton> RAOF: hey, could you check libglu from git that it's reasonably packaged? mainly ripped off from mesa, but in case I missed something..
<RAOF> Ok.
<tjaalton> thanks
<tjaalton> merging xserver 1.13
<LLStarks> tjaalton, and break fglrx?
<tjaalton> LLStarks: it's already broken
<tjaalton> we have rc5 in quantal
<LLStarks> kinda sad that amd makes a driver that can only be used for a few days a year if you are an alpha tester
<tjaalton> at least you have a proper replacement
<LLStarks> radeon is not a replacement lol
<tjaalton> says you
 * RAOF is perfectly happy on radeon
<LLStarks> i hear bridgman and deucher don't even coordinate on what features are okay to open source
<RAOF> That sounds like an odd complaint; AFAIK, video decode is the only thing that's not available.
<tjaalton> and power management, aiui
<LLStarks> powerxpress needs work too
<LLStarks> enduro or whatever its called now
<LLStarks> can't use it without prime or fglrx
<LLStarks> atpx doesn't work
<RAOF> I'm not sure how much power management is âwe don't have the specsâ versus âwe don't have the manpowerâ. Certainly it's substantially worse than fglrx.
<RAOF> What's atpx?
<tjaalton> doesn't vdpau work with it nowadays?
<RAOF> Yeah, but shaders only. The video decode hardware is tied up with the video encryption hardware, and there be dragons.
<tjaalton> ahh..
<RAOF> At least, that's what I gathered at XDC.
<RAOF> Although there's been some reverse-engineered decode support happening recently, IIRC.
<LLStarks> RAOF, i think amd just open sourced the acpi
<RAOF> LLStarks: The acpi for what?
<LLStarks> http://lists.freedesktop.org/archives/dri-devel/2012-July/025517.html
<LLStarks> enduro laptops
<tjaalton> that's nice
<RAOF> Ah. The switcheroo interface. I take it they've settled on just the one now, then? :)
<RAOF> tjaalton: Seems like now would be a good time to clean up those lintian messages?
<tjaalton> RAOF: libglu or xserver?
<RAOF> tjaalton: libglu.
<tjaalton> oh right, ha
<tjaalton> hmm, dunno about the itp bug
<RAOF> Oh, I'd ignore that.
<RAOF> But you might as well fix the copyright address, drop all those ancient Conflicts, and add a symbols file.
<tjaalton> right
<tjaalton> replaced the address with an url
<tjaalton> and the source package warnings are due to me not being in uploaders
<RAOF> Pfft.
<tjaalton> don't dare to add myself there :P
<tjaalton> uploaded libglu to the queue
<tjaalton> oh dang
<tjaalton> forgot the symbols file
<tjaalton> but, it hasn't got new ones for years I think
<RAOF> Oh, yeah.
<RAOF> AFAIK there shouldn't be any new symbols in libglu, ever. The symbols file is just a nice heads up should we break something in the build :)
<tjaalton> right
<tjaalton> uploaded openchrome 0.3.1, let's hope it doesn't need a FFe
<tjaalton> we should probably ask for an exception for driver point-releases
<ml|vacation> well those are usually a good idea
<ml|vacation> but with raof on release team, shouldn't be a problem :)
<tjaalton> wacom 0.17.0 fails to build miserably
<Prf_Jakob> Soo the daily quantal iso freaks out a bit.
<Prf_Jakob> The installer started at 2560x1600
<Prf_Jakob> "Try Ubuntu" mode fixed that tho.
<tjaalton> that's with a vmware virtual machine?
<Prf_Jakob> oh, yeah
<tjaalton> i've seen a bug about that but can't find it now
<tjaalton> btw, vmmouse doesn't use signal-safe logging
<Prf_Jakob> Okay
<Prf_Jakob> Is that bad?
<tjaalton> not sure
<Prf_Jakob> And is that a Xorg 1.13 feature?
<tjaalton> logs in 1039157 look bad :)
<tjaalton> bug 1039157
<ubottu> Launchpad bug 1039157 in linux (Ubuntu Precise) "vmwgfx kernel module not loaded by default" [Undecided,In progress] https://launchpad.net/bugs/1039157
<tjaalton> yeah
<tjaalton> not that any released evdev version has that either
<Prf_Jakob> Btw, do you work for canonical?
<tjaalton> yes
<Prf_Jakob> k, (put you into a contact list for devs).
<tjaalton> ok
<Prf_Jakob> I'm going on a extended leave, so I'm writing things down for other VMware devs :)
<Prf_Jakob> Mmm it went 2560x1600 after I installed it as well.
<Prf_Jakob> Is Quantal using Wayland?
<tjaalton> no
<tjaalton> so the splash screen has 25x16 or just X?
<tjaalton> assuming the bug above isn't fixed yet, what if you force load vmwgfx via kernel cmdline?
<tjaalton> it should use kms then?
<Prf_Jakob> Yeah it worked fine when I loaded the kernel module.
<tjaalton> ok, so it's the same bug
<tjaalton> or a symptom of it
<Prf_Jakob> Tho I don't know if thats because I restarted lightdm
<Prf_Jakob> Or because kms fixed it.
<Prf_Jakob> Oh right, dave sent out some patches to dri-devel that fixes that.
<tjaalton> dumb ioctl patch?
<Prf_Jakob> Feature request, disable the dash blur effect when on llvmpipe, that thing kills performance.
<Prf_Jakob> No, let me look it up.
<tjaalton> i bet there are people on it :)
<tjaalton> since no unity2d anymore
<Prf_Jakob> K
<Prf_Jakob> Heh somebody already resent a identical patch :)
<Prf_Jakob> Like right now.
<tjaalton> "add MODULE_DEVICE_TABLE so vmwgfx loads at boot"
<Prf_Jakob> Yeah
<Prf_Jakob> There is one by Dave as well, along with a config adding patch.
<Prf_Jakob> You should apply both of Daves, and enable the config, that way you can remove the config hack in xf86-video-vmware.
<tjaalton> oh right, those ones
<tjaalton> yeah
<tjaalton> I'll let tim know :)
<Prf_Jakob> http://lists.freedesktop.org/archives/dri-devel/2012-August/027124.html & http://lists.freedesktop.org/archives/dri-devel/2012-August/027125.html
<Prf_Jakob> I RB them all here http://lists.freedesktop.org/archives/dri-devel/2012-August/027139.html
<tjaalton> yeah
<Prf_Jakob> Ok I replyed to rtg's email.
<Prf_Jakob> Is he on IRC? Is he a X or Kernel guy+
<Prf_Jakob> ?
<tjaalton> kernel
<tjaalton> on #ubuntu-kernel
<Prf_Jakob> ok
<Prf_Jakob> ta
<tjaalton> enough uploads for one day.. mesa, xserver, -intel, -openchrome
<dupondje> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1046505 => just happend again to me on same site :p
<ubottu> Launchpad bug 1046505 in xorg (Ubuntu) "i915_hangcheck_hung" [Undecided,New]
<tjaalton> dupondje: would be nice if you could upstream it to bugs.fd.o
<dupondje> https://bugs.freedesktop.org/show_bug.cgi?id=54611 there :)
<ubottu> Freedesktop bug 54611 in Driver/intel "i915_hangcheck_hung" [Normal,New]
<tjaalton> great :)
<shadeslayer> tjaalton: more weirdness, if I now boot without nomodeset, it hangs at : fb conflicting fb hw usage radeondrmfb vs efi vga
<tjaalton> the beta got silently released, it seems
<bjsnider> what beta?
<bjsnider> had to do that
<tjaalton> just noticed all the uploads went in
 * dupondje really likes the response times on bugs.fd.o
<dupondje> :
<dupondje> :)
#ubuntu-x 2012-09-07
<tjaalton> wonderful, mesa failed to build on md64
<RAOF> Odd? Why?
<Sarvatt> https://launchpad.net/ubuntu/+source/mesa/9.0~git20120903.e1673d20-0ubuntu1/+build/3768452
<Sarvatt> thats bad, screwed updates for amd64 people
<tjaalton> built just fine on my sbuilder, dammit
<tjaalton> and my ppa it seems
<Sarvatt> new git checkout probably fixes it, only like 30 radeon/llvm commits since then
<Sarvatt> ok most of those are radeonsi we dont enable :)
<tjaalton> sure we do
<tjaalton> on mesa at least
<Sarvatt> oh i was thinking USE_R600_LLVM_COMPILER
<ajmitch> so it should be relatively safe at the moment to install from the q-lts-backport ppa, I assume? 
 * ajmitch can pick up pieces if things go wrong
<Sarvatt> ajmitch: not sure, the guy updating that ppa has been on vacation for 2 weeks, it might not be ok
<ajmitch> ah, he's still touring .au?
<Sarvatt> lots of changes in quantal since then
<Sarvatt> i've been on vacation too and havent kept up
 * ajmitch mostly wanted the kernel, but new X on ivy bridge was tempting to try out
<ajmitch> I'll wait for a bit before I update that part then
<tjaalton> that is kept uptodate
<tjaalton> by the kernel team, so go ahead and use the kernel
<Sarvatt> tjaalton: it still has mesa 8.0.4, way out of date
<tjaalton> just fine for ivy
<Sarvatt> 3.6 kernel is the biggest boost for ivy at the moment
<ajmitch> is that still likely to land for quantal?
<tjaalton> who wants boost, stability is what I'm after :)
<Sarvatt> nope 3.5
<tjaalton> 3.4-> is what provides that
 * ajmitch wants stability, this zareason laptop came with an odd 3.3.6 kernel from a PPA which is far from ideal
<Sarvatt> zareason shipped a ppa with a 3.3 kernel?
<Sarvatt> yeah 3.5 is way better off
<Sarvatt> 3.2 had problems that is taking quite a long time to backport fixes to
<ajmitch> yeah I suspect that's why they used what they did, but it has some serious issues, I prefer to recommend they use something tested
<tjaalton> oh i'm not on ubuntu-announce, that's why didn't notice beta was released
<ajmitch> you're missing out :)
<tjaalton> before these were sent to u-d-a
<Sarvatt> zareason is strange, they ship what works, theres lots of people paid to make 3.2 work for oems which we're doing for lenovo hp asus and dell but -proposed updates only come once every 3 weeks so it takes awhile, by now 3.2 in -proposed should be ok (aka 3.2.0-31) but 3.5.x aka quantal really is optimal for performance reasons
<tjaalton> ah, didn't know we have mesa 9.0 in quantal..
<Sarvatt> tjaalton: you uploaded it........
<tjaalton> a snapshot, yes
<tjaalton> oh well :)
<ajmitch> Sarvatt: it is a bit strange, they're a small team & have set up a NZ shop recently, so I met them last weekend
<tjaalton> just sent one more patch to backport to 3.2.x, no reply yet though
<tjaalton> ben is probably on holiday, no activity since aug 19th
<tjaalton> on the stable tree at least
<tjaalton> triggered a mesa rebuild on amd64, went fine this time ..
<tjaalton> bf ->
<RAOF> --parallel issues?
<tjaalton> most likely
<Sarvatt> cool
<RAOF> tjaalton: What was that -intel bug where compiz was hung with a black screen after resume, waiting for a swap that'll never complete?
<RAOF> tjaalton: Nevermind; backscroll wins!
<tjaalton> :)
<tjaalton> 966744
<tjaalton> so I've hit other bugs trying to reproduce that :/
<tjaalton> +while
<RAOF> tjaalton: Were you still reproducing that on Quantal? Jason Warner & Didier seem to be seeing it.
<tjaalton> RAOF: yeah, but not that frequently
<tjaalton> was it you or ickle who suggested to run compiz with xtrace
<RAOF> ickle, I think.
<tjaalton> uploaded intel-gpu-tools 1.3, forgot to close the bug on the changelog
<RAOF> :)
<tjaalton> "oops, no ffe"
<tjaalton> RAOF: hey, could you accept gvfs for precise-proposed, fixes bug 819304
<ubottu> Launchpad bug 819304 in gvfs (Ubuntu Precise) "gvfsd-cdda crashed with signal 5 in _g_dbus_oom()" [Low,In progress] https://launchpad.net/bugs/819304
<dileks> hi. are you planning mesa-9.0 backports in q-lts-backport ppa?
<tjaalton> later
<tjaalton> the whole stack will be copied
<tjaalton> what gets in quantal
<dileks> what means exactly later, one of the next betas or very later?
<dileks> I can do packaging myself, thats not the problem.
<tjaalton> it doesn't need packaging but running scripts
<tjaalton> maybe next week once maarten is back from vacation
<dileks> scripts sounds good
<dileks> where are those "scripts"?
<tjaalton> bzr somewhere, i was supposed to review them but.. :P
<tjaalton> seem to be working fine
<dileks> I was thinking of bumping to xserver-1.13 (final) and take sources for libdrm/intelgfx from quantal
<dileks> hmm, v2.20.6 released of intelgfx ddx
<tjaalton> can't wait until next week?
<dileks> looks like I only need to rebuild quantal package
<dileks> no. want to do some drm-intel-next testing.
<tjaalton> then run quantal
<dileks> maybe
<dileks> just read today an article about q beta is released
<dileks> anyway, got to go
<dileks> thanks for the informations
<tjaalton> yw
<tjaalton> apw: did you have issues with the mesa in quantal? mind giving the newer snapshot a try if yes?
<apw> tjaalton, is it in -proposed?
<apw> tjaalton, or has it been in there a few days?
<tjaalton> since after the beta, but hang on
<apw> the machine which was very unwell has -proposed enabled and now seems ok
<tjaalton> it went straight to quantal
<tjaalton> but there are people saying that a compiz/unity update fixed it, probably papering over the actual bug
<tjaalton> since compiz is using gles now
<apw> tjaalton, yes then i think i see the same
<apw> as the issue went away around monday
<tjaalton> hmm
<tjaalton> ok, well good to know that it's better, now to figure out how to find out if the old bug is still there
<tjaalton> downgrading compiz isn't easy, I'm told
#ubuntu-x 2012-09-08
<ml|vacation> RAOF: argh now I know how you feel, total travel back is going to be over 32 hours I think..
#ubuntu-x 2013-09-03
<shadeslayer> any ideas why this would happen : http://paste.kde.org/p53409839/
<shadeslayer> when I connect a HDMI cable to my DVI adaptor
<mlankhorst> shadeslayer: kernel bug probably?
#ubuntu-x 2013-09-04
<bdmurray> mlankhorst: what is the status of bug 1033533?  I've just run into it, so apport tells me, on saucy
<ubottu> bug 1033533 in xserver-xorg-video-nouveau (Ubuntu Raring) "Xorg crashed with SIGABRT: exaMemcpyBox with src=0x0 on nouveau with SW rendering" [High,Triaged] https://launchpad.net/bugs/1033533
#ubuntu-x 2013-09-05
<mlankhorst> bdmurray: it's not a real bug, it's a consequence of another bug, and that bug only makes it harder to find the real bug
<agrestringere> Hello, looking at a bug #1220685 that seems like a hybrid Nvidia "optimus" issue, is there a response or wiki materials I can include as a reply to the bug?
<ubottu> bug 1220685 in xorg (Ubuntu) "Unity did not start on fresh install" [Undecided,Confirmed] https://launchpad.net/bugs/1220685
<bdmurray> mlankhorst: well, do you have any suggestions on how I can help with finding the real bug or avoid it as it is making it hard to work.
<mlankhorst> bdmurray: well.. whats in dmesg when it happens?
<mlankhorst> bdmurray: but I fear you may need to use an older kernel probably, 3.6 or earlier :P
<bdmurray> mlankhorst: I don't see anything in dmesg
<mlankhorst> bdmurray: that's unlikely
#ubuntu-x 2013-09-06
<mlankhorst> bdmurray: nm same happened here :P
<mlankhorst> but system was locked up first, I think
#ubuntu-x 2013-09-08
<erappleman> trying to understand why chris is injecting a political message upstream... that NEWS file will be a part of the ubuntu archive sources
<ScottK> Then it will be easier to understand why things are in there as patches and not upstream.
#ubuntu-x 2014-09-04
<bandit-led> i keep experiencing an issue with screen corruption example http://i.imgur.com/wIXZMLY.png and ideas thoughts?
<bandit-led> Card: NVIDIA GF114 [GeForce GTX 560] bus-ID: 01:00.0 chip-ID: 10de:1201 
<bandit-led> X.Org: 1.15.1 drivers: nvidia (unloaded: fbdev,vesa,nouveau) Resolution: 1680x1050@60.6hz 
<bandit-led> LX Renderer: GeForce GTX 560/PCIe/SSE2 GLX Version: 4.4.0 NVIDIA 343.13 Direct Rendering: Yes
#ubuntu-x 2014-09-05
<led-bandit> is there an active nvidia channel for linux?
<mlankhorst> for nouveau?
<mlankhorst> nvidia bugs go through nvidia, mostly
<led-bandit> a response! yay
<led-bandit> i am in #nvidia and here posted almost 24 hours ago no response
<mlankhorst> i dont think they look at it
<led-bandit> lol great 97 people in that channel and all bots
<led-bandit> thank-you very much for the reply
<led-bandit> looks like i am stuck in xfce for the time being :D
#ubuntu-x 2015-08-31
<ricotz> mamarley, I am currently pushing 304.128
<mamarley> ricotz: Where did you find out about that?  I normally check the Linux part of the devtalk.nvidia.com forum and I haven't seen anything there.
<mamarley> Maybe they don't post legacy drivers there?
<ricotz> mamarley, I guess aaron didn't noticed yet
<ricotz> the ftp server lists ist
<ricotz> ist/it
<mamarley> Ah, OK.  I will start checking that daily as well.
<mamarley> Or maybe I will be an overachiever and write a script that checks it automatically...
<ricotz> 355.11 ;)
<mamarley> Argh!
<mamarley> Maybe I should handle this one?  I don't want you to have to do all the work...
<ricotz> please do
<mamarley> OK
<ricotz> mamarley, please use the ppa packaging for now
<mamarley> Yep, that is what I am doing.
<ricotz> not the git one
<ricotz> ok
<ricotz> vivid/wily are the same, trusty has a different substvars
<ricotz> feel free to upload it is somewhere else for review if you are unsure
<ricotz> bbÃ¶
<ricotz> bbl
<mamarley> OK
<mamarley> ricotz: Is nvidia-settings any different across the distro versions?
<ricotz> no
<mamarley> Thanks, that's what I thought.
<mamarley> ricotz: I uploaded nvidia-settings to https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages.  Vivid and Trusty are failing but that is just because I forgot to put the libvdpau update in there as well.
<ricotz> mamarley, ok, no, use a common orig-tarball
<mamarley> That's what I was trying to do.  I used "debuild -S".
<ricotz> try harder then ;)
<ricotz> "dpkg-buildpackage -S -sa" and "dpkg-buildpackage -S -sd"
<mamarley> OK, I will do that.  Just a sec...
<ricotz> you used "uupdate"?
<mamarley> I'm not sure what that means.
<ricotz> man uupdate
<ricotz> mamarley, want me to upload nvidia-settings?
<mamarley> No, I want to figure out how to do it correctly.
<mamarley> Dangit, even when I use debuild -S -sd it still uploads the orig tarball.
<mamarley> I will try again from scratch.
<ricotz> mamarley, any luck?
<mamarley> ricotz: Uh, maybe.  Just a minute.
<mamarley> Here goes nothing.
<mamarley> ricotz: I think it worked that time!
<mamarley> Yep, all the uploads were accepted even though only the first had the orig.tar.bz2.
<mamarley> Now for the driver itself.
<ricotz> mamarley, btw you don't need to upload things to check if a source package as wanted
<ricotz> mamarley, ok
<ricotz> please create new ones for the gpu ppa
<ricotz> mamarley, I have the driver ready for upload
<mamarley> ricotz: Do you want any more changes other than just the version number?
<mamarley> If you have the driver ready, don't wait for me.  I can practice on my staging PPA so next time I won't need any help.
<ricotz> mamarley, should I upload everything then?
<mamarley> ricotz: Sure, but can you please check my driver upload to my staging PPA once I get that done?
<ricotz> mamarley, feel free to ask though, but in my experience it sometimes helps to figure out things yourself
<ricotz> mamarley, ok
<mamarley> ricotz: I did figure it out myself before, but as you can see, I figured it out all wrong. :/
<ricotz> mamarley, the fundamental problem with nvidia-settings it isnt debsrc-3.0 and only supported *.tar.gz tarballs therefore the original tar.bz2 gets repacked
<mamarley> Ah, OK.
<mamarley> I didn't realize that before, so I downloaded the .tar.bz2 files because they are smaller.
<ricotz> there are *only* official bz2 versions
 * mamarley beats himself with the clue-by-four.
<mamarley> ricotz: I know I appear as a complete n00b right now, but I promise you I can be helpful.
<ricotz> mamarley, don't worry
<mamarley> I just need to get accustomed to the correct way of doing things after doing it wrong for so long.
<ricotz> mamarley, you are familiar with the dkms patching stuff in the driver packagign though?
<mamarley> Yes, I have added patches to fix compiling against new kernels a few times.
<ricotz> ok
<mamarley> I am uploading my practice driver now, but it takes a long time because I have a ridiculously slow Internet connection right now.
<ricotz> mamarley, same here ;)
<mamarley> ricotz: Woohoo, it looks like all of my driver builds were successful in https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages !
#ubuntu-x 2015-09-02
<ricotz> mamarley, are you going to look at 346.96?
<mamarley> ricotz: Sure.
<mamarley> Did you ever look to see if the packaging I did of 355.11 was acceptable?
<ricotz> mamarley, alright, push it to your staging ppa, I will look at it then
<mamarley> Sure.
<mamarley> 355.11 is already in the staging PPA.
<mamarley> ricotz: I know the packaging for Wily and Vivid is the same, but is there any difference between Trusty and Precise?
<ricotz> mamarley, yes, huge ones!
<mamarley> OK, thanks!
<ricotz> better grab all packages
<mamarley> OK, will do.  Still working on Wily right now.
<ricotz> bbl
<mamarley> I got it packaged for Wily, now I am testing to make sure the kernel module will compile before I upload it.
<mamarley> It compiled successfully, so I will upload to my staging PPA now.
<mamarley> ricotz: OK, everything is uploaded to https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages now.  They aren't done building yet, but I am going to be gone for a few minutes.
<mamarley> ricotz: They are compiled successfully now. :)
<ricotz> mamarley, great, I will take a look later and copy them over if everything is fine
<mamarley> ricotz: Is there any reason why nvidia-settings is still at 346 for Precise?  Is there a dependency missing or something?
<mamarley> Oh wait, I see it.  Drivers above 346 were never packaged for Precise, so updating nvidia-settings to a higher major version would be pointless.
<jcastro> ricotz: mamarley: at some point we should discuss how to get these into distro if appropriate
#ubuntu-x 2015-09-03
<ricotz> mamarley, thanks for 340.93, I will eventually get to it
<mamarley> ricotz: No problem.  I noticed you only copied the one for Trusty but uploaded everything else yourself.  Was there some error in my packaging?
<ricotz> mamarley, no obvious error, but there are were official releases since the last update and you didnt drop the kernel patches which are not needed anymore
<ricotz> I kept the transition packages for 331 to force moving to 340
<mamarley> Oops, sorry.  I thought you wanted me to drop the transition packages?
<ricotz> mamarley, that part was fine and in case of 340 needed since 331 is obsololete and unsupported
<mamarley> Ah, OK.
<mamarley> I am beginning to think that it was a bad idea to make me a part of this project.  All I am doing is wasting your time...
<ricotz> mamarley, I copied yours before pushing so the diffs are available
<ricotz> mamarley, ah, you saved me quite some time to get the tarballs up ;)
<ricotz> having 340 for precise would be nice though
<mamarley> ricotz: Just wait until I move in a month.  My upload connection will be 20x faster. :)
<ricotz> mamarley, hehe
<jcastro> mamarley: ricotz: I have made https://launchpad.net/~graphics-drivers-testers for people who want to send feedback
#ubuntu-x 2015-09-05
<soee> hi, can someone confirm that it is impossible to switch to nvidai card on Wily atm. (when using machine with intel + nvidia) ?
<brainwash> so, can Xorg be run as non-root in ubuntu now?
<brainwash> wily + startx
<brainwash> there is https://bugs.launchpad.net/lightdm/+bug/1292324
<ubottu> Launchpad bug 1292324 in Light Display Manager "Support non-root X" [Wishlist,Triaged]
#ubuntu-x 2015-09-06
<tjaalton> no, and with bugs like https://github.com/systemd/systemd/issues/1163 it won't become the default until stable
#ubuntu-x 2016-09-05
<tseliot> ricotz, mamarley: I have just pushed a couple of changes in yakkety (nvidia-graphics-drivers-367_367.44-0ubuntu2)
<mamarley> Not seeing that in Launchpad yetâ¦
#ubuntu-x 2016-09-08
<ricotz> mamarley, I assume you are already playing with 370.28?
<mamarley> ricotz: Nope, I wasn't even aware that it existed, but I will package it shortly.
<ricotz> mamarley, no problem, I started to look at in the meantime
<mamarley> ricotz: Does that mean I shouldn't do anything with it?
<ricotz> mamarley, I will update the driver package, if you want to take a look at nvidia-settings?
<mamarley> Sure
<ricotz> ah 367.44-0ubuntu2 needs to be merged too
<mamarley> Yeah, tseliot mentioned that a few days ago but it hadn't been uploaded yet.
<ricotz> yeah seems to be lost somewhere on the way
<soee_> NVIDIA 370.28 Linux Driver Has Pascal Overclocking, PRIME Sync, PixelShiftMode
<mamarley> soee_: Yep, ricotz is working on it.
<soee_> \o/
<ricotz> mamarley, soee_, launchpad is taking quite some time for publishing :(
<mamarley> Yeah, that happens a lot recently.
 * mamarley wonders if anyone has tested the 370 series on a 1000-series card yet.
<Sarvatt> mobile 1080 was fine with 370.23
<mamarley> Cool :)
#ubuntu-x 2017-09-04
<henning__> hi there. could anyone tell me what is being executed in ubuntu in respect to x when i connected an additional monitor to my computer?
<tseliot1> henning__: the gnome-settings-daemon (or the unity-settings-daemon) deals with that
#ubuntu-x 2018-09-03
<tjaalton> (win 29
<tjaalton> uh
#ubuntu-x 2018-09-05
<ricotz> mamarley, hi, are you able to use gimp on your nvidia machine?
<mamarley> ricotz: It starts but I haven't tested actually editing any images.
<ricotz> mamarley, I see, it doesn't even show up here and I suspect nvidia
<tomreyn> btw the ubuntu (proprietary gpu) drivers ppa points to mmarley's github. but this is now 404.
<mamarley> Oh, sorry, I never updated that anyway and I deleted almost everything I had on GitHub when it was acquired by Microsoft.
<tomreyn> so it'd be good to remove / replace the link at https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa (to https://github.com/mamarley/nvidia-graphics-drivers/) if someone could do this.
#ubuntu-x 2018-09-07
<RAOF> Hey, would it be possible to add a development link from `libnvidia-egl-wayland.so.1` to `libnvidia-egl-wayland.so.1.0.3` (and obviously keep it up to date?)
<RAOF> Urgh, of course I mean a `libnvidia-egl-wayland.so` link.
<tjaalton> mamarley: ^
