#ubuntu-x 2007-03-05
<crimsun> tepsipakki: (http://lists.debian.org/debian-devel-announce/2006/11/msg00010.html has a couple hints if you've not read it already)
<tepsipakki> crimsun: the bugs linked from that are already fixed in the versions that feisty has
<tepsipakki> slomo pointed out a possible gtk-bug which is reported upstream
<tepsipakki> https://launchpad.net/ubuntu/+source/gtk+2.0/+bug/88608
<Ubugtu> Malone bug 88608 in gtk+2.0 "[apport]  xchat crashed with SIGABRT in xcb_xlib_lock" [High,Confirmed]  
* Starting logfile irclogs/ubuntu-x.log
<tepsipakki> hi seb128 
<seb128> Hi tepsipakki
<tepsipakki> xf86-video-intel 2.0RC1 was released this morning
<seb128> good
<tepsipakki> along with xorg-server 1.2.99.901 :)
<seb128> do you have an updated package? ;)
<tepsipakki> it needs the new server
<tepsipakki> but I packaged a git-snapshot on saturday
<seb128> the xorg-server question should be discussed with Mithrandir and cjwatson
<tepsipakki> true
<tepsipakki> I'm just playing here
<tepsipakki> we have some brand new Lenovo hardware with widescreen monitors and the current drivers suck
<tepsipakki> so I'll test the new driver
<tepsipakki> the server works fine with my ati
<seb128> good
<Treenaks> tepsipakki: does ati work with direct rendering as well for you?
<tepsipakki> yes
<Treenaks> tepsipakki: my dad's pc complains about a version mismatsch somewhere (1.25.0 vs 1.3.0)
<tepsipakki> with the old one?
<Treenaks> tepsipakki: with yesterday's feisty
<tepsipakki> I don't remember having issues
<Treenaks> I'll try to debug some more if I can
<tepsipakki> ok
<tepsipakki> seb128: could we sync x11proto-randr from experimental (1.2.0-1 -> 1.2.1-1)?
<seb128> tepsipakki: sure
<tepsipakki> that's needed for xorg-server-1.3 to compile
<tepsipakki> and it's just headers anyway
<tepsipakki> and a minor release.. blabla :)
<tepsipakki> seb128: slomo pointed out bug 88608
<Ubugtu> Malone bug 88608 in gtk+2.0 "[apport]  xchat crashed with SIGABRT in xcb_xlib_lock" [High,Confirmed]  https://launchpad.net/bugs/88608
<seb128> tepsipakki: what about it?
<seb128> tepsipakki: looks like a GTK bug, I'm subscribed to the bug upstream
<tepsipakki> do you feel it is a gtk+2.0 bug?
<tepsipakki> oh, good
<seb128> weird that slomo pinged you about it
<seb128> he opened the GTK upstream bug
<tepsipakki> actually first he asked if the patch in #74948 could be included
<tepsipakki> bug 74948
<Ubugtu> Malone bug 74948 in xserver-xorg-video-ati "Please include xv scaling patch from upstream GIT" [Undecided,Confirmed]  https://launchpad.net/bugs/74948
<tepsipakki> and then referred to a brief discussion with fabbione on #u-d about the locking bugs
<tepsipakki> and then I found this one: https://bugs.freedesktop.org/show_bug.cgi?id=9336
<Ubugtu> Freedesktop bug 9336 in Lib/Xlib "Assert in Java application WW2D" [Normal,Assigned]  
<tepsipakki> Novell has a patch which they have applied. It's just a workaround, but maybe something that we could want too
<seb128> right
<seb128> we want a way to workaround bugged apps like java things mentioned there
<tepsipakki> here is the patch https://bugzilla.novell.com/attachment.cgi?id=122211
<seb128> yeah, I already look at it, looks fine enough
<tepsipakki> I'll ask on #debian-x what they think about it
<seb128> cool
<tepsipakki> hm, what is it that makes the manpages to be .1x and not .1?
<tepsipakki> configure:      linux*) APP_MAN_SUFFIX=1x ;;
<tepsipakki> easy
<tepsipakki> xorg-server_1.2.99.901-0ubuntu1 and xserver-xorg-video-intel_1.9.91-0ubuntu1 built
<Ubugtu> New bug: #89827 in xserver-xorg-video-tdfx (main) "Driver TDFX (Voodoo3) not supported" [High,Unconfirmed]  https://launchpad.net/bugs/89827
<tepsipakki> X Window System Version 1.2.99.901 (1.3.0 RC 1)
<tepsipakki> works
<tepsipakki> ..but the intel-driver not
<seb128> oh?
<tepsipakki> for some reason it still doesn't get the native resolution of 1680x1050
<crimsun> and you're sure the hardware is emitting DDC info properly?
<crimsun> I have several FPs that don't, and thus 1680x1050 fails
<crimsun> (Dell 20"s)
<crimsun> however, I also have one Acer 20" that works properly
<tepsipakki> no I'm not sure
<tepsipakki> it's Lenovo T221 or something
<tepsipakki> it does recognize it as a widescreen though, so I get a nice 1280x800 :)
<tepsipakki> now the intel-driver pushes 1280x768 on a Sun monitor (native 1280x1024)
<Ubugtu> New bug: #89590 in xorg (main) "Feisty doesn't recognize 17" LCD screen" [Undecided,Needs info]  https://launchpad.net/bugs/89590
<Ubugtu> New bug: #89853 in xorg (main) "[regression]  X broken in Feisty Herd 5 Live " [Undecided,Unconfirmed]  https://launchpad.net/bugs/89853
<tepsipakki> I've put a new ati-driver in the usual place
<tepsipakki> it has three patches which fix bugs
<tepsipakki> thought that maybe they needed some testing before uploading, but either way
<pochu> tepsipakki: about my question of the other day, do you know where can I get the modesetting driver?
<pochu> I've I can obtain it, I'll test a newer git checkout :)
<tepsipakki> I've packaged 1.9.91
<tepsipakki> but it doesn't convince me
<pochu> tepsipakki: can I test it?
<pochu> hmm, why?
<tepsipakki> it needs a newer server
<tepsipakki> I can't get it to work with any other resolution than 1280x768
<tepsipakki> I can put those available
<pochu> I can't get it to work with any other resolution than 1280x768
<pochu> that can be the reason of my problem ^
<pochu> though I have 1.7.2.git20070210-1
<tepsipakki> http://users.tkk.fi/~tjaalton/xorg72/crack
<tepsipakki> god this Z61p is hopeless
<tepsipakki> network goes up and down all the time, can't install it
<pochu> if I'm using a lower vertical resolution, it would be stretched
<pochu> tepsipakki: that's the i810, or the modesetting driver?
<tepsipakki> both
<tepsipakki> they got merged
<tepsipakki> as -intel
<pochu> oh, ok :)
<pochu> gonna test
<miguel> tepsipakki, I'm pochu
<miguel> it doesn't work
<miguel> (EE) Failed to load /usr/lib/xorg/modules/drivers//i810_drv.so
<tepsipakki> use intel
<miguel> (EE) Failed to load module "i810" (loader failed, 7)
<miguel> tepsipakki, ah, oks
<miguel> tepsipakki, in xorg.conf?
<tepsipakki> although there should be a symlink
<tepsipakki> yes
<miguel> gonna try
<miguel> I thought 7.2 didn't use xorg.conf :)
<tepsipakki> it still needs one for practical reasons..
<tepsipakki> though it should work without
<miguel> doesn't work
<miguel> same error
<miguel> though I've changed the xorg.conf
<tepsipakki> strange
<miguel> oh, and Fatal server error: no screens found
<miguel> maybe this is useful:
<miguel> dlopen: /usr/lib/xorg/modules/drivers//intel_drv.so: undefined symbol: xf86CrtcConfigPrivateIndex
<miguel> (EE) Failed to load /ser/lib/xorg/modules/drivers//intel_drv.so
<miguel> (EE) Failed to load module "intel" (loader failed, 7)
<tepsipakki> did you upgrade the server?
<miguel> (EE) No drivers available
<tepsipakki> grab the new xserver-xorg-core from the same url
<miguel> tepsipakki, with the package in your webpage?
<tepsipakki> yes
<miguel> tepsipakki, ah, ok
<miguel> hehe
<miguel> didn't do :(
<miguel> tepsipakki, could you give me the url again?
<tepsipakki> http://users.tkk.fi/~tjaalton/xorg72/crack
<miguel> tepsipakki, the core is enough?
<tepsipakki> yep
<tepsipakki> lunch-> (overdue)
<miguel> tepsipakki, it works
<miguel> but a few issues:
<miguel> the fonts in the login (and the circles of the password) are really, really, small
<miguel> and when I restarted the X, the screen had, for a second, horizontal color lines
<miguel> this happen also when logout
<miguel> though the "little fonts" isn't anymore :)
<miguel> I'm going to restart, to be sure about the other issue
<miguel> tepsipakki, oh, and I didn't have to change the xorg.conf (it had the i810 driver), so the symlink is working :)
<miguel> rebooted, and still that problem
<miguel> I can take a screenshot, or make a video, if you don't know what I'm talking about (my english is not good enough)
<miguel> anyway, I have to go now
<miguel> I'll come later
<miguel> bye!
<pochu> tepsipakki: still here :)
<pochu> I was wrong, the fonts issue is still there
<pochu> in the login page, in the options menu, for example
<pochu> now I have to go
<pochu> bye!
<Ubugtu> New bug: #89870 in xserver-xorg-video-ati (main) "XaaNoOffscreenPixmaps needed to work winth compiz and radeon" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89870
<Ubugtu> New bug: #89669 in xorg (main) "herd4 did not detect videocard at install ..." [Undecided,Unconfirmed]  https://launchpad.net/bugs/89669
<Ubugtu> New bug: #28898 in xserver-xorg-video-ati (main) "IBM A21p display is corrupted" [Medium,Needs info]  https://launchpad.net/bugs/28898
<Ubugtu> New bug: #86821 in libxrandr (main) "[apport]  totem crashed with SIGSEGV in __pthread_mutex_unlock_usercnt()" [Medium,Needs info]  https://launchpad.net/bugs/86821
<Ubugtu> New bug: #86363 in linux-source-2.6.20 (main) "Feisty: When switching users the touchpad won't work (dup-of: 68370)" [Undecided,Confirmed]  https://launchpad.net/bugs/86363
<pochu> tepsipakki: I'm here again, if I can help with something, tell me :)
<tepsipakki> hi, I saw that font issue as well
<seb128> tepsipakki: have you read that /etc/X11/rgb.txt conflict bug?
<tepsipakki> yes
<tepsipakki> maybe we need an xrdb update?
<seb128> that looks like a conffile move no?
<tepsipakki> sorry
<tepsipakki> let me check again
<tepsipakki> gah, I'll check it when I get home ->
* Starting logfile irclogs/ubuntu-x.log
<Ubugtu> New bug: #89942 in xserver-xorg-video-i810 (main) "Screen corruption after suspend/resume" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89942
<Ubugtu> New bug: #89930 in xorg (main) "screen size not detected correctly" [Undecided,Needs info]  https://launchpad.net/bugs/89930
<Ubugtu> New bug: #89771 in laptop-mode (main) "touchpad does not work after switching users on laptop (dup-of: 68370)" [Undecided,Confirmed]  https://launchpad.net/bugs/89771
<Ubugtu> New bug: #89742 in compiz (main) "[apport]  compiz.real crashed with SIGSEGV in viaGetLock() (dup-of: 81889)" [Medium,Rejected]  https://launchpad.net/bugs/89742
<paul__> I wish bug #68267 will be look at.
<Ubugtu> Malone bug 68267 in xorg "x11-common is uninstallable when debconf method is kde" [Undecided,Confirmed]  https://launchpad.net/bugs/68267
<Ubugtu> New bug: #89961 in xorg (main) "Xorg 7.2 radeon driver doesn't support ATI Technologies Inc M22 [Radeon Mobility M300] " [Undecided,Rejected]  https://launchpad.net/bugs/89961
<tepsipakki> paul__: I'll look at it tomorrow
<tepsipakki> ..while I split our xorg changes as patches and feed them to debian
<paul__> thanks!
#ubuntu-x 2007-03-06
<Ubugtu> New bug: #90000 in xorg (main) "adept_updater crashes on x11-common update" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90000
<tepsipakki> seb128: seems that Replaces: xrgb is not enough for x11-common
<seb128> no
<seb128> that's likely a conffile
<seb128> and moving conffile around packages is no fun
<tepsipakki> well, I'll gladly drop that delta
<seb128> do you know if that's Ubuntu specific or if Debian has the same bug?
<seb128> what delta?
<tepsipakki> it's all ours ;)
<tepsipakki> made by Mithrandir 5 Jul 2006
<seb128> ah
<seb128> for what reason?
<tepsipakki> no idea
<tepsipakki>   * Add replaces for xinit since we now ship Xsession from x11-common.
<tepsipakki>   * Ditto for xrgb as we ship rgb.txt in x11-common.
<tepsipakki> I'd like to split our diff into patches and feed the interesting bits to debian
<seb128> would be nice
<tepsipakki> we could sync libxi btw, debian has bumped the epoch
<seb128> cool
<tepsipakki> hey, should we just upload the new ati-driver.. it has three patches included, one of them already applied in upstream git 
<tepsipakki> it would fix a bunch of bugs
<tepsipakki> "at the usual place"
<seb128> I'll have a look
<seb128> thank you for the work ;)
<tepsipakki> heh, there are some active dudes who keep on pinging me about these ;)
<tepsipakki> so this should shut them up for awhile :)
* cjwatson uploads xorg for a keyboard variant change
<tepsipakki> cjwatson: feel free, I'll add that to the xkblayout-patch
<Ubugtu> New bug: #89835 in console-setup (main) "French alternative keyboard should be default" [Wishlist,Fix released]  https://launchpad.net/bugs/89835
<Ubugtu> New bug: #90094 in linux-restricted-modules-2.6.17 (restricted) "madwifi should respect countrycode" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90094
<Ubugtu> New bug: #90139 in xorg (main) "xorg broken vmware upgrade 6.06 to feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90139
<Ubugtu> New bug: #90169 in mesa (main) "SecondLife, GL.O.B.S. and other GL apps have a Black Window on Radeon drivers - Patch available" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90169
<Ubugtu> New bug: #21595 in xkeyboard-config (main) "alts_toggle breaks instead of overriding ralt -> l3" [High,Confirmed]  https://launchpad.net/bugs/21595
<tepsipakki> there's a patch for mesa from upstream git in bug #90169
<Ubugtu> Malone bug 90169 in mesa "SecondLife, GL.O.B.S. and other GL apps have a Black Window on Radeon drivers - Patch available" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90169
<Ubugtu> New bug: #90185 in libx11 (main) "libx11-6 2:1.1.1-1ubuntu1 crashes Azureus" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90185
<Ubugtu> New bug: #35484 in Ubuntu "Won't load X " [Medium,Rejected]  https://launchpad.net/bugs/35484
<Ubugtu> New bug: #90175 in xorg (main) "vesa driver used instead of radeon for R300" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90175
<tepsipakki> I'm sick of all these livecd-bugs..
<tepsipakki> it's something in the environment which makes xresprobe to fail
<tepsipakki> ddcprobe works fine
<Ubugtu> New bug: #30149 in Ubuntu "postinst scripts seem to assume existence of /var/lib/x11/X.md5sum" [High,Fix released]  https://launchpad.net/bugs/30149
<Ubugtu> New bug: #90196 in xrdb (main) "[apport]  xrdb crashed with SIGFPE" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90196
<cjwatson> tepsipakki: did I hear somebody saying it worked fine without splash?
<cjwatson> I imagine it's the attempt to start the X server while usplash is running. As a last resort maybe it would be possible to arrange to shut down usplash temporarily and restart it at the right progress bar position afterwards
<tepsipakki> cjwatson: no, with or without it's the same. I tried with a Thinkpad Z61p which has a 1920x1200 panel, livecd loads with 1024x768 vesa :)
<tepsipakki> and I tried Fedora 7 and it got 1600x1200
<tepsipakki> with vesa also, since the ATI chip isn't supported by the free driver
<tepsipakki> someone said on a bug that maybe casper should bind-mount /dev while it configures X
<cjwatson> oh, yeah, Mithrandir said something about that
<Ubugtu> New bug: #89400 in xorg (main) "key cntrl doesn't work in xorg" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89400
<Ubugtu> New bug: #88743 in xorg (main) "X.org crashes after 7.04 distribution upgrade" [Medium,Unconfirmed]  https://launchpad.net/bugs/88743
<Ubugtu> New bug: #13101 in xorg (main) "Problems with Trident CyberBlade XP4m32 on Toshiba Tecra M1" [Medium,Fix committed]  https://launchpad.net/bugs/13101
#ubuntu-x 2007-03-07
<Ubugtu> New bug: #90207 in adept (main) "First Adept update fails (dup-of: 68267)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90207
<paul__> tepsipakki, have you check bug #68267 yet?
<Ubugtu> Malone bug 68267 in xorg "x11-common have an important debconf bug" [Undecided,Confirmed]  https://launchpad.net/bugs/68267
<paul__> This is also bug #85979, but without my propose fix
<Ubugtu> Malone bug 85979 in adept "Wrong nice value while upgrading debconf " [Medium,Confirmed]  https://launchpad.net/bugs/85979
<Ubugtu> New bug: #85990 in Ubuntu "Debconf reports incorrect nice value (kubuntu feisty herd 4) (dup-of: 68267)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/85990
<Ubugtu> New bug: #88697 in adept (main) "dpkg: invalid nice value (dup-of: 68267)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88697
<Ubugtu> New bug: #90253 in update-manager (main) "[feisty]  Unable to update some packages. (dup-of: 68267)" [Undecided,Confirmed]  https://launchpad.net/bugs/90253
<Ubugtu> New bug: #57716 in linux-restricted-modules-2.6.17 (restricted) "Edgy  Eft - fglrx module not started" [High,Confirmed]  https://launchpad.net/bugs/57716
<Ubugtu> New bug: #85979 in adept "Wrong nice value while upgrading debconf  (dup-of: 68267)" [Medium,Confirmed]  https://launchpad.net/bugs/85979
<Ubugtu> New bug: #90081 in linux-restricted-modules-2.6.17 (restricted) "Packages fails to install on amd64" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90081
<tepsipakki> I've put a new xorg available, it fixes a bug which makes upgrades with KDE-frontend not to fail, and a fix to enable horizontal scrolling with synaptics
<tepsipakki> it's at http://users.tkk.fi/~tjaalton/xorg72/new
<tepsipakki> as usual..
<tepsipakki> I'll put a new libx11 as well, with that workaround-patch from Novell
<tepsipakki> oh, it was for libxcb
<seb128> morning
<tepsipakki> good morning!
<tepsipakki> pitti uploaded some packages
<seb128> yeah, I noticed
<seb128> I was going to start on them
<seb128> I've read -changes before starting so that's alright ;)
<tepsipakki> ok, new xorg in the usual place
<tepsipakki> reverts the "fix" for x11-common.config
<seb128> looking
<seb128> uploaded
<tepsipakki> thanks
<tepsipakki> the "never trust random fixes from random people without testing" episode..
<seb128> was that broken for everybody?
<tepsipakki> I guess so
<tepsipakki> apt-get just hangs asking that question
<seb128> do any of you test updates?
<tepsipakki> I just did
<tepsipakki> that bug about adept failing on x11-common was first reported for edgy
<tepsipakki> funny that debian doesn't seem to have issues with it
<cjwatson> probably just luck; there should be no relevant differences
<cjwatson> it might just be an annoyance with Debian, whatever way it works out
<cjwatson> debconf is functionally identical between Debian and Ubuntu, anyway
<tepsipakki> yep
<tepsipakki> noticed that there is no support for vesa in lcdsize.sh in xresprobe
<tepsipakki> maybe that's the reason why it fails to set up a correct resolution for so many people
<Ubugtu> New bug: #87814 in debconf (main) "Kubuntu 7.04 chash at update (dup-of: 68267)" [Medium,Confirmed]  https://launchpad.net/bugs/87814
<Ubugtu> New bug: #90347 in xorg (main) "[Feisty]  x11-common fails to upgrade" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90347
<tepsipakki> ok, I got xresprobe to work better with vesa
<tepsipakki> but the changes might be too invasive
<Ubugtu> New bug: #90353 in xorg (main) "xserver-xorg cannot be upgraded on feisty (xserver-xorg_1%3a7.2-0ubuntu4_all.deb)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90353
<Ubugtu> New bug: #90355 in xorg (main) "Cannot install package x11-common" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90355
<tepsipakki> sigh
<Ubugtu> New bug: #90323 in xserver-xorg-video-i810 (main) "855GM and Intel 915 widescreen does not work" [Undecided,Confirmed]  https://launchpad.net/bugs/90323
<tepsipakki> I've put a new xresprobe in the usual place
<seb128> tepsipakki: looking
<tepsipakki> the big change is not to probe with a bare-bones xorg.conf, but to rely on the new server..
<tepsipakki> that's one way to get other than 1024x768 for vesa
<Ubugtu> New bug: #90358 in xorg (main) "the x11-common in Distribution updates cannot install (dup-of: 90347)" [High,Confirmed]  https://launchpad.net/bugs/90358
<Ubugtu> New bug: #89878 in xorg-server (main) "Screen blanks, locks during install of herd 5" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89878
<Ubugtu> New bug: #90365 in xorg (main) "x11-common fails to configure" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90365
<seb128> tepsipakki: 
<seb128> I get 403 errors when trying to download xresprobe
<tepsipakki> really?
<tepsipakki> weird
<tepsipakki> try again?
<tepsipakki> ah
<tepsipakki> "permission denied".. wtf?
<seb128> 403
<pochu> I can't configure x11-common (today update). is this a known problem?
<seb128> pochu: yes, and a fixed version has been uploaded some hours ago
<pochu> seb128: oh, ty :)
<pochu> you guys are fast :)
<tepsipakki> well, it took 2.5 hours to realize it was broken..
<pochu> it asked for a number, but there weren't a field to input it :)
<pochu> was that the problem, or there was another?
<tepsipakki> that
<pochu> this time has configured fine, though it hasn't asked me for anything :)
<tepsipakki> it shouldn't
<pochu> then everything it's fine :)
<pochu> ty guys
<Ubugtu> New bug: #90377 in xorg (main) "x11-common update stuck" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90377
<tepsipakki> I don't get it.. for some reason our www-server doesn't like my xresprobe-files
<tepsipakki> but if I copy with another name all is ok
<Ubugtu> New bug: #90361 in debconf (main) "Configuring x11-common debconf (dup-of: 90347)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90361
<Ubugtu> New bug: #67097 in xorg (main) "upgrade to edgy gives a popup complaining about nice values" [Undecided,Unconfirmed]  https://launchpad.net/bugs/67097
<cjwatson> (another dup for you, but I forget what of)
<tepsipakki> thanks
<tepsipakki> 68267
<tepsipakki> marking it
<tepsipakki> there is a proper fix for that now
<tepsipakki> https://no.spoon.fi/~jvtm/patches/ubuntu/ubuntu-feisty-x11-common.config-validate_nice_value-fix.diff
<tepsipakki> showed it on #debian-x
<Ubugtu> New bug: #90236 in xorg (main) "[Feisty Herd 5 alternate cd]  Installer hangs while configuring xserver" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90236
<tepsipakki> seb128: there is a tarball xres.tar.gz which you can download..
<seb128> k
<tepsipakki> but that change maybe needs more eyes
<tepsipakki> or rather, discussion
<Ubugtu> New bug: #90389 in xorg (main) "Debconf dont have a field to put the nice value" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90389
<cjwatson> Ubuntu, where you can get reminded of your mistakes from now to eternity
<tepsipakki> heh
<kylem> what's wrong?
<tepsipakki> kylem: xorg_7.2-0ubuntu4 was broken
<kylem> oh. bummer.
<tepsipakki> yeah.. I didn't test the "fix" so here we are
<Ubugtu> New bug: #90376 in xorg (main) "Firefox doesn't know how to communicate with the server" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90376
<seb128> I'm happy that was not me who uploaded the broken version :p
* seb128 hides from pitti
<seb128> oh, he's not on the chan right, not fun then ;)
<pochu> tepsipakki: do you know the reason why -intel driver has that small font issue, or have you filed a bug? If not, I can do it
<tepsipakki> xpdyinfo miscalculates something
<tepsipakki> xdpyinfo
<tepsipakki> I got it to work via d-sub
<tepsipakki> IIRC
<pochu> tepsipakki: can I do something then?
<pochu> is that a driver bug, or is that of us?
<tepsipakki> it's upstream
<tepsipakki> maybe there was a bug open already
<pochu> I can't find it
<pochu> in fdo?
<tepsipakki> yes
<tepsipakki> maybe not
<Ubugtu> New bug: #90402 in xorg (main) "Update Manager not working" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90402
<Ubugtu> New bug: #89440 in xorg-server (main) "Scroll/Progress bar problem on Ubuntu Herd 5" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89440
<Ubugtu> New bug: #41951 in xcalc (main) "Wrong name of -color app-defaults file" [Medium,Fix released]  https://launchpad.net/bugs/41951
<Ubugtu> New bug: #29435 in mesa (main) "Missing GL/gl.h" [Medium,Confirmed]  https://launchpad.net/bugs/29435
<Ubugtu> New bug: #90414 in xorg (main) "x11-common_1%3a7.2-0ubuntu4_i386.deb problem by config script, wrong value" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90414
<pochu> fixed ^
<tepsipakki> just marked as dupe
<pochu> :)
<Ubugtu> New bug: #35739 in xserver-xorg-driver-i810 (main) "Missing support for 945GM chipset" [Medium,Fix released]  https://launchpad.net/bugs/35739
<Ubugtu> New bug: #24810 in mesa (main) "[r128]  blender crashes with SIGSEGV when DRI active" [Medium,Needs info]  https://launchpad.net/bugs/24810
<Ubugtu> New bug: #32021 in mesa (main) "ATI 9200 RV 280 temperamental GL surfaces" [Medium,Needs info]  https://launchpad.net/bugs/32021
<pochu> lol Ubugtu xD
<pochu> new bug?
<tepsipakki> no, new comments
<pochu> tepsipakki: sure?
<tepsipakki> I'm going through those
<pochu> never saw that feature in Ubugtu :)
<Ubugtu> New bug: #30021 in xserver-xorg-input-synaptics (main) "Touchpad scroll area not setup" [Medium,Rejected]  https://launchpad.net/bugs/30021
<tepsipakki> if only beta.launchpad.net wasn't so slow..
<Ubugtu> New bug: #57814 in mesa (main) ""radeon_cp_reset called without lock held"" [Undecided,Needs info]  https://launchpad.net/bugs/57814
<Ubugtu> New bug: #52791 in mesa (main) "ppracer don't run at all" [Undecided,Needs info]  https://launchpad.net/bugs/52791
<Ubugtu> New bug: #56637 in mesa (main) "blender corrupts screen with radeon driver (dup-of: 40307)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/56637
<Ubugtu> New bug: #47338 in mesa (main) "libglu-dev and libgl-dev broken on amd64" [Medium,Needs info]  https://launchpad.net/bugs/47338
<cjwatson> pochu: it tends to flag things as new bugs when they're reassigned to a different package
<pochu> cjwatson: is that supposed to be a bug, or is that fine?
<tepsipakki> those were not reassigned though
<tepsipakki> but maybe some other variable was changed
<pochu> dunno if Seveas knows this
<Ubugtu> New bug: #90109 in xorg (universe) "Add Alpha RGB GLX Visuals to xorg.conf for nVidia cards" [Medium,In progress]  https://launchpad.net/bugs/90109
<tepsipakki> what.. "in progress"
<tepsipakki> oookay
<tepsipakki> f*ck
<tepsipakki> new xresprobe on the way
<tepsipakki> and there it is
<tepsipakki> seb128: ping, could you fetch the new xresprobe.. it's a oneliner fix that was dropped from the previous version
<cjwatson> pochu: up to Seveas I guess
<seb128> tepsipakki: pong, k
<tepsipakki> cool, thanks
<seb128> np
<tepsipakki> hm, need to reply to mdz's mail :)
<seb128> about?
<tepsipakki> xresprobe
<seb128> did it break and how?
<seb128> update uploaded
<tepsipakki> the first upload was incomplete
<tepsipakki> I don't think anyone has been able to test this much, but tomorrow we get new daily-cd's..
<tepsipakki> I did test it on a laptop, but running manually
<tepsipakki> ok, home sweet home, bbl ->
<Ubugtu> New bug: #90434 in xorg (main) "please enable dontzap by default" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90434
<Ubugtu> New bug: #90442 in xorg (main) "Please enter an integer between -20 and 19." [Undecided,Unconfirmed]  https://launchpad.net/bugs/90442
<pochu> I haven't reported that ^ :)
<Ubugtu> New bug: #82806 in xorg (main) "With compiz running in feisty, text doesn't display in Run Application dialog" [Undecided,Confirmed]  https://launchpad.net/bugs/82806
<Ubugtu> New bug: #44112 in xserver-xorg-video-tdfx "3D games crashed with voodoo3" [High,Fix released]  https://launchpad.net/bugs/44112
<Ubugtu> New bug: #34436 in xserver-xorg-video-ati (main) "[r128]  XVideo output distorted/stretched on Mobility M4" [Medium,Needs info]  https://launchpad.net/bugs/34436
<pochu> pochu is bugging fdo :)
<pochu> tepsipakki: can you confirm the login small fonts?
<pochu> http://bugs.freedesktop.org/show_bug.cgi?id=10217
<Ubugtu> Freedesktop bug 10217 in Driver/intel "Gnome login page has really small fonts" [Normal,New]  
<Ubugtu> New bug: #43963 in discover-data (main) "Sis graphics card detected as vesa" [Medium,Fix released]  https://launchpad.net/bugs/43963
<Ubugtu> New bug: #46670 in discover1-data (main) "Graphic Chipset SIS M760 doesn't work (dup-of: 43963)" [Medium,Needs info]  https://launchpad.net/bugs/46670
<Ubugtu> New bug: #52316 in xserver-xorg-video-sis (main) "Video card in Haier H51 laptop not correctly recognised as SiS. (dup-of: 43963)" [Undecided,Needs info]  https://launchpad.net/bugs/52316
<tepsipakki> I'd need to dig up my account somewhere
<tepsipakki> I'm sure it will be confirmed before long
<tepsipakki> note that the experimental driver most likely won't make it in feisty
<tepsipakki> since it has regressions and atm depends on the new server (which won't make it either)
<pochu> tepsipakki: what about including it in universe (as the -modesetting in edgy)
<tepsipakki> it still needs the server
<tepsipakki> maybe they will fix it so that it doesn't
<pochu> k
<Ubugtu> New bug: #90418 in debconf (main) "[apport]  dpkg-preconfigure crashed with SIGSEGV in xcall_QGroupBox() (dup-of: 90347)" [Undecided,Confirmed]  https://launchpad.net/bugs/90418
#ubuntu-x 2007-03-08
<Ubugtu> New bug: #40209 in xorg (main) "/etc/X11/X symlink left pointing to /bin/true after upgrade" [High,Fix released]  https://launchpad.net/bugs/40209
<Ubugtu> New bug: #44904 in xserver-xorg-video-i810 (main) "Intel 82945G Express Chipset (GMA950) Flight 7" [Medium,Unconfirmed]  https://launchpad.net/bugs/44904
<Ubugtu> New bug: #43506 in xresprobe (main) "Mitsubishi Diamond Pro 2045u Stuck at 1024x768 @ 60 Hz" [Medium,Needs info]  https://launchpad.net/bugs/43506
<Ubugtu> New bug: #52032 in xorg (main) "Wrong man link in /etc/X11/xorg.conf" [Low,Confirmed]  https://launchpad.net/bugs/52032
<Ubugtu> New bug: #52685 in xorg (main) "x11-common installs dup files" [Undecided,Confirmed]  https://launchpad.net/bugs/52685
<Ubugtu> New bug: #54740 in xorg (main) "xutils should be removed" [Low,Confirmed]  https://launchpad.net/bugs/54740
<Ubugtu> New bug: #56501 in xserver-xorg-video-i810 (main) "xserver-xorg-driver-i810: Error in I830WaitLpRing(), now is -99922196,	start is -99924197" [Undecided,Unconfirmed]  https://launchpad.net/bugs/56501
<Ubugtu> New bug: #57767 in xserver-xorg-video-i810 (main) "display is garbled on intel 855gm" [Low,Unconfirmed]  https://launchpad.net/bugs/57767
<Ubugtu> New bug: #81174 in xresprobe (main) "[Feisty]  Mesa used instead of 'nv'" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81174
<Ubugtu> New bug: #90515 in Ubuntu "prompt to enter integer on x11-common update (dup-of: 68267)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90515
<Ubugtu> New bug: #49824 in Ubuntu "Kubuntu 6.10 max sound volume is too low compared to 5.10" [Undecided,Needs info]  https://launchpad.net/bugs/49824
<kylem> heh. how are some of these xorg bugs...
<crimsun> that one certainly isn't
<Ubugtu> New bug: #90555 in xorg (main) "No boarders on windows in 3D mode." [Undecided,Unconfirmed]  https://launchpad.net/bugs/90555
<Ubugtu> New bug: #90571 in xserver-xorg-video-ati (main) "regression: blank screen on hp nw8240 after last xorg driver update" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90571
<Treenaks> 90571 -- inverse of 22985 ?
<tepsipakki> a regression maybe
<Treenaks> probably
<tepsipakki> Mirv is on it
<Treenaks> weird thing is, this guy doesn't seem to see bug 20283, but he does have a NW8240/1920x1200/X700
<Ubugtu> Malone bug 20283 in xserver-xorg-video-ati "[fgl v5000]  really bad sync" [Medium,Needs info]  https://launchpad.net/bugs/20283
<tepsipakki> was that bug your pet?-)
<Treenaks> tepsipakki: kind of :)
<Treenaks> tepsipakki: I;ve had it on my (canonical-supplied; laptop-testing-team) laptop since I got it
<Treenaks> which must've been around hoary/breezy
<tepsipakki> you should probably mention the model in the description
<Treenaks> tepsipakki: will change
<Treenaks> fixed
<tepsipakki> thanks
<Treenaks> tepsipakki: I've also asked the reporter of 90571 send his video bios, so I can compare his and mine
<tepsipakki> good
<Treenaks> (as noted in freedesktop 8038)
<Ubugtu> Freedesktop bug 8038 in Driver/Radeon "Wobbly image on Radeon Mobility X700 (RV410)" [Normal,Needinfo]  http://bugzilla.freedesktop.org/show_bug.cgi?id=8038
<Treenaks> I think this comment sums up the fix for all 3 bugs: https://bugs.freedesktop.org/show_bug.cgi?id=5473#c48
<Ubugtu> Freedesktop bug 5473 in Driver/Radeon "Blank screen with Radeon Mobility X700 (Acer Ferrari 4005)" [Major,Reopened]  
<Treenaks> Lure: your bios is slightly different from mine -- I've forwarded it
<Lure> Treenaks: ok, I hope it will help upstream 
<Ubugtu> New bug: #90587 in xresprobe (main) "Graphics very slow" [Undecided,Needs info]  https://launchpad.net/bugs/90587
<Ubugtu> New bug: #90604 in xserver-xorg-video-ati (main) "[r300]  ati driver unuasble slow (full cpu usage just for drawing gtk apps)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90604
<tepsipakki> should the binary-nvidia crashers be just rejected?
<seb128> no
<seb128> reassign to the restricted package I would say
<tepsipakki> ok
<Ubugtu> New bug: #90607 in xserver-xorg-video-ati (main) "screen completely garbled with ati open source driver when doing ctrl+alt+f1" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90607
<Ubugtu> New bug: #90558 in xorg (main) "Boot of Desktop 6.10 (Edgy Eft) installer hangs on i845" [High,Unconfirmed]  https://launchpad.net/bugs/90558
<Ubugtu> New bug: #56221 in xorg-server (main) "Xnest crashes on start" [Undecided,Rejected]  https://launchpad.net/bugs/56221
<Ubugtu> New bug: #41150 in xserver-xorg-video-ati (main) "Ubuntulooks toolbar button draw problem" [Medium,Unconfirmed]  https://launchpad.net/bugs/41150
<Ubugtu> New bug: #90622 in xserver-xorg-video-i810 (main) "Maps disappearing when zooming in on google earth" [Undecided,Confirmed]  https://launchpad.net/bugs/90622
<qense> I've got a question.
<qense> I don't know what to do with bug 89632 (https://launchpad.net/ubuntu/+source/xorg/+bug/89632)
<Ubugtu> Malone bug 89632 in xorg "moving windows jumps xorg cpu usage + fan" [Undecided,Needs info]  https://launchpad.net/bugs/89632
<qense> I think it's of a bug in nvidia-glx or a hardware error
<qense> What should I do?
<Ubugtu> New bug: #90639 in xrdb (main) "Just restarted X server and it didn't restart, resorted to startx" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90639
<pochu> tepsipakki: what problems do you have with the -intel driver? (appart of the login fonts? :)
<pochu> it would be great to have it in feisty, even in universe
<tepsipakki> it only does 1280x800
<tepsipakki> for me
<Ubugtu> New bug: #90184 in xserver-xorg-video-ati (main) "[feisty]  desktop effects problem (ATI)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90184
<pochu> that's what I need :)
<pochu> and I have it, hehe, but it's a little weird
<tepsipakki> I've tried it with three different monitors
<pochu> tepsipakki: and have you bugged fdo? :)
<Ubugtu> New bug: #89603 in xserver-xorg-input-synaptics (main) "Synaptics touchpad won't work with Feisty Fawn" [Undecided,Needs info]  https://launchpad.net/bugs/89603
<pochu> tepsipakki: oh, and feel free to confirm the fonts bug :)
<tepsipakki> maybe I have time tomorrow
<Ubugtu> New bug: #90685 in xorg-server (main) "[apport]  Xorg crashed with signal 5" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90685
<Ubugtu> New bug: #90688 in xorg (universe) "disable composite in fglrx" [Undecided,Confirmed]  https://launchpad.net/bugs/90688
<Ubugtu> New bug: #82940 in xorg (main) "sis_agp must be blacklisted to get working direct rendering with fglrx" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82940
<tepsipakki> pochu: about the tiny fonts with -intel: http://lists.freedesktop.org/archives/xorg/2007-March/022367.html
<tepsipakki> so it's known by the devs
<pochu> hehe, I didn't thought in the ML
<pochu> I searched the bug tracker though :)
<pochu> tepsipakki: ty
<Ubugtu> New bug: #73240 in xkeyboard-config (main) "German keyboard layout - deadkeys by default" [Undecided,Unconfirmed]  https://launchpad.net/bugs/73240
<tepsipakki> woohoo, xorg bug count under 400
<pochu> tepsipakki: fixed! http://bugs.freedesktop.org/show_bug.cgi?id=10217
<pochu> tepsipakki: hehe
<Ubugtu> Freedesktop bug 10217 in Driver/intel "Gnome login page has really small fonts" [Normal,Resolved: fixed]  
<tepsipakki> oh, that's nice
<pochu> tepsipakki: we can try a recent git checkout ;)
<pochu> hehe
<tepsipakki> debian-experimental now has rc1
<pochu> has rc1 that fix?
<tepsipakki> no, it's the initial release
<tepsipakki> of -intel
<pochu> and which one did you package?
<pochu> 1.9.91
<tepsipakki> same
<tepsipakki> that's the 2.0 rc1
<pochu> am
<pochu> so, or a recent git, or wait :-/
<tepsipakki> yes
<pochu> tepsipakki: have you seen this? http://www.ubuntu.com/employment#head-91d2b3d557b5ad20989d4f696c28a540b4938b40
<pochu> hehe
<tepsipakki> hmm... yes
<pochu> hehe
<pochu> that's your profile, isn't it? ;)
<tepsipakki> I'm just a volunteer atm ;)
<tepsipakki> need to get the worst regressions fixed
<tepsipakki> actually there aren't that many
<pochu> tepsipakki: do you think xserver 1.3 will be out before feisty release? and if so, do you think we will be able to ship it?
<tepsipakki> no, I don't think so..
<tepsipakki> I guess it will be released before, but it's too late
<pochu> :(
<tepsipakki> bedtime ->
<pochu> night!
#ubuntu-x 2007-03-09
<Ubugtu> New bug: #45441 in xorg (main) "EXA in Kubuntu Dapper causes systray problems" [Medium,Needs info]  https://launchpad.net/bugs/45441
<Ubugtu> New bug: #32877 in xorg-driver-synaptics (main) "Jumpy trackpad tracking" [Medium,Needs info]  https://launchpad.net/bugs/32877
<Ubugtu> New bug: #15497 in xserver-xorg-video-ati (main) "[rv280]  panel doesn't always sync right after power off" [Low,Confirmed]  https://launchpad.net/bugs/15497
<tepsipakki> crimsun: thanks for the libxcb upload :)
<tepsipakki> a silly mistake
<tepsipakki> ooh, xf86-video-nv 1.99.1 (2.0rc1)
<crimsun> tepsipakki: np :)
<Ubugtu> New bug: #42816 in xserver-xorg-video-ati (main) "[RV350]  Black screen (dup-of: 27466)" [Medium,Confirmed]  https://launchpad.net/bugs/42816
<Ubugtu> New bug: #42157 in xserver-xorg-video-ati (main) "login screen crashes" [Medium,Fix released]  https://launchpad.net/bugs/42157
<Ubugtu> New bug: #45806 in xserver-xorg-video-ati (main) "OpenGL acceleration glitch (only on dapper 64)" [Medium,Unconfirmed]  https://launchpad.net/bugs/45806
<Ubugtu> New bug: #28976 in xserver-xorg-video-ati (main) "Xsession crashes when opening gdesklets" [Medium,Fix released]  https://launchpad.net/bugs/28976
<Ubugtu> New bug: #41042 in xserver-xorg-video-ati (main) "No Screen Resolution Adjustment Possible" [Medium,Fix released]  https://launchpad.net/bugs/41042
<Ubugtu> New bug: #47371 in linux-restricted-modules-2.6.15 (restricted) "[fglrx and Radeon 9200]  Can't start openoffice or blender after update to dapper" [High,Confirmed]  https://launchpad.net/bugs/47371
<Ubugtu> New bug: #66178 in linux-restricted-modules-2.6.17 (main) "Update worked, until enable 3d" [Undecided,Unconfirmed]  https://launchpad.net/bugs/66178
<Ubugtu> New bug: #88935 in Ubuntu "rendering slowness (dup-of: 88568)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88935
<Ubugtu> New bug: #44897 in linux-restricted-modules-2.6.17 (restricted) "nvidia-settings .desktop file" [Medium,Confirmed]  https://launchpad.net/bugs/44897
<Ubugtu> New bug: #89189 in xorg (main) "No text in save/dialog boxes" [Medium,Unconfirmed]  https://launchpad.net/bugs/89189
<Ubugtu> New bug: #21545 in xserver-xorg-video-ati (main) "[r100]  cursor glitches when scanline is being updated" [Medium,Needs info]  https://launchpad.net/bugs/21545
<Ubugtu> New bug: #31918 in xserver-xorg-video-ati (main) "ati radeon M6 LY dri needs driver reload to work" [Medium,Unconfirmed]  https://launchpad.net/bugs/31918
<Ubugtu> New bug: #38661 in xserver-xorg-video-ati (main) "No direct rendering, Radeon IGP345M" [Medium,Unconfirmed]  https://launchpad.net/bugs/38661
<Ubugtu> New bug: #37675 in xserver-xorg-video-ati (main) "Setup video mode not supported by Dell LCD display" [Medium,Unconfirmed]  https://launchpad.net/bugs/37675
<Ubugtu> New bug: #46937 in xserver-xorg-video-ati (main) "On resume from hibernate, 3d screensaver does not display correctly" [Low,Unconfirmed]  https://launchpad.net/bugs/46937
<Ubugtu> New bug: #90953 in xserver-xorg-video-sis (main) "sis651 vga problem" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90953
<Ubugtu> New bug: #90871 in xorg (main) "User must edit xorg.conf in order to modify synaptics settings" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90871
<Ubugtu> New bug: #90976 in xorg (main) "X fails to boot in regular installation of Herd 5" [Undecided,Confirmed]  https://launchpad.net/bugs/90976
<Ubugtu> New bug: #43293 in acpi-support (main) "Fn+F4 doesn't switch to ext monitor Compaq 4020us (all other Fn keys fine)" [Medium,Needs info]  https://launchpad.net/bugs/43293
<Ubugtu> New bug: #34435 in xserver-xorg-video-ati "Cairo and ATI RENDER extension cause scrambled buttons in UbuntuLooks" [High,Confirmed]  https://launchpad.net/bugs/34435
<Ubugtu> New bug: #35829 in xserver-xorg-video-i810 (main) "Bad 3d acceleration in 915GM" [Medium,Rejected]  https://launchpad.net/bugs/35829
<Ubugtu> New bug: #24927 in xserver-xorg-video-i810 (universe) "Widescreen LCD resolution incorrect." [Medium,Confirmed]  https://launchpad.net/bugs/24927
<Ubugtu> New bug: #90985 in mesa (main) "mesa s3tc support" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90985
#ubuntu-x 2007-03-10
<Ubugtu> New bug: #24203 in xserver-xorg-video-i810 (main) "segfaults on ACPI?" [Medium,Rejected]  https://launchpad.net/bugs/24203
<Ubugtu> New bug: #23816 in xserver-xorg-video-i810 (main) "[i915]  GL screensavers only drawn on top 1/3 of screen" [Medium,Rejected]  https://launchpad.net/bugs/23816
<Ubugtu> New bug: #41692 in xserver-xorg-video-i810 (main) "Xorg i810 driver crashes on resume after sleep (i815) "Active ring not flushed"" [Medium,Rejected]  https://launchpad.net/bugs/41692
<Ubugtu> New bug: #27712 in xserver-xorg-video-i810 (main) "xorg.conf: "HorizSync" and "VertRefresh" not automatically entered upon installation" [Medium,Rejected]  https://launchpad.net/bugs/27712
<Ubugtu> New bug: #54432 in xorg (main) "Flickering Problem of i815 Display in X Window after Suspension or Hibernation of Xubuntu" [Undecided,Rejected]  https://launchpad.net/bugs/54432
<Ubugtu> New bug: #44212 in xserver-xorg-video-i810 (main) "DDX driver too old for 3D" [Medium,Rejected]  https://launchpad.net/bugs/44212
<Ubugtu> New bug: #57097 in xserver-xorg-video-i810 (main) "Maya opengl glitches if VideoRam is more than 16MB" [Undecided,Rejected]  https://launchpad.net/bugs/57097
<Ubugtu> New bug: #21031 in xserver-xorg-video-i810 (main) "[i845G]  DDC fails through VBE (dup-of: 9525)" [Medium,Needs info]  https://launchpad.net/bugs/21031
<Ubugtu> New bug: #38202 in xserver-xorg-video-i810 (main) "Xorg crashes when using 915resolution on Intel Mobile 915GM/GMS/910GML Express" [Medium,Rejected]  https://launchpad.net/bugs/38202
<cjwatson> tepsipakki: I think a slightly better name for gatos' scanpci man page would have been scanpci.1gatos.gz, BTW
<cjwatson> using man's sectional extension mechanism
<tepsipakki> oh, I'll fix it
<tepsipakki> didn't know of such a mechanism
<cjwatson> it's not the best-known bit of the system
<Ubugtu> New bug: #37364 in xserver-xorg-video-i810 (main) "backlight does not turn off with xset dpms...works with vbetool" [Medium,Unconfirmed]  https://launchpad.net/bugs/37364
<tepsipakki> I bet ;)
<Ubugtu> New bug: #21820 in mesa-utils (main) "glxgears -printfps undocumented" [Medium,Confirmed]  https://launchpad.net/bugs/21820
<Ubugtu> New bug: #44740 in xserver-xorg-video-i810 (main) "Windows not redrawn properly after resume from suspend or hibernate" [Medium,Needs info]  https://launchpad.net/bugs/44740
<Ubugtu> New bug: #91077 in mesa (main) "Closing glxgears window causes xcb_xlib_lock assertion and sound interruption" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91077
<Ubugtu> New bug: #91081 in xorg (main) "Causes visual artifacts on S3Virge MX chipset" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91081
<Ubugtu> New bug: #91064 in xorg (main) "nvidia-glx-legacy has disabled GL by default " [Undecided,Unconfirmed]  https://launchpad.net/bugs/91064
<Ubugtu> New bug: #90023 in xorg (main) "All java gui application Core Dumps." [Undecided,Unconfirmed]  https://launchpad.net/bugs/90023
<Ubugtu> New bug: #91111 in xserver-xorg-video-ati (main) "Graphical card not supported" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91111
<Ubugtu> New bug: #84830 in xorg (main) "Can't make video work right on a HP dv2125nr laptop with NVidia GO 6150 chipset" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84830
<Ubugtu> New bug: #91126 in xorg (main) "Not loading 'mga' video driver for Matrox video card" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91126
<Ubugtu> New bug: #90850 in mesa (main) "[apport]  earth3d crashed with SIGSEGV in viaGetLock()" [Medium,Unconfirmed]  https://launchpad.net/bugs/90850
<Ubugtu> New bug: #91139 in xorg-server (main) "[apport]  Xorg crashed with signal 5b43" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91139
<Ubugtu> New bug: #45303 in acpi-support (main) "ThinkPad X30 needs SAVE_VBE_STATE=false" [Medium,In progress]  https://launchpad.net/bugs/45303
<Ubugtu> New bug: #91147 in xorg (main) "black screens" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91147
<Ubugtu> New bug: #91158 in xorg (main) "reflexive link in /usr/bin/X11" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91158
<Ubugtu> New bug: #89369 in xorg (main) "With "desktop effects" enabled, every other terminal window fails to draw text." [Medium,Confirmed]  https://launchpad.net/bugs/89369
<Ubugtu> New bug: #91193 in xorg (main) "Screen Resolution fails to set 1600x1200" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91193
<Ubugtu> New bug: #91235 in xorg (main) "Feisty Herd 5 sets Intel GMA X3000 to VESA-mode instead of i810" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91235
<Ubugtu> New bug: #91222 in xorg (main) "1280x1024 screen resolution not supported in Feisty" [Undecided,Needs info]  https://launchpad.net/bugs/91222
#ubuntu-x 2007-03-11
<Ubugtu> New bug: #91330 in xserver-xorg-input-mouse (main) "my mouse dont work" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91330
<Ubugtu> New bug: #91336 in xserver-xorg-video-mga (main) "mga driver produces incorrect refresh rate on G100" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91336
<Ubugtu> New bug: #91351 in xorg (main) "X.Org segfaults after login" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91351
<Ubugtu> New bug: #87003 in xorg (main) "NVIDIA 7600GT detected as vesa not nv" [Undecided,Confirmed]  https://launchpad.net/bugs/87003
<Ubugtu> New bug: #43876 in xorg (main) "White Lines Flash in KDE When Restoring Windows" [Undecided,Rejected]  https://launchpad.net/bugs/43876
* Starting logfile irclogs/ubuntu-x.log
<Ubugtu> New bug: #91422 in xorg-server (main) "FEISTY: ctrl alt f1 terminal doesn't work with special characters (, ..)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91422
<Ubugtu> New bug: #50501 in xorg (main) "Screen freezes black and locks up randomly" [Undecided,Needs info]  https://launchpad.net/bugs/50501
<tepsipakki> what the hell.. I've now reproduced for the first time the "firefox scrolling is slow" bug
<tepsipakki> but it only happens with certain tabs
<tepsipakki> so it must be a firefox bug
<tepsipakki> although X is the process taking up cpu time
<Ubugtu> New bug: #47948 in xorg (main) "It doesn't let me use the savage driver" [Medium,Needs info]  https://launchpad.net/bugs/47948
#ubuntu-x 2008-03-03
<ubotu> New bug: #194739 in xf86-input-evtouch (universe) "My touchscreen can't work well" [Undecided,New] https://launchpad.net/bugs/194739
<ubotu> New bug: #196938 in firefox-3.0 (main) "Some pages shows crazy in FF3 (dup-of: 182038)" [Undecided,Incomplete] https://launchpad.net/bugs/196938
<ubotu> New bug: #194933 in linux-restricted-modules-2.6.24 (restricted) "Compiz + 169-series NVIDIA drivers: frequent visual corruption of window title bars upon various title bar events" [Undecided,New] https://launchpad.net/bugs/194933
<ubotu> New bug: #194851 in compiz (main) "Pink shadows with Compiz (dup-of: 186382)" [Low,New] https://launchpad.net/bugs/194851
<ubotu> New bug: #197789 in firefox-3.0 (main) "resized images are rendered all black (dup-of: 182038)" [Undecided,Incomplete] https://launchpad.net/bugs/197789
<ubotu> New bug: #139544 in linux-restricted-modules-2.6.22 (restricted) "Restricted Manager pushes wrong driver" [Undecided,Confirmed] https://launchpad.net/bugs/139544
<ubotu> New bug: #197955 in linux-restricted-modules-2.6.24 (restricted) "not installable in hardy amd64" [Undecided,Confirmed] https://launchpad.net/bugs/197955
<ubotu> New bug: #197116 in xorg-server (main) "Screen garbage with Intel 830 (Install CD)" [Undecided,New] https://launchpad.net/bugs/197116
<seb128> bryce: around?
<ubotu> New bug: #150058 in xserver-xorg-video-ati (main) "defects in some parts of the screen" [Undecided,New] https://launchpad.net/bugs/150058
<ubotu> New bug: #198044 in xorg (main) "nv kernel module not found" [Undecided,New] https://launchpad.net/bugs/198044
<bryce> seb128: heya
<seb128> hey bryce
<seb128> bryce: did you start on moving the gnome-desktop to a copy?
<bryce> yes, I got most of the changes done friday; now just need to get it to compile and build
<seb128> bryce: ok, lool doesn't agree that's the best way to do thing and likes the lib with unstable define better so I'm not sure what is right now
<seb128> sorry about that
<seb128> maybe worth discussing at the meeting this week
<bryce> uff
<bryce> ok, I'll set aside the remainder of that work.  Sounds like the radeonhd xrandr bugs need some attention so I'll focus on those.
<seb128> yes, I was going to mention that
<seb128> sorry again
<seb128> I still think the copy is better than abusing the lib so it's not sure that will not be used yet ;-)
<seb128> I'm cleaning duplicates of the g-s-d crasher now
<seb128> there seem to be different issues
<bryce> ok
<seb128> an xerror, likely happening to people who have a driver not supporting xrand1.2
<seb128> and a crasher
<seb128> https://bugs.edge.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/197706 has a detailled stacktrace of the crasher
<bryce> I suspect the fix is going to need to be some sort of blacklist in g-s-d, so it'll probably be good to know what range of cards have the problem
<seb128> hum?
<seb128> why?
<seb128> I think the crasher is a code bug which should be fixed
<seb128> and there is likely an api to ask xorg if xrandr1.2 is supported no?
<bryce> well, what I suspect is that the drivers are actually saying they do support xrandr 1.2, but in reality they don't
<jcristau> it's called XRRQueryVersion()
<seb128> those drivers should be fixed if they do that no?
<bryce> certainly, but I'm worried that may be a lot more work than can be achieved in the near term
<bryce> also, at least one reporter was using -nvidia, which we can't fix
<bryce> seb128: have you seen any reports of this issue by fglrx users?
<seb128> all that sounds like we want to drop the change and defer the spec to next cycle
<seb128> https://bugs.edge.launchpad.net/ubuntu/+source/gnome-desktop/+bug/197153 has comments from intel, fglrx, radeonhd users
<ubotu> Launchpad bug 197153 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGSEGV" [Undecided,New] 
<bryce> well, let me look into it; it might be something simpler
<seb128> https://bugs.edge.launchpad.net/dell/+bug/197354 is nvidia using xinerama
<ubotu> Launchpad bug 197354 in gnome-settings-daemon "gnome-settings-daemon doesn't work with xinerama (nvidia, amd64) (dup-of: 197153)" [Undecided,New] 
<ubotu> Launchpad bug 197153 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGSEGV" [Undecided,New] 
<seb128> "enabling Xinerama (with one or two displays) causes it to crash on startup. The assertion "screen != NULL" fails in screen_update, after a parse error starting xrandr manager."
<seb128> interesting comment
<bryce> ok, if nvidia with xinerama and fglrx are also failing, then it may be just a missing xrandr 1.2 check, which should be easy to stick in
<seb128> https://bugs.edge.launchpad.net/ubuntu/+bug/198017 is a dell laptop using nvidia
<ubotu> Launchpad bug 198017 in ubuntu "Gnome Desktop crashes if i start it with compiz (dup-of: 197153)" [Undecided,New] 
<ubotu> Launchpad bug 197153 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGSEGV" [Undecided,New] 
<ubotu> New bug: #197999 in xorg (main) "Changing of Screen Resolution does not work. The present resolution stays whatever button I click on." [Low,Invalid] https://launchpad.net/bugs/197999
<bryce> http://www.engadget.com/2008/03/03/hands-on-with-the-9-inch-eee-pc/
<ubotu> New bug: #198165 in xorg (main) "Screen rotation does not work on ATI R350 (Radeon 9800 Pro) with "radeon" driver" [Undecided,New] https://launchpad.net/bugs/198165
<ubotu> New bug: #198176 in xorg (main) "gdm[5056]: WARNING: gdm_slave_xioerror_handler: Fatal X error - Restarting :0" [Undecided,New] https://launchpad.net/bugs/198176
<ubotu> New bug: #194760 in xresprobe (main) "EDID fail" [Undecided,New] https://launchpad.net/bugs/194760
<ubotu> New bug: #198184 in linux-restricted-modules-2.6.24 (restricted) "Linux-image-2.6.24-11-generic doesn't wakeup the screen after suspend" [Undecided,New] https://launchpad.net/bugs/198184
#ubuntu-x 2008-03-04
<ubotu> New bug: #198263 in xserver-xorg-video-ati (main) "firefox 3 displays incorrectly" [Undecided,New] https://launchpad.net/bugs/198263
<ubotu> New bug: #198264 in xkeyboard-config (main) "debian/rules patch rule clear file 'rules/base.mlv_s.part'" [Undecided,New] https://launchpad.net/bugs/198264
<ubotu> New bug: #198268 in xserver-xorg-video-ati (main) "screen scrambles before or after login" [Undecided,New] https://launchpad.net/bugs/198268
<seb128_> bryce: hey
<ubotu> New bug: #198309 in xkeyboard-config (main) "sony vaio vgn-sz650n keyboard geometry problem" [Undecided,New] https://launchpad.net/bugs/198309
<ubotu> New bug: #198149 in xserver-xorg-video-ati (main) "Using Hardy Alpha live CD, I cannot use Full Graphics mode on any computer with ATI drivers." [Undecided,Confirmed] https://launchpad.net/bugs/198149
<ubotu> New bug: #195721 in xserver-xorg-driver-ati "glxinfo crashes after login  ( systemfreeze ) " [Undecided,Confirmed] https://launchpad.net/bugs/195721
<ubotu> New bug: #124406 in ubuntu "Keyboard keys get stuck and repeat (Feisty, Gutsy) (dup-of: 194214)" [Undecided,Confirmed] https://launchpad.net/bugs/124406
<ubotu> New bug: #158436 in ubuntu "[gutsy] key release events get lost (dup-of: 194214)" [Undecided,Confirmed] https://launchpad.net/bugs/158436
<ubotu> New bug: #198393 in xrandr "xrandr fails to output to VGA unless connected at boot" [Undecided,New] https://launchpad.net/bugs/198393
<cr3> dpkg-reconfigure xserver-xorg does not seem to prompt for the video driver anymore, is this a known change?
<tjaalton> cr3: yes
<cr3> tjaalton: is this a bug or is there another way to reconfigure xserver-xorg now?
<tjaalton> cr3: what do you mean?
<tjaalton> it's not a bug
<tjaalton> the xserver uses the best driver available, unless you want to use binary blobs
<jcristau> if you want to change it, 'vim' works fine
<tjaalton> :)
<tjaalton> cr3: for restricted drivers, use the driver manager. soon it'll have cmdline interface as well
<bryce> hi seb
<bryce> hmm, no seb
<seb128> hi
<seb128> does anybody sees what is wrong there http://people.ubuntu.com/~seb128/xorgbug?
<seb128> that's the xorg conf written by displayconfig-gtk on gutsy when selecting the monitor corresponding to the configuration and the corresponding xorg log because it starts in failsafe mode after using displayconfig-gtk
<bryce> no permission to view the xorg.conf
<seb128> bryce: fixed
<bryce> do you have the Xorg.0.log from the original boot attempt?
<seb128> original boot?
<bryce> the attempt to launch X prior to the failsafe attempt
<bryce> Xorg.0.log.old perhaps
<seb128> bryce: http://people.ubuntu.com/~seb128/xorgbug/Xorg.0.log.old
<seb128> the box boots correctly after installation
<seb128> the problems start happening after using displayconfig-gtk to configure a monitor
<seb128> bryce: http://people.ubuntu.com/~seb128/xorgbug/xorg.conf.1 is the stock working config
<bryce> ah ok
<bryce> well I think we are going to deprecate displayconfig-gtk now
<seb128> ok, so not worth debugging ;-)
<bryce> probably not
<bryce> my guess is that an incorrect monitor configuration got selected
<seb128> what will be the recommend wait to configure a CRT monitor when the default resolution is not adapted?
<seb128> well, the selected model is the one connected to the PC
<seb128> and selecting a generic monitor with a non too high resolution doesn't work either
<seb128> I don't have the log for those though
<seb128> I've not been on the buggy box, just doing remote debugging
<bryce> well, sudo dpkg-reconfigure xorg-server is still the best way to do it (we even recommend it still when displayconfig-gtk fails)
<bryce> ideally, I think we know a lot better now how to quirk monitors and update drivers to fix these sorts of issues directly
<seb128> well, my fix is "sudo cp xorg.conf.1 xorg.conf" which works fine
 * bryce nods
<seb128> but I've issue explaining why selecting the right monitor leads to a situation why I need to do command line magic to get a working box again ;-)
<seb128> why -> where
<bryce> yep, well in such cases we'll just need to apologize and promise to try to sort out why the monitor was not autodetected
<bryce> I think we can leave displayconfig-gtk available for people to install and use if they wish; although like you see, it doesn't give a guarantee of a correct config either
<ubotu> New bug: #195669 in xorg (main) "pc running at low resolution " [Undecided,Incomplete] https://launchpad.net/bugs/195669
<seb128> bryce: and do you see what is wrong in this one? http://people.ubuntu.com/~seb128/xorgbug/Xorg.9.log I think that's another try with a generic monitor which should be no issue
<seb128> bryce: would hardy be better? I can give a daily CD to try ;-)
<seb128> bryce: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/198450
<ubotu> Launchpad bug 198450 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGSEGV" [Medium,New] 
<seb128> bryce: this user still get a crash using the new versions
<seb128> version rather, I did upload your gnome-desktop update but no gnome-settings-daemon change
<bryce> seb128: sorry, I'm feeling ill, and suspect I am going to be taking some sick days
<bryce> 198450 probably needs the gnome-settings-daemon change
<bryce> seb128: hard to say without knowing the Xorg.0.log and/or driver
<bryce> when I looked into this monday, I saw there's two different mechanisms that can lead to the crash at the same spot in the code, so both the gnome-desktop and gnome-settings-daemon fixes are needed to 
<bryce> I haven't ruled out that there might be more than those two ways for it to get to that point with an invalid pointer, so we do need to watch for additional crashes.
<seb128> bryce: ok, no hurry, get well
<seb128> I've to go
<seb128> later
<ubotu> New bug: #198484 in nvidia-settings (universe) "nvidia-settings FFe" [Undecided,New] https://launchpad.net/bugs/198484
<bryce> tjaalton: $ ls -l /var/log/Xorg.0.log
<bryce> -rw-r--r-- 1 root root 3841563 Mar  4 09:43 /var/log/Xorg.0.log
<bryce> but I think that may be due to all the xrandr fiddling I've been doing
<tjaalton> possibly so
<bryce> I wonder if the user installed something that is making a lot of xrandr calls or something
<tjaalton> I wonder what that might be :)
<bryce> do you have an idea?
<bryce> (sorry if I'm missing obvious stuff, my brain feels like it's full of fluff right now)
<ubotu> New bug: #190821 in nvidia-settings (universe) "nvidia-settings corrupts xorg.conf" [Undecided,Incomplete] https://launchpad.net/bugs/190821
<tjaalton> nope.. no I idea :/
<tjaalton> hope that he'll reply to the bug soon
<ubotu> New bug: #198503 in nvidia-settings (universe) "nvidia-settings doesn't remember window size or default to a decent window size" [Low,Confirmed] https://launchpad.net/bugs/198503
<seb128> bryce: gsd update uploaded too, thanks for your work fixing those
<bryce> cool thanks
<bryce> seb, timo, I'm going to go offline now for a while (feeling pretty crappy).  send me an email if there are emergencies I need to work on, I'll check in as I can.
<seb128> bryce: no emergency don't worry
<seb128> get better
<seb128> later
<tjaalton> bryce: ok, get well
<ubotu> New bug: #198522 in xorg (main) "X can stop responding when clicking the shutdown button" [Undecided,New] https://launchpad.net/bugs/198522
<ubotu> New bug: #192198 in xulrunner-1.9 (main) "rendering problem on firefox 3 (gmail) (dup-of: 186186)" [Undecided,Incomplete] https://launchpad.net/bugs/192198
<ubotu> New bug: #183754 in xorg (main) "NV5MGA (RIVA TNT2 MODEL 64 PRO) i can't use it." [Undecided,Incomplete] https://launchpad.net/bugs/183754
<ubotu> New bug: #198521 in xorg (main) "Hardy regression: i810 video incorrect size; cursor paints blocks" [Undecided,New] https://launchpad.net/bugs/198521
<soren> tjaalton, bryce: What's the current vibe about vmmouse by default?
<tjaalton> soren: undecided, but should be fine
<soren> tjaalton: Awesome.
<ubotu> New bug: #46378 in xkeyboard-config (main) "Bad mapping for Right-Click on PowerPC" [Medium,New] https://launchpad.net/bugs/46378
#ubuntu-x 2008-03-05
<ubotu> New bug: #198599 in xserver-xorg-input-aiptek (universe) "Fix for buggy aiptek-drivers" [Undecided,New] https://launchpad.net/bugs/198599
<ubotu> New bug: #177295 in linux-ubuntu-modules-2.6.22 "ipw2200: Firmware error detected.  Restarting. (dup-of: 116456)" [Undecided,Confirmed] https://launchpad.net/bugs/177295
<ubotu> New bug: #198611 in xorg-server (main) "Xorg crashes when executing setxkbmap" [Undecided,New] https://launchpad.net/bugs/198611
<ubotu> New bug: #198622 in linux-restricted-modules-2.6.24 (restricted) "nvidia_new fails to load" [Undecided,New] https://launchpad.net/bugs/198622
<ubotu> New bug: #198609 in xorg (main) "xorg does not allow user to reconfigure video driver and monitor specifications" [Undecided,New] https://launchpad.net/bugs/198609
<Ng> should alpha5 have had the EXA greedy stuff for most Intel chips?
<Ng> I re-installed with it last night and I got EXA, but it's not greedy
<jcristau> Ng: for 965 afaik
<Ng> ah I thought it was going to be extended to cover older chips too
<mvo> bryce, tjaalton: can we get something like http://people.ubuntu.com/~mvo/tmp/xserver-xorg-video-intel_2.2.1-1ubuntu3.debdiff ? there was a discussion on the xorg list and i965 has hardware overlay afterall - it would be nice to use it
<mvo> for me on my 965 even with greedy a fullscreen video is flickering
<mvo> the debdiff has two issues: a) textured video is still default b) it conflicts somehow with the exa+greedy patches (blank screen when both are applied)
<mvo> please let me know what you think
 * mvo -> lunch
<tjaalton> mvo: you mean remove patch 01_fix_compiz_video.diff and replace with 10&11? why not
<tjaalton> Ng: ugh, I should have uploaded that package, but forgot
<Ng> aha :)
<Ng> OOI, is there a way to enable EmulateScrollWheel type things without editing xorg.conf?
<tjaalton> don't think so
<tjaalton> busy hacking into winxp :) ->
<tjaalton> bbl
<mvo> tjaalton: not exactly, 01_fix_compiz_video needs to stay, but in a modified form, it is required for xf86VFillKeyHelperDrawable - but that is something that should probably go upstream too
<mvo> tjaalton: it needs some love to make it work with bryce greedy patch, I don't know it, so I will just wait for bryce to comment. but the ubuntu3 version works fine for me and video playback is smoother and work on 965 and compiz the same way as the others (that is, on screen transformations the video window is blank, but it does not do any damage like dri)
<tjaalton> mvo: ok, sounds good
<mvo> thanks tjaalton
<ubotu> New bug: #198759 in xkeyboard-config (main) "Right CTRL don't work" [Medium,New] https://launchpad.net/bugs/198759
<ubotu> New bug: #198789 in xserver-xorg-video-intel (main) "xorg does not allow user to reconfigure video driver and monitor specifications - Intel Driver" [Undecided,New] https://launchpad.net/bugs/198789
<ubotu> New bug: #198803 in linux-restricted-modules-2.6.24 (restricted) "X1650 black screen, system freeze and crash" [Undecided,Incomplete] https://launchpad.net/bugs/198803
<ubotu> New bug: #198781 in xserver-xorg-driver-i810 "intel 945 monitor on laptop acer 3690  with hardy heron" [Undecided,Incomplete] https://launchpad.net/bugs/198781
<ubotu> New bug: #198832 in linux-restricted-modules-2.6.24 (restricted) "[Hardy] Unable to completely remove nvidia-glx" [Undecided,New] https://launchpad.net/bugs/198832
<ubotu> New bug: #116065 in xorg-driver-synaptics "System hangs randomly and error message "Alps GlidePoint can't grab event device, errno=1022"" [Undecided,Fix released] https://launchpad.net/bugs/116065
<mvo> bryce: did you see my earlier question about 965 and overlay mode?
<tjaalton> mvo: I guess he's on sick leave..
<mvo> tjaalton: oh, sorry then, I wasn't aware of ths
<jcristau> tjaalton: badalloc with -intel on i830 with XV and compiz, does that ring any bells for you?
<bryce> mvo: yeah came down with the flu... let me check
<mvo> get well! its not terrible important, I was just curious about your opinion (see scrollback for more details)
<tjaalton> jcristau: hmm, actually I've seen that with nvidia
<bryce> mvo, it looks like it adjusts support for some features with 9xx and 965 hardware.  If upstream has reviewed and accepted it, and if we have ample testing by people on various hardware, it may be safe.
<bryce> mvo, since it opens up functionality where it's not been available before, it probably needs a lot of testing
<bryce> the patch feels a bit more on the "feature" side than "bug fix" side, so I'd also want to understand the problems it solves in more detail
<bryce> mvo, also it appears there are several distinct patches in the patch, that look like they're not interdependent (but I could be wrong).  It may be better at this stage in the release to treat each piece as a separate patch, to make it easier to revert them individually if needed.
<bryce> mvo, I'm also curious how it conflicts with the greedy patch
<mvo> bryce: the patch adds a option to make textured video configurable (that bit is complettely optional) and it also turns on the hardware overlay support for i965 (just like we for 810-945). overlay video runs much smoother for me than textured video (at least with compiz)
<mvo> upstream is in the process of reviewing it (keith replied to the patch on xorg some days ago)
<mvo> I have no idea how it interactes with the greedy patch currently, i haven't looked into that
<mvo> we didn't do that for gutsy (i965 hardware video overlay) because we thought that it would not be available on i965 (there were no docs from intel back then)
<mvo> but it turns out that there is hw overlay support 
<bryce> mvo, ah gotcha.  Since I'm not up to par anyway, let's wait for keithp's review first, and see what form of the patch they take upstream.
<mvo> sounds good, thanks for looking at it
<mvo> and get well soon :)
#ubuntu-x 2008-03-06
<ubotu> New bug: #198951 in gnome-control-center (main) "[intel 855GM] gnome-display-properties crashed with SIGSEGV in screen_info_new()" [Medium,New] https://launchpad.net/bugs/198951
<ubotu> New bug: #189033 in ubuntu "reboot - resolution problem - HARDY (dup-of: 189599)" [Undecided,New] https://launchpad.net/bugs/189033
<ubotu> New bug: #198780 in xorg (main) "firefox crashes immediately on opening webpage" [Undecided,Confirmed] https://launchpad.net/bugs/198780
<ubotu> New bug: #197130 in xorg (main) "[hardy] Black X screen and system halt after installing linux-rt" [Undecided,New] https://launchpad.net/bugs/197130
<seb128> is that normal than radeonhd is not installed by default?
<jcristau> well there are 3 drivers for the same hardware :)
<tjaalton> seb128: yes, it's normal. -ati supports the same chips
<tjaalton> ..and more
<seb128> is that new?
<seb128> when I installed hardy on my desktop I got vesa mode
<tjaalton> yep, starting from 6.8.0
<seb128> until I installed radeonhd
<seb128> ok
<tjaalton> alpha6 should work OOTB :)
<seb128> cool
<ubotu> New bug: #199023 in linux-restricted-modules-2.6.24 (restricted) "fglrxinfo crashed with SIGSEGV" [Undecided,Incomplete] https://launchpad.net/bugs/199023
<mvo> tjaalton: I get random flickering with r500 and radeon, but it works great other than that. is there a open bug about this?
<tjaalton> mvo: can't recall.. let me check
<tjaalton> mvo: nope, there doesn't seem to be any similar bugs filed, at least not against that package :)
<mvo> thanks, I guess I should file one then
<bryce> morning
<tjaalton> hey bryce 
<ubotu> New bug: #199205 in xserver-xorg-input-joystick (universe) "X.org wont start with input-joystick" [Undecided,New] https://launchpad.net/bugs/199205
<tjaalton> \sh: hmm, thanks.. I'll see if I can live with it for awhile first
<tjaalton> :)
<tjaalton> huh
<tjaalton> wrong channel apparently :P
<ubotu> New bug: #163044 in xorg (main) "terminal display error when reading PDF files" [Undecided,Confirmed] https://launchpad.net/bugs/163044
<ubotu> New bug: #199223 in xorg (main) "X crash every time after update" [Undecided,New] https://launchpad.net/bugs/199223
<ubotu> New bug: #198811 in xserver-xorg-input-synaptics "[Hardy - Alpha5] Synaptics touchpad doesn't work well" [Undecided,Confirmed] https://launchpad.net/bugs/198811
<ubotu> New bug: #199253 in xserver-xorg-input-keyboard (main) "Can't use ~ Â´ ` on PT_pt keyboard" [Undecided,New] https://launchpad.net/bugs/199253
<ubotu> New bug: #199034 in xserver-xorg-video-intel (main) "X server will not start (agpgart)" [Undecided,New] https://launchpad.net/bugs/199034
<ubotu> New bug: #199285 in xterm (main) "xterm crashes when compiz is on" [Undecided,New] https://launchpad.net/bugs/199285
<ubotu> New bug: #199304 in linux-restricted-modules-2.6.24 (restricted) "[wishlist] Please integrate fglrx 8.03" [Undecided,New] https://launchpad.net/bugs/199304
#ubuntu-x 2008-03-07
<pwnguin> who wrote the screen&graphics program?
<pwnguin> ah, found it. displayconfig-gtk
<ubotu> New bug: #199337 in xserver-xorg-video-ati (main) "External monitor stays black when hotplugging with Acer laptop" [Undecided,New] https://launchpad.net/bugs/199337
<ubotu> New bug: #199359 in linux-restricted-modules-2.6.24 (restricted) "[hardy] DRI not working with fglrx" [Undecided,New] https://launchpad.net/bugs/199359
<desertc> http://www.phoronix.com/scan.php?page=news_item&px=NjM3OA
<desertc> Phoronix is releasing an open source benchmarking suite.
<desertc> ... for graphics
<desertc> This will be a big step forward toward being able to discuss practical numbers for comparison.
<ubotu> New bug: #157556 in ubuntu "consoles are blank with framebuffers (dup-of: 129910)" [Undecided,Confirmed] https://launchpad.net/bugs/157556
<pwnguin> peoplezwell neat
<pwnguin> i guess that gives my brainstorm submission a bit more weight ;)
<pwnguin> http://brainstorm.ubuntu.com/idea/3259/
<pwnguin> well, so far they're only releasing the stuff to make graphics from results
<ubotu> New bug: #191508 in linux-restricted-modules-2.6.24 (restricted) "[nvidia] compiz doesn't show shadows, works with manual driver install" [Undecided,Confirmed] https://launchpad.net/bugs/191508
<pwnguin> so what all do i need to do to get an onscreen keyboard for gdm?
<tjaalton> try #ubuntu-desktop..
<ubotu> New bug: #199075 in compiz (main) "Compiz crashes the system (dup-of: 151168)" [Undecided,New] https://launchpad.net/bugs/199075
<ubotu> New bug: #192407 in linux-source-2.6.22 (restricted) "Thinkpad T61 crashes on resume from suspend" [Undecided,Invalid] https://launchpad.net/bugs/192407
<ubotu> New bug: #199458 in xorg (main) "cannot use refresh rate of 100Hz with Sony Multiscan G200 + Nvidia FX5200 (WinXp works)" [Undecided,New] https://launchpad.net/bugs/199458
<asac> tjaalton: bryce: how can i figure the driver used for a display?
<asac> if not driver, maybe i can figure the accellmethod used?
<asac> (at best programmatically)
<tjaalton> asac: I don't think there's a better way than parsing the log :/
<tjaalton> randr might support it some time
<asac> darn
<asac> isn't there an property or something :(
<asac> tjaalton: xdpyinfo displays a bunch of extensions. maybe i can guess something from that?
<asac> tjaalton: http://paste.ubuntu.com/5404/
<asac> thats hat it spits out for me
<asac> ok at least we could figure fglrx from that i guess :)
<ubotu> New bug: #199486 in xinit (main) "ConsoleKit integration" [Undecided,New] https://launchpad.net/bugs/199486
<asac> tjaalton: i would like to hack a bit on xservers xaa code ... how can i do that without trashing my install?
<asac> (e.g. the question is: how to best build upstream code, while not wiping my existing install)
<jcristau> asac: http://hoegsberg.blogspot.com/2008/02/building-and-installing-drmdrix-stack.html
<jcristau> that might help
<asac> thx
<ubotu> New bug: #199551 in linux-restricted-modules-2.6.24 (restricted) "Fullscreen presentation is only shown on half a screen" [Undecided,New] https://launchpad.net/bugs/199551
<tjaalton> asac: xdpyinfo doesn't seem to reveal the driver, at least not directly :/
<asac> yeah ... cworth said that such info is currently not exposed by xserver
<asac> would need to be added
<asac> tjaalton: ^^
<jcristau> i don't think there's any plan to add that
<tjaalton> shame
<jcristau> why?
<tjaalton> well, it could prove useful.. sometimes :)
<tjaalton> can't think of a use case for myself though
<bryce> it's a question that's come up a number of times, for various reasons
<bryce> (usually due to a need to work around some driver-specific problem or other)
<jcristau> but then you end up with a pile of workarounds which stay around longer than the driver bugs
<bryce> jcristau: in each case they ended up using the parse-Xorg.0.log, so not providing that data did not achieve that stability-through-secrecy aim
<jcristau> well i don't think it's about secrecy. more about not encouraging broken things like that.  and you don't have access to Xorg.0.log if you're a remote client :)
<bryce> I think there is value in having increased information such as the driver for testing purposes
<bryce> I've run into this answer before ("not wishing to encourage misuse") but there are definitely legitimate uses for having such info
<bryce> plus, there are drivers we cannot easily fix, so we have no choices but to work around the issues
<jcristau> anyway. /me goes back to uploading this week's new releases
<ubotu> New bug: #196596 in linux-restricted-modules-2.6.24 (restricted) "Suspend fails on Sony Vaio SZ650, nVidia 8400M GS and nvidia-glx-new" [Medium,Triaged] https://launchpad.net/bugs/196596
<tjaalton> jcristau: bug 38939 seems similar to the bug you mentioned
<ubotu> Launchpad bug 38939 in xorg-server "MPlayer receives BadAlloc when playing very large movies using Xv" [Medium,Confirmed] https://launchpad.net/bugs/38939
<jcristau> thanks
<tjaalton> huh, so RH has had two patches for libx11, the other for a bug that has 17 dupes
<tjaalton> definately going to include them
<bryce> now that  dpkg-reconfigure xserver-xorg no longer prompts for video settings, what should we advise for users needing to workaround areas where configuration cannot be done automatically?  
<ubotu> New bug: #199671 in linux-restricted-modules-2.6.24 (restricted) "Hibernate fails on Asus F5N laptop" [Undecided,New] https://launchpad.net/bugs/199671
#ubuntu-x 2008-03-08
<ubotu> New bug: #199700 in xorg-server (main) "xrandr changes break composite on 2nd head" [Undecided,New] https://launchpad.net/bugs/199700
<ubotu> New bug: #199705 in xorg (main) "compiz wont start by default on xubuntu startup" [Undecided,New] https://launchpad.net/bugs/199705
<tjaalton> bryce: either use dc-g or edit by hand :/
<tjaalton> unless jockey could be used for that with appropriate parameters
<ubotu> New bug: #198935 in xorg (main) "After installation of nvidia proprietary driver, x can no longer detetct my monitors available resolutions" [Undecided,New] https://launchpad.net/bugs/198935
<ubotu> New bug: #197981 in xorg (main) "ati radeon x 1650" [Undecided,New] https://launchpad.net/bugs/197981
<ubotu> New bug: #194892 in xorg (main) "No DRI using fglrx through restricted driver manager" [Undecided,New] https://launchpad.net/bugs/194892
<ubotu> New bug: #190761 in xorg (main) "Screen defaults to 1280x1024" [Undecided,New] https://launchpad.net/bugs/190761
<bryce> tjaalton: hmm, I suspect we're going to get some complaints about this (I already fielded one today).  But maybe it won't be as common.
<bryce> night
<tjaalton> bryce: could be, but as you said it's very uncommon to actually need that. radeonhd/unichrome/i810 ftl
<ubotu> New bug: #199317 in xorg (main) "paused Totem cause the system black and unusable" [Undecided,New] https://launchpad.net/bugs/199317
<ubotu> New bug: #199823 in xserver-xorg-video-intel (main) "[Hardy] Blender's 3D viewport grid looks strange " [Undecided,New] https://launchpad.net/bugs/199823
<ubotu> New bug: #199923 in xserver-xorg-input-evdev (main) "evdev grabs all devices even if it's disabled" [Undecided,New] https://launchpad.net/bugs/199923
<ubotu> New bug: #199983 in linux-restricted-modules-2.6.24 (restricted) "nvidia-glx-new restricted driver no longer offered for GeForce Go 7900GS " [Undecided,New] https://launchpad.net/bugs/199983
#ubuntu-x 2008-03-09
<ubotu> New bug: #199993 in xorg-server (main) "[Hardy][patch]xorg.conf should include a big enough virtual screen" [Undecided,New] https://launchpad.net/bugs/199993
<ubotu> New bug: #89640 in linux-restricted-modules-2.6.20 "kde changes screen refresh rate of nvidia card" [Undecided,New] https://launchpad.net/bugs/89640
<ubotu> New bug: #119413 in xorg-server (main) "Control Center in KDE not displaying complete options (Gutsy LiveCD Tribe1)" [Undecided,New] https://launchpad.net/bugs/119413
<ubotu> New bug: #183875 in xserver-xorg-input-mouse (main) "USB problem" [Undecided,Incomplete] https://launchpad.net/bugs/183875
<ubotu> New bug: #200148 in wacom-tools (main) "wacom tablet doesn't reach the whole screen" [Undecided,New] https://launchpad.net/bugs/200148
<ubotu> New bug: #199721 in gnome-control-center (main) "gnome-display-properties crashed with SIGSEGV (dup-of: 198951)" [Undecided,New] https://launchpad.net/bugs/199721
<ubotu> New bug: #199869 in gnome-control-center (main) "gnome-display-properties crashed with SIGSEGV (dup-of: 198951)" [Undecided,New] https://launchpad.net/bugs/199869
<ubotu> New bug: #200220 in xorg (main) "xorg freezes while starting tvtime" [Undecided,New] https://launchpad.net/bugs/200220
<ubotu> New bug: #200229 in xorg (main) "LCD panel is not recognized on Asus F5N laptop" [Undecided,New] https://launchpad.net/bugs/200229
<ubotu> New bug: #200240 in linux-restricted-modules-2.6.24 (restricted) "Wrong kernel module for Atheros AR5007EG Wireless loaded - wireless not working" [Undecided,New] https://launchpad.net/bugs/200240
<ubotu> New bug: #200246 in linux-restricted-modules-2.6.24 (restricted) "X Fails on fglrx upgrade" [Undecided,New] https://launchpad.net/bugs/200246
<superm1> hey bryce, this new resolution panel : is there going to be a sense of "left" and "right"?  Doesn't seem to do much good when it just guesses :)
<ubotu> New bug: #200303 in linux-restricted-modules-2.6.22 "[nvidia] doesn't work on inspiron (geforce 8400m)" [Undecided,New] https://launchpad.net/bugs/200303
<ubotu> New bug: #195436 in linux-restricted-modules-2.6.24 (restricted) "Compiz - no shadows" [Medium,Confirmed] https://launchpad.net/bugs/195436
<ubotu> New bug: #198196 in 3ddesktop "cant stretch icons (dup-of: 186382)" [Undecided,New] https://launchpad.net/bugs/198196
<bryce> superm1: yes eventually (possibly for Hardy, definitely for Hardy+1)
<ubotu> New bug: #200377 in gnome-control-center (main) "gnome-* crashes with SIGSEGV, this is gnome-display-properties (dup-of: 198951)" [Undecided,New] https://launchpad.net/bugs/200377
#ubuntu-x 2009-03-02
<tjaalton> damn nvidia crashing on me when I change the user
<tjaalton> this 180.* is very unstable
<superm1> neither of the closed drivers has ever been good for me when changing users.  i've unfortunately just learned to not try since it's so questionable if one release does it properly
<tjaalton> it was stable in intrepid, although sometimes you had to enter the password blindly, because the screen would be white
<tjaalton> hmm so the screen is locked by default now.. maybe that has something to do with it
<tjaalton> I mean even with just one user
#ubuntu-x 2009-03-03
<Skiess1> hi
<Skiess1> so..
<Skiess1> my laptop graphics doesn't work right
<Skiess1> it says it has S3 Savage4
<Skiess1> but it works only with the 'vesa' driver
<bryce> <bryce> tjaalton_: hmm, on fdo #19574 it is said that our patch 156 should be upstream, however the change doesn't appear to be present in our xserver git tree.  This is lp bug #311254
<ubottu> Launchpad bug 311254 in xorg-server "Xorg crashed with SIGSEGV in CopyKeyClass()" [High,Fix released] https://launchpad.net/bugs/311254
<tjaalton_> bryce: I'll check in a minute
<tjaalton_> (merged 1.6.0 in git btw, finally)
<bryce> yep, I see
<bryce> :-)
<tjaalton_> so, tseliot joined the big C :)
<tjaalton> good news
<bryce> yep :-)  today's his first day
<bryce> maybe yesterday your time
<tjaalton> bryce: confirmed, that patch is not in 1.6-branch
<bryce> I've not seen him so far today to congratulate him, so guess he's buried under the usual canonical newhire paperwork stuff.
<tjaalton> hehe
<bryce> pushed up another patch
<tjaalton> we put our flat up for sale on Sunday, and will receive the first offer today, so it's been quite hectic here.. now if the bank would let us know how much they are willing to lend us extra ;)
<bryce> oh I bet!  where you moving?
<tjaalton> that's a good question, but we'll stay in the city (Espoo, next to the capital)
<tjaalton> meaning that we haven't made any decisions yet
<bryce> ah, will you be moving to a house, or another flat?
<tjaalton> it also means that I'll have to skip Barcelona, because we'll likely be moving at that time
<tjaalton> a house probably
<superm1> bryce, nah, i'm fairly sure i already saw a bug or two assigned to him in oem projects ;)
<bryce> superm1: heh
<bryce> tjaalton: cool, hope the bank gives you much love
<bryce> tjaalton: sorry to hear you won't be in barcelona, but yeah moving can be quite an ordeal
<bryce> tjaalton: on bug https://bugs.freedesktop.org/show_bug.cgi?id=18321 - do you think the busid could just be forced to the highest busid?
<tjaalton> you can see my current office here in the pics, so I'm in desperate need for more space :) http://www.oikotie.fi/myytavat+asunnot/kerrostalo/ymmersta/espoo/1754092
<ubottu> Freedesktop bug 18321 in Server/general "xserver 1.5.2 fails to start with more than one display card" [Normal,New]
<superm1> bryce, it sure can.  I just bought my first house this last week and i couldn't believe home much random stuff i'd gathered to move between my old apartment and new house
<tjaalton> bryce: it's something to try.. no idea what the proper fix should involve
<bryce> tjaalton: I like the sun room, that's where I'd put my office!  :-)
<tjaalton> bryce: heh, just that its quite cold when there's no sun, and a bit too hot in the summer ;)
<bryce> proper fix : probably something DRI2-ish
<tjaalton> you mean it would use them both instead of just one?
<bryce> right
<bryce> speak of the devil :-)
<bryce> tseliot: we were just wondering where you were so we could give you congrats on your first day :-)
<bryce> tjaalton: if I understand the code, this might work - http://people.ubuntu.com/~bryce/default_bustype.patch
<tseliot> bryce: thanks :-)
<tjaalton> tseliot: cheers, noticed it on facebook ;)
<tseliot> right. Thanks tjaalton ;)
<tjaalton> bryce: I don't know the code much, but maybe it could work :)
<bryce> I'll give it a test tomorrow.  if I understand what the code is doing, that may be all that's needed
<tjaalton> yeah
<bryce> tjaalton: what are your thoughts on 334711?
<bryce> https://bugs.edge.launchpad.net/ubuntu/+source/mobile-meta/+bug/334711
<ubottu> Launchpad bug 334711 in mobile-meta "Ubuntu MID misses several X input drivers" [High,Confirmed]
<bryce> night
<tjaalton> bryce: maybe having it in the seed would be cleaner in the sense that it's specific to that use case
<tjaalton> then they can drop it once (and if) evdev replaces evtouch
<seb128> does anybody there knows about XListInputDevices()?
<seb128> I'm looking at bug #204850
<ubottu> Launchpad bug 204850 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGSEGV in gsd_mouse_manager_start()" [Medium,Triaged] https://launchpad.net/bugs/204850
<seb128> the code does that basically
<seb128>         XDeviceInfo *devicelist = XListInputDevices (GDK_DISPLAY(), &numdevices);
<seb128> 	for (i = 0; i < numdevices; i++) {
<seb128> 		if ((device = device_is_touchpad(devicelist[i]))) {
<seb128> the stacktrace shows that
<seb128> (gdb) print devicelist
<seb128> $1 = (XDeviceInfo *) 0x0
<seb128> (gdb) print numdevices
<seb128> $2 = 32537
<seb128> is there something wrong with the way this function is used there?
<jcristau> yes. check that devicelist isn't NULL before using it.
<jcristau> XListInputDevices doesn't set *ndevices if it fails
<seb128> doh
<seb128> ok, I was wondering why the number was not 0, thanks!
<tseliot> seb128: yes, that's a function from Xinput
<tseliot> oops, I didn't read the last comments here
<seb128> tseliot: that's ok I got the reply I was looking for, it doesn't set the value to 0 when there is nothing to list which explains the bug
<tseliot> ok
<jcristau> seb128: otoh it shouldn't fail :)
<jcristau> unless xinput is disabled, but..
<seb128> one of the bug submitter says he's using a vnc server which doesn't support xinput
<jcristau> ok, that makes sense
<tjaalton> bryce: the intel crashes might be due to changes in the kernel for vblank, assuming that the code path is hit on non-vblank configuration
<tjaalton> since it was all very stable for me not too long ago
<tjaalton> and now I can crash it just by closing the lid N times
<mahfiaz> tjaalton, I think I have similar problems on my T61 with nvidia
<tjaalton> mahfiaz: same with my desktop, but AIUI nvidia doesn't use drm.ko, so either my diagnose is wrong or it's something different
<tjaalton> hmm, there should be a way to check that out
<tjaalton> right, it can't because it would violate GPL even more
<mahfiaz> I get blank screens once in awhile, X server may even start fine again, but nothing shows up on X, console is fine, resetting helps
<jcristau> tjaalton: the drm code is bsd licensed :)
<tjaalton> oh :)
<jcristau> (it's shared with the BSDs)
<tjaalton> anyway, modules.dep shows no dependencies, so it shouldn't use it I guess
<jcristau> yeah nvidia has their own thing, they don't use the drm/dri
<bryce> tjaalton: what's the plan for fixing the intel crashes?
<tjaalton> bryce: well, rtg pulled a couple of patches from .29 that were meant for vblank, but since we aren't going to use it those should probably be dropped
<tjaalton> I should probably check what was pulled and ask them to be removed
<tjaalton> *reverted
<tjaalton> I'm not sure if it's helpful to debug something that's based on backports
<tjaalton> helpful for upstream
<tjaalton> it might even be fixed already
<jcristau> wow. psb people on dri-devel.
<tjaalton> about time ;)
<mnemo> tjaalton, bryce: i did some work to find an upstream mesa patch that fixes 965 rendering glitches currently seen on intrepid and jaunty... i've ported the upstream patch to ubuntu's mesa and added it to the mesa quilt in intrepid and jaunty ( two debdiffs are attached to this bug https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/330476 )
<ubottu> Launchpad bug 330476 in xserver-xorg-video-intel "[965] render defects in google earth / atunnel screensaver (intrepid and jaunty-as-of-feb-3rd)" [Unknown,Fix released]
<tjaalton> mnemo: thanks, refiled against mesa
<bryce> mnemo: thanks for doing that
<mnemo> np =) happy to help out
#ubuntu-x 2009-03-04
<bryce> tjaalton: heya, what remains to be done before 1.6.0 can be uploaded?
<tjaalton> bryce: new libdrm I guess
<tjaalton> hmm no
<tjaalton> it was intel that needed it
<tjaalton> "Experience with the kernel portions of KMS (kernel mode switching) " :)
<tjaalton> from the employment page
<crevette> good morning
<crevette> does anyone has some knowledge about bluetooth input device in Xorg ?
<crevette> a reporter said it's bluetooth HID working under VT but not with Xorg
<crevette> https://bugs.edge.launchpad.net/ubuntu/+source/bluez/+bug/328216
<ubottu> Launchpad bug 328216 in bluez "Bluetooth keyboard not working in X in 9.04" [Undecided,New]
<tjaalton> crevette: not much to say without Xorg.0.log
<crevette> tjaalton, just I wanted some pointer, does a bluetooth device is listed in xinput ?
<crevette> s/does/is/
<crevette> and s/is//
<tjaalton> I don't know
<crevette> okay let ask the log first
<crevette> can I add xorg as inpacted package?
<tjaalton> not yet ;)
<crevette> I'm sure this is xork, blame xorg
<crevette> :)
<tjaalton> so, fedora now has a patch for wacom to init all devices
<tjaalton> http://cvs.fedoraproject.org/viewvc/devel/linuxwacom/linuxwacom-0.8.2.2-HAL.patch?revision=1.1&view=markup
<tjaalton> Alexia_Death: ^^
<superm1> bryce, i was talking to cjwatson about a 60 second delay to wait for X to start (or fail to start for that matter) in ubiquity-dm (used for --automatic).  i've got a case where it's failing to start because a monitor might not be plugged in.  do you know of any way to tell it to start up anyway even if it's not finding a monitor and bailing?
<jcristau> there's no way to do that atm afaik
<superm1> hmm okay then, the alternative solution would to be dropping that delay in the amount of time to wait until declaring X failed to start. what's a safer number that's less than 60?
<superm1> assuming you can be starting off of live media and what not which is slower
<jcristau> it'd probably be feasible to fix x to start at 800x600 (or 640x480) even if nothing's connected..
<superm1> maybe forcing vesa as a fallback then.  i'm not if vesa is enforcing this too
<superm1> *sure
<superm1> this was with the intel driver that I was seeing this behavior
<bryce> superm1, jcristau: I'd have no problem changing that, any ideas where this is being set?  xserver?
<superm1> bryce, i think something would need to  be added to the X server to fall back to vesa and try that if the current driver should work and tries to work, but for some reason bales
<superm1> because from the server's perspective, i dont think there is a way you'll see this situation
<crevette> hey superm1
<superm1> hi crevette 
<bryce> hmm
<bryce> superm1: ok, not totally sure what would need implemented, but can you file a wishlist bug against xorg-server for this?
<crevette> superm1: as you're not on #u-mobile, if you're interested with testing bluez 4.32 (https://edge.launchpad.net/~bmillemathias/+archive/ppa)
<crevette> superm1: and you're invited to report regression from 4.30 in https://bugs.edge.launchpad.net/bugs/337443
<ubottu> Launchpad bug 337443 in bluez "[jaunty] Please update bluez to 4.32 version" [Undecided,New]
<superm1> bryce, sure.  i think i've got a rough idea of what needs doing, just don't know the codepath, so i'll try best to word it
<superm1> crevette, looks like a bug fix release other than " Add support for new BtIO helper library."
<bryce> ok thanks, that may help. 
<superm1> if nothing is using that, i dont see why an FFe would be denied (unless of course there Are regressions ;))
<crevette> superm1: yes, there were some crasher, especially in 4.31 which wasn't uploaded
<superm1> ah okay
<crevette> 4.31 was crashy
<superm1> i think bluez upstream does releases too quickly imho
<crevette> "Release early, release often"
<crevette> :)
<crevette> it is hard to test all corner case for packagers
<crevette> cases
<jcristau> superm1: why would you fall back to vesa, as opposed to just making your driver set a default fallback mode?
<Alexia_Death> tjaalton: HAL people wont accept that upstream.
<Alexia_Death> tjaalton: so with that they will keep patching hal forever.
<tjaalton> Alexia_Death: umm, it's a patch for wacom
<Alexia_Death> The kernel driver?
<Alexia_Death> Ping said that was too much work to be done sensibly...
<jcristau> tjaalton's link is a linuxwacom patch...
<jcristau> so not hal, and not kernel.
<Alexia_Death> Sorry, I dont have time to take a closer look...  then I assume its X driver and makes the driver insitalize the rest.
<tjaalton> yes
<Alexia_Death> There are tons of things that can go wrong... and how does it know what is pesent for a particular tablet?
<Alexia_Death> and how to name the devices?
<tjaalton> don't ask me :)
<tjaalton> ask peter
<Alexia_Death> oh well... I hope they manage to sell that to ping.
<Alexia_Death> If its good that is.
<tjaalton> there alread was a patch on the list that was supposed to do the same
<tjaalton> but this one is by _the_ X input dude
<Alexia_Death> whot?
<tjaalton> yes
<Alexia_Death> then it has pretty good chances of being good.
<Alexia_Death> doesnet solve it for serial devices tho. they need to be still loaded through dbus.
<tjaalton> fedora's wacom.fdi has some rule for serial devices
<superm1> jcristau, there would have to be support added to that on a driver by driver basis then
<superm1> jcristau, whereas VESA will just work on anything at low res (in  theory)
<jcristau> vesa would probably be easier, yes.  i'm just not sure it's the right thing to do
<tormod> bryce: re bug 335214, how do we flag (bugs that need) cherry-picking upstream commits?
<ubottu> Launchpad bug 335214 in xorg-server "[RV570] devices could not be detected correctly" [Undecided,Confirmed] https://launchpad.net/bugs/335214
<tormod> I think we previously had a list on the wiki, but w.u.c is broken now, so I can't check
 * bryce looks
<bryce> yeah I used to do it in wiki, but nowadays it's easier to just snag the cherries as I see them
<bryce> tormod, so I would be okay with assigning to me and either a) downloading the patch and attaching it to the bug report, or b) putting [patch] in the title.  Whichever is easier
<bryce> assigning to me is optional of course, but it'll add them to my todo list
<bryce> heh @329562.  He could not find lspci-nnv so attached /usr/bin/lspci instead
<tormod> bryce, thanks
#ubuntu-x 2009-03-05
<maco> since this is "-x" not "-x-graphics" that means odd keyboard behaviour goes here?
<bryce> maco: see https://wiki.ubuntu.com/X/Reporting for how to report X bugs
<maco> bryce: what package would it be?  i dont think its xkeyboard-config because i'm not having any trouble setting it to the layout i want or anything like that
<maco> my keyboard just happens to type completely on its own
<bryce> probably the xinput system, so xorg-server
<maco> ok
<maco> thanks
#ubuntu-x 2009-03-06
 * bryce waves to tseliot
<tseliot> hi bryce
<Ng> well that was exciting, hit my brightness up keys a few times, my screen filled with purple garbage and X restarted \o/
<Ng> nothing in Xorg.0.log.old, or /var/crash/ :/
<pcguy11> hello
<pcguy11> can someone please help me with bug 306970?
<ubottu> Launchpad bug 306970 in xserver-xorg-video-i128 "xorg i128_drv.so: undefined symbol xf86usleep" [Undecided,Confirmed] https://launchpad.net/bugs/306970
<pcguy11> hello, anyone here?
<tjaalton> pcguy11: just try jaunty
<pcguy11> I have to stick with intrepid
<tjaalton> then try to build the jaunty version
<pcguy11> can I just install the jaunty i128 driver on intrepid?
<tjaalton> no
<tjaalton> you have to build it
<pcguy11> so I would have to change apt-get to point to jaunty, do a apt-get source xserver-xorg-video-i128
<pcguy11> apt-get build-dep xserver-xorg-video-i128
<pcguy11> right?
<tjaalton> or use pbuilder
<tjaalton> and grab the source pkg files first
<tjaalton> directly from the archive, not with apt
<pcguy11> What is pbuilder?  Can you point me to some documentation please?
<tjaalton> google :)
<tjaalton> I'm not really here
<pcguy11> I will give pbuilder a try.  Thanks
<tjaalton> np
<tjaalton> bbq ->
<superm1> tseliot, ping.  wanted to talk to you about those scripts that are (eventually) going to live to make people's lives sane if they install an nvidia driver that isn't yet packaged
<tseliot> superm1: yes, I haven't worked on them yet
<tseliot> superm1: basically they should remove my packages first
<superm1> tseliot, well i had some ideas for them, did you have a wiki page started?
<tseliot> when users run the nvidia installer
<tseliot> no, not yet. Feel free to create a new one
<superm1> okay well let me pass them by you now at least then and then i can try to transcribe into a wiki page
<superm1> so they should probably also 1) install DKMS
<superm1> 2) register the driver with DKMS (and if possible use DKMS for the first build)
<tseliot> this wasn't the purpose of the helper scripts
<superm1> maybe not the purpose, but can there be an extension to do these types of  things?
<tseliot> basically I talked to Aaron about the problems which are caused when you use his installer and my packages are already installed
<superm1> i guess I don't know the breadth of when these scripts get executed.  I had assumed there was a preinst and postisnt equivalent
<tseliot> think of them as preinst, postinst, prerm, postrm scripts
<tseliot> they cannot change how the installer works
<tseliot> but they can still clear the environment before and after the installation/uninstallation of the driver
<superm1> okay so then for preinst clean up any installed drivers with apt packages
<tseliot> yes, exactly
<superm1> postinst, take the build stuff and register it with dkms
<tseliot> this would conflict with nvidia's current behaviour
<superm1> how do they currently handle upgraded kernels though?
<superm1> I thought you had to rerun the installer for those cases
<tseliot> as the installer builds and installs the module
<tseliot> they don't handle this case
<superm1> that's what I thought; so it might have to be built twice then - once by their installer and once by DKMS
<tseliot> ok but this would require more than just a simple postinst
<superm1> yeah
<superm1> i'm just thinking it's a logical extension if people are going to be wanting to install the drivers from NV and expecting them to work like the drivers in the archive
<tseliot> unfortunately they don't want to put distro-specific stuff in the installer
<superm1> i see.  well then perhaps its worthwhile for them to do something similar to what AMD is doing in their rpm postisnt
<superm1> where they check for if DKMS is installed, they build and register with it, but they don't require it
<superm1> then in the preinst when you remove other packages, you could just add DKMS too?
<superm1> so you wouldn't need any more complicated of a postinst then, and you wouldn't be changing their behavior (they would)
<tseliot> superm1: you can try to ask Aaron via email and CC me
<superm1> well I've got a with our contacts on Monday, so let me mention it there first and see what they say
<tseliot> ok, great
<superm1> i'm not sure how closely tied into aaron's group my contacts are. so maybe they'll just direct me at him
<superm1> thanks tjaalton 
<superm1> oops tseliot 
<tseliot> ?
<superm1> thanks for discussion and what not. i'll let you know what happens
<tseliot>  superm1: ok :-)
<pcguy11> Hi,  I tried the jaunty source code for my i128 video card driver and it still gives me the same error message about AddScreen/ScreenInit failed for driver 0
<pcguy11> see bug #306970
<ubottu> Launchpad bug 306970 in xserver-xorg-video-i128 "xorg i128_drv.so: undefined symbol xf86usleep" [Undecided,Confirmed] https://launchpad.net/bugs/306970
<pcguy11> pastie: hi
<Q-FUNK> howdy
<Q-FUNK> I've got a strange situation here with intrepid where X works but logging into gnome gives us a blank screen.  this is a fresh install.
<Q-FUNK> does it ring any bell?  we already tried removing compiz and that wasn't it
<bryce_> tjaalton: any thing holding us up from rolling out the xserver in git?
<tjaalton> bryce_: nope
<bryce_> tjaalton: ok cool, mind if I upload right now, or would you like to do the honors?
<tjaalton> bryce_: go ahead .)
<tjaalton> :)
<bryce_> (alpha-6 freeze is coming up, so I want to make sure we get stuff in)
<bryce_> ok will do
<bryce_> shall I do libdrm as well, or did you have some plans with that?
<tjaalton> not other than perhaps dropping the nouveau-backport, since it should be included in 2.4.5
<bryce_> is that just a patch?
<tjaalton> yes, IIRC
<bryce_> ok
<tjaalton> in git
<bryce_> is libdrm managed in git?
<tjaalton> yes
<bryce_> oh
<bryce_> ok, I'll give it a poke
<tjaalton> mesa too btw ;)
<bryce_> sigh
<bryce_> right
<tjaalton> not that I've been much help lately
<bryce_> I think I forgot to commit my last change to mesa
<tjaalton> heh
<bryce_> tseliot: btw is the python-randr api code mentioned on https://wiki.ubuntu.com/X/Blueprints/ScreenConfigurationUI available somewhere?
<tseliot> not yet, I haven't touched that code from December
<tseliot> bryce_: I would like to write something in C with dbus so that we can call it from other languages such as python 
<bryce_> tseliot: would you be interested/willing to mentor a GSoC student for this work?  
<bryce_> (if ubuntu does GSoC this year)
<tseliot> bryce_: for which project?
<tseliot> the former?
<bryce_> for the C/dbus work.  Or is that not something you think is appropriate for a student to do?
<tseliot> bryce_: it seems pretty tough for a student, at least IMO
<bryce_> I guess I should back up...  would you be interested in / have time for being a mentor for a student on some X-related project?
<tseliot> bryce_: I don't know how it works and I haven't talked to smagoun yet about what he want me to do. Would it be ok if I gave you a reply next week after I talk to him?
<bryce_> certainly
<tseliot> ok
<tseliot> good night
#ubuntu-x 2009-03-07
<bryce_> tjaalton: you around?  I have a question on doing the xserver merge, if I need to have an orig.tar.gz for it?
<bryce_> tjaalton: nevermind, sorted it out
<ziroday> Hi I'm looking at https://bugs.launchpad.net/ubuntu/+source/hal/+bug/277946 and wondering what more information is needed
<ubottu> Ubuntu bug 277946 in hal "[intrepid] wizardpen tablet wont configure (multiple xinput entries)" [Undecided,New]
#ubuntu-x 2010-03-08
<superm1> hmm radeon KMS appears to not let my second monitor work
<superm1> that's a bit annoying
<tjaalton> superm1: check the new kernel (-16) once it's built
<tjaalton> and pushed out of NEW
<superm1> tjaalton, okay will do
<tjaalton> it has the drm backport, so that ought to help
<tjaalton> maybe together with -ati 6.12.191
<Sarvatt> yay blob broken once again - FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 'rcu_lock_map'
<Sarvatt> they like locking nvidia out some new way every new merge window :)
<libv> and all they do is alienate nvidia users more
<superm1> tseliot, i wanted to ask you what the plan for how remixs/derivatives should be supporting a plymouth theme.  the artsy folks for mythbuntu need to have some sort of idea what they should be targeting
<superm1> it seems silly to produce a whole new theme with all that logic you have in the .script, so just dropping a logo in place seems more ideal
<tseliot> superm1: the idea is to make some packages which will introduce a new logo (and maybe change the writings colour and the background colour) and use alternatives to select the theme
<tseliot> the plan is, of course, to reuse the .script file
<superm1> tseliot, ah yeah, that would work swell.  so target the same resolution as the logo you ship then currently and things should work fine
 * tseliot nods
<superm1> okay i'll feed that back to them, thanks!
<tseliot> np
<mvo> tjaalton: hi, I just finished debugging a odd upgrade issue from a hardy->lucid upgrade and it turns out that xorg read a really old XCF86Config-4 that wants to load i810. should u-m on upgrade remove/move  XF86Config-4 ?
<tjaalton> mvo: oh yes
<mvo> :)
<mvo> ok
 * mvo will add code after lunch
<tjaalton> though it's strange that it would read it, can't find any reference to it
<tjaalton> from the code
<tjaalton> hmm ok, found it
<tjaalton> mvo: or maybe append the name with .obsolete or something
<tjaalton> instead of removing
<mvo> tjaalton: ok, I will do that
<mvo> tjaalton: should I file bugreport about i830 and kernel mode setting failing horrible? or is that HW considered just outdated
<tjaalton> mvo: I think the plan is to make the kernel use !kms on those
<tjaalton> while the driver still supports it
<tjaalton> so the problem should be known already
<tjaalton> apw: ^^
<mvo> tjaalton, apw: ok, thanks. let me know if you need a bugreport about it, i830+kms = blank screen. along the same lines, should "nofb" imply "nomodeset" ? I tried nofb to get a a terminal, but no luck until I discovered nomodeset
<apw> mvo, i assume that you have this issue with the drm33 backport?  
<mvo> (otherwise I'm pretty happy that the "intel" supports my old i830 chip again with a reasonable speed)
<apw> and if so then yes we would want a bug on that
<tjaalton> oh the meta was updated
<apw> tjaalton, litttery just now
<tjaalton> yeah :)
<mvo> apw: this is with whatever is in lucid currently (2.6.32.15.16)
<tjaalton> so it's still the .32 drm, try with -16 which should be available now
<mvo> ok
 * mvo updates
<tjaalton> you probably need to install the new kernel manually until the new linux-meta has been published
<apw> mvo let me know when you have that test result, as if we need to blacklist you you'd be a good test case for the blacklisting support
<bjsnider> Sarvatt, what is that error supposed to mean?
<mvo> apw: ok, so: Linux version 2.6.32-16-generic (buildd@rothera) ; fb0: inteldrmfb frame buffer device ; fb1: VGA16 VGA frame buffer device - blank screen both console and X. so -16 does not fix it for me
<jcristau> ugh.  that's wrong.
<mvo> intel8x0: clocking to 48000
<mvo>  Console: switching to colour frame buffer device 128x48
<jcristau> although maybe fb1 doesn't matter..
<mvo> (rebooting with nofb:) nofb is not honored: "fb0: inteldrmfb frame buffer device"
<mvo> nomodeset makes it happy again
<apw> mvo does blacklisting vga16fb help any?
<mvo> apw: give me a minute
<mvo> bug #534375 - vga16fb I try next, I just did it, but for some reason it loaded it anyway, maybe wrong blacklist file
<ubottu> Launchpad bug 534375 in linux "blank screen with 2.6.32-16 on intel i830 vga" [Undecided,New] https://launchpad.net/bugs/534375
<mvo> apw: no change with blacklisted vga16fb
<tjaalton> it's probably using a wrong output
<apw> mvo, thanks ...
<mvo> tjaalton: interssting, what can I do to control that?
<tjaalton> if X loads and you can hear the login sound
<tjaalton> I'm not sure if you can :)
<mvo> heh :)
<mvo> ok
<apw> sounds like we need a bug ... 
<mvo> when i pass "nomodeset" all is fine
<tjaalton> bug 534375
<ubottu> Launchpad bug 534375 in linux "blank screen with 2.6.32-16 on intel i830 vga" [Undecided,New] https://launchpad.net/bugs/534375
 * mvo boots again now to run apport-collect
<tjaalton> well maybe it just needs a quirk like the ddx driver
<tjaalton> though you'd think those were ported over
<mvo> tjaalton: the xf85EdidModes.c stuff in xserver-xorg-core?
<tjaalton> mvo: no, the ones in -intel
<tjaalton> I believe there are some for 830 chips
<Sarvatt> mvo: http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h=7b9c5abee98c54f85bcc04bd4d7ec8d5094c73f4
<Sarvatt> its just not in linus' tree yet
<tjaalton> heh, that's likely the cause
<Sarvatt> mvo: the symptom in the log is likely the cause he meant, that commit is the fix :)
<tjaalton> right :)
<bjsnider> tseliot, what does jockey mean by saying that nvidia-current is activated but not in use?
<tseliot> bjsnider: maybe that the module is not loaded but the package is installed
<bjsnider> the nvidia driver is loaded
<bjsnider> this guy's system is seriously pooched
<bjsnider> nouveau and vesa are not loaded
<Sarvatt> probably no nvidia xorg.conf in that state
<Sarvatt> if its like my machine when i get in that state :)
<bjsnider> we'll see
<tjaalton> I need to find out why nvidia dkms fails to build here ("make[1]: Makefile: No such file or directory")
<Sarvatt> bjsnider: that error from earlier was because they exported a symbol as GPL only in the 2.6.34 kernel so the nvidia module cant use it, sorry missed the question
<bjsnider> Sarvatt, i don't even know how to respond to that
<bjsnider> what possible justification could there be for doing such a thing? how could that possibly help anything?
<tjaalton> Sarvatt: where did you get that error?
<tjaalton> this thread? http://www.nvnews.net/vbulletin/showthread.php?p=2203489
<mvo> Sarvatt: thanksf for the git link, I'm building a updated kernel now to see if that fixes the problem (will take a while, this is a old machine :)
<Sarvatt> yeah and it was this commit http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f5f654096487c6d526c47bb66308f9de81f091cf
<bjsnider> whose code is it?
<Sarvatt> actually, ya can try a drm-intel-next kernel from the mainline-ppa
<Sarvatt> that commit should be in this one mvo - http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/current/
<mvo> Sarvatt: cool, downloading now
<Sarvatt> i've made 6 bad lid state quirks this past week for people, getting to be a really common problem and I think I convinced the intel guys to add the ignore acpi lid state module option patch upstream eventually so things are at least usable without recompiling a kernel when UMS userland isn't around 
<Sarvatt> we're sticking with 2.9.1 it looks like but we still have it set to KMS only with a configure flag at build time
<Sarvatt> probably better off using vesa any which is what happens with nomodeset anyway on that 830 though :)
<mvo> Sarvatt: no change (with the intrl-drm-next) kernel. well, right. I don't mind how the problem is fixed, I just don't like the regression on lts->lts upgrade, especially since even "recovery mode" will result in this blank screen so a normal (even a technical) user will have a hard time with the bug
<mvo> (also of course this hardware is pretty dated by now)
<zniavre> good afternoon im alwais experienced some nvidia-173 worrie with nvidia-settings it works but there some bugs quite annoying, am i to the good place to ask ?
<zniavre> http://dl.dropbox.com/u/187396/screenshot4.png
<zniavre> always*
<zniavre> i filed a bug report few weeks ago about the same bug , i did what the mainteners ask but it did not solved the nvidia-settings bug 
<zniavre> what should i do ?
<Alice_32> hi does anyone know if is there any chance to get ati card work in lucid>? at the moment im using open source driver and the problem is that it use 50% of my cpu and the catalyst driver doesnt work at all any advice, help?
<Sarvatt> Alice_32: try adding radeon.modeset=0 to your kernel command line
<diverse_izzue> i have trouble with external screens on lucid since kernel -15. kernel -15 didn't boot at all with an external screen connected, kernel -16 boots, but i have a very jittery image. i had seen the same behaviour under karmic if i ran it with a 2.6.33 kernel.
<Sarvatt> hmm so nvidia-settings isn't really backwards compatable at the moment?
<Sarvatt> perhaps that calls for a nvidia-settings-173 and such
<diverse_izzue> Sarvatt, ^^, any idea how to debug?
<tseliot> there is only one nvidia-settings in Ubuntu
<Sarvatt> yeah it doesnt work with 173 apparently from zniavre's comments earlier
<Sarvatt> if it fails to query some extensions the older driver doesnt support its not showing the configuration panel for that section at all it looks like
<Sarvatt> I wonder if we're hitting this in any of our nvidia bugs - http://www.nvnews.net/vbulletin/showthread.php?t=148652
<tseliot> Sarvatt: do we have a bug report about it?
<Sarvatt> especially now that we just reenabled RENDER
<Sarvatt> i dont know, its the type of bug you need to manually check the xorg log to see if an extension was silently not getting enabled
<tjaalton> n-s is open source, so it's fixable
<apw> is it possible to tell under X whether you are running using the emergency fallback X server?
<tseliot> apw: maybe gdm keeps track of this in its logs?
<tseliot> bryceh should know more about this
<apw> tseliot, it seems like something we should get reported by apport if we can tell
<cnd> bryceh: what's the plan for nvidia 195 drivers?
<tseliot> apw: that's a good idea
<tseliot> cnd: we're waiting for news from Nvidia
<cnd> there's a suspend/resume bug that is present in 195, but not 190
<cnd> tseliot: is there an eta on that?
<tseliot> cnd: are you sure that it doesn't depend on the combination kernel/driver?
<cnd> tseliot: the resume bug occurs on the new .33 drm kernel with 195
<cnd> I think any other combo is ok
<tjaalton> the blob doesn't use drm at all
<cnd> tjaalton: yes, but it still seems to cause issues
<tjaalton> cnd: what about mainline 2.6.33?
<tjaalton> cnd: what about mainline 2.6.33?
<Sarvatt> cnd: so it works fine with -15 and not with -16, you're sure of that and can reproduce it?
<bryceh> apw, well it's invoked with an option to use xorg.conf.failsafe and Xorg.failsafe.log, so easy thing would be to look at ps and see if a command with those options is present
<cnd> I just installed the nvidia-current package, but xorg.conf wasn't generated
<cnd> how can I generate it?
<cnd> (this is on lucid)
<jcristau> $EDITOR
<cnd> jcristau: ummm... yeah, I've already done that route, but I don't know what the values should be now
<cnd> is driver still nvidia or nvidia-current
<cnd> neither seems to work for me
<bjsnider> jockey will generate it for you
<cnd> bjsnider: is there a way to invoke that from tty?
<cnd> or do I need to use vesa to get into X to start jockey?
<bjsnider> vesa i assume
<cnd> ahhh, looks like jockey-text may work
<cnd> yep, jockey-text -e xorg:nvidia_current did the trick
<Sarvatt> ack, tickets to brussels for UDS are crazy
<Sarvatt> http://sourceforge.net/mailarchive/forum.php?thread_name=1268030255-13422-1-git-send-email-airlied@gmail.com&forum_name=dri-devel  \o/ \o/
<apw> bryceh, thanks
<Sarvatt> hmm, thinking about redoing ppa-purge as a graphical utility, anyone have any recommendations on where a good place to hook it into an existing package would be instead of making it a standalone app?
<bryceh> Sarvatt, yeah in fact I was thinking of this yesterday
<bryceh> there exists a utility add-apt-repository (installed by default I think??)
<bryceh> I was thinking, "Sarvatt's ppa-purge is sort of like rm-apt-repository - I wish it was included in whatever provides a-a-r"
<Sarvatt> hmmm
<Sarvatt> checking out software-properties now
<Sarvatt> if anyone is using nouveau on edgers -  I'm uploading a lbm-nouveau and it needed alot of work readding nouveau back to it, can ya tell me if it works with the -16 kernel? keep in mind you'll need to blacklist nouveau manually at the moment until I fix that
<mvo> bryceh: that sounds like a good idea (to include rm-apt-repository)
<mvo> Sarvatt: you have a working script for this already (purge-ppa?)
<bryceh> mvo, yeah we've been using it in xorg-edgers for some time now (but it should work well with any arbitrary repo)
<mvo> cool
<mvo> where can I find it?
<mvo> oh, I have it already
 * mvo looks closer
<bryceh> yeah... https://edge.launchpad.net/~xorg-edgers/+archive/ppa/+files/ppa-purge_0.2.6.dsc
<Sarvatt> https://edge.launchpad.net/ppa-purge
<mvo> nice (and a nice idea)
<mvo> I put it on my todo list, I'm about to leave for today (but couldn't resist looking at it :)
<bryceh> :-)
 * mvo waves
<RAOF> bryceh: In ubuntu-x?
<bryceh> sure
<RAOF> Would seem a little bit more on-topic :)
<bryceh> the kernel freeze is coming up thursday
<bryceh> apw is uploading the kernel for that tomorrow morning his time
<bryceh> he wanted to know what to do about the nouveau api bump this go around
<RAOF> I think we sit on the current api.
<tjaalton> upstream is going to stabilize it during the next two months, and call the result 1.0.0
<RAOF> Right, that too.
<bryceh> by current api do you mean not the new api?
<RAOF> And by âstabilizeâ they mean âbreak it again until they're reasonably happy with itâ.
<RAOF> By current api I mean the api we have in lucid at the moment; the 0.0.15 api.
<bryceh> ok good
<RAOF> 0.0.16 looks like it'll be broken within 2 months anyway.
<bryceh> for lack of better info, that's essentially what apw and I decided to do for now
<bryceh> if we wish to change it, it could be changed post-beta1, given archive admin blessing
<RAOF> I don't think we'll want to, but good to know.
<Sarvatt> pretty much guaranteed to be at least 2 api breaks between now and what alot of the devs want to be in 1.0.0, seems pretty solid that they need more than 0.0.16 for 1.0.0 because they are working out how to stabilize it in a way thats compatable with the memory manager rewrite in the ~1 year from now timeframe
<bjsnider> Sarvatt, you're talking about nouveau?
<Sarvatt> theres also the issue of them putting nouveau_class.h into libdrm for some reason but thats not that big of a deal since lucid wont have mesa support.
<Sarvatt> yep
<bjsnider> linus ain't gonna like that
<Sarvatt> nope :)
<Sarvatt> but it looks like by then there will be a generic KMS fallback to guard against these things so you can at least get into X
<RAOF> Well, you can do that now, can't you?  We should be falling back on fbdev to get to X.
<RAOF> (And it worked for me, last time I tried it)
<bryceh> ok yeah this all sounds good to me.  obviously we can't chase upstream forever so if the 16 api isn't likely to be The One, let's not knock ourselves out trying to get it.
<bryceh> if that limits our backporting abilities, well such is life
<apw> bryceh, ... that sounds like a sound position
<bryceh> apw, right on cue :-)
<bryceh> ok sounds like we're decided then
<Landswellsong> Guys, sorry for storming in, does anybody knows if Xorg ubuntu's team accept part time job applications?
<tjaalton> Sarvatt: what do I need to get just the nouveau gallium for lucid? rebuild mesa 7.8 from edgers?
<bryceh> Landswellsong, if you mean canonical, no not to my knowledge
<Landswellsong> bryceh: yep them. so it's fulltime-only?
<bryceh> Landswellsong, *nod*
<Sarvatt> RAOF: afaik if you boot with 0.0.16 api, have libdrm 0.0.15, have nouveau installed compiled against 0.0.15, nouveau is going to try to claim it and fail because of the drm vs things just working in slow mode in the future
<bryceh> Landswellsong, ask canonical hr for a definitive answer; probably depends a bit on the role in question
<Sarvatt> tjaalton: ya need libdrm nouveau a .34 kernel *and* mesa
<Landswellsong> bryceh: are they present on IRC?
<bryceh> Landswellsong, don't think so
<tjaalton> Sarvatt: oh, because of the api bump?
<Sarvatt> yup
<tjaalton> duh
<Landswellsong> bryceh: thanks a lot
<Sarvatt> i put lbm-nouveau with the api bump in the PPA, for now you can just manually blacklist nouveau/rebuild initramfs
<Sarvatt> need to update the ddx in edgers now and add a modprobe conf to blacklist nouveau to it
<Sarvatt> hmm wonder if i should blacklist drm/ttm/drm_kms_helper too
<Sarvatt> naah shouldn't need to, lbm-nouveau should only load the lbm- renamed ones
<BUGabundo> o/
<rye[fixing-x]> hello
<BUGabundo> hey rye[fixing-x]
<rye[fixing-x]> after the latest update I am unable to start my X
<rye[fixing-x]> here's the dmesg - http://paste.ubuntu.com/391310/
<rye[fixing-x]> the first item is that plymouth does not start, afterwards the X session looks extremely strange - green bars only
<rye[fixing-x]> as I understand, there was some change to make nouveau driver the default
<rye[fixing-x]> so I went forward and purged my nvidia modules to make it as clean as possible, and moved xorg.conf to a backup file
<rye[fixing-x]> after this I can see the green bars (previously the screen was shutting down along with the backlight)
 * rye[fixing-x] finished my sad story
<rye[fixing-x]> BUGabundo, are there some related reports of this?
<BUGabundo> rye[fixing-x]: what distro, version , gpu, and drivers?
<BUGabundo> cause if it is lucid with nvidia, just purge plymouth
<rye[fixing-x]> BUGabundo, lucid, nvidia, nouveau drivers (I believe)
<rye[fixing-x]> BUGabundo, so I need to purge plymouth or I can remove splash from boot params?
<BUGabundo> purge it
<Sarvatt> RAOF: this look right? http://pastebin.com/eiA2GkC2
<Sarvatt> and http://pastebin.com/drMm5vVs
<Sarvatt> -16 kernel is in btw, dont we have to remove the lbm dep on the ddx now?
<Sarvatt> going to just have a hard dep on the versioned lbm in edgers I guess
<rye[fixing-x]> no compiz in nouveau, right?
<rye[fixing-x]> BUGabundo, btw, thanks. Removed plymouth and got X back
<BUGabundo> cool
<BUGabundo> you can have 3D with nouveau
<BUGabundo> with the version in xodger ppa
<RAOF> Sarvatt: Yeah, once the -16 kernel is in, pointed at by linux-meta, and mirrored we can drop the lbm dep.
<Sarvatt> its in already, i got it this morning
<Sarvatt> unless that was a new ppa one and i didnt notice..
<Sarvatt> oops, postrm had an error in it, silly mistake
<Sarvatt> ok new ddx uploaded to edgers with the blacklist changes and such
<Sarvatt> both of my nvidia laptops are in use so i cant test any of this out :(
<Sarvatt> btw it might be good to get the word out about the ignorelid module option on nouveau for people having black screen after boot problems
<Sarvatt> on laptops
<BUGabundo> like me ?
<Sarvatt> if you're having that problem with nouveau yeah
<rye[fixing-x]> Sarvatt, and me
<Sarvatt> boot with nouveau.ignorelid=1 with the 2.6.32-16 kernel, or lbm-nouveau.ignorelid=1 with xorg-edgers PPA
<rye[fixing-x]> Sarvatt, additionally, the VTs were unusable so if I had no other laptop then it would take a while to understand what to blame...
<Sarvatt> if it fixes it for you file a bug with dmesg and dmidecode output, subscribe me to it and i'll upstream a quirk for your machine
<rye[fixing-x]> Sarvatt, I got X back when I purged the plymouth, as BUGabundo suggested
<Sarvatt> alrighty, that wasnt the problem then
<rye[fixing-x]> Sarvatt, are lid detection and plymouth connected?
<Sarvatt> nah plymouth has lots of issues right now and its not strange to have it boot up to a blank screen sometimes :D
<rye[fixing-x]> Sarvatt, are there any public announcement that will make sure people with nVidia hw will know that they will not have 3d in Lucid ?
<rye[fixing-x]> including compiz?
<Sarvatt> darnit, looks like I screwed up the lbm-nouveau packaging
<RAOF> rye[fixing-x]: No, but that's because it's the status-quo.
<Sarvatt> ahhh darnit, control.stub.in overwrote the control.stub
<RAOF> rye[fixing-x]: We're expecting users who want 3D to install the proprietary nvidia drivers, just like they do today.  Nouveau is being used as a better -nv.
<Sarvatt> no nouveau for edgers till tomorrow, dont have time to rewrite the control a third time
<rye[fixing-x]> RAOF, so if I got my X broken with the latest upgrades then it was not really intended?
<RAOF> If you got your X broken with the lates upgrades, I'd like you to file a bug!
<rye[fixing-x]> RAOF, here's what I got after reboot- http://paste.ubuntu.com/391310/
<Sarvatt> hmm, not sure what i need to do to make sure the nouveau stuff i add to control and control.stub persists after building the source package..
<rye[fixing-x]> omg... ACPI Warning: _BQC returned an invalid level (20090903/video-631) - not again.... regression in kernel..
<RAOF> Sarvatt: You're after control.stub.in and control.d/flavour-something-or-other
<Sarvatt> your bios is screwed up, probably designed for windows only like most HP's
<rye[fixing-x]> Sarvatt, no, I had this fixed in Karmic, there was a bug in the kernel leading to missing backlight support
<Sarvatt> do you have a platform driver to handle backlight for your machine?
<rye[fixing-x]> Sarvatt, but backlight is working now...
<rye[fixing-x]> omg.
<Sarvatt> like thinkpad-acpi or something
<rye[fixing-x]> Ok, I will try to restore my system to previous state, reproduce the actual failure with nvidia drivers and report if that is reproducible
<Sarvatt> its just a warning, if you have a platform driver handling backlight controls anyway it should be fine
<Sarvatt> RAOF: hmm control.stub.in only has 2 packages in it
<rye[fixing-x]> Sarvatt, frankly speaking, i don't remember the details - bug 428910. Ok, restoring proprietary nvidia drivers
<ubottu> Launchpad bug 428910 in linux "Acer Aspire 5520 has backlight broken in Karmic Koala" [Medium,Fix released] https://launchpad.net/bugs/428910
<Sarvatt> ahah control.d/flavour-control.stub
<Sarvatt> comment #5 in that bug explains the problem pretty clearly
<Sarvatt> hmm did tseliot remove the nouveau blacklist from nvidia-current and replace it with lbm-nouveau?
<RAOF> I thought both were blacklisted.
<RAOF> That could cause some consternation if so!
<Sarvatt> hmm I see it in /etc/modprobe.d/nvidia-graphics-drivers.conf
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/534469
<ubottu> Launchpad bug 534469 in nvidia-graphics-drivers "Failed To Load NVIDIA 195.36.08 Kernel modules" [Undecided,New]
<Sarvatt> its not blacklisted for that person
<rye[fixing-x]> Sarvatt, are you talking about my case?
<Sarvatt> no
<rye[fixing-x]> Sarvatt, i see that something cannot open nvidia-graphics-drivers.conf on boot, btw
<Sarvatt> really?
<rye[fixing-x]> Sarvatt, yes, but the symlink is actually present
<Sarvatt> ugh, dont tell me that update-initramfs doesn't pack .conf's that are links in the initrd
<rye[fixing-x]> Sarvatt, will unpack the initrd now...
<Sarvatt> that'd mean all blob users are broken with the -16 kernel right now
<RAOF> Sarvatt: Yeah.  Are you investigating, or shall I?
<RAOF> Sarvatt: That's the sort of OMG bug that warrants a bit of attention :)
<Sarvatt> it's in my 2.6.32-15 initrd
<Sarvatt> so thats not the problem at least
<rye[fixing-x]> Sarvatt, nvidia-graphics-drivers is a symlink to /etc/alternatives symlink that links to /usr/lib/nvidia-current/modprobe.conf
 * rye[fixing-x] is decompressing my initrd...
<Sarvatt> yep, i was  just worried it wasn't packing symlinks into the initrd but it is
<rye[fixing-x]> Sarvatt, but is it going that deep ?
<Sarvatt> its not a symlink in the initrd
<rye[fixing-x]> true
<Sarvatt> upgrading this machine to -16 now to see if theres anything screwy there
<rye[fixing-x]> Sarvatt, I get 'Failed to open config file nvidia-graphics-drivers.conf: No such file or directory'
<Sarvatt> where?
<rye[fixing-x]> don't see the path though :-/
<Sarvatt> you get that during boot?
<rye[fixing-x]> during the boot procedure right after fsck finishes checking the drives
<rye[fixing-x]> hm... actually during fsck checks the drives...
<Sarvatt> ok thats not good..
<RAOF> Sing out if you'd like some help.
<bjsnider> RAOF is just itching to get in on this one
<rye[fixing-x]> I might have not noticed it earlier because there were no nouveau drivers that could grab the hw w/o the blacklist rules, right?
 * RAOF will be very happy to let Sarvatt handle it while RAOF fixes f-spot mem leaks.
<Sarvatt> there was though, lbm-nouveau but it wasn't in the same directory as the other drivers so it probably got checked to load
<Sarvatt> I don't know whats up RAOF
<Sarvatt> my nvidia box didn't survive a reboot and i'm not at home with it :(
<rye[fixing-x]> Sarvatt, sorry about that :(
<Sarvatt> checked to load after it tried to load nvidia
<Sarvatt> I meant*
<RAOF> Ok.  I'll have a look.
<rye[fixing-x]> hm, if that is in initrd... no, fsck is not finished, so ...
<rye[fixing-x]> hm
<rye[fixing-x]> I have /usr on a separate partition. Assuming that / gets mounted early, with /etc having modprobe symlink pointing to not-yet-existing /usr...
<Sarvatt> changing nvidia-* to install seperate .conf's instead of an alternative is probably what needs to be done
<RAOF> rye[fixing-x]: That's a good thought; we (try to) support /usr on a separate partition, but it's not exactly a common configuration.
<rye[fixing-x]> Sarvatt, let me remove the symlink and make it a proper file...
<Sarvatt> rye[fixing-x]: when you extract your initrd the etc/modprobe.d/nvidia-whatever.conf has the right contents in it?
<Sarvatt> gzip -dc < /boot/initrd.img-2.6.32-16-generic  | cpio -i
<rye[fixing-x]> Sarvatt, yes, the initrd has a regular file, not a symlink 
<Sarvatt> will extract it to the current directory
 * rye[fixing-x] reboots the nVidia box with symlink on the root fs replaced with a normal file
<rye[fixing-x]> Sarvatt, and it workeds
<Sarvatt> you should be able to just manually add a /etc/modprobe.d/blacklist-nouveau.conf with blacklist nouveau in it, sudo update-initramfs -u then reboot to see if that works where the symlink doesnt
<rye[fixing-x]> *worked
<Sarvatt> ah
<rye[fixing-x]> Sarvatt, so that means that everyone with /usr on a separate partition will have such issue with -16
<rye[fixing-x]> Sarvatt, but I still can't understand why it uses the live /, not initrd  one :-/
<Sarvatt> possibly even without /usr seperate which is the worrying thing :(
<Sarvatt> if /usr is on / and / is getting fscked..
<RAOF> I'm rebooting now to check.
#ubuntu-x 2010-03-09
<Sarvatt> sudo tune2fs -C 200 /dev/sdax to force a fsck
<rye[fixing-x]> Sarvatt, the initrd archive contains regular file, hm...
 * rye[fixing-x] has not enough knowledge about the boot process
<Sarvatt> looks like it uses the ones in / by the time it tries to load the video driver from that bugs dmesg and it just packs all the modprobe.d confs in incase any of them are relevant early
<RAOF> So, just a regular reboot worked fine.
<RAOF> I'll force a fsck.
<BUGabundo> great
<BUGabundo> going to a tty, closed my gdm and session :(
<BUGabundo> any logs you guys might find useful ?
<Sarvatt> rye[fixing-x]: was that bug i linked earlier yours?
 * Sarvatt cant load launchpad
<rye[fixing-x]> Sarvatt, erm... what bug? The one with backlight - yes, that was mine, bug 534469 is not mine, but I have the same symptom, I suppose
<ubottu> Launchpad bug 534469 in nvidia-graphics-drivers "Failed to load NVIDIA 195.36.08 kernel modules because nouveau is loading." [Undecided,New] https://launchpad.net/bugs/534469
<Sarvatt> ah ok
<RAOF> Ok.  And booting with a fsck still works.
<rye[fixing-x]> Sarvatt, subscribed to it...
<RAOF> So, it looks like this is only an issue for those with /usr on a separate partition?  In which case, I'm back to f-spot hacking.
 * rye[fixing-x] wants to drop separate partitions, since he has issues with mounted, ureadahead and now with X due to separating of /usr and /var...
<BUGabundo> Sarvatt: RAOF: you guys want my xorg logs? would be nice to see this not happen again :(
<RAOF> BUGabundo: Feel free to file a bug with âubuntu-bug xorgâ; that'll attach everything we'd like, and I go through the nouveau bugs frequently.
<BUGabundo> blob
<BUGabundo> "Please wait while bug data is processed. This page will refresh every 10 seconds until processing is complete." ??
<rye[fixing-x]> Sarvatt, should I as bug Â£534469 about separate /usr or you will do that?
<rye[fixing-x]> awesome, GBr layout makes me mad
<rye[fixing-x]> Sarvatt, bug #534469
<ubottu> Launchpad bug 534469 in nvidia-graphics-drivers "Failed to load NVIDIA 195.36.08 kernel modules because nouveau is loading." [Undecided,New] https://launchpad.net/bugs/534469
<BUGabundo> https://bugs.edge.launchpad.net/ubuntu/+source/xorg/+bug/534755
<ubottu> Launchpad bug 534755 in xorg "gdm/session killed when jumping to TTY" [Undecided,New]
<BUGabundo> RAOF: ^^^
<rye> ok, it is now 2:26 AM here, so I go offline. Will ask OP about separate /usr in case nobody else does in the morning
<rye> good luck and thanks for the help with troubleshooting
<Sarvatt> sorry, in the middle of a bunch of other troubleshooting at the moment, will take a look at it in a bit
<Sarvatt> got an interesting crash resuming with the blob - http://pastebin.com/Ptqia4fi
<Sarvatt> no problem with the blob after 6 boots here, glad its not as bad as it could have been :)
<RAOF> Sarvatt: Yeah.
<RAOF> I didn't particularly want to do any nvidia firefighting today :)
<Sarvatt> maybe we need our systems to boot in 15 seconds like the bug reporter to reproduce :)
<Sarvatt> hmm looks like BUGabundo got the same X segfault resuming with the blob as I did in one of his old logs - http://launchpadlibrarian.net/40541663/GdmLog2.txt
<bjsnider> nvidia released an update to the nv driver
<bjsnider> they added gem, gallium, dri2, vdpau, and full support for all hardware reaching back over 10 years
<superm1> haha
<bjsnider> ok, maybe not
<bjsnider> they added ion support after their usual 5 minutes of work
<bryceh> tjaalton, btw notice some pending stuff for xorg in git; is there a reason this isn't uploaded yet?
<bryceh> tjaalton, and if not, shall I upload it? (I've a fix for apport I'd like to roll out)
<Sarvatt> apw: unfortunately the i915 powersave=0 module option is still needed on my netbook so dont be surprised if you hang after resume with -16
<Sarvatt> the plus side is it no longer flickers constantly with powersave=1 after resume, but it still eventually hangs to a solid color until I suspend/resume again
<Sarvatt> i'm not sure what's up with xorg, tjaalton was pinging you a few days ago saying you needed to import an older release before uploading it I think?
<Sarvatt> [14:40] <tjaalton> bryceh: expect a yet-another merge clash with xorg, since you didn't push the changes :)
<Sarvatt> [14:41] <tjaalton> just the changelog though, as usual
<Sarvatt> [15:46] <tjaalton> hm, need to merge xorg since xorg-dev is uninstallable
<bryceh> yeah pretty sure I fixed that
<bryceh> Sarvatt, still unclear why the git tree isn't pushed... was there an issue with it?
<bryceh> s/pushed/uploaded/
<Sarvatt> checking it out now, had a few problems
<Sarvatt> hmm
<Sarvatt> looks like your failsafe translation stuff got zapped
<Sarvatt> think thats what tjaalton was talking about
<Sarvatt> xgettext -f debian/po-failsafe/POTFILES.in -d failsafexinit -o debian/po-failsafe/failsafexinit.pot -L Shell
<Sarvatt> xgettext: error while opening "debian/po-failsafe/POTFILES.in" for reading: No such file or directory
<Sarvatt> bryceh: xorg git should be all fixed up now
<Sarvatt> forgot to git add the internationalization file before commiting
<Sarvatt> oops, would help if i remembered to enter my pass to push that last one :) now its fixed
<tjaalton> Sarvatt: the Vcs* tags were removed from debian
<tjaalton> and Standards-Version is in the wrong place :)
<tjaalton> bryceh: other than that it's good to go, I was just waiting for other potential fixes
<tjaalton> hmm, it never had any Vcs tags in debian
<tjaalton> so if they were added by us, then ok
<tjaalton> oh yeah, 2009-11-05 Bryce Harrington Add Vcs tags
<Sarvatt> ahh sorry, thanks for fixing it
<Sarvatt> 4 hour queue for the fixed up linux-backports-modules in edgers :(
<RAOF> :(  There goes my quick PPA build of f-spot.
<Sarvatt> anyone else's trackpads get laggy today?
<RAOF> Not mine.
<Sarvatt> ugh, maybe it was the -intel update
<RAOF> Let me flick the stupid switch on my nvidia/intel netbook and check :)
<RAOF> My (now intel) netbook doesn't know anything about laggy trackpads.
<RAOF> Bah!  Stupid IA32-only atom processors.  Who produces a chip that only supports such a register starved, ancient ISA anyway!
<tjaalton> superm1: before I file a bug, do you know why dkms fails to build nvidia when invoked via dpkg-reconfigure, but succeeds when I put the make command in a script?
<superm1> tjaalton, did it fail on first install too?
<tjaalton> the error is "make[1]: Makefile: No such file or directory"
<superm1> and are you seeing this on lucid or karmic?
<tjaalton> both actually, but now using only lucid
<superm1> on karmic i'd expect it was caused by a permissions problem
<superm1> but on lucid everything should be owned by root:root
<tjaalton> it succeeds when the package is installed via preseeding pkgsel/include
<tjaalton> or at least I think it does
<superm1> well that sounds a bit bizarre then
<tjaalton> hum no, it wasn't installed like that
<tjaalton> "make module" does create the Makefile when run by hand or via the script
<tjaalton> but not the dkms way
<superm1> so it sounds like something is wrong in the dkms.conf then for this nvidia driver
<superm1> although i would expect to be hearing a lot more about this then
<superm1> you don't already have a Makefile in /usr/src/nvidia-current-195.36.08$  ?
<tjaalton> yes, but it's cleaned away
<tjaalton> when the dir is copied to /var
<tjaalton> running make creates a symlink to Makefile.kbuild
<tjaalton> make clean removes the file/symlink
<superm1> why would Makefile be cleaned when the dir is copied over though?
<tjaalton> I'll pastebin the shell debug output
<tjaalton> added 'set -x' to dkms
<tjaalton> it does run make clean there
<superm1> but i dont see anything in the clean rule for the Makefile that deletes itself
<tjaalton> but it's in makefile
<superm1> oh i see
<tjaalton> http://pastebin.ubuntu.com/391587/
<tjaalton> so it copies the source and then cleans it :)
<tjaalton> lines 994-1012
<superm1> still sounds to me like a bug in the way the nvidia source is doing it
<superm1> running clean should be safe
<superm1> but i'm baffled still why this would work during the first install then
<tjaalton> yep
<tjaalton> well it didn't, was wrong about that
<superm1> i've got installs here that it has worked on first install and on upgrades though
<superm1> speaking of which, i just did an install of the -16 kernel on a system with nvidia right now, and it DTRT
<superm1> let apport file the bug for you on the failure and attach that set -x run to dkms to the bug too
<tjaalton> this is a slightly modified environment, apport isn't useful there.
<superm1> well then attach everything it would have attached
<tjaalton> ok I will
<superm1> http://paste.ubuntu.com/391604/ yeah, it def still WFM
<tjaalton> superm1: could you get the same output of it (set -x), so I could compare them?
<superm1> tjaalton, in /usr/sbin/dkms?
<tjaalton> superm1: yep
<superm1> http://pastebin.com/Mf6AC8iY tjaalton 
<tjaalton> hrm, I did a rollback of all the custom settings and reinstalled the package, and it built fine
<superm1> oh dang, that didnt capture it
<tjaalton> I can't think of anything that would conflict with this though
<tjaalton> there's only one make etc
<superm1> what were you customizing?
<tjaalton> well some shell settings might have something to do with it
<tjaalton> there are lots of changed configs etc, for the uni environment
<tjaalton> or perhaps just that I logged in from the console, and not via sudo
<superm1> its quite possible that some variables need to be unset for DKMS that aren't being unset then
<tjaalton> hmm I can get the output here
<superm1> it wouldnt be the first bug that came up from an unsanitary environment at least
<tjaalton> ok, I'll dig something out of this :)
<tjaalton> noticed that there are a bunch of variables being unset in dkms
<superm1> yeah, quite possible there needs to be more unset
<tjaalton> though why does it succeed when run by hand, hmm..
<tjaalton> anyway, thanks so far
<tjaalton> superm1: found it, unsetting ARCH made it work
<tjaalton> don't know why we set that
<bdrung> has someone time to sponsor bug #534026?
<ubottu> Launchpad bug 534026 in xserver-xorg-video-ati "Please merge xserver-xorg-video-ati 1:6.12.191-1 (main) from Debian experimental (main)." [Undecided,Confirmed] https://launchpad.net/bugs/534026
<tjaalton> we are past FF, so it probably needs an exception
<tjaalton> oh it's approved already
<tjaalton> he
<tjaalton> *eh
<tjaalton> don't change the packaging
<tjaalton> check how other packages enable the patchsystem
<tjaalton> synaptics for instance, they all are basically the same
<jcristau> debian/README.source should have explanations how to enable the patch system
<tjaalton> right
<bdrung> debian/README.source is not very helpful. the debian maintainers remove all quilt invocation from their rule file.
<bdrung> i know, that we shouldn't change the packaging, but in my opinion using 3.0 (quilt) is better than hacking debian/rules. the debian maintainers prefer quilt. So this is not the issue.
<bdrung> tjaalton: ^
<tjaalton> bdrung: I don't understand... debian/rules already had everything set up for patching
<tjaalton> changing the source package format is way bigger than keeping the rules diff
<bdrung> tjaalton: http://launchpadlibrarian.net/40489726/xserver-xorg-video-ati_6.12.191-1ubuntu1-v2.patch
<tjaalton> well, philosophically anyway :)
<bdrung> yes
<bdrung> tjaalton: i can convert the debdiff if you insist on not using 3.0 (quilt)
<jcristau> 3.0 (quilt) is unusable
<tjaalton> bdrung: perhaps wait until bryceh chimes in
<jcristau> bdrung: enabling the patch system is not "hacking debian/rules", and it's 2 lines in the debdiff instead of a complete revamp of the package
<bdrung_> tjaalton, jcristau: i updated the patch for bug #534026 to make you happy. ;)
<ubottu> Launchpad bug 534026 in xserver-xorg-video-ati "Please merge xserver-xorg-video-ati 1:6.12.191-1 (main) from Debian experimental (main)." [Undecided,Confirmed] https://launchpad.net/bugs/534026
<jcristau> bdrung_: ta
<bdrung_> jcristau: ta?
<jcristau> thank you
<bdrung_> jcristau: for what does the a stand in ta?
<jcristau> http://www.urbandictionary.com/define.php?term=TA :)
<bdrung_> interesting
<tjaalton> bdrung_: thanks, replied
<bdrung_> tjaalton: thanks. what does the ACK mean? wouldn't uploading it instead of acknowledging it the right thing to do?
<tjaalton> bdrung_: I'd like to hear what bryceh thinks
<superm1> tjaalton, okay file a DKMS bug to add it to the unset list too then
<tjaalton> superm1: done, bug 534986
<ubottu> Launchpad bug 534986 in dkms "please unset ARCH in /usr/sbin/dkms" [Undecided,New] https://launchpad.net/bugs/534986
<apw> bryceh, does switching away from and back to VT-7 work for you with an updated system?
<apw> actually scratch that, bryceh does your X end up on VT-8 now?
 * apw has a drm:drm_mode_getfb error on VT-7, and X is on 8 ... oddness
<bryceh> apw, what's odd is I do have some systems on VT8, and others on VT7
<bryceh> it's not consistent
<apw> and now i have the feeling something odd happened during boot ... somethign i'd not twigged about
<bryceh> also I do see a myriad number of issues related to vt switching
<bryceh> probably all unrelated
<apw> i got a modeset between plymouth and gdm which i shouldn't
<apw> i suspect it started on 7 blew up, and restarted on 8
<bryceh> I had a system where vt switching did not work at all, because plymouth was not installed; after installing it, it worked again
<apw> wibble
<bryceh> apw, there seem to be a set of pretty severe interactions between plymouth and X
<bryceh> esp. related to vt switching - see the bugs filed in the plymouth bug tracker
<apw> very strange, i presume keybuk is looking at plymouth at the mo
<superm1> and i assume it's those same interactions to blame for why enter is killing X sometimes?
<apw> superm1, i am starting to feel its when you don't have KMS you get that behaviour
<apw> that always first return fecks you
<apw> but i've not done any sort of repeated test to confirm
<superm1> apw, i've had it happen with KMS working
<superm1> well "working"
<apw> its perfect, wonderful, you cannot see any issues
<bryceh> superm1, that's right
<superm1> i have problems where the second monitor doesn't work once X starts
<bryceh> superm1, bug 532047
<ubottu> Launchpad bug 532047 in plymouth "Plymouth text-mode splash causes X to crash on first run due to shared tty7" [High,In progress] https://launchpad.net/bugs/532047
<apw> superm1, which version have you tested kernel wise
<superm1> apw, -15 and the -16 that just hit the archive
<superm1> i just updated hardy->lucid the other day
<apw> so -16 is as bad, boo
<bryceh> superm1, basically, while X is showing the login screen plymouth is displaying some confirmation dialog behind the scenes and waiting for user input.  If the user hits enter or '2', plymouth sends X a SIGQUIT
<apw> bryceh, yay for plymouth
<bryceh> yeah
<superm1> I thought gdm requests plymouth to quit though?
<jcristau> superm1: seems to be full of races..
<bryceh> superm1, the bug had been believed fixed at one point but users are definitely still reproducing it on latest bits, so dunno
<Sarvatt> the problem is that plymouth is leaving the signal handler active on its console X is starting on and it just so happens that both the 2 or enter keycodes are quit key sequences, first time they are hit after it happens gdm restarts X on VT8 and its fine after that
<Sarvatt> you should be able to add a stty -F /dev/tty7 -isig somewhere in the gdm startup scripts to work around it
<apw> bryceh, do we yet have any known bad cards which need blacklisting.  i have preliminary blacklisting code which could do with a test
<apw> (for kms)
<bryceh> apw, yeah jdstrand would be a good test case
<bryceh> he's quite motivated to seeing the issue he saw resolved and has been quite active at helping do testing for us
<apw> bryceh, sounds good ... i hear he is doing some testing for manjo right now, once he has those results i'll ask him for his ids
<Sarvatt> shoot, looks like a bunch of stuff I said got dropped
<Sarvatt> <Sarvatt> bryceh, apw: any ideas on ways to add chipset detection logic to i915 to selectively set the default module options for certain cards? a way to set powersave=0 default for 945 and modeset=0 for 8xx would help a lot since 965+ doesn't need powersave=0 and such
<Sarvatt> <Sarvatt> 8xx seems to be just as buggy with UMS as KMS from what I can see, just in different ways.. It's working with modeset=0 for a lot of people as a side effect of us explicitly disabling UMS support in intel so vesa is used
<Sarvatt> <Sarvatt> and if we're sticking with --kms-only on 2.9.1 theres not much reason not to update to 2.10.x imo
<Sarvatt> but sounds like you guys were already talking about it while i was disconnected :)
<apw> Sarvatt, i have patches which currently would allow a change of options, they currently only change modeset
<apw> it would be no real difficulty to go one step further
<Sarvatt> changing powersave=0 just for 945 would be nice, the 965+ bugs with it seem to be fixed
<jcristau> my 945gm seems happy enough with powersave now
<apw> the change of powersave sounds like somethign which should just be turned off for those cards in the driver itself
<Sarvatt> have you suspended and used the machine more than 30 minutes after resuming?
<apw> rahter than overriding the module parameters
<bryceh> Sarvatt, I'm going to drop the --kms-only bit
<jcristau> Sarvatt: ah, no, i haven't used suspend
<apw> yeah suspend is always a pig
<Sarvatt> thats where the problem is, it hangs to a black screen with 100% gpu usage in framebuffer compression after resume and another suspend/resume cycle fixes it until it happens again
<jcristau> ok
<apw> yeah that one was a swine to find last time, is it back in the drm .33 backport they
<jcristau> do you know the fdo bug number for that off-hand?
<apw> then
<Sarvatt> i've been just dealing with it and suspending/resuming again to fix it for the power savings though :D
<apw> heh that was a world of pain
<apw> so Sarvatt i think the powersave thing may need doing a more sane way
<Sarvatt> jcristau: one sec, i'll dig some up but i'm in the middle of formatting a pixman patch to submit upstream for arm simd detection problems with our toolchain
<jcristau> Sarvatt: yeah no hurry, thanks
<apw> using the driver flags themselves so if you could email me with a list of the cards which are bust, i915 and !945+ or whatever it is and we'll see about fixing it properly
<apw> Sarvatt, actually lets file a bug on it a nice clean generic bug on the kernel asking for it disabled for them, and assign it to me
<Sarvatt> jcristau: https://bugs.freedesktop.org/show_bug.cgi?id=26594  (marked fixed but its only fixed by the reporter using powersave=0..) http://bugzilla.kernel.org/show_bug.cgi?id=14781 (lots of me-too's from 945 with the seperate issue from the original reporter..)
<ubottu> Freedesktop bug 26594 in DRM/Intel "[945GM] Screen corruption and flickering" [Normal,New]
<Sarvatt> seems like those are the only two i have bookmarked, i subscribed to other ones and they are somewhere in my mailbox so they will take some digging
<jcristau> hrm not much activity on that fdo bug
<Sarvatt> darnit, I need to get my butt in gear and put in a resume to you guys so I can have time to do all of this stuff instead of doing it while sitting in traffic all day between jobs :)
<bryceh> heh
<Sarvatt> ah hah
<Sarvatt> jcristau: https://bugs.freedesktop.org/show_bug.cgi?id=26266
<ubottu> Freedesktop bug 26266 in Driver/intel "Screen lockup some time after wakeup from standby (to ram)" [Critical,Assigned]
<jcristau> Sarvatt: ah thanks, i'll ping this
<bryceh> morning RAOF
<RAOF> bryceh: Good morning.
<RAOF> Why don't I ever run into these bugs first? :/
<bryceh> RAOF, I know, I ask myself that a lot 
<bryceh> insufficient time usually
<Sarvatt> hmm, with these new launchpad dialogues do debdiff's count as patches?
<Sarvatt> This file does not look like a patch.
<Sarvatt> ah well I'll just say yes anyway :)
<bryceh> debdiffs do count as patches
<bryceh> really launchpad should distinguish between regular patches and debdiffs better, but it doesn't
<bryceh> tjaalton, I've uploaded xorg with the fix for the intel apport script.  Geir will probably appreciate it
<tjaalton> bryceh: ok good, don't forget to push :)
<bryceh> oh yeah
<tjaalton> bryceh: btw, did you see that bdrung merged -ati?
<tjaalton> waiting for upload
<bryceh> yeah working on it next in fact
<tjaalton> ok
<bryceh> it's fine by me, I've just been swamped with other stuff
<bryceh> thanks for reviewing and mentoring ben
<tjaalton> np
<bryceh> -ati uploaded
<RAOF> bryceh: I'm cleaning up nouveau DDX; I'll have a package in git soon for you to sponsor, if you could.
<bryceh> RAOF, great, I'll be ready
<bdrung> bryceh: debuild -S -sa
<bryceh> dah
<ibkanat> >	anyone have tips on getting a tablet to work with ubuntu 10.4? I followed https://help.ubuntu.com/community/AiptekTablet but didnt work
<bdrung> bryceh: thanks for sponsoring
<bryceh> bdrung, thanks for doing the merge!  It xx'd out two items from my todo list :-)
<bdrung> :)
<bryceh> (technically I think we needed a FFe for updating -ati, but since we're still pre-beta I think we can handwave through it and beg forgiveness if anyone complains)
<bdrung> bryceh: we have a FFe for it
<bryceh> bdrung, ah then excellent.  
<bryceh> bdrung, will that cover to upgrade to 6.13 when its out?
<bdrung> bryceh: bug #534026 comment 5
<ubottu> Launchpad bug 534026 in xserver-xorg-video-ati "Please merge xserver-xorg-video-ati 1:6.12.191-1 (main) from Debian experimental (main)." [High,Fix released] https://launchpad.net/bugs/534026
<bdrung> bryceh: probably not, but i assume that an upgrade request will be granted
<bryceh> ok
<Sarvatt> \o/ https://wiki.ubuntu.com/X/Tagging -- I didn't know that existed and was just about to ask if you had a list bryce :)
<bryceh> Sarvatt, :-)
<bryceh> Sarvatt, ah didn't know it wasn't common knowledge, yes it's quite good
<bryceh> Sarvatt, also if you don't know about this report, you might like it as it goes along with that page nicely:  http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/symptoms_intel.html
<bryceh> Sarvatt, that's a report showing the symptoms for bugs in a sortable column, limited to ones tagged 'lucid' (so you don't have to troll through ones against karmic that haven't been re-tested yet)
<bryceh> Sarvatt, that report is a good way to spot dupes
<Sarvatt> my bug work would be a *heck* of alot more productive if I could figure out how to mass search attached logs on bug reports. I usually spend most of my free time keeping up to date with mailing lists and git logs and every day I find myself trying to find errors strings that aren't in the bug reports so I have to resort to searching for symptoms and wasting time trying to see if its the one thats fixed
<Sarvatt> almost wish you could get attachments sent in bug mails though i'd need 10 gmail accounts then :)
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel?field.searchtext=GPU+lockup&orderby=-importance&search=Search&field.status:list=NEW&field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=INCOMPLETE_WITHOUT_RESPONSE&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.status:list=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_pack
<Sarvatt> age=
<Sarvatt> 845 and 855 have major problems for sure
<BUGabundo> Sarvatt: ahaha
<Sarvatt> oops too long for one line
<Sarvatt> thats like not even a week's worth of bugs and 845/855 is dominating it
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel?field.searchtext=GPU+lockup
<Sarvatt> there we go
<bryceh> Sarvatt, arsenal has some stuff to help do searches on attachments
<bryceh> Sarvatt, if you grab the arsenal code I can help show you how to craft tools to search log files
<Sarvatt> most of the 8xx bugs seem to be page table error hangs
<BUGabundo> for a moment I though you meant the english team that beat my FCPorto tonight 
<Sarvatt> including the EIR: xxxxxxxxx line from i915_error_state in the bug description would be nice
<bryceh> Sarvatt, I may be able to do that in the apport script
<bryceh> I need to look into what Geir's been doing with the reports; I think there's fair room for more automation
<Sarvatt> checking out arsenal now, proposed a merge with a change to the README to point at the new Template-Python svn address
<bryceh> great
<RAOF> bryceh: pkg-xorg git has xserver-xorg-video-nouveau update in it.
<bryceh> RAOF, ok on it
<Sarvatt> looks pretty straight forward
<Sarvatt> yeah process-xorg-retargeting.py needs some fixing up for nvidia from what I see, it's retargetting nvidia-graphics-drivers bugs on lucid to nvidia-graphics-drivers-180
<bryceh> RAOF, uploaded
<RAOF> bryceh: Danke.
<bryceh> Sarvatt, true
<bryceh> Sarvatt, bzr pull and check again
<Sarvatt> i'm going to need to set up a private launchpad instance to mess with these scripts I guess :)
<Sarvatt> oh dang, I was behind a few days
<bryceh> Sarvatt, nah, many of the scripts include a dry_run bool you can set so you can run them without causing changes
<bryceh> those that don't have that probably should
#ubuntu-x 2010-03-10
<bryceh> Sarvatt, re: arsenal script to transition nvidia-180 tasks to nvidia-gfx-drivers... sweetness
<Sarvatt> pushed it here - https://code.edge.launchpad.net/~sarvatt/arsenal/working
<Sarvatt> verified the first 10 it hit were all correct on the dry run, running it for real now :D
 * bryceh currently working on script to make a report of lucid bugs with upstream tasks and the upstream status of the bug
<Sarvatt> man, this makes thing a breeze
<bryceh> yep
<Sarvatt> do one of these grok the xorg logs for backtraces and put it in the description?
<bryceh> no, but that could be done
<bryceh> I've got some code about halfway done which identifies backtraces, and the pci-extract.py script is an example of pulling data from attachments and putting it into the description
<bryceh> see starting at around line 321 of arsenal_lib.py, that has some routines for doing stuff with backtraces
<bryceh> I've also got a script xparselog around somewhere which parses Xorg.0.log files.  Don't think it extracts backtraces but probably could.  It's perl though so needs reimplemented in python
<bryceh> xlogparse
<bryceh> there's a copy of it in xorg-pkg-tools
<Sarvatt> sweet, I'll look into extending it for what I have in mind in the future then. i'd like to dump info on backtraces and assertions, put them in the description, and have a dupe-o-matic script that'll dupe based off of those strings if you pass it a target bug number
<bryceh> great idea
<Sarvatt> like there are probably 50 or more bugs right now against nvidia with the same backtrace and the symptoms arent easy to tell its a dupe from the description
<bryceh> I think the apport crash bugs are structured well enough that the traces should be machine readable and should be straightforward to do
<bryceh> yep
<Sarvatt> segfault on resume ones with nvidia-current on lucid
<Sarvatt> and karmic for people with PPA versions (which is probably the majority of karmic nvidia users)
<Sarvatt> backtrace looks like this for everyone http://paste.ubuntu.com/392187/
<RAOF> Is there a way to make apport report bugs against PPA packages?
<Sarvatt> people describe it so many different ways, its way too much effort to manually dupe them all
<bjsnider> i think it does
<bryceh> Sarvatt, yeah
<Sarvatt> black screen on resume, suspend doesn't work, X stuck on a black screen, my kittens hit the power button
<bryceh> Sarvatt, yeah that looks quite familiar
<RAOF> bjsnider: Really?  When did that happen?
<bryceh> btw just pushed a script 'retest.py' - this is an example script I used to ask people to retest with the new drm
<bjsnider> some guy managed to report a bug on a package in one of my ppas
<bryceh> I have to recode it every time I use it for whatever I need, but that's a lot easier than manually going through all the bugs individually
<bjsnider> no idea how he did it
 * RAOF tests.
<RAOF> bjsnider: Doesn't work for me.
<bjsnider> i might be able to track the bug he reported down, so maybe you can figure out how he did it
<Sarvatt> it rejects it if the bug is filed against a PPA version doesn't it?
<RAOF> Right. âNot a genuine Ubuntu packageâ.
<Sarvatt> ..which doesn't mean much with things going to the catchall xorg
<RAOF> Sarvatt: Oooh, sneaky.
<RAOF> Right.  That will work.
<Sarvatt> dang bryceh, arsenal is going to suck my life away :)
<bryceh> :-)
<bryceh> Sarvatt, if you get to a point with a script where it'd be useful to run regularly, I can add it to my cron to run it hourly/daily/weekly with the other scripts
<bryceh> that gets some life back :-)
<bjsnider> RAOF, it won't show me bugs i subscribed to when they're closed
<bjsnider> so i can't find it
 * RAOF is going to have to set aside a day or two to work out exactly how arsenal works.
<superm1> RAOF, i've got something set up for mythtv that files bugs for PPA packages
<superm1> other MOTU's said it's better not to file them into ubuntu though, but rather use a different project
<superm1> so that's what we do for mythtv
<bryceh> not a bad idea
<Sarvatt> yeah I noticed some random person invalidating bugs we actually requested to be filed against apw's ppa with the drm kernels
<RAOF> Particularly since we've got a nouveau project just sitting around in launchpad...
<superm1> http://pastebin.com/dHRhrdSR
<superm1> basically if it's not a distro package, you set the crashdb accordingly
<RAOF> Aaah, *that's* where I've seen it before :)
<superm1> and here's the crashdb setup stuff http://pastebin.com/95fwzpkk
<Sarvatt> with X stuff its getting filed straight to xorg which isn't a PPA version though
<RAOF> That might be worth setting up at some point.  For now, both ubuntu-bug and apport-collect will work for nouveau packages in the xorg-edgers/nouveau PPA as long as it gets run as âubuntu-bug xorgâ.
<Sarvatt> my wife is not a happy camper about not being able to come to brussels if I go to UDS :) airfare is ridiculous.
<bjsnider> put her in a piece of luggage
<bjsnider> that's my brilliant solution
<RAOF> Ok.  Lunch time.
<bjsnider> somebody needs to invent star trek-y transporters
<bryceh> heh, the hotel costs might dwarf the airfare even still
<DanaG> https://bugs.launchpad.net/bugs/534677
<ubottu> Launchpad bug 534677 in xserver-xorg-video-ati "[lucid] Broken backlight control with Radeon open-source drivers" [Undecided,New]
<DanaG> hmm, is xorg-edgers supposed to support "BACKLIGHT" property in xrandr?
<tjaalton> RAOF: why not advice people to run 'ubuntu-bug xserver-xorg-video-nouveau' instead?
<tjaalton> it'll collect the same information, and save developer time when there's less need to move bugs around
<RAOF> tjaalton: Because (1) bryce has found that people get confused, and advises just xorg, (2) if they choose to do the extra work and install the upstream nouveau packages they can't run ubuntu-bug xserver-xorg-video-nouveau.
<tjaalton> why (2)? it doesn't matter what the version is
<tjaalton> the apport links are installed by x11-common
<RAOF> tjaalton: But if they run ubuntu-bug x-x-v-nouveau, and x-x-v-nouveau is not an archive package, apport will bail.
<tjaalton> oh boo
<RAOF> Right.
<RAOF> Otherwise I would have, yes.
<tjaalton> ok
<LLStarks> bryceh, does fglrx support kms?
<tjaalton> LLStarks: no
<tjaalton> it doesn't even support the xserver in lucid
<LLStarks> what about that custom build we dry-humped amd for?
<tjaalton> still, if it takes more than six months to support the server abi, they surely won't support kms
<LLStarks> http://www.phoronix.com/scan.php?page=news_item&px=ODA1Mw
<LLStarks> bryceh...
<LLStarks> >__<
<tjaalton> eh?
<tjaalton> 2.10 doesn't support ums
<LLStarks> usermode is old hat.
<tjaalton> so 8xx users would be sad if we went to 2.10
<tjaalton> so use kms and be happy
<LLStarks> so, what happens for mystic?
<LLStarks> drop i810?
<tjaalton> if you mean the driver it's long gone
<LLStarks> really? i wouldn't be able to run lucid on an i810e?
<tjaalton> no, -intel supports it, somewhat
<LLStarks> so, by october, ums will be dropped entirely and the legacy quirks will be hammered out so they can support kms?
<tjaalton> maybe
<LLStarks> is edgers ready for tearless playback or is kernel work needed?
<tjaalton> no idea
<LLStarks> aside from that, i consider the i945 drivers perfect. you guys do amazing work.
<LLStarks> jeez. nouveau and gallium are moving so fast.
<LLStarks> i wouldn't be surprised if 3d performance makes exponential gains this year.
<tjaalton> i heard it would need a rewrite of the memory manager, so probably not this year
<bryceh> tjaalton, I've got code which can fairly reliably sort out moving bugs from xorg to the right video driver
<tjaalton> bryceh: ok, good
<bryceh> tjaalton, it's less reliable for bugs about input devices, but should be just fine for -nouveau
<bryceh> I used to think we should educate everyone on what the right package to file against, but then I saw no one every got it right anyway.
<bryceh> I figured I could write a crappy script which would do it better than the average bug reporter
<bryceh> and so here we are ;-)
<tjaalton> heh, alright
<tseliot> hyperair: are you around?
<hyperair> yes?
 * hyperair makes some noise so tseliot notices him
<bryceh> hi tseliot
<tseliot> hi bryceh
<tseliot> hyperair: so, about bug #248392
<ubottu> Launchpad bug 248392 in ia32-libs "32bit libgl search for dri at wrong place on 64bit system" [Low,Confirmed] https://launchpad.net/bugs/248392
<hyperair> yes?
<hyperair> wait, you mean it's still not fixed?
<tseliot> hyperair: wouldn't it be enough if I simply set --with-dri-searchpath=/usr/lib/dri:/usr/lib32/dri/ on 64bit?
<hyperair> tseliot: that would work, i suppose.
<tseliot> hyperair: what happens if one of those paths doesn't exist?
<hyperair> tseliot: but you'd have to correctly detect 64-bit in debian/rules.
<hyperair> tseliot: it falls back to the next path.
<hyperair> tseliot: it's similar to PATH
<hyperair> i think there was some environment variable that does the same thing
<tseliot> hyperair: ok, I wanted to be sure
<hyperair> LIBGL_SEARCH_PATH or something
<hyperair> that is used if set, and if not, the value from --with-dri-searchpath is used.
<hyperair> after that the code is the same.
<tseliot> hyperair: as regards detecting 64 bit archs I would simply do: ifeq ($(DEB_BUILD_ARCH),amd64)
<hyperair> tseliot: amd64 isn't our only 64-bit arch, is it?
<hyperair> there's ia64..
<tseliot> do we still support that?
<hyperair> don't we?
<hyperair> our buildds build that don't they?
<tseliot> well, yes but that doesn't mean that it's supported
<hyperair> so you're going to just leave it broken?
<tseliot> see, ia32-libs for example didn't even build on ia64: https://launchpad.net/ubuntu/+source/ia32-libs
<hyperair> meh
<jcristau> err.
<tseliot> it's not my call and I don't have the hardware anyway
<jcristau> the search path you want to change is in the i386 packages anyway
<jcristau> the native packages work fine
<bryceh> ia64 is not supported, and not something we care about.
 * hyperair sighs. okay then
<hyperair> do what you wish. i don't mind, as long as amd64 works at the end of the day
<tseliot> jcristau: right. Adding --with-dri-searchpath=/usr/lib/dri:/usr/lib32/dri/ should fix it
<jcristau> tseliot: adding that to the i386 package.  not the amd64/ia64 ones.
<tseliot> jcristau: would 64bit mesa really use 32bit binaries?
<tseliot> if I added that?
<jcristau> wtf
<tseliot> hehe
<jcristau> the point is to let 32bit mesa load 32bit drivers
<jcristau> you're making me sad
<tseliot> yes, I know
<tseliot> I'll try to entertain you if you like :-P
<hyperair> tseliot: so, which package do you intend to do --with-dri-searchpath for?
<hyperair> tseliot: the 32-bit, or the 64-bit one?
<hyperair> tseliot: it won't work with the 64-bit one, and with the 32-bit one, it'll fallback to looking in /usr/lib32 which is fine i suppose.
<tseliot> hyperair: I was planning on updating mesa 32 bit and on refreshing ia32-libs so that the fix gets in
<hyperair> tseliot: that sounds fine to me
<tseliot> ok
<hyperair> at least, i don't see any potential breakage from what you're doing (it's not so different from what i'm doing, from the mesa point of view)
<hyperair> but really, when is our multiarch support going to improve?
<tseliot> I'll test it here
<hyperair> ia32-libs is a wild hack
<tseliot> in lucid +1 I guess
<jcristau> ha.
<jcristau> in $something + 1
<hyperair> ...
<tseliot> I'm not the right person to ask
<hyperair> i'm willing to bet lucid+1 will *not* get improved multiarch support
<hyperair> nor will lucid+2
<hyperair> anyway i've got to run
 * hyperair brb in 15 minutes or so
<bryceh> tseliot, heya, how's things going?
<bryceh> tseliot, do you expect to be coming to UDS Brussels?
<tseliot> bryceh: not so bad, last night upstream gave me some tips on plymouth (to add the support for 16 colours) :-)
<tseliot> bryceh: sure, I'll be there
<bryceh> excellent :-)
<tseliot> bryceh: how are things going for you?
<bryceh> tseliot, glad you're focused on plymouth.  Seems it needs much TLC.
 * tseliot nods
<bryceh> tseliot, busy as always, but going good.  Glad we have raof on board.
<tseliot> :-)
<bryceh> tseliot, at the moment I'm brainstorming ideas for topics to discuss at UDS
<bryceh> any requests?
<tseliot> bryceh: maybe support for touchscreens ;) ?
<bryceh> so far got:  X.org general session; Wayland ; Rootless-X ; Multitouch ; X-freeze apport hooks ; X.org Hardware Workshop
<tseliot> oh, it's there already
<tseliot> I'll let you know if something else comes to my mind
<bryceh> ok cool
<bryceh> 6 sessions should be plenty
 * tseliot nods
<bryceh> feel like I'm missing something obvious though.  But guess there's plenty of time still to think of it.
<tseliot> right, we have time
<tjaalton> btw, evtouch could be synced from debian
<tjaalton> builds against 1.7
<tjaalton> tseliot: are you planning to move the mesa libGL back to /usr/lib?
<tjaalton> for lucid
<tseliot> tjaalton: hmm... I haven't decided yet. I think it would be safer not to do it at this point
<tjaalton> I'm thinking that it would be worse to have a LTS with it, at least if it's known to be temporary
<bryceh> tjaalton, feel free to file a sync request if you'd like; otherwise it's already on my todo list just haven't gotten to it
<bryceh> tjaalton, it looked like maybe it needed merging, but I didn't look close
<tjaalton> well, the changes were to the fdi file, dunno if they should be moved to the udev rule or not
<bryceh> tjaalton, btw my merges page is going to be stuck on march 5th for a bit.  Gotta reincarnate a chroot before I can get that functioning again
<tjaalton> bryceh: heh, so it seems
<tjaalton> I guess ogra doesn't work on the touchscreens anymore, or evdev is enough for him?-)
<bryceh> he does not work on them anymore
<bryceh> I think it's more a case of frustration than of being satisfied with alternatives
<tseliot> :-)
<bryceh> but we did manage to get good braindumps from him into one of the blueprints last uds
<bryceh> there is a ton beyond just X that needs worked to get touchscreen support up to snuff
<bryceh> but plenty to do just within X even still
<bryceh> tjaalton, fwiw shuttleworth has just recently developed a very strong interest in touchscreen support
<bryceh> (I gather he's just purchased his first touchscreen hardware)
<tjaalton> heh, ok
<tjaalton> upstream is working on multitouch
<tjaalton> wacom has some temporary hacks, but they won't live for long
<bryceh> I've got one of the proposed -evdev patches in my queue to look into more
<tjaalton> the kvm one?
<bryceh> no the multitouch one
<tjaalton> ah
<bryceh> by benjamin
<bryceh> got a lot of discussion on xorg-devel, sounds like it'll probably get reimplemented completely before its through, but sounds like it basically works
<bryceh> I've got a meeting thursday with some of the oem folks to determine what we want to do for lucid
<tjaalton> ok, so it's not the one on bug 379313 :)
<ubottu> Launchpad bug 379313 in xserver-xorg-input-evdev "Handling NextWindow Touchscreen (multitouch)" [Medium,Incomplete] https://launchpad.net/bugs/379313
<bryceh> no, but that one looks like something we could consider including
<bryceh> tjaalton, I put my notes at https://wiki.ubuntu.com/X/Blueprints/Multitouch
<bryceh> the particular hw we're looking at is N-Trig but really we'd want touchscreen support across a pretty broad range of hw
<tseliot> Stantum or 3M should be more Linux friendly: http://www.lii-enac.fr/en/projects/shareit/multitouch-devices.html
<tseliot> (no firmware issues)
<tjaalton> bryceh: ok, interesting plans. wonder how risky this might be though :)
<bryceh> tjaalton, aha! you've discovered my angle
<tjaalton> :)
<tseliot> tjaalton, hyperair: I've pushed the fix for bug #248392 in git
<ubottu> Launchpad bug 248392 in mesa "32bit libgl search for dri at wrong place on 64bit system" [Medium,In progress] https://launchpad.net/bugs/248392
<hyperair> tseliot: cool, thanks =)
<tseliot> hyperair: of course ia32-libs will have to be updated too but I'll deal with it after I'm done with the rest
 * hyperair nods
<asac> hi
<asac> ;)
<asac> so how comes that on armel X falls back to fbdev
<asac> is that hardcoded patch we have somewhere?
<lool> asac: It's in the server code
<asac> lool: so we have a hack?
<lool> there's a function which has hardcoded logic depending on various information from the host
<lool> asac: We have a patch to use PCI ids insteaed
<asac> lool: for armel?
<asac> ;)
<asac> where is that? any idea?
<lool> asac: Not for armel, that's the problem
<asac> right ;)
<lool> asac: NCommander was working on that a year or so ago, was supposed to extend with some arm logic IIRC
<asac> so seems the imx driver is a full copy of fbdev + a patch for EXA
<lool> asac: the dove one is a fork from fbdev too
<asac> right
<lool> But I think that's ok
<asac> so easy way feels to extend the current hard coded logic to honour subarch or something
<asac> and least try that first 
<lool> asac: I think it's in listPossibleVideoDrivers() in hw/xfree86/common/xf86AutoConfig.c, but it could possibly be somewhere else
<lool> It ressembles my memory of it
<asac> cool i will check that out
<asac> in what source is that ;)
<asac> me tries the common thing
<lool> asac: This is typically where we hookde the poulsbo pci ids at some point
<asac> good thanks for that pointer
<lool> asac: Actually, search for poulsbo in that file   ;-)
<lool> asac: Careful, might be some patches which change this logic in debian/patches/
<lool> In fact there are 5
<asac> ok i have /* Fallback to platform default frame buffer driver */
<asac> thats the place i am looking for ;)
<asac> so adding imxdrv there if we are on imx (not sure how to detect that at runtime) might be a hacky but efficient way to accomplish a "prefer imxdrv if available"
<asac> lool: any idea to do a proper testing?
<jcristau> look in /proc/fb?
<lool> That's an excellent idea
<asac> i have
<asac> 0 DISP3 BG
<asac> 1 DISP3 BG - DI1
<asac> 2 DISP3 FG
<lool> we were considering crazy shit back a couple of cycles, /proc/fb sounds sane
<asac> yeah cool
<asac> but what do i parse to distinguish?
<lool> Hmm it's not too nice on babbage
<asac> i can check for cpuinfo ;)
<asac> and if its Freescale BBG use imxdrv
<asac> at least add to matches
<lool> asac: I really think /proc/fb is a better place because it depends on the drivers people build in their kernel
 * asac hopes it would then go to fbdev if that module isnt installed
<asac> lool: but what do we get from there?
<lool> Say, we could have multiple drivers in the kernel for a platform like OMAP and it would affect which xorg driver to use
<asac> i dont see anything that tells me: "this is imx"
<jcristau> it tells you the name of the kernel fb driver
<asac> right. so you want to fix the kernel
<asac> hmm
<lool> asac: Alternatively, /sys might have more info
<asac> yeah
<jcristau> if you kernel fb driver doesn't tell you who it is, then fix that
<lool> I'm +1 on that suggestion too, but there might be kernels in the wild already
<asac> ok. are there convenience funcs for parsing /dev/fb already somewhere?
<lool> Actually, there are
<lool> asac: You mean /proc?
<lool> asac: Don't think so
<lool> asac: Just FTR, another (ugly) approach would be to prepend arch specific drivers to the list if you know they will fail and pass on to the default fbdev; but that's uglier than what's proposed here (might be less work, but we don't care, right? :-)
<asac> lool: right. but i dont think we can assume they will fail
<asac> thats why i think i could just check cpuinfo for now
<asac> and prepend with arch specific drivers
<asac> then long term we can fix /dev/fb info
<asac> at least here in imx the driver doesnt really check if its supported ;)
<lool> asac: Why not just recognize the crap you have in /proc/fb now, and also fix the contents and recognize the fixed output as an alternative?
<lool> That's as much work as parsing cpuinfo since you have to check cpuinfo per board anyway
<lool> but it's future proof
<asac> lool: but is the current output in any way unique?
<lool> asac: Not any more than cpuinfo
<asac> hehe
<asac> right. so ... yeah; sure
<asac> will do that then ;)
<lool> asac: I actually suspect cpuinfo is worse; because there were more boards than graphics drivers
<lool> asac: Check the dove output, see if it's sane?
<asac> thats the plan
<Sarvatt> asac: can you point me at this xf86-video-imx driver?
<asac> Sarvatt: havent published yet. will net you know when its avail
<asac> let
<Sarvatt> RAOF: did you see that they fixed a plymouth/ubuntu specific problem in nouveau git? http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=c642b9f7a13bdeecd0a83ddcbf6d6d4f2c287501
<Sarvatt> just removes a harmless error message from the logs people are reporting bugs on -- [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
<bryceh> tjaalton, have you given thought to merging in xserver 1.7.6?
<tjaalton> bryceh: yep, we should follow the stable branch
<tjaalton> though maybe wait until it's released
<tjaalton> there were a couple of issues with .901, one with selinux and a regression due to the fix for bug 25400 (apparently fixed now)
<ubottu> Launchpad bug 25400 in mozilla-thunderbird-locale-fr "mozilla-thunderbird-locale-fr: new changes from Debian require merging" [Medium,Fix released] https://launchpad.net/bugs/25400
<tjaalton> freedesktop bug 25400
<ubottu> Freedesktop bug 25400 in Server/general "Fedora 12: Mouse cursor trapped inside menu button" [Blocker,Reopened] http://bugzilla.freedesktop.org/show_bug.cgi?id=25400
<bryceh> tjaalton, ok great, it sounds fine to me so if you'd like to merge it in, go ahead whenever you feel it's ready
<bryceh> otherwise I'll re-check again in a couple weeks
<bryceh> tjaalton, jcristau, I'm looking at -evtouch currently.  We've unfortunately built up quite a bit on it in ubuntu, however looks like it's mainly fdi files which I gather are no longer relevant?
<bryceh> or should those be ported to udev or xorg.conf.d rules?
<tjaalton> bryceh: I'll merge once 1.7.6 or the next rc is released
<tjaalton> bryceh: yeah the fdi files are useless as-is, and I'm not sure if they should be converted or not
<tjaalton> leaning towards no, it has the calibrator anyway
<bryceh> ok
<bryceh> the only other bits besides the fdi stuff appears to be a couple tweaks to calibration stuff
<bryceh> 21_more_calibration_fixups.patch and 20_fix_calibrate_submission_directions.patch
<apachelogger> bryceh: ping
<bryceh> the former patch debian took, the latter one doesn't sound that critical.  Time for a sync request
<tjaalton> yeah
<jcristau> \o/
 * jcristau likes synced stuff :)
<tjaalton> me too, there are plenty of candidates left :)
<tjaalton> well, a handful at least
<tjaalton> bryceh: lifeless should probably merge libx11 ;)
<bryceh> tjaalton, heh
<bryceh> I'd asked him to send his patches upstream when I saw him in portland, hmm
<tjaalton> the klingon one was rejected
<bryceh>   * Add klingon language definition.
<bryceh> >_<
<tjaalton> since the locale isn't known by libc
<tjaalton> glibc
<jcristau> and the glibc patch was rejected iirc
<tjaalton> ah, ok :)
<bryceh> +en_US.UTF-8/XLC_LOCALE:			la_AU.UTF-8
<bryceh> what's la_AU?
<apachelogger> bryceh: I am trying to debug bug 526919
<ubottu> Launchpad bug 526919 in xorg-server "[Karmic] X crash due to xsetroot in startkde after recent update" [Undecided,Incomplete] https://launchpad.net/bugs/526919
<bryceh> latin with an australian accent?
<apachelogger> bryceh: but gdb doesnt like me and claims that any way I try to display/print privates it is at address 0x0
<bryceh> Eu tu, mate?
<jcristau> heh
<tjaalton> :D
<bryceh> apachelogger, heh, that doesn't sound good
<tjaalton> fosters jacta est
<bryceh> hehe
<tjaalton> yeah I see the use case
<apachelogger> bryceh: my thinking exactly :D espcially since both have an address according to the bt
<bryceh> apachelogger, are you following my tips in comment #13?
<apachelogger> yes
<apachelogger> dpkg.log is just too massive to trace the issue
<bryceh> apachelogger, it does sometimes happen that gdb doesn't produce useful results, so there are some alternate angles to doing debugging, like inserting print statements in the code
<apachelogger> removing stuff from startkde lead to the conclusion that the crash can also be fixed by removing the ksplash from the startup sequence
<bryceh> apachelogger, ok if you've made some progress at narrowing down what in startkde is triggering it, it would be good to update the bug report with a shorter use case
<apachelogger> *nod*
<bryceh> apachelogger, even if you can't pinpoint the exact issue, with a simple test case it may be possible to go upstream with the bug
<apachelogger> bryceh: I'll poke some more into that, because I do not see me going after the issues with print statements unless the owner of the machine sends it to me :)
<bryceh> ok
<bryceh> yeah remote debugging is tough
 * apachelogger is glad that the user granted him access to begin with :)
<BUGabundo> evening
#ubuntu-x 2010-03-11
<bryceh> morning RAOF
<RAOF> bryceh: Good morning!
<bjsnider> it is not the morning
<RAOF> Not anymore, no.
<jdub> hey gang
<jdub> i'm poking around in launchpad to see if a bug is already filed about this
<jdub> my i965 isn't getting hardware gl love
<jdub> a bit of apparently salient info:
<jdub> $ LIBGL_DEBUG=verbose glxinfo 2>&1 | grep error
<jdub> libGL error: dlopen /usr/lib/dri/i965_dri.so failed (/usr/lib/dri/i965_dri.so: undefined symbol: _mesa_meta_clear)
<jdub> libGL error: unable to load driver: i965_dri.so
<jdub> libGL error: driver pointer missing
<jdub>  
<jdub> hmm
<jdub> think i may have figured it out
<jdub> yay, looks like i had some evil meta debs from elsewhere installed
<jdub> thanks for providing the counselling couch
<jdub> ;)
<stefanlsd> heys! really appreciate the nouveau drivers in lucid, but need the propietry drivers for some stuff. cant load it since it seems the frame buffer takes ownership of the device and nvidia-current module says no device found. cant find any documentation on how to disable it, any ideas pls?
<stefanlsd> best way i've found for now is to boot -15 kernel, which isnt great :)
<jcristau> stefanlsd: echo blacklist nouveau > /etc/modprobe.d/nvidia.conf
<jcristau> then update-initramfs
<stefanlsd> jcristau: thanks. will give it a try!
<tseliot> jcristau, stefanlsd: my packages already do that
<johanbr> stefanlsd, removing plymouth and/or booting without the "splash" kernel option may also help
<stefanlsd> tseliot: is you package new, cause i just noticed i already have it black listed in there, and about 10 minutes ago i just ran the system / hardware drivers and enabled nvidia
<stefanlsd> johanbr: removed splash doesnt, help, can try remove plymouth
<tseliot> stefanlsd: no, it's not new. Did you reboot?
<bjsnider> it was new 2 months ago
<stefanlsd> tseliot: yeah, every day :)  relevant part of dmesg in pastebin   http://pastebin.ubuntu.com/393390/
<tseliot> stefanlsd: I mean, after installing nvidia
<stefanlsd> tseliot: doesnt seem like it removes it in the initrd. but yeah, i've always had nvidia installed. im gonna reboot right now just to confirm, brb
<bjsnider> i wonder what jockey says is going on in his case
<Sarvatt> yeah it puts all the gpu stuff in the initrd by default just incase its needed, the nvidia package adds a nouveau blacklist but i've seen 2 reports where that blacklist wasn't working for some reason since non-lbm nouveau went in. in one case it was because /usr was on a seperate partition that was getting fscked so it couldn't follow the symlink in /etc/modprobe.d/
<Sarvatt> tseliot: i was going to ask you about that, would it be a better idea to just put a versioned .conf in /etc/modprobe.d/ instead of making it an alternative?
<tseliot> Sarvatt: what do you mean by "versioned .conf"?
<Sarvatt> like nvidia-current.conf nvidia-173.conf nvidia-96.conf
<tseliot> also, we could put it somewhere in /lib perhaps?
<stefanlsd> tseliot: hi, back, still doesnt work
<stefanlsd> tseliot: interesting what you said about above
<tseliot> Sarvatt: those files would conflict with each other
<tseliot> stefanlsd: do you have /usr on a separate partition?
<stefanlsd> tseliot: i have a problem booting, it seems random. 1/2 boots it is unable to mount my /usr partition
<stefanlsd> i hard power down my laptop, and power up, and then it finds it
<tseliot> hmm..
<bjsnider> stefanlsd, so /usr on your system is on its own partition?
<stefanlsd> tseliot: yeah, /usr /home /var /tmp / on seperate partitions
<tseliot> ok
<Sarvatt> just seems racy with the mounts not being available all the time for people with oddball partition layouts
<bjsnider> i wonder if there's an open bug regarding not being able to find separate partitions
<Sarvatt> ah i was thinking nvidia-173 and such werent parallel installable with nvidia-current
<stefanlsd> been wanting to debug why for some reason it doesnt see my /usr partition for a while now. seems like some race issue
<tseliot> Sarvatt: using /lib instead of /usr/lib would fix it
<Sarvatt> mountall is where you want to look
<bjsnider> maybe his fstab is broken
<bjsnider> or old or something
<Sarvatt> stefanlsd: try changing /etc/init/udev.conf to require local-filesystems to start
<Sarvatt> not sure if thats the right way but things are starting too parallel for you with the oddball partition setup, it's expecting a standard layout
<stefanlsd> Sarvatt: whats the syntax for the udev.conf file for require?   I just put "require local-filesystems"  under the start line?    hehe, its not that oddball btw :)
<bjsnider> sure it is
<jcristau> no
<jcristau> pretty standard actually
<bjsnider> ok
<Sarvatt> i dont think its oddball either but theres alot of issues with upstart and non standard layouts
<bjsnider> i forgot that's how the ubuntu installer lays things out every time
<jcristau> (more so 10 years ago than now, but well)
<stefanlsd> but yeah, seems like a few bug reports for things expecting stuff in /usr and /usr not being available (specifically /usr/lib)
<Sarvatt> hmm I'm not sure udev would be the place to put it actually stefanlsd..
<Sarvatt> try start on virtual-filesystems and local-filesystems though in /etc/init/udev.conf and hopefully that wont wreck your machine :) i believe you need to update-initramfs -u after you change it
<Sarvatt> it'll probably add quite a bit of time to your boot time, the racyness is a fallout from all of this boot speed work :(
<stefanlsd> Sarvatt: kk. thanks. gonna reboot and check :)
<stefanlsd> brb (hopefully)
<stefanlsd> mm, back. 
<stefanlsd> soo, the blacklisting worked now...
<stefanlsd> although the system feels very slow... everything sluggish. not sure if its just me
<stefanlsd> what happened to glxinfo
<stefanlsd> im pretty sure this isnt accelerated
<stefanlsd> aah yeah, /proc/nvidia doesnt exist
<stefanlsd> prob X config now. gonna try reconfig. nvidia kernel module is loading
<stefanlsd> Sarvatt: ok thanks. its working now
<stefanlsd> so i guess for the record, blacklisting with a seperate /usr partition isnt working
<tjaalton> just like ureadahead doesn't work with separate /var partition
<tjaalton> I'm down to just having /tmp and /boot separate, need to disable /var/tmp somehow so people can't fill root with it
<tjaalton> like link it to /tmp
<stefanlsd> tjaalton: aah ok. i've seen that ureadahead does give errors on mine also
<tseliot> stefanlsd: can you file a bug report about blacklisting while using separate partitions, please?
<stefanlsd> tseliot: will do, any suggestions on package?
<tseliot> stefanlsd: nvidia-graphics-drivers would be fine
<tseliot> thanks
<djr13> i'm getting gpu lockups under nouveau with an nv18 card
<djr13> ...any ideas/things to check?
<djr13> getting gpu lockups/X freezing under multiple kernels, Xorg versions/nouveau versions
<Sarvatt> bryceh: sent you an email with a ton of ideas regarding X specific UDS discussion points. basically things such as gallium implementation, extending synaptics device settings that are missing to the GUI (like corner button settings and tap button assignment), xserver 1.8 migration pains like xorg.conf.d and the new abi's, libkms that plymouth will most likely depend on, and issues we've seen with KMS migration such as backlight control
<bryceh> Sarvatt, ok great thanks, I'll take a look
<tseliot> Sarvatt: "synaptics device settings" - good point, it reminds me of what I haven't had the time to work on, among other things ;)
 * bryceh just got retasked to focus on multitouch support for a while
 * tseliot whistles
<Sarvatt> thats a rough one
<Sarvatt> going to need quite a number of kernel patches for starters to handle the touchscreen support for the more common devices (n-trig?)
<bryceh> Sarvatt, yep
<djr13> anyone: what could i do to find the cause of gpu lockups in nouveau...only happens with nv18...
<bryceh> djr13, speak with RAOF
<djr13> bryceh: eh? thanks, i'll see what they say
<Sarvatt> file a bug for starters, need alot of logs to help you troubleshoot it :)
<Sarvatt> ubuntu-bug xorg from a terminal, and subscribe RAOF and Sarvatt to it
<diverse_izzue> since kernel -15 i have trouble with radeon kms and external screens. is that known, and that to do about it?
<bryceh> diverse_izzue, look in launchpad to see if it's a known issue
<djr13> Sarvatt: you mean me? :) yeah I thought of that...i can't quite find it in any log so far....and thanks also...couldn't recall how to file bugs :-/
<diverse_izzue> bryceh, i should search for the component "linux"?
<bryceh> diverse_izzue, process is file a bug if there isn't one already, see http://wiki.ubuntu.com/X/Troubleshooting for some techniques to debug the type of problem, forward the bug upstream to bugs.freedesktop.org and make a bug link, and work with upstream towards a fix
<Sarvatt> gotta work and purposefully leaving the laptop at home this time so I wont be able to look at it until tonight though
<bryceh> diverse_izzue, once there's a fix, the patch will need backported to lucid, and then integrated to our packaging
<diverse_izzue> bryceh, i had the same issue with the vanilla 2.6.33 kernel, but not the 2.6.32 one
<bryceh> diverse_izzue, I don't know if anyone on the developer end of things will have time to help on your bug so the more of that process you can do, the easier it'll make it and more likely it'll be to looked at.  If you think it's an emergency, talk with rickspencer3 to help alter priorities accordingly
<bryceh> diverse_izzue, if you're certain it's a kernel bug, you probably should be talking to the kernel team rather than us - see #ubuntu-kernel
<diverse_izzue> bryceh, genereally, how much trouble does the new ati stack still make?
<djr13> Sarvatt: would "ubuntu-bug xorg" still likely collect the correct info if I switched cards a couple hours ago?
<bryceh> djr13, nope
<diverse_izzue> bryceh, if you just said sth. please repeat, had an X crash
<bjsnider> djr13, there is also a #nouveau channel where the devs lurk
<bryceh> diverse_izzue, the way you asked your question it's not possible to answer it
<bryceh> diverse_izzue, again see launchpad if you're curious about bugs
<djr13> hmm looks like i'm stuck trying to get it running with a half-broken Xorg :)) should be possible though...
<diverse_izzue> all right
<djr13> bjsnider: yes i've been there...no responses :((
<bryceh> diverse_izzue, we'd put out some calls for testing on the stack and no one reported any show stopper type issues, but not many people helped do the testing so it's not really possible to make broad generalizations about it
<bryceh> upstream says it should be good to go
<diverse_izzue> ok, i just recently tuned into the testing. i do have issues, and will make sure they are reported soon
<tjaalton> diverse_izzue: you could also try on #dri-devel, say that .33 has a regression
<bjsnider> bryceh, i'd say it is how it is. there aren't many good choices there. it's either radeon or fglrx
<diverse_izzue> bjsnider, but there's regression potential. i could use external screens in karmic, and currently my system does either hang on boot with external screen or show an extremely jittery picture
<bjsnider> i suppose fglrx doesn't work with the kernel yet
<bryceh> bjsnider, tjaalton, btw apw implemented kms blacklisting support in the kernel, so if there are hw-specific issues that are best fixed by making the hw use ums instead, give him pci id's (and make sure there are bug report #'s for tracking)
<tjaalton> or the xserver
<diverse_izzue> bjsnider, i haven't tried and i won't...
<bjsnider> diverse_izzue, it's not much help in any case i suppose
<bjsnider> they'll probably patch it the day before lucid is released
<tjaalton> bryceh: ok, nice
<bryceh> bjsnider, unfortunately ATI NDA prevents us from disclosing when fglrx will be delivered to us
<bjsnider> hahhaa whatever
<bryceh> but it will be available in lucid
<diverse_izzue> sometimes the industry is difficult to understand...
<bjsnider> bryceh, why would you sign one of those awful things?
<bryceh> bjsnider, well I didn't sign it personally ;-)
<apw> bjsnider, tjaalton, bryceh, right ... get me the bug numbers, make sure the device ids are clearly in there and i'll put together a test kernel for them
<bryceh> knowing stuff under an nda is almost worse than not knowing :-/
<bryceh> if I didn't know, then I could give you educated guesses ;-)
<bryceh> anyway, --> lunch.  bbiab
<bjsnider> i provided an educated guess based on their past behaviour
<bryceh> Sarvatt, you about?
<bryceh> Sarvatt, can you bump me up to administrator in xorg-edgers (https://edge.launchpad.net/~xorg-edgers/+members)?
<bryceh> Sarvatt, I want to add a ppa for multitouch
<Sarvatt> bryceh: only tormod can do that but I created https://edge.launchpad.net/~xorg-edgers/+archive/multitouch
<bryceh> Sarvatt, thanks
 * bryceh copies in multitouch package
<Sarvatt> jcristau: you have experience with xserver 1.8 post xorg.conf.d merge right? when you create xorg.conf.d snippets for input devices and such and they are matched does it handle video device autoconfiguration the same as not having an xorg.conf currently does?
<bryceh> apw, mt kernels can be dropped @ https://edge.launchpad.net/~xorg-edgers/+archive/multitouch/+packages
<bryceh> feh, we're drowning in these GPU lockup bugs
<Sarvatt> hmm, i see some trends in the gpu lockup bugs
<Sarvatt> 8xx are all at boot time and justify quirking to UMS, every other one I've looked at so far looks like it was triggered by the plymouth sigquit restarting X deal..?
<bryceh> Sarvatt, ooh really?  that's good insight
<bryceh> so for 8xx we could just have apw blacklist them all (which we were thinking of doing anyway)
<Sarvatt> there's a little issue with libdrm I haven't figured out yet, I get a drm error every time i stop or restart gdm
<Sarvatt> digging through my logs to find the exact message
<bryceh> for the plymouth ones, I wonder if there's a way we can check for that situation automatically and avoid filing more bug reports in that case?
<jcristau> Sarvatt: afaik stuff is handled as if you had the xorg.conf.d contents in xorg.conf
<Sarvatt> [drm:i915_gem_madvise_ioctl] *ERROR* Attempted i915_gem_madvise_ioctl() on a pinned object
<Sarvatt> I get that switching to a VT and doing a sudo service stop gdm
<Sarvatt> i need to file an upstream bug on that one now that i figured out it wasnt plymouth related
<Sarvatt> hmm i have an error in my dmesg now when i suspended with the powersave=1 945 black screen hang, that used to just be silent and will trigger the apport script too so I gotta check 945 hang bugs for that
<Sarvatt> Mar  8 18:25:13 asuka kernel: [97322.963349] render error detected, EIR: 0x00000010
<Sarvatt> Mar  8 18:25:13 asuka kernel: [97322.963369] page table error
<Sarvatt> Mar  8 18:25:13 asuka kernel: [97322.963381]   PGTBL_ER: 0x00000010
<Sarvatt> bryceh: what devices are you trying to support? if it's n-trig you get multitouch/stylus/touch and eraser support through wacom and just need to extend the udev rules as well as integrate the n-trig kernel module (not to mention the non-redistributable windows firmware it needs..). you will lose everything but touch events using evdev?
<bryceh> yeah n-trig is the priority
<bryceh> apw's looking into the kernel module (see https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-multitouch)
<bryceh> Sarvatt, I got a patch that adds multitouch support to -evdev which is in the aforementioned ppa now
<bryceh> don't have the hw to test it though
<superm1> that reminds me, my touchscreen broke on upgrade to lucid, is it expected to be working right now?
<superm1> single touch
<Sarvatt> a bug report would help alot when you have time, unless it was before wacom 0ubuntu2 was uploaded then it was expected not to work
<Sarvatt> -- Timo Aaltonen <tjaalton@ubuntu.com>  Fri, 05 Mar 2010 10:52:11 +0200
<Sarvatt> serial tablets were broken until then needing the wacom udev rules update it had
<bryceh> superm1, probably due to dropping HAL
<Sarvatt> (most tablet pc's having serial digitizers, not sure what device you have)
<superm1> i dont have the HW handy right now.  i'll get a bug report together when i ge thome
<superm1> i dist-upgraded on sunday, so so i should have that
<Sarvatt> yeah that'd be much appreciated, it *should* be working at this point
<superm1> Ok, that's what i needed to determine, whether the bug report would do anygood since it was "supposed" to be working
<Sarvatt> actually I just noticed we're missing waltop tablets support, and i was under the impression serial wacom devices needed Option "ForceDevice" "ISDV4" in xorg.conf as well
#ubuntu-x 2010-03-12
<bryceh> Sarvatt, hey did you get an arsenal script to search through Xorg.0.log files?
<superm1> Sarvatt, bug 537801
<ubottu> Launchpad bug 537801 in xf86-input-wacom "Touchscreen doesn't work after karmic->lucid upgrade" [Undecided,New] https://launchpad.net/bugs/537801
<superm1> wait a minute, it asked me if i want to include my "sensitive" logs from gdm and then makes the bug public?
<superm1> that doesn't seem right
<bryceh> superm1, it takes sudo privs to access them
<bryceh> superm1, but we're not going to manually eyeball the gdm scripts to sanitize them of any sensitive info
<bryceh> I'm not really even sure why they require su to look at them
<superm1> ah i see
<Sarvatt> superm1: ohh boy..
<Sarvatt> that device actually has a proprietary blob driver not in ubuntu
<Sarvatt> evtouch is whats supposed to support it for the basics, wacom is just taking control of it
<Sarvatt> this is the driver for ubuntu btw - http://www.ideacom.com.tw/download/DRIVE/IDC_Linux_3_1_0.tar.gz 
<superm1> Sarvatt, it worked without it though in karmic?
<superm1> so i guess evtouch was grabbing it in karmic then based on what you're saying
<superm1> but that appears to be in universe now in lucid?
<Sarvatt> yeah, I'm really unsure of the status of evtouch in lucid, it doesn't even look to be functional with a udev xserver at first glance?
<superm1> it looks like it's depending on an old version of xserver-xorg-core
<superm1> unstable looks to have a patch for x server 1.7
<Sarvatt> http://packages.debian.org/squeeze/xserver-xorg-input-evtouch
<Sarvatt> yeah
<Sarvatt> bryce was looking into syncing it earlier
<superm1> so is our delta droppable then?
<Sarvatt> the delta is all fdi files it looks like which are not functional anymore and need translating into udev rules, that's going to need some serious work
<superm1> is there a guide for doing that?
<superm1> looking at th existing rules, it seems a lot of them are just setting the x driver, not any bits
<superm1> oh synaptics seems to do options too
<superm1> oh but what a disgusting init script it had
<superm1> i am starting to think i dont want to commit to helping with this ;)
<bryceh> yeah I put in a sync request on -evtouch yesterday.  Waiting on an archive admin to flag it through
<Sarvatt> need to be sure it'd actually even work before anyway, i'd start by grabbing the one from squeeze and adding your device to the udev rules it has to see if it even works
<bryceh> I don't know if the current evtouch driver works, but it certainly doesn't build against xserver
<bryceh> tjaalton didn't think the fdi's would need converted to udev
<bryceh> however I wrote a page explaiing how to do this on the ubuntu-x wiki, in the input config section
<Sarvatt> i need to find a really cheap evtouch device
<superm1> Sarvatt, http://configure.us.dell.com/dellstore/config.aspx?oc=blcwwfp&c=us&l=en&s=bsd&cs=04&kc=vostro-v13
<superm1> that's what i have
<Sarvatt> a bit out of my price range :) i think they sell cheapo usb digitizers people use to convert existing screens that work with evtouch though
<Sarvatt> so we need a udev rule that sets the symlink, port all our hal matches and quirks to it, and figure out how to not have wacom interfere with it and vice versa because it seems wacom is loading for everything that matches ID_INPUT_TABLET
 * Sarvatt wishes we had xorg.conf.d right about now
<bryceh> don't we?
<Sarvatt> nope thats xserver 1.8
<bryceh> I think tjaalton backported it
<bryceh> maybe I'm wrong
<Sarvatt> he was playing with it but i'm not sure its something sane to backport especially this late, he had to remove the input abi bump in that came with it and remove ifdef's for the higher input abi so wacom would work with it and i have no idea if other drivers have similar things
<Sarvatt> superm1: does your device work if you remove /lib/udev/rules.d/69-xserver-xorg-input-wacom.rules ?
<Sarvatt> packaging that blob ideacom driver seems like a good idea even if I just throw it in a PPA, asus and dell are both using that same device for their netbook touchscreens :D
<superm1> Sarvatt, it would be best to get it in restricted tbh
<superm1> Sarvatt, i just installed the debian package and things didn't work, i'll brb and try to remove that rule
<superm1> Sarvatt, well without that rule wacom doesn't load, but evtouch isn't loading either
<superm1> so i'm guessing it still needs some kind of udev rule
<Sarvatt> yeah evdev should be taking it without the wacom rule, I was wondering if evdev was working with it
<superm1> http://pastebin.com/PCzdX3pV
<Sarvatt> does that device show up in lsusb?
<Sarvatt> if so can you pastebin lsusb -v?
<superm1> http://pastebin.com/hFry6d9y
<superm1> looks like yea
<Sarvatt> superm1: maybe something like this as say /lib/udev/rules.d/67-xorg-evtouch.rules -- http://pastebin.com/0FmeGQpm
<Sarvatt> or maybe just dropping lines 10-20 even if that doesn't work
<tjaalton> superm1, Sarvatt: yeah wacom shouldn't be the "catch-all" tablet driver, but evdev
<tjaalton> and xorg.conf.d doesn't really work for video drivers, because they need more than just the Driver section (in order to do fallbacks for instance)
<tjaalton> superm1: so try to get evdev load, it should match evtouch in functionality
<tjaalton> +to
<superm1> Sarvatt, that udev rule didn't do the trick
<superm1> nor with removing lines 15-20
<tjaalton> move the wacom rule away, does it load evdev then?
<superm1> i posted the pastebin above with wacom out of the way
<superm1> i'm a bit confused, it looked like it tried to load evdev for a joystick device
<tjaalton> heh, yeah it needs a patch to only load for event*
<tjaalton> type: MOUSE
<tjaalton> so probably got it wrong then
<Sarvatt> elographics seems to have fallen through the cracks too, lucid archive and debian git versions dont compile against xserver 1.7
<Sarvatt> luckily theres http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-drv-elographics/elographics-1.2.3-abi.patch?view=markup
<Sarvatt> same with mutouch http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-drv-mutouch/mutouch-1.2.1-abi.patch?view=markup
<tjaalton> luckily? those should just die :)
<libv> tjaalton: about xorg.conf.d; it could've worked for graphics drivers
<libv> but the modesetting model adopted for RandR1.2 lacked the expressivity to do this properly
<libv> and now people are all on kms anyway, so there is no point going there (as "relevant" drivers will not go close anyway)
<tjaalton> libv: ok
<tjaalton> is the intel gpu lockup thingie a bit trigger happy perhaps?
<tjaalton> intel has 50 more bugs than nvidia-180, 509 and counting :)
<jcristau> bryceh: xserver -1u3 is not in git?
<unggnu> hi all
<unggnu> I have some problems with font rendering and Intel since quite some time. Karmic is affected and Lucid too. It seems better since the 2.6.33 drm but lately I have seen it again. Some lines are just black or completly white and if I scroll them out of the view and back again they are fine. What's the best way to debug things like that?
<unggnu> But there definately seem to be less corruptions than before 2.6.33 drm
<unggnu> Or does it might also be a Firefox problem?
<unggnu> Btw. is the overlay support backported in the -intel driver for Lucid?
<sebner> bryceh: around by any chance?
<Sarvatt> hmm  ${SHA1_LIB} was removed from XSERVER_SYS_LIBS in the newest xserver 1.7.5.902 ( http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.7-branch&id=ff5fb43a4b38c707a1a9948ace621a62b5b2457a ), our xkb cache patch isn't working now and looks related to that
<Sarvatt> http://launchpadlibrarian.net/40884919/buildlog_ubuntu-lucid-i386.xorg-server_2:1.7.5.902~git20100312%2Bserver-1.7-branch.5a2b3f36-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz
<bryceh> Sarvatt, hrm
<bryceh> Sarvatt, was there a rationale for removing it?
<tjaalton> looks like a mistake
<bjsnider> ok, why is nvidia-current creating libvdpau_nvidia.so.1 as a link to the .so version?
<bjsnider> my package creates the .so version as a link to the 19x.xx.xx file, which is the soname of the library. but why is a .so.1 link necessary too?
<superm1> bjsnider, probably want to raise that again whenever tseliot is in the room
<bjsnider> why are the old packaging scripts set up to create the links in the .links files as well as manually in the rules file?
<superm1> They're old :)
<tjaalton> looks like a mistake
<tjaalton> (echo)
<bjsnider> why isn't it sunny today...
<bjsnider> ok, i'm going to retire from the question asking business
<superm1> haha
<bjsnider> what i don't understand is, if a library has a soname of anything except 1, for example 52 like libavcodec, you have libavcodec.so.52
<bjsnider> then you have a link, libavcodec.so that points to it
<bjsnider> i can understand that link
<bjsnider> the linker doesn't know for sure what the soname is, so you need that generic link
<bjsnider> but why create the .so.1 link?
<bjsnider> everything seems to need a .so.1 link even if the soname isn't actually 1
<tjaalton> The run-time library package should include the symbolic link that ldconfig would create for the shared libraries. For example, the libgdbm3 package should include a symbolic link from /usr/lib/libgdbm.so.3 to libgdbm.so.3.0.0. This is needed so that the dynamic linker (for example ld.so or ld-linux.so.*) can find the library between the time that dpkg installs it and the time that ldconfig is run in the postinst script
<tjaalton> from the debian policy
<jarek> Who can build package with current openchrome trunk? It can resolve many bugs for via chips.
<jarek> I can test it on my laptop
<tjaalton> jarek: what about the version on debian?
<tjaalton> it should be synced anyway
<jarek> it's quite old for debian
<jarek> So, I need to contact with debian devs?
<tjaalton> huh, old?
<jarek> without latest commits ;)
<jarek> current svn is 840, but package is 812
<tjaalton> right
<jarek> ther is patch witch can fix problem with resolution on my laptop
<jarek> I want test it, but I am not familiar with compilation that kind of stuff
<tjaalton> svn ftl
<jarek> I must force myself to do this some day
<jarek> currently I'm using windows on this old crap
<jcristau> bjsnider: ld -lfoo looks for libfoo.so
<jcristau> bjsnider: and produces a binary with a reference to libfoo.so.N
<jcristau> bjsnider: so at runtime ld.so sees that reference and loads libfoo.so.N
<tjaalton> jarek: what card/chip do you have?
<bjsnider> jcristau, yes, that i understand perfectly. what i don't understand is creating the libfoo.so.1 link to libfoo.so.N
<jcristau> eh, what?
<jcristau> there's no .so.1 link
<bjsnider> http://bazaar.launchpad.net/~albertomilone/nvidia-drivers-ubuntu/nvidia-current/annotate/head:/debian/nvidia-current.links.in
<bjsnider> you can see them being created all over the place there
<bjsnider> and they were in the previous packaging scripts too
<jcristau> oh. nvidia.
<jarek> It's unichrome pro, Fujitsu Amilo L7310W
<jcristau> bjsnider: for libGL, its SONAME *is* libGL.so.1.  the others i have no idea.
<jarek> I'm not sure chipset name, can be CN400 or PM880
<bjsnider> jcristau, so perhaps this is some sort of bizarro nvidia quirk?
<tjaalton> or just a packging goof
<jcristau> bjsnider: anything related to nvidia is a bizarro quirk as far as i'm concerned :)
<bjsnider> the libs in here are named like this: libnvidia-compiler.so.190.53
<bjsnider> so i don't see why a .so link to that isn't good enough
<jcristau> did you check what the soname is?
<bjsnider> that is the soname isn't it?
<jcristau> ?
<jcristau> how should i know
<bjsnider> it's called 190.53 so isn't that the soname?
<jcristau> no
<bjsnider> i see
<jcristau> the soname is in the elf header.  it may be the same as the file name, or it may be different
<bjsnider> how am i supposed to check that?
<jcristau> objdump -p
<bjsnider> jarek, there's another driver called unichrome that might work as well. the developer is in here
<bjsnider> especially if your hardware is "old crap" as you put it
<jarek> tjaalton: I googled for chipset name, and it saying PN800, but system information for windows showing pci names CN400/PM880
<jarek> bjsnider, my laptop isn't working like I expected a years ago, since then I tested livecd without succes
<jarek> I can't do testing on working alerdy system
<bjsnider> have you ever tried the unichrome driver?
<bjsnider> jcristau, all of these sonames are 1, so perhaps the so.1 link is necessary for that reason?
<jcristau> yes
<jarek> I really don't remember, but I'm using older driver then openchrome, can be via or unichrome
<bjsnider> you don't know what driver you're currently using?
<jarek> currently my laptop is windows land
<bjsnider> oh right
<bjsnider> so it didn't work off the livecd
<jarek> it's started with wrong resolution
<bjsnider> libv, which driver would be best for this guy's hardware?
<jarek> I see  1/4 of screen
<bjsnider> that ain't good
<jarek> It's known bug
<jarek> but the cure is propably in current trunk on openchrome
<jarek> I hope to test it on lucid prime time
<bjsnider> luc might not be here at the present time
<BUGabundo> bu noute
<jarek> bjsnider: If it's too late for lucid, I will wait for daily 10.10 builds, hope my laptop will run without problems then
<bjsnider> jarek, stick around in here until luc is here and then discuss it with him
<jarek> ok, thanks
#ubuntu-x 2010-03-13
<libv> bjsnider: sadly for this hw i only have VGA out running atm.
<libv> even though it really is a matter of allowing the vt3118 chipset to use the existing panel code
<libv> crtcs and pll should be fine, but i might want to have a test run of the cursor on secondary/scaling
<bjsnider> libv, so what driver would work best for him in your estimation?
<libv> atm, openchrome
<libv> although milage may vary, and he might have to play with the option to pick one of the three modesetting options
<libv> s/options/paths/
<bjsnider> libv, didn't you say you supported all hardware just shy of the newest one?
<libv> bjsnider: yes, VGA only atm.
<libv> bjsnider: crtcs and plls have been tested through
<bjsnider> don't know what that alphabet soup means, except for vga
<libv> bjsnider: if you think openchrome supports all hardware... well... they only support DVI that is integrated on the chip
<libv> panel is the next todo, but then i got into working hw layouts into the code, to be able to map all things properly
<bjsnider> maybe you should sign an NDA with via
<bjsnider> hahaaa
<libv> but then i went off and worked towards a unified graphics driver stack
<libv> nah, i have enough info and enough hw
<libv> just not enough time
<libv> or too many projects for too little time
<Sarvatt> new wacom in edgers tracking the devel branch with quite alot of fixes for serial tablets incase anyone was having problems with it
<Sarvatt> turns out it wasn't the xkbcomp cache patch that the removal of ${SHA1_LIB} from XSERVER_SYS_LIBS was affecting but more likely 02_Add-libgcrypt-as-an-option-for-sha1.diff so debian will be affected too, building now with http://sarvatt.com/downloads/patches/0001-Add-back-missing-SHA1_LIB.patch
<Sarvatt> that change fixes the xserver build \o/
<dhansen7> is there any kind of pre-release proprietary ati driver available for ubuntu 10.04 alpha?
<Sarvatt> dhansen7: no unfortunately
<dhansen7> is there an eta?
<dhansen7> hopefully they land before 10.04 gets released
<Sarvatt> there's no eta either unfortunately outside of there being one expected to be ready before release, it could be the very last day before release until they are ready :(
<Sarvatt> i'm going to go out on a limb and say I suspect it will be the april catalyst release that supports xserver 1.7 and they cant release that until given the go ahead by ati
<bjsnider> there's another person over in +1 with that nvidia problem caused by moutning /usr on a separate partition
<Sarvatt> tseliot is going to fix it
<Sarvatt> just needs to be moved to /lib
<bjsnider> yeah i know. i just wonder if all of the bellyaching i see in that channel from nvidia people is due to that issue
<Sarvatt> this looks so interesting -- http://cgit.freedesktop.org/~krh/xserver/commit/?h=glamor-ddx&id=c6eabffab8f5ba52ea04cd2290ef59e7864c6d95
#ubuntu-x 2010-03-14
<Sarvatt> ok, how about a nonouveau (can anyone think of a better word?) boot option to blacklist the nouveau module so people can actually use vesa or nv without manually blacklisting it? noticing this is a pretty sore spot right now
<Sarvatt> oh, blacklist=nouveau directly from the kernel command line looks like a valid option now that I'm digging through initramfs-tools, didn't know that
<Sarvatt> http://bazaar.launchpad.net/~sarvatt/initramfs-tools/working/revision/163 is kind of pointless then if they can just do blacklist=nouveau, need to try that out
<Sarvatt> i'm thinking it might be handy to have say, failsafex or the old xforcevesa as boot arguements. we could blacklist all KMS drivers in initramfs-tools and have the gdm upstart job pick failsafeX if it matches because its already checking the kernel command line for inhibitors
<Sarvatt> then we could just extend the kernel command line check in /etc/init/gdm.conf to check for the command and set env XORGCONFIG=/etc/X11/xorg.conf.vesa and ship a new stock vesa xorg.conf?
<Sarvatt> actually we could just make gdm exit1 if it matches, that'd automatically start a failsafe session
<verbalshadow> what did i miss? booting with Mobility Radeon HD 4200 with KMS now freeze my system and won't boot with out disabling.
<Sarvatt> verbalshadow: mind filing a bug so we can look at your logs?
<Sarvatt> just ubuntu-bug xserver-xorg-video-ati and subscribe Sarvatt if you dont mind
<Sarvatt> and whoa booting straight into failsafe is insanely fast compared to normal booting, menu was up in 11 seconds on this slow hdd netbook
<verbalshadow> Sarvatt: filing now
<verbalshadow> ok  now i need to file a bug on ubuntu-bug it thinks i don't have an internet connection and can't connect to the crash DB :(
<Sarvatt> hmm, not having any luck adding the xforcevesa option to initramfs-tools. i added the option to Init and had it set blacklist=drm,i915,nouveau,radeon and quiet=n, and also tried adding a check for xforcevesa to scripts/init-top/blacklist and blacklist those modules explicitly in there 
<Sarvatt> but plymouth seems to be loading drm/i915 and such on its own
<Sarvatt> changed the gdm upstart job to exit 1 if it sees xforcevesa in /proc/cmdline to load failsafe and that part works but its using fbdev on top of KMS of course because drm and such is loaded for plymouth
<Sarvatt> looks like i need to either extend plymouth to recognize xforcevesa as well or remove splash from the cmdline if xforcevesa is used
<Sarvatt> no luck, removing splash doesn't stop i915 from loading. hmm
<bjsnider> is superm1 ever in here on weekends?
<Sarvatt> verbalshadow: https://bugs.edge.launchpad.net/ubuntu/+source/apport/+bug/538097
<ubottu> Launchpad bug 538097 in launchpad "Apport cannot connect to crash database" [Undecided,Confirmed]
<Sarvatt> maybe if you ping him and ask a question he might pop up :)
<bjsnider> are there any useful dkms logs anywhere? there's one in /var/log but it's no help
<albert23> bjsnider: there is a full build log like  /var/lib/dkms/nvidia/kernel-2.6.31-20-generic-x86_64/log/make.log
<bjsnider> if the build didn't happen on that kernel that directory and log do not end up existing
<bjsnider> all i get here is exit code 6
<Sarvatt> anyone really familiar with compiz? i'm almost positive its one of our patches breaking resoluions where one side is the same as the max texture size, 010-disable-child-window-clipping.patch maybe? it's just 1 pixel thats the problem, 2047x1152 works for instance if the max texture size is 2048
<RAOF> I used to be a bit familiar with compiz.
<BUGabundo> RAOF: used to ?
<RAOF> Compiz *has* been around a while :).
<BUGabundo> ahh
<BUGabundo> well, before compiz we had 
<Sarvatt> we should probably adjust our max texture size checks in 060_move_checks_to_compiz.patch to max -1 though because people with 2048x1152 monitors are having all kinds of problems
<BUGabundo> ... what was it called? ....
 * BUGabundo blanks
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/428769
<ubottu> Launchpad bug 428769 in xserver-xorg-video-intel "compiz starts with a blank screen on a 2048x1152 monitor" [Undecided,Confirmed]
<Sarvatt> i want to ask those people to try a fedora livecd and see if its different because they dont have most of our compiz patches :D
<RAOF> Which lucky bugger has a 2048x1152 monitor? :)
<Sarvatt> lots of mac people
<RAOF> Aaah.
<BUGabundo> ehe
<MarcoPau> Hello, I just put xserver-no-backfill ppa in my sources.list but I don't get anything upgraded out of it. Any hint? Using karmic
<libv> jcristau: ?
<MarcoPau> the xorg-server package itself is not available
<libv> jcristau: how does this affect compatibility over the different kernel versions?
<libv> (from a separation pov, i like the move though, this drm/libdrm stuff is a right mess)
<libv> nah, nm my question, the compat issue is just as bad from either side of the change
<libv> there are only two solutions to this compatibility issue anyway
<jcristau> meh.  whoever tries to make it work with different versions can fix things up
<libv> yes :)
<libv> it's an issue between developer and user, and the packager is between a rock and a hard place there
<libv> unable to satisfy both in the current constellation
#ubuntu-x 2011-03-07
<vish> !away > zz_Azelphur, Azelphur 
<RAOF> Does anyone happen to have a sandybridge system lying around to test the new mesa on?
<bryceh_> Oneiric Ocelot
<RAOF> ?
<vish> ha! the naming has begun!
<brobostigon>  http://paste.ubuntu.com/576959/ https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/730099
<ubot4`> Launchpad bug 730099 in xserver-xorg-video-intel (Ubuntu) "[i915gm] GPU lockup 0c40b170 (ESR: 0x00000001 IPEHR: 0x02000011) (affects: 1) (heat: 6)" [Undecided,New]
<brobostigon> hi, i wrote that bug up yesterday, after experiencing it, for a few days, any ideas as to how this canbe resolved,please.
<cnd> tjaalton, if you're around, would you be interested in uploading a package for me?
<cnd> it's a new package that I have rights to upload to, but the rights can't be managed untill it's in the archive :(
<tjaalton> cnd: sure
<cnd> tjaalton, http://people.canonical.com/~cndougla/utouch/
<cnd> the package is "libgrip"
<tjaalton> cnd: ok, uploaded
<cnd> thanks!
<brobostigon> hi,it justhappened again under natty while running unity. 730099
<brobostigon> i have just updated that bug, with info about the lockup that haoened a few minutes ago.
<brobostigon> anyone got a eeepc 900 ssd, with the gpu in 730099, with natty, with all recent updates,who can confirm such a bug exists please.
<lag> cnd: Hey buddy
<lag> cnd: Did you manage to have a look into my little problem?
<cnd> lag, not yet :(
<cnd> I'll try to get to it today though
<lag> cnd: Okay, I'll not nag :)
<lag> That would be awesome
<lag> If you have the time
<stefanlsd> hihi. i have a macbook pro running natty and im trying to stop syndaemon (i think) from disabling my usb external mouse when i type. under mouse touchpad you can untick -      â tito
<stefanlsd>                    | disable touchpad while typing - any idea how i do this for my mouse also?
<stefanlsd> bleh, sorry for bad paste
<soreau> There is a bug that causes xv video playback to have strange colors on rv350. I went to bisect ddx but now I see that the bug is somehow related to xorg-edgers repo because I installed master xf86-video-ati to /opt/xorg and if I point X to load these modules, video playback is fine. However even after ppa-purging and reinstalling xorg-edgers, the problem persists. I also have confirmed at least one other person had this issue using xorg-edgers
<soreau> The question is, how can I figure out what's wrong when using xorg-edgers? Old stuff lying around? (I haven't installed anything other than xorg-edgers and ddx to /opt/xorg so far and it's a relatively clean install) or ubuntu patches? (where can I find the patch list xorg-edgers uses on top of master git component?) or any other random oddity? Really not sure how to diagnose it further
<soreau> This wasn't happening up until about a month and a half ago
<codemagician> Hi guys.  My 10.10 desktop machine X process regularly hits 100% and hangs my machine. I'm using Nvidia chipset card with 270.29 drivers.   Can anybody help suggest an approach to diagnose the issue?
<codemagician> The card is Asus EN210 Silent (GeForce 210)
<lag> What do you guys know about CMAPs?
<hrw> hi
<hrw> [15765.380030] radeon 0000:01:00.0: GPU lockup CP stall for more than 10020msec
<hrw> does someone has idea how to get rid of it?
<brobostigon> i am getting lockup errors here aswell,but on intel i915gm.
<hrw> my gfx card is stuck now spitting this ,essage each 10s
<hrw> thats on up-to-date natty with xfce
<codemagician> Any takers on the 100% CPU Xorg?  By the way, its a i7 3GHz core processor so a little greedy for a single 1920x1080 display :-)
<hrw> ok, time to reboot
<stefanlsd> if anyone was interested, found solution - bug #219487
<ubot4`> Launchpad bug 219487 in mouseemu (Ubuntu) "Typing blocks external mouse (affects: 4) (dups: 1) (heat: 26)" [Wishlist,Confirmed] https://launchpad.net/bugs/219487
<brobostigon> anyone here have an eeepc or other machine with natty, who can confirm 730099, please.
<hrw> bug 730099
<ubot4`> Launchpad bug 730099 in xserver-xorg-video-intel (Ubuntu) "[i915gm] GPU lockup 0c40b170 (ESR: 0x00000001 IPEHR: 0x02000011) (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/730099
<hrw> would have to dig out my intel based laptop
<brobostigon> hrw: a confirmation i am not alone would be good, because then it would give some impatus for it to be fixed, for everyones benefit.
<brobostigon> hrw: if you could, that woukd be good, please, :)
<hrw> sure, powerting up
<brobostigon> thank you, :)
<hrw> and ugrading
<hrw> cause with system updated around 25th Feb I did not had problems
<brobostigon> hrw: it is entirly random as to when it happens, i didnt have any problems, untill 3 days ago.
<hrw> 715MB of updates to fetch
<brobostigon> wow.
<hrw> should not take more then 15-20 minutes
<codemagician> With regards to the 100% CPU usage for xorg, somebody suggest to add "UseEvents True" to my xorg.conf file to potentially fix what they considered was a known problem in the community.  May I ask if this could be the issue?
<brobostigon> hrw: does it have the same gpu as specified in the bug?
<brobostigon> hrw: and by chance, do you know someone who ould fix it.?
<hrw> mine has newer one 8086:2a43 (gm45)
<hrw> brobostigon: no idea who
<brobostigon> oh, ok.
<bjsnider> codemagician, have you eliminated every other possible cause of this issue, ie. firefox or something else running?
<codemagician> codemagician, i only had shell windows running
<codemagician> bjsnider, i only had shell windows running
<codemagician> bjsnider, also the screen pixelates before it crashes
<bjsnider> is it possible this is a broken graphics card?
<codemagician> bjsnider, another point (not sure how relevant it is) but this seems to happen within the first 10mins of startup.  If I manage to survive longer then the machine holds up.  I switch my machine off each night
<codemagician> bjsnider, no.  I tried it in a windows box
<codemagician> bjsnider, im not proud of that btw
<codemagician> ;-)
<bjsnider> codemagician, have you tried with and without compositing?
<codemagician> bjsnider,  is that the System->Preferences->Appearance->Visual Effects ?
<bjsnider> yes
<codemagician> bjsnider, yes, it crashed in all 3 modes
<codemagician> bjsnider, and often crashes especially when attempting to switch between them
<bjsnider> did you check /var/log/Xorg.0.log?
<codemagician> bjsnider, shall I check this after a crash?
<bjsnider> the info is saved there, so it can be checked anytime
<bjsnider> there are quite a few xorg logs in there too
<codemagician> http://pastebin.com/vQDFnkxH
<codemagician> any clues in that ?
<bjsnider> pastebin the older logs too
<codemagician> http://pastebin.com/YDHhx1GS
<codemagician> line above is Xorg.0.log.old
<codemagician> http://pastebin.com/SQQaNSiZ
<codemagician> line above Xorg.1.log
<codemagician> this one has fatal error line
<codemagician> that file is referring to itself btw
<codemagician> also, I noticed the kernel version at the top of that log doesn't match uname -a
<codemagician> Linux reddwarf 2.6.35-27-generic #48-Ubuntu SMP Tue Feb 22 20:25:29 UTC 2011 i686 GNU/Linux
<codemagician> whereas the log says "[  1279.434] Build Operating System: Linux 2.6.24-28-server i686 Ubuntu"
<codemagician> maybe this isn't important
<andypiper> hi folks... I have a weird Natty alpha 3 issue which may be X related
<andypiper> I installed a fresh Natty Alpha 3 on a netbook (AAO)
<andypiper> but on boot, no input buttons / clicks work
<andypiper> same applies for both synaptics touchpad... and USB mouse
<andypiper> if I go out to console a rmmod/modprobe psmouse it sometimes gets better
<andypiper> but even then only tap-to-click works, the trackpad buttons don't
<andypiper> should I file this against X in lp?
<bryceh_> andypiper, the rmmod/modprobe workaround sort of suggests it's a kernel bug
<andypiper> yes... I thought that might be the case. Hrm.
<andypiper> okies.
<bryceh_> andypiper, to 'linux' might be the better package.  But if you're unsure, file 'ubuntu-bug xorg' and we can take a look before sending it to the kernel queue
<andypiper> do you mean file against both? sorry I'm confused by that statement :-)
<andypiper> or tag it with those fields?
<bryceh_> andypiper, a standard diagnosis method would be to try booting older or newer kernels and see if the functionality comes back
<andypiper> right - but at the moment this is just a stock new Natty alpha 3 install... would need to hunt out older kernels I guess
<bryceh_> 'ubuntu-bug xorg' is a command to run which will file the bug for you (and attach a mess of files we like to have)
<andypiper> oh! cool
 * andypiper goes off to try it
<bryceh_> 'ubuntu-bug linux' works equally well too
<andypiper> ok I'm going to reboot that machine to get it in the right "state" and then VNC over to run that.
<andypiper> since currently the tap-to-click is in a working state at least (trackpad buttons not though)
<andypiper> did wonder if it was an xorg.conf setting I'd missed on the trackpad, but so far I've not messed with the config files
<bjsnider> codemagician, bug 441653
<ubot4`> Launchpad bug 441653 in xorg-server (Ubuntu) "radeon graphics mode and console does not start - xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system call (affects: 51) (dups: 1) (heat: 270)" [Undecided,Confirmed] https://launchpad.net/bugs/441653
<andypiper> curiouser and curiouser... on reboot, login to gdm (via keyboard) and VNC over, right-click works, left-click doesn't (from remote system)
<codemagician> bjsnider, this doesn't fit the symptoms 
<bjsnider> i think it does
<bjsnider> it's not a graphics driver bug
<codemagician> seems strange so many people link the two
<andypiper> ok logged my weird netbook issue as bug 730823
<ubot4`> Launchpad bug 730823 in xorg (Ubuntu) "Input device button/click not working on fresh Natty Alpha 3 install (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/730823
<andypiper> thanks for your help bryceh_ and understand if it's eventually deemed "not an X issue" :-)
<Sarvatt> cnd: have you already refreshed this monster 500_xi2.1.patch for xserver 1.10 final?
<cnd> Sarvatt, no, I haven't
<cnd> has 1.10 final been released/
<cnd> ?
<Sarvatt> yeah was going to throw in in xorg-edgers but this is a hell of a patch to fail on :)
<jcristau> 10 days ago?
<cnd> oh, I figured rc3 was going to be out for a while
<cnd> didn't realize final would be released 24 hours later
<cnd> Sarvatt, have you tried it to see if the patch still applies?
<Sarvatt> http://paste.ubuntu.com/577118/
<Sarvatt> haven't even looked at the hunks yet, just saw it failed and asked right away in case you already knew about it
<cnd> ahh, not bad
<cnd> Sarvatt, I can clean it up if you need
<codemagician> bjsnider, this fits my problem https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180/+bug/617994
<ubot4`> Launchpad bug 617994 in nvidia-graphics-drivers-180 (Ubuntu) "Slow performance and high CPU usage on Maverick (dup-of: 629910)" [Undecided,Confirmed]
<ubot4`> Launchpad bug 629910 in nvidia-graphics-drivers (Ubuntu Maverick) (and 1 other project) "nvidia 256.53 xorg-server 1.9.0 performance regression with antialiased text (affects: 73) (dups: 2) (heat: 310)" [High,Fix released]
<cnd> Sarvatt, but I would think it should be straightforward to fix it
<cnd> Sarvatt, in fact, I'm guessing wiggle --replace will probably take care of the failures by itself
<cnd> configure.ac and xf86Module.h changes are trivial
<Sarvatt> okie i'll fix it up
<cnd> the failure in test/input.c is interesting cause I wouldn't think it would fail
<cnd> so that could be more challenging
<cnd> but it shouldn't be hard
<bjsnider> codemagician, that bug was fixed, and everyone had that bug. all nvidia users
<cnd> Sarvatt, are the binary blob drivers fixed for 1.10 abi again?
<Sarvatt> cnd: yep since last week
<cnd> cool
<bjsnider> well, nvidia is
<codemagician> bjsnider, not sure what to say.  it happens and there is nothing running only shell windows
<Azelphur> Trying to help the nouveau people with an mmio trace for my gtx 570, in order to do so I need to reload the nvidia module. I can rmmod it fine but when I try to modprobe it it says that the module doesn't exist.
<Azelphur> Anyone know how to solve that one?
<Sarvatt> cnd: yeah that wasnt a big deal at all, it was just http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.10-branch&id=93a73993708b1345c86ec3ec06b02ed236595673 and the abi bumps
<cnd> ahh
<cnd> Sarvatt, thanks for doing that for me :)
<Sarvatt> http://sarvatt.com/downloads/patches/500_xi2.1.patch in case it comes up again when i'm not around
<Sarvatt> ugh, amd64 buildds are backed up a few hours but i386 isn't, why does that always happen when I need to rebuild the world for a new xserver abi transition? :D
<Sarvatt> (ppa's dont autoretry dep waits so uploading before xserver builds on all arches is a PITA)
<cnd> Sarvatt, are you pushing your changes to git?
<cnd> I actually have some bug fixes for that patch
<cnd> so either I merge my fixes into that refreshed patch
<cnd> or we remerge the patch with my fixes
<cnd> remerging would be easiest I think
<Sarvatt> Successfully uploaded packages.
<Sarvatt> xorg-server (2:1.10.0+git20110307+server-1.10-branch.35503964-0ubuntu0sarvatt) natty; urgency=low
 * Sarvatt groans at automated scripts uploading when he wanted to wait
<trinikrono> hey guys i found a bug 721080 and i was wondering if it was a dupe of 702090?
<ubot4`> Launchpad bug 721080 in ubuntu "[arrandale] GPU lockup a5cb7103 (IPEHR: 0x01800002) (affects: 1) (heat: 254)" [Undecided,New] https://launchpad.net/bugs/721080
<bryceh_> hi trinikrono
<trinikrono> o/
<bryceh_> trinikrono, the error codes there look different than the prototypical 702090 crash
<bryceh_> trinikrono, however the thing to check is to look in the CurrentDmesg and BootDmesg for where the "GPU hang" message is
<bryceh_> typically with 702090 this will be during boot, towards the end of the boot sequence
<bryceh_> so like either at the end of BootDmesg or the top of CurrentDmesg
<trinikrono> ok
<bryceh_> also, oftentimes there'll be more dmesg spew following the error, because it resets the GPU and keeps on truckin'
<trinikrono> because the i915errorstate makes no sense to me as yet
<trinikrono> bryceh_: so i can still mark it against xserver-xorg-video-intel right
<bryceh_> trinikrono, if you're curious to learn, there is a tool available which converts the error codes into actual messages
<bryceh_> trinikrono, yes
<trinikrono> well i am curious, i seem to be finding xorg bugs everywhere i go
<trinikrono> i use savage though if that makes a difference
<bryceh_> trinikrono, yeah it does; the GPU dumps and i915errorstate stuff is particular to the -intel driver, but savage uses the -savage driver
<bryceh_> trinikrono, here's a doc with a higher level explanation of the gpu dump stuff:  https://wiki.ubuntu.com/X/InterpretingIntelGpuDump
<bryceh_> trinikrono, I think part of the problem with -savage is that since the userbase for it is much smaller than other video drivers, us ubuntu-x guys don't pay that much attention to it
<bryceh_> trinikrono, however if you'd be interested in doing bug triage or other work on the driver, it could help a lot, and we'd certainly be able to give you tips and pointers
<trinikrono> yes i spoke to tormod a few weeks ago about some of the savage bugs , so if i can help i will
<bryceh_> cool, yes he keeps an eye on -savage and is a great resource
<trinikrono> bryceh_: in your x org bugs do we look for upstream bugreports in freedesktop or is it different?
<bryceh_> trinikrono, sometimes yes, however I tend to just forward the bugs upstream and let upstream decide whether they're dupes.  Often it's difficult for us at the distro level to know for sure
<bryceh_> trinikrono, but I do always at least google around to see if the bug has been reported anywhere outside ubuntu (and sometimes this turns up dupes inside ubuntu too)
<Sarvatt> looks like 116_xi2_1.patch in synaptics is going to be the painful one to maintain
<RAOF> Sarvatt: Fortunately, we have someone to blame! :)
<Sarvatt> RAOF: eh, our synaptics patches have always been hell to carry forward in git, not really anything new :D
<Sarvatt> all of xserver 1.10 is up in xorg-edgers now, hopefully the rest builds fine
 * Sarvatt is so sick of updating the mesa build system
<Sarvatt> had to disable nouveau-vieux in there, after about 6 hours of messing with it I got fed up and started pushing the xserver 1.10 stuff
<Sarvatt> gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I../../../../../include -I../../../../../src/mapi -I../../../../../src/mesa -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri -I/usr/include/libdrm    -Wall -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing  -fPIC  -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS -DPTHREADS 
<Sarvatt> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XCB_DRI2 -DHAVE_LIBUDEV -DXCB_DRI2_CONNECT_DEVICE_NAME_BROKEN -DUSE_DRICORE  nouveau_screen.c -o nouveau_screen.o
<Sarvatt> In file included from nouveau_screen.c:27:0:
<Sarvatt> nouveau_driver.h:40:28: fatal error: nouveau_device.h: No such file or directory
<Sarvatt> compilation terminated.
<Sarvatt> make[7]: *** [nouveau_screen.o] Error 1
<Sarvatt> need to figure out whats needed for this mesa wayland stuff ricotz pointed out still
<bryceh_> thanks Sarvatt
 * bryceh_ patch pilots
<bryceh_> Sarvatt, wayland?  I have some notes that Darxus provided on what mesa patches would be required in order for doing newer wayland snapshots
<RAOF> From memory, you need the wayland protocol stuff built first, then build mesa against that, then you can build the wayland demos with EGL support.
<Sarvatt> the patches are upstream, there's a new wayland egl platform to use but need to figure out where all the deps go
<RAOF> That sounds like a job for Super bryceh_, though :)
<bryceh_> ick :-)
<Sarvatt> also I was a bit confused about the wayland packaging, wayland-client.pc is in libwayland-client-dev, but both the library and protocol headers are in wayland-dev and there's no dependency on either of them for the other?
<RAOF> libwayland-client isn't a dependency of libwayland-client-dev?
<Sarvatt> nope
<Sarvatt> unless i'm missing something
<bryceh_> it's entirely possible I did not do that right
<RAOF> That seems unlikely to be correct.
<RAOF> Not that anyone's going to notice for a while :)
<bryceh_> splitting out the client and server bits was pretty recent, and I don't think I did much testing of the -dev packages (certainly not on a clean machine)
<Sarvatt> sudo apt-get install libwayland-client-dev
<Sarvatt> The following NEW packages will be installed:
<Sarvatt>   libwayland-client-dev
<Sarvatt> sudo apt-get install libwayland-client0
<Sarvatt> The following NEW packages will be installed:
<Sarvatt>   libwayland-client0
<Sarvatt> should wayland-client.h should be in libwayland-client-dev where the .pc is and wayland-client-protocol.h in the wayland-dev one?
<ricotz> Sarvatt, bryceh_ http://people.ubuntu.com/~ricotz/wayland/
<ricotz> moving the headers might be useful for a nicer organization
<bryceh_> sure
<RAOF> Do clients need wayland-client-protocol.h?
<bryceh_> RAOF, looks like clients don't include it directly, but instead include wayland-client.h, but then that has this:
<bryceh_> ./wayland/wayland-client.h:#include "wayland-client-protocol.h"
<bryceh_> so... yes
<RAOF> I guess this would be more obvious were we packaging a more recent snapshot where these things are actually in different tarballs.
<bryceh_> yep
<bryceh_> in fact that's one reason I didn't worry too much about the packaging at this point; I think it's going to need a pretty heavy revamp due to the split up of the repo
<bryceh_> also, it seems debian is moving away from using xsfbs, so that needs to be dropped and a more pure dh approach used instead (which I think ricotz proposed before and looks suitable)
<bryceh_> I think there's also been some changes to licensing in recent snapshots, so copyright needs to be reviewed 
<RAOF> It was certainly moving to... MIT?  Or from MIT to LGPL?
<RAOF> One of the two :)
<Sarvatt> wow, that looks to be the most painless transition ever - https://launchpad.net/~xorg-edgers/+archive/ppa/+builds?build_text=&build_state=all
<bryceh_> the latter
<RAOF> Sarvatt: Yeah, the API change from 1.10RC2 to 1.10 isn't big :)
<Sarvatt> the packaging changes were though, I figured something would break at least
<Sarvatt> I didn't change where I was syncing drivers from expecting things to break and fix it after, guess unstable worked fine
<Sarvatt> KiBi rocks :)
<jcastro> Hi! I am pretty sure I found an upstream bug related to this bug report: https://bugs.launchpad.net/xserver-xorg-driver-ati/+bug/715330
<ubot4`> Launchpad bug 715330 in xserver-xorg-video-ati (Ubuntu) (and 2 other projects) "Freeze after login with KMS enabled on Radeon HD6310 (affects: 2) (heat: 14)" [High,Confirmed]
<jcastro> however in the upstream bug report it mentions putting an option in xorg.conf
<jcastro> do I need to just have a blank file with the Option line or do I need some sort of skeleton for the file?
<bryceh_> you'll need a skeleton
<RAOF> You can get a skeleton by running âX -configureâ; I think you'll need at least a Device section to hang that Option line on.
<jcastro> ah awesome
<Sarvatt> jcastro: http://paste.ubuntu.com/577213/
<RAOF> I take it that the fusion netbook isn't a bundle of Just Worksâ¢ then?
<jcastro> RAOF: I am close! 
<jcastro> I think it's just an option that's hosing it
<jcastro> Sarvatt: that totally works!
<Sarvatt> need to disable pageflip on fusion then?
<jcastro> yeah, let me update the bug
<jcastro> and confirm with the OP
<jcastro> there are only 2 fusions shipping right now, I have one and he has the other
<Sarvatt> its a kernel bug but we could flip it over as the default option in the X driver easily until its fixed
<Sarvatt> I think i915g wants to be in dri-alternates now with 7.11 :P
<RAOF> Yeah, I think so too.
<brobostigon> !bug 730099
<ubot4`> Launchpad bug 730099 in xserver-xorg-video-intel (Ubuntu) "[i915gm] GPU lockup 0c40b170 (ESR: 0x00000001 IPEHR: 0x02000011) (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/730099
<brobostigon> isuffer from that, it not nice, that bug sucks. :(
<RAOF> Hm.  That's not going to be the gen2 relaxed alignment stuff.
 * RAOF has a browse.
<brobostigon> i need a clever man or women to explain to me, whay a gpu lockup is to start, so i know what it is.
<bryceh_> RAOF, yeah it's that i915/i945 freeze bug that ickle thought the relaxed fence patch would fix
<bryceh_> brobostigon, it's when the display stops updating, but usually you can still move the mouse and ssh in
<RAOF> 915 isn't gen2, is it?
<bryceh_> dunno
<RAOF> Oh, bah.  Yes it is :)
<Sarvatt> nope first of the gen3
<brobostigon> bryceh_: ah, i see. yes, i canstill move the mouse and ssh in, yes.
<bryceh_> brobostigon, if you want a lot more technical details, see https://wiki.ubuntu.com/X/InterpretingIntelGpuDump
<bryceh_> or for just troubleshooting directions (mostly out of date and not relevant for your case) there is https://wiki.ubuntu.com/X/Troubleshooting/Freeze
<brobostigon> bryceh_: thank you, how would this be fixed, what can i add onto the bug, to help it get fixed?
<bryceh_> I think we have a large surplus of debug info at this point ; the next action for this particular bug is blocked waiting on upstream to provide a patch
<RAOF> If it were gen2 I'd be tempted to try libdrm 2.4.24, but I don't think that codepath will apply here.
<bryceh_> RAOF, do you have ideas on other next actions for this?
<brobostigon> bryceh_: would it be possible to talk to them, to get it moving alittle,?
<bryceh_> brobostigon, I've already been poking at them, but no response (I think ickle might have been on vacation last week)
<brobostigon> bryceh_: ok, that is something atleast isnt it, thank you. :)
<bryceh_> also, since this is like 99% likely to be a bug in kernel drm code rather than X itself, it might be appropriate to try to get kernel team attention onto it
<bryceh_> brobostigon, one thing to test that might turn up some useful info would be to try reproducing the bug on a non-Ubuntu distro (debian, redhat, etc.)
<bryceh_> one that also has the 2.6.38 kernel ideally
<brobostigon> should i try a new kernel, for example  from http://kernel.ubuntu.com/~kernel-ppa/mainline/ ?
<bryceh_> that would demonstrate the bug is or is not due to something particular to the Ubuntu kernel or plumbing layer
<RAOF> It might be worth trying the new libdrm anyway.
<RAOF> I'll throw it up in aubergine.
<bryceh_> brobostigon, yes, although others have already tested the latest kernel and found it didn't change anything
<bryceh_> brobostigon, there is also the drm-next builds that the kernel team provides, which may be a better thing to test
<bryceh_> "I'll throw it up in aubergine."  If I had a sig I'd put that in it.
<brobostigon> bryceh_: i could try a debian sid, from sd, on this machine. it will take ait of work, but it could be done.
<brobostigon> installing from live usb, too sdhc.
<brobostigon> anf then booting of sdhc.
<bryceh_> brobostigon, it could help in case the kernel team isn't looking at it on the assumption that it's an upstream bug, and upstream isn't looking at it on assumption it's a ubuntu-specific issue ;-)
<bryceh_> fwiw, I have a 945 and have not seen this freeze myself
<bryceh_> however this i945 seems to be magical and is immune to half the bugs that *should* be affecting it
<brobostigon> bryceh_: would debiantesting be new enough, and then pulling the kernel from experimental?
<bryceh_> brobostigon, that seems a reasonable base for testing
<bryceh_> I don't know what kernel is in experimental, but anything 2.6.38-ish should do the trick
<brobostigon> bryceh_: ok, i will try that tommrow, and report back, 
<bryceh_> brobostigon, great, thank you
<brobostigon> its definatly, the newest stablekernel release.
<Sarvatt> its a dupe of  bug #715096
<ubot4`> Launchpad bug 715096 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "[i945gm] GPU lockup (ESR: 0x00000001 IPEHR: 0x02000011) (affects: 10) (dups: 8) (heat: 185)" [High,Incomplete] https://launchpad.net/bugs/715096
<brobostigon> different ESR and IPEHR.
<Sarvatt> kees: didn't you have that bug too? I thought I remembered you and ickle talking about it
<Sarvatt> 730099 is a dupe of 715096, 730099 isn't your bug?
<brobostigon> i filed 730099 myself.
<kees> Sarvatt: yeah, I just hit it once ever though
<bryceh_> fwiw, I suspect ALL of the i915 and i945 lockups are the same bug, even though they differ in ESRs and IPEHRs
<kees> Sarvatt: my really annoying bug is the i915 corruption
<bryceh_> I think it is a bit hw-specific and maybe conditional-specific as to what error code actually pops up, but my gut says they probably have the same underlying root cause
<brobostigon> what are ESR's and IPEHR's ?
<bryceh_> brobostigon, see https://wiki.ubuntu.com/X/InterpretingIntelGpuDump
<brobostigon> bryceh_: is that the same page you pointed me at earlier? i havent managed torread it yet,
<bryceh_> brobostigon, it is
<brobostigon> bryceh_: ok, i will read it, for bed time reading. :)
<Sarvatt> kees: ahh ok, wasn't sure if he tossed a magic patch at you that got lost or something maybe, sorry to bug ya :P
<brobostigon> thank you for you help and explanation everyone, really appreciated.
<brobostigon> good night everyone.
<bryceh_> night
<brobostigon> night bryceh_ 
<kees> Sarvatt: I just wish the corruption bug would get attention :(
<Sarvatt> kees: which?
<kees> bug 717114
<ubot4`> Launchpad bug 717114 in xserver-xorg-video-intel (Ubuntu Natty) (and 4 other projects) "[i945gm] Screen Corruption with new Xorg stack with terminal programs (affects: 14) (dups: 2) (heat: 70)" [Medium,Triaged] https://launchpad.net/bugs/717114
<Sarvatt> time to force myself to use the netbook for a day to reproduce these gen3 problems
#ubuntu-x 2011-03-08
<RAOF> kees: Looks like that might be fixed in the most recent drm-fixes pull request? (So, not yet in any kernel that you'll have access to, but stillâ¦ âº)
<bryceh_> kees, I can repro it but haven't had time to poke around with it yet
<bryceh_> RAOF, is the drm-fixes branch built by the kernel team?
<bryceh_> http://kernel.ubuntu.com/~kernel-ppa/mainline/
<bryceh_> looks like not, but they have builds of drm-next and drm-intel-next, - think the fix is in one of those?
<RAOF> I don't think so, but let's play chase-the-git-commit!
<RAOF> bryceh_: No, not in drm-next, but is in drm-intel-next.
<bryceh_> RAOF, what's the commit id(s)?
<RAOF> bryceh_: 467cffba8 (ooh!  gen2 *and early gen3*), a1656b, and 0ee537abbd
<bryceh_> thanks
<bryceh_> heh, I just finished saying my 945 never freezes, and then guess what
<RAOF> :)
<RAOF> Ding!
<bryceh_> so maybe for the betterment of our testing, we just need to get a lot more brash and braggy about how bugfree our hw is?
<RAOF> My GM45 *never* hangs!
<trinikrono> vesa never hangs!
<RAOF> (Because it's never used âº)
<bryceh_> feh, of course now I can't seem to reproduce it
<bryceh_> kees, assuming you've still been seeing the bug with the current kernel, please load the drm-intel-next kernel and run that for a day or two and see if you can verify the issue is missing there
<kees> bryceh_: I'll try, I'm in the middle of debugging some other ubuntu-specific kernel changes :P
<bryceh_> yeah I'm in the middle of patch pilot work but can bang on it tomorrow or wednesday probably
<bryceh_> (if I can ever reproduce it reliably again)
<RAOF> You know one of the biggest things I miss in git? from bzr  Being able to reference tools by their unique prefixes (bzr st, etc)
<bryceh_> RAOF, yeah
<bryceh_> been rockin' the bzr today with patch piloting
<RAOF> I think mesa 7.10.1 is ready for upload, by the way.
<RAOF> I also think that there are some cherry-picks that will fix bug #721881 (or at least turn it into a non-segfault)
<ubot4`> Launchpad bug 721881 in xserver-xorg-video-intel (Ubuntu) "compiz crashed with SIGSEGV in intel_region_data() (affects: 1) (heat: 246)" [Medium,New] https://launchpad.net/bugs/721881
<bryceh_> RAOF, how much testing has it gotten so far?
<bryceh_> i.e. is it ready to go now, or should I test it on my own hw first (which will have to wait 'til tomorrow)
<RAOF> It's had a couple of day's testing on my hardware.  It wouldn't hurt to test on yours, too.
<bryceh_> alright; better safe than sorry, I'll todo it for tomorrow
<RAOF> I'll ensure it's in cooperteam.net/Packages along with binaries.
<bryceh_> ok coo
<bryceh_> wow, we're getting wayland bug reports - bug #729614
<ubot4`> Launchpad bug 729614 in wayland (Ubuntu) "wayland-compositor crashed with SIGSEGV in wl_event_loop_dispatch() (affects: 2) (dups: 1) (heat: 18)" [Medium,New] https://launchpad.net/bugs/729614
<bryceh_> someone has actually used it :-D
 * bryceh_ wanders off
<bjsnider> bryceh_, now...you have to fix the bug
<bryceh_> heh
<bryceh_> maybe if I get bored between now and release day
<bryceh_> actually it's probably already fixed upstream, there's probably a patch that can be backported
<bryceh_> hrm, Mr. Spikey McSpike has returned to the graph...  http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg
<bryceh_> meh, just dupes of known gpu lockups.  sure wish we could get those solved
 * bryceh_ really wanders off
<LLStarks> hmmm. does sandy bridge optimus mean that the framebuffer for the discrete gpu would be on the cpu?
<RAOF> No, because the CPU doesn't have that kind of memory on it.
<RAOF> Unless you feel like taking up many megabytes worth of L3 cache with your framebuffer that you'll need to copy out to system memory anyway :)
<tjaalton> bryceh_: evtouch doesn't even build, and should be removed from the archive imo :)
<tjaalton> (re: the recently added patch)
<tjaalton> oh goodness, new unity that should fix the crashing decorator every time I send an email from tb
<bryceh_> tjaalton, ah, I knew it was obsolete.  Yeah we should get rid if it if it'll never build again
<tjaalton> well it's patchable, but it's gone from debian too, and no upstream..
<LLStarks> isn't deprecation wonderful?
<tjaalton> yep
<tjaalton> bryceh_, RAOF: thoughts about merging xorg? I haven't looked at it too closely, but at least dexconf would get removed, finally
<bryceh_> tjaalton, would be a good idea, not sure how we've missed it
<tjaalton> bryceh_: I'll prepare it today
<tjaalton> been a while..
<bryceh_> tjaalton, last week I happened to clean up most of the bugs filed against xorg - https://bugs.edge.launchpad.net/ubuntu/+source/xorg
<bryceh_> pretty much all the ones with an importance set seem to be things relevant to the xorg package now
<tjaalton> yeah I noticed, good stuf
<tjaalton> f
<tjaalton> bryceh_: the next UDS we might discuss about splitting failsafe/apport from xorg, so they could be maintained separately, to minimize the churn (and keep them on lp if appropriate)?
<tjaalton> iirc that has been planned at some point
<lag> Can any of you tell me what a CMAP (colour map) is please?
<bryceh_> tjaalton, in fact we already have a blueprint on it.  I'd planned to work on it this cycle but just didn't get to it (work on wayland took a bit more time than expected).  I can make it a focus next cycle.
<tjaalton> bryceh_: ah good
<bryceh_> in fact there already is a package with these files in universe - 'xdiagnose'
<bryceh_> so mostly is just a matter of setting up the appropriate rules and so on to transition us, and do plenty of testing
<tjaalton> yeah
<RAOF> bryceh_: I don't have strong opinions on merging xorg.  If tjaalton wants to do it, great :)
<RAOF> bryceh_, tjaalton: If you're interested in testing mesa 7.10.1 it's in http://cooperteam.net/Packages (i386 and amd64)
<tjaalton> RAOF: ok, I hear there are lot of intel changes, so I'll load it on my laptop..
<RAOF> Yup.
<RAOF> It's almost all intel fixes (mainly for sandybridge)
<RAOF> But also a bunch of glsl, etc.
<RAOF> Oh, and I pulled in a patch to make nvaf not kill X. 
<lag> Morning all
<lag> I just conducted a dist-upgrade to Natty
<lag> Which removed my Nvidia driver
<lag> When I try to install it again, apt attempts to uninstall 23 packages - what's the latest?
<tjaalton> nvidia-current is at 270.29
<lag> It was nvidia-current I tried to install
<lag> But it wants to remove btrfd-tools, libclutter, python things, and a load of libs
<tjaalton> not because of nvidia
<lag> The following packages have unmet dependencies: 
<tjaalton> please use pastebin
<lag> xserver-xorg-core: Breaks: xserver-xorg-video-8 which is a virtual package
<lag> I can't, I'm not typing any more out :)
<lag> it's on a console, no copy-paste
<tjaalton> install pastebinit :)
<tjaalton> anyway
<tjaalton> sure about not having some ppa's around?
<tjaalton> could be a stale mirror too
<lag> Oddly, my sources file still says Maverick?
<tjaalton> didn't use do-release-upgrade?
<lag> I didn't initiate it
<tjaalton> oh, who did?-)
<lag> The Update Manager
<tjaalton> you said "dist-upgraded"
<tjaalton> so I thought you ran apt-get by hand
<lag> Yes, it did a dist upgrate
<lag> upgrade*
<tjaalton> well the upgrader probably failed and it fell back on maverick?
<lag> It said it has competed successfully 
<tjaalton> run do-release-upgrade -ed
<tjaalton> uh, -d
<lag> I've just initiated another full upgrade
<tjaalton> so sources.list is full of maverick, or both m and n?
<lag> There were no m
<lag> s/m/n
<tjaalton> probably ask mvo how that could've happened
<mvo> lag: could you mail me the logs in /var/log/dist-upgrade/* (or file a bug) please?
<lag> mvo: I'll take a look when my (second) upgrade has finished
<mvo> ok
<lag> tjaalton: mvo: Same deal
<tjaalton> RAOF: can't connect to your server
<tjaalton> lag: file a bug against update-manager then (ubuntu-bug update-manager)
<lag> Woooooooooooo
<lag> I'm in 
<mvo> to diagnose this, we need the logs
<lag> What a nuisance 
<RAOF> tjaalton: Try again?
<lag> mvo: One step at a time
<tjaalton> RAOF: yeah, works now
<lag> mvo: Okay, I still have issues
<lag> mvo: What logs are going to be of most help to you?
<lag> dmsg, gdm
<mvo> lag: if you used update-manager or do-release-upgrade for the upgrade /var/log/dist-upgrade/* will contain what is needed
 * mvo will be away for lunch for a couple of minutes now
<asac> RAOF: hey ... do you know if "00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)" gallium is now working in natty or xorg-edgers?
 * asac would like to have that ;)
<RAOF> You want gallium on that?  I don't believe 965g has seen more than a handful of commits since last I tested it, and then it immediately hung the GPU pretty much regardless of what I threw at it.
<RAOF> Now, if you had a slightly older GPU, i915g is getting to the point where we might want to ship it in dri-experimental :)
<lag> mvo: You are now in possession of my logs
<RAOF> asac: Why do you particularly want gallium support for that?  egl_dri2 should give (complete?) GL|ES1 and GL|ES2 support with the classic driver.
<RAOF> But not OpenVG, and I guess there may be differing levels of extension support.
<asac> RAOF: hmm. are there packages for maverick? guess not right?
<RAOF> UUuuuumâ¦ dunno :)
<asac> RAOF: i want GLES2 accell ... not more
<RAOF> Works in Natty, then :)
<asac> RAOF: if there are other ways to achieve that i ma happy
<RAOF> (And should in xorg-edgers)
<asac> RAOF: maverick in xorg-edgers
<asac> '
<asac> ?
<RAOF> Just checking.
<RAOF> Yup, I think so.  xorg-edgers has a shiny trunk snapshot of mesa, and should build egl_dri2.
<asac> ok what was the script that helps downgrading to archive version for that stuff again?
 * asac wants to be save
<RAOF> ppa-purge.
<RAOF> Available in xorg-egders and also in Natty universe :)
<asac> thanks ... i will try ;)
<brobostigon> i was talking to someone last about trying to confirm 730099, and trying a non-ubuntu kernel, howeer it reminded me, that only a couple of weeks ago, i had debian sid on my eeepc, and no gpu lockup problems, so it confirms what wnted to test, because of my memory failiure.
<lag> mvo: Are you back from lunch yet?
<lag> mvo: I'm guessing this may have something to do with my issue: Xorg:1258 conflicting memory types c0000000-c0960000 write-combining<->uncached-minus
<tjaalton> umm, a failure to dist-upgrade from 10.10 has little to do with X
<mvo> lag: hello, the logs have some uncommon pattern, I wonder what was triggering the conffile prompt for /etc/lsb-release ? did you modify this file manually? it seems the actual problem is a postinst failure from seamonkey-browser, but the error message is very odd (/var/lib/dpkg/info/seamonkey-browser.postrm): No such file or directory)
<lag> I haven't modified lsb-release, only read it (to make sure the update was successful 
<lag> )
<mvo> lag: I can not say much about why gdm does not start anymore, but the error look not good :/
<lag> I did manual edit /etc/apt/sources.list
<lag> I s/maverick/natty
<tjaalton> mvo: a case of the "top of the list" dpkg bug? (the one with gazillion dupes)
<mvo> lag: is ther a /etc/lsb-release.dpkg-old  or something like this still left? if so, could you pastebin it please?
<lag> But that was to 'fix' the already occurred problem
<mvo> tjaalton: well, the seamonkey one is the origin of the failure cascade, but it is a odd failure
<lag> Should I try to uninstall it and do another upgrade?
<lag> Where did you see the failure?
<mvo> lag: I was looking at apt-term.log
<lag> tjaalton: It must have something to do with it
<lag> tjaalton: I upgrade, x stops working
<mvo> hm, actually this looks like a old log 
<lag> Okay
<tjaalton> lag: but because of the incomplete upgrade, not due to some drive bug
<lag> tjaalton: Well I've never seen it before
<lag> tjaalton: The kernel has been upgraded too
<tjaalton> of course
<lag> More timestamps and less DOS EOLs needed in the logs me thinks
<lag> Oh I see, they're not EOLs they're backspaces
<cnd> lag, the device.event file you sent me is empty
<cnd> at least, that's what thunderbird tells me
<cnd> I don't know whether to believe it or not :)
<lag> cnd: It is on my desktop too
<cnd> lag, that's odd
<lag> cnd: I can't create another one just yet, as I'm having major dramas with my Desktop
<cnd> lag, when you go to create it, chvt to a console
<lag> cnd: I don't know why it would be empty though, I followed the instructions very carefully 
<cnd> some X drivers, synaptics in particular, grab the event device node
<cnd> oh wait, that's in the instructions
<cnd> hmm
<cnd> lag, you did touch the screen to generate events, right :)
<lag> No?
<cnd> oh, I guess I need to make that clear :)
<lag> That'll be it then :)
<lag> I guess you did :)
<cnd> you need to generate events for the recording
<lag> I'll do it again, when I can log back in to my Desktop
<lag> mvo: Any advice on that?
<cnd> lag, ok, thansk!
<tseliot> Sarvatt: when are we going to have xserver 1.10 RC3 in Natty? (just to know when I should upload nvidia)
<Sarvatt> tseliot: could do it today if you want to sponsor ~50 packages :P xorg-edgers is up to date
<tseliot> Sarvatt: 50 might be a bit excessive, given my todo list ;) Good to know that it's in xorg-edgers
<Sarvatt> i'm not sure though, need to ask RAOF and bryce and see if they have any plans yet, I've had my head in the sand doing other stuff
<Sarvatt> it's a pretty painless transition though, 2 xserver patches upstream already and one that needed an easy refresh, everything else just needs rebuilds
<tseliot> ah, that's good
<Sarvatt> haven't been able to reproduce any kind of text corruption on gen3 intel darnit
<tjaalton> RAOF: the mesa seems to work fine, no gpu hangs on 965GM unlike with 7.10
<tjaalton> the _new_ mesa, that is
<tjaalton> bryceh_: btw, you haven't pushed the latest xorg changes to git
<tjaalton> whee, waltop tablets work just fine on natty, need to switch 50-wacom.conf to match it
<bryceh_> tjaalton, pushed
<Sarvatt> any objections to doing something like this for ati to fix jcastro's bug? http://sarvatt.com/downloads/patches/palm_disable_pageflip.patch
<Sarvatt> https://bugs.launchpad.net/xserver-xorg-driver-ati/+bug/715330
<jcastro> Sarvatt: it has some issues resuming from suspend, but I haven't investigated
<cnd> bryceh_, do you know when the next xorg-server upload will be?
<Sarvatt> do we need a FFe for it?
<bryceh_> Sarvatt, yeah probably 
<bryceh_> cnd, within the next week or so probably
<cnd> bryceh_, ok, I've pushed some bug fixes and am working on one last issue right now
<cnd> they don't have to go in asap, so it can wait
<bryceh_> cnd, oh thought you meant when were we going to do the xserver abi bump
<cnd> I mean package upload for xorg-server
<cnd> whether or not it includes any abi bumps
<bryceh_> cnd, ok thanks for letting me know. 
<Sarvatt> cnd: looks like we're on the same flight to/from budapest along with the rest of the world
<cnd> Sarvatt, cool :)
<cnd> let me see what seat I am
<Sarvatt> I dont have a seat yet, just booking it now
<cnd> Sarvatt, I'm at 25G both ways
<cnd> Sarvatt, though I doubt you're on the same flight as me going to budapest
<cnd> I'm going for the design sprint the week before too :(
<Sarvatt> oh whoops, didn't look at the date
<cnd> yeah, tricky tricky :)
<Sarvatt> well shoot, I accepted it because I thought you and vanhoof would be on it but you're both going early, whoops :P
<Sarvatt> seat in front of you has power but you don't, boo
<cnd> really?
<Sarvatt> cnd: at least it isn't 1 week each in shanghai then portland then 2 weeks in budapest like vanhoof has to do :D
<Sarvatt> http://www.seatguru.com/airlines/American_Airlines/American_Airlines_Boeing_767-300_B.php
<cnd> Sarvatt, oh well... I don't usually try to do work on these flights
<cnd> too hard
<cnd> and I should be sleeping on the flight over
<bryceh_> cnd, xserver uploaded
<cnd> bryceh_, oh, thanks!
<LLStarks> is -nv gone from the default archive now?
<tjaalton> LLStarks: not yet
<tjaalton> bryceh_: thanks!
<RAOF> Sarvatt: Yeah, that disable-pagefilp patch looks like a good idea.
<bryceh_> so, I've lost track a bit, but is the latest -nvidia support the latest xserver abi bump?
<bryceh_> if that's the case, then should we think about updating to the xserver with this abi now?
<RAOF> If it does, then yeah.  We should move to 1.10 final.
<bryceh_> RAOF, do you want to go ahead and prep the package upload?
<RAOF> Yup.
<bryceh_> I'll find out what the -nvidia situation is
<bryceh_> I think we're good, but just to doublecheck
<tjaalton> that should then wait for tseliot to prep nvidia?
<tjaalton> he was asking for the schedule this afternoon
<bryceh_> tjaalton, ahh, ok
<bryceh_> tjaalton, yeah maybe we should set up a staging ppa for this
<bryceh_> then we can put all the bits and pieces together in there and do test upgrades
<tjaalton> or prepare the packages and we'll upload them tomorrow when we're around
<bryceh_> right.  my earlier statement was ambiguous, I was meaning the thinking should be done now, not the upload ;-)
<tjaalton> yeah, sure
<RAOF> We should certainly coordinate with tseliot.  After all, that's why we haven't updated already :)
<bryceh_> ok, looks to me like everything is good to go on the proprietary driver front, but I'll shoot off another coordination email with tseliot and everyone
<RAOF> And I'll stop trying to debug this unity deadlock and get on the packaging.\
<bjsnider> RAOF, the 270.30 driver works with 1.10 final, and tseliot is waiting for that to be uploaded before he send the blob in. 
<bryceh_> alright, I've emailed tseliot and cc'd raof and others
<bryceh_> RAOF, I think we can just reuse https://edge.launchpad.net/~ubuntu-x-swat/+archive/ppa for staging purposes
<bryceh_> this is pretty much what was in mind when that was set up originally anyway
<tjaalton> can the packages get pulled from the ppa to the archive, or would it need another round of uploads?
<bryceh_> tjaalton, I think we'll have to do another set of uploads
<tjaalton> since if it's the latter, I'd just shove them in the archive. the diff to the current stack is small
<bryceh_> it's more the abi change I'm concerned with than actual bugs
<tjaalton> rebuilds take care of that, and versioned depends
<tjaalton> versioned build-depends
<bryceh_> yeah, but in theory that should have worked last time too
<tjaalton> well there are packages we are not in charge of
<tjaalton> but -video-all doesn't depend on them (like vbox)
<tjaalton> or maybe I'm missing something :)
<bryceh_> tjaalton, RAOF and I found that when we bumped the ABI going from 1.9 to 1.10 that even though we both tested the individual packages and .debs thoroughly, there were bugs we missed because we installed the .debs individually, resolving dependencies by hand.
<bryceh_> so we felt it would be a better practice and not that much additional effort, to stage the packages in a ppa first, so we can easily do test upgrades
<bryceh_> tjaalton, it seems that as ubuntu has evolved, the tolerance for cowboying in xserver changes has decreased a lot since a couple years ago ;-)
<tjaalton> meh :)
<bjsnider> gee, i wonder why?
<tjaalton> those bastards breaking blobs again?-)
#ubuntu-x 2011-03-09
<RAOF> Man this regex is getting evil.
<RAOF> It's aliveâ¦ it's ALIVE!
<RAOF> That's rather nice.  3 build failures, two of which were an insufficiently sentient regex.
<tjaalton> sigh, chromium is not that usable (for my workflow), and firefox keeps "hanging" every 10s for 1s, what else is there.. opera?
<RAOF> That firefox thing seems pretty awful.  What's it doing?
<RAOF> It's not doing something brain-dead like fsyncing the history database again?
<tjaalton> beats me. the cpu-usage spikes every few seconds, and that's when scrolling etc is paused
<tjaalton> even typing a comment on a bug..
<RAOF> :(
<RAOF> Know of any useful ati cherry-picks offhand while I'm patching it to build against 1.10?
<tjaalton> ah there's no 6.14-branch for bugfixes..
<tjaalton> there was something on debian-x@ iirc, unless it was that build-fix
<RAOF> Probably the build-fix.
<RAOF> The changelog entries post-6.14 don't link to any bugs not caused by commits post-6.14.  I think I'll just fix the build then :)
<tjaalton> yeah, can't seem to find it either
<RAOF> Ooh.  I should add Sarvatt's disable-pageflip-on-palm patch.
<bryceh_> yeah that firefox laggy behavior is really irritating.  I'm using chromium now because of that.
<tjaalton> I'm trying with some extensions disabled, but we'll see if it helps or not
<tjaalton> what's most irritating with chromium is that typing '/' doesn't initiate search, and tabbing on the address bar doesn't select the next one on the list, need to use the cursor keys
<tjaalton> and there's a limit of tabs per window, since you can't see the title
<bryceh_> yeah
<tjaalton> there should be a 'firefox compatibility' -extension for it :)
<bryceh_> I do like that the location bar doubles as a search field, but I miss the reliable autocomplete
<RAOF> The awesome bar is actually pretty awesome, yeah.
<bryceh_> best thing so far about chromium is I can right click on my bug graph svg's and choose "Open in a new window"
<bryceh_> the fact I can't do that in firefox has been a bit of a bummer
<tjaalton> btw, since when does neither of them open the windows on the correct workspace?
<tjaalton> probably a compiz bug, annoying
<RAOF> Alright.  Once the builds are done, ubuntu-x-swat/ppa should be nicely installable.
<tjaalton> hum, I should prepare -fpit
<bryceh_> RAOF,  :-)
<RAOF> Let's go make some pasta!
<Amaranth> yay mesa 7.10.1
<tjaalton> building xinput-calibrator_0.7.5-1
<Amaranth> dang, still can't do fullscreen youtube
<Amaranth> will have to try intel-drm-next tomorrow
<tjaalton> bryceh_, RAOF: objections for pushing xinput-calibrator to natty? it's not in debian yet for some reason (been on the mentors-queue for some time), sent an email to Tias about the status but haven't heard back yet
<tjaalton> http://www.freedesktop.org/wiki/Software/xinput_calibrator
<bryceh_> tjaalton, no objections, in fact I think packaging it was down in my todo list somewhere
<tjaalton> bryceh_: yeah I was about to do it too, then noticed that tias had done it himself
<tjaalton> built without any warnings/errors
<RAOF> No objections, but you'll need the obvious FFe.
<tjaalton> yep
<bryceh_> tjaalton, IIRC when I played with it, it spit out stuff you paste into xorg.conf.  I thought it could use a bit more integration so it actually would offer to store that info to /etc/X11/xorg.conf.d/ or some such
<bryceh_> tjaalton, of course that was like >1 yr ago so maybe it's changed
<tjaalton> bryceh_: yeah, would be nice to integrate that with the installer
<tjaalton> for now it'd just be a replacement for the calibrator in evtouch
 * bryceh_ nods
<lag> bug 731810
<ubot4`> Launchpad bug 731810 in linux (Ubuntu) "X is broken post upgrade to Natty (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/731810
<lag> mvo: tjaalton: Take a look at the currentDmesg.txt
<tjaalton> lag: attach Xorg.0.log too
<lag> tjaalton: It just says out of memory
<tjaalton> did you get your upgrade issues sorted?
<lag> tjaalton: Uploaded
<lag> tjaalton: This is my upgrade issue
<tjaalton> yesterday you said that sources.list was still on maverick, and nvidia wouldn't install due to that
<tjaalton> anyway, try putting 'nopat' to the kernel cmdline
<tjaalton> as a kernel boot option
<lag> tjaalton: I saw that on a previous bug report
<lag> tjaalton: I have just installed the latest nVidia driver from their website
<tjaalton> uh
<tjaalton> no
<tjaalton> it won't work
<lag> :(
<lag> Why not?
<tjaalton> unless it's the beta driver
<tjaalton> this is a kernel bug
<tjaalton> does 'nopat' help?
<lag> Don't know yet
<tjaalton> does the nouveau driver work?
<tjaalton> if you purge nvidia
<lag> tjaalton: Trying nopat now
<lag> tjaalton: I think I'm going to have to uninstall nVidia's driver
<tjaalton> please :)
<lag> Okay, that's now uninstalled - trying nopat
<tjaalton> nopat with nvidia didn't work?
<lag> Not with nVidia's driver
<lag> Trying it with nvidia-current
<lag> Just a purple screen
<tjaalton> try without nvidia
<lag> Now some flashing (after 5muns)
<tjaalton> so it'd load nouveau
<lag> nvidia-cirrent is still installed
<tjaalton> purge it
<lag> [    43.639] (EE) Failed to load module "nvidia" (module does not exist, 0)
<tjaalton> remove xorg.conf
<lag> Ooooooooo
<lag> We have a login prompt 
<lag> We have desktop
<tjaalton> ok so it's a bug in nvidia after all..
<lag> So what aren't I going to get?
<lag> Compiz?
<tjaalton> right
<tjaalton> there's libgl1-mesa-dri-experimental, but it's pretty much unsupported
<lag> And I don't get a choice as to which desktop I want
<lag> And everything looks just a little bit crap
<lag> Do you think I should try to install nvidia-current again?
<tjaalton> unity2d should work
<lag> I don't get a choice
<lag> No selection items at the bottom
<lag> I'm going to try and install nvidia-current again
<lag> No joy
<lag> That sucks ass
<lag> Who picks up nvidia-graphics-drivers (Ubuntu) bugs?
<tjaalton> tseliot
<tseliot> what's up?
<lag> tseliot: bug 731810
<ubot4`> Launchpad bug 731810 in nvidia-graphics-drivers (Ubuntu) ""conflicting memory types" -> "Failed to allocate primary buffer: out of memory" (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/731810
<tjaalton> tseliot: nouveau works, nvidia fails :)
<lag> s/:)/:(
<tseliot> lag: can you try to disable grub's bootsplash?
<lag> tseliot: I took out splash from the cmdline
<lag> No difference 
<tseliot> lag: that would be plymouth's splash
<tseliot> it's not the same thing
<lag> tseliot: Okay, how do I take out Grub's?
<tseliot> lag: can you attach your grub.cfg, please?
<lag> tseliot: Done
<tseliot> lag: since this is just a temporary thing, please try editing that file as in this patch:
<tseliot> http://pastebin.ubuntu.com/577746/
<tseliot> then do *not* update grub but just reboot
<tseliot> if this works I think I can fix it in the nvidia package
<lag> tseliot: Do I have to install nvidia again then?
<tseliot> lag: no, if it's already installed there's nothing else you should do but reboot
<lag> It's not
<lag> I had to uninstall it to get a desktop up
<tseliot> lag: ok, reinstall it then
<lag> tseliot: Doing that now
<tseliot> good
<lag> tseliot: How do I change back settings - will they rectify after one reboot or will I have to revert the patch?
<tseliot> lag: if you do update-grub your changes will go away
<lag> tseliot: Nope
<lag> tseliot: I received a loging
<lag> login*
<lag> tseliot: After logging in, the first window opened (Xchat) then crashed
<lag> tseliot: http://paste.ubuntu.com/577753/
<tseliot> lag: can I see your dmesg, please?
<lag> tseliot: http://paste.ubuntu.com/577762/
<tseliot> lag: the framebuffer is still there. Can I see your grub.cfg?
<lag> tseliot: Which one? The edited, or non-edited?
<tseliot> lag: the one that you used when booting
<lag> tseliot: http://paste.ubuntu.com/577768/
<tseliot> hmm... let me see how I did it in my natty machine
<tjaalton> x loaded fine this time did it not?
<lag> tjaalton: Well, I don't think fine is the word I'd use
<lag> The whole thing locked up on login
<tjaalton> lag: but x loaded up
<lag> tjaalton: Something did
<lag> I saw the outline of the first app that was visible (XChat)
<lag> Then nothing ...
<tjaalton> so you autoload apps on your session?
<tseliot> lag: I lost the changes to my grub.cfg file but I guess we can edit the file a little better
<lag> tjaalton: I do
<lag> tjaalton: If I had to load them all by hand every day, I'd shoot myself!
<tjaalton> lag: so the system locks up completely, or does for instance the mouse cursor move?
<lag> Mouse moves and even changes to the resize cursor when over the edges of the window
<lag> But I can't actually resize
<tjaalton> so the session is broken, not the driver
<lag> Everything's working in the background, I can SSH in
<tjaalton> that's natty for you
<tjaalton> try with a classic desktop
<lag> That is with the Classic Desktop
<tjaalton> unity is broken here as well
<tjaalton> then with a clean session
<lag> How do you mean?
<tjaalton> failsafe gnome session
<tjaalton> for instance
<tjaalton> dunno where the session stuff is stored
<tjaalton> ah, seems to be .config/gnome-session
<tjaalton> nope
<lag> tjaalton: I'll have to do it in a minute, as I have a meeting now
<tjaalton> .config/autostart maybe
<tseliot> lag: please try this: http://pastebin.ubuntu.com/577777/
<tjaalton> tseliot: X is up
<tseliot> tjaalton: yes, it is but vesafb can cause a number of problems with some nvidia and amd cards, not only prevent X from starting
<tseliot> and vesafb is still in his dmesg
<tseliot> tjaalton: if it's a bug in Unity i.e. it can't be reproduced using the classic desktop, then it's a different issue
<lag> Hi honey, I'm home
<lag> tseliot: 
<lag> [    44.690] (EE) Failed to load module "nv" (module does not exist, 0)
<lag> [    44.690] (II) LoadModule: "vesa"
<tseliot> lag: that's not a problem
<tseliot> it's just the autoloading stuff
<lag> Okay
<tseliot> lag: you have to make sure that dmesg | grep vesa doesn't return anything
<tseliot> lag: the last diff that I gave you should help
<tseliot> http://pastebin.ubuntu.com/577777/
<lag>         set gfxpayload=text
<lag> I did that
<tseliot> lag: and remove the line that loads the modules
<tseliot> i.e. if [ "$linux_gfx_mode" != "text" ]; then load_video; fi
<lag> tseliot: Yep, it's gone
<tseliot> lag: so, what's the output of "dmesg | grep vesa"?
<lag> tseliot: Rebooting now - the dmesg was full of crap
<tseliot> ok
<lag> tseliot: No Vesa stuff
<tseliot> lag: good. Now see if you can reproduce the problem
<tseliot> if you still can, then it's a different issue
<lag> Yep, still there
<tjaalton> how do you know you're starting the classic desktop?
<lag> What log will be most useful now?
<tjaalton> unless you've chosen it from the gdm menu
<lag> I did choose it from the menu, the same thing happened
<tjaalton> then move your .config/autostart away
<tjaalton> further advice probably from #ubuntu-desktop
<tseliot> this command should tell you whether you're running unity "grep -i unity ~/.xsession-errors"
<tseliot> instead of the classic desktop
<lag> Okay, rebooting
<tjaalton> classic still shows unity-window-decorator there
<lag> In fact, with the driver installed I don't get a choice 
<lag> No option at the bottom of the login prompt
<tseliot> ouch
<tjaalton> do you still have maverick on sources.list?
<lag> Starting unity-window-decorator
<lag> That's the only thing it says
<tjaalton> create a new user and try with that
<lag> tjaalton: Lookup
<lag> tjaalton: Lockup*
<tjaalton> then it's something for #ubuntu-desktop
<lag> tjaalton: Nice demonstration of your Teflon shoulders there :D
<tjaalton> lag: well debugging this started over 4h ago
<tjaalton> and debugging user sessions is not my expertise
<apw> does anyone know if vesafb does content handoff to the X server; like the drm drivers do?
<jcristau> doubt it.
<cnd> tjaalton, heard of any trackpad issues lately?
<cnd> a bunch of fixes were pushed to xorg-server yesterday and Kaleo is reporting issues with his trackpad
<cnd> I'm wondering if anyone else is having issues
<tjaalton> cnd: haven't seen any new bugs related to that
<cnd> tjaalton, ok, thanks!
<Sarvatt> lag: try booting with nopat added to grub
<lag> Sarvatt: I did
<tjaalton> suggested already :)
<Sarvatt> oh, missed that
<lag> Sarvatt: I also found that on an old bug report :)
<Amaranth> btw, I found the cause of my excessive i915 wakeups
<Amaranth> Apparently both evolution and thunderbird are drawing a _lot_, I'm guessing it's the constant progress spinners
<codemagician> bjsnider, hi. I have a new xorg.log from todays crash. did you add more debug to it?
<codemagician> bjsnider, http://pastebin.com/jjHCe0FR
<codemagician> This was X hanging on bootup before any applications started up.  My hardware is Asus EN210 (GeForce 210) Nvidia card with 10.10 ubuntu desktop.  If anyone can help diagnose why X keeps hanging and reaching 100% cpu, would be most appreciated...
<bjsnider> there's a generic error message printed on line 327
<bjsnider> codemagician, http://www.nvnews.net/vbulletin/showthread.php?t=46678
<bjsnider> do that thing
<codemagician> okay
<codemagician> bjsnider, I guess I should read the link on part 1 for stability?
<bjsnider> couldn't hurt
<bjsnider> codemagician, you know you can use the nouveau driver instead of nvidia right?
<codemagician> may I ask.. why does the log show different version of the kernel to my uname output?
<codemagician> bjsnider, i didn't know that.
<bjsnider> if you remove nvidia-current and delete /etc/X11/xorg.conf and then reboot you'll get nouveau
<codemagician> how to I remove the nvidia-current with sudo apt-get remove ?
<bjsnider> right
<codemagician> is nouveau another alternative driver?
<codemagician> i mean... why are there two 
<bjsnider> you must be very new to linux if you're asking why there are two
<codemagician> bjsnider, yes, I recently switched from imac
<codemagician> i guess its open source
<codemagician> and nvidia are proprietary?
<bjsnider> nvidia is a proprietary driver produced by nvidia. its license is incompatible with the gpl. nouveau is an open gpl driver already in the kernel produced by many developers
<codemagician> aha, I see 
<bjsnider> but mostly ben skeggs of red hat (i think that's his name)
<codemagician> do I need to remove nvidia-current-modaliases  nvidia-settings ?
<bjsnider> no
<codemagician> so now I just delete the xorg.conf and reboot?
<bjsnider> codemagician, why didn't you want to use the excellent mac osx?
<codemagician> bjsnider, I like to get my hands dirty
<bjsnider> it's such fun to use and so delightfully expensive
<codemagician> bjsnider, linux seems more fun to learn
<bjsnider> is this situation you're in now fun?
<codemagician> bjsnider, actually the most annoying thing about the iMac was the mouse acceleration
<codemagician> bjsnider, ha ha. good point. well its new install, so I should give it a chance
<bjsnider> you're installing ubuntu on an imac?
<codemagician> bjsnider, rome wasn't built in a day
<codemagician> bjsnider, i gave the mac to my sister and built a new machine
<bjsnider> you built this computer from scratch?
<codemagician> bjsnider, yeah, built from parts
<codemagician> bjsnider, i7 core, P6 asus Mobo, X-25 SSD
<codemagician> bjsnider, I went for the graphics card because its got a big heatsink with no fan
<codemagician> bjsnider, i like the silence
<bjsnider> that should work fine
<bjsnider> you nough all-intel, which is the right move
<bjsnider> bought, i mean
<codemagician> i checked on linux compatible websites first
<codemagician> i was tempted to go for the i5 with built in GPU
<codemagician> but I thought having nvidia was going to give me more flexibility in future
<bjsnider> and you're using maverick?
<codemagician> i've always had nvidia graphics cards and they've always been great
<codemagician> yes, maverick
<bjsnider> how did you install ubuntu? where did you get it?
<codemagician> would it have been better to go for LTS version
<codemagician> I downloaded from ubuntu directly and made a USB pen
<codemagician> using the windows USB installer app
<bjsnider> are you dual-booting or something?
<codemagician> no, i used a separate laptop
<codemagician> i have a windows laptop so I can test websites with IE
<codemagician> I'll try a reboot now
<codemagician> hopefully i'll be back in a moment
<bjsnider> i would have used the amd64 desktop install cd
<codemagician> i have intel processor
<codemagician> i read online that 32bit version would give more choice of packages
<codemagician> i'll reboot. back in a moment!
<codemagician> I'm on Nouvea now
<bjsnider> codemagician, amd64 covers all 64-bit processors except the itanium
<codemagician> I assumed amd meant AMD processors only
<bjsnider> intel uses amd's code that allows 32-bit code to run on a  64-bit processor
<codemagician> aha, i see
<codemagician> i followed the sheep
<codemagician> performance isn't really an issue
<codemagician> just stability
<bjsnider> i386 gets you an easier time with flash, maybe some 3d games if that's your thing. otherwise amd64 is faster
<codemagician> the adobe flash player crashes my firefox every other youtube video
<bjsnider> ooooook
<apw> bryceh_, about?  i've almost got a PPA to test for the vesafb triggered GPU hangs
<Sarvatt> Amaranth: ^^
<Amaranth> cool
<Amaranth> is there a ppa for intel-drm-next?
<Sarvatt> just http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/
<apw> bryceh_, well once the kernels finish building my ppa:apw/purple is worth a test
<Amaranth> whoops, if you install an image without installing the headers first you get lots of dkms failure fun :)
<bryceh_> apw, awesome
<bryceh_> apw, ok, I'll keep an eye on the build and go beat the bushes for testers once the .deb is ready.  thanks!
<Amaranth> ok so it seems drm-intel-next has some really weird failure
<Amaranth> gdm starts and I even get a tooltip because the mouse is on something but the keyboard and mouse don't work and based on the way the power button and ctrl-alt-del work I think X isn't getting keyboard/mouse grabs
<Sarvatt> hmm, quite a lot of things on https://launchpad.net/~sarvatt/+uploaded-packages show failures to build in the archive now because they were copied to a screwed up test build archive but they built in ubuntu fine, what the heck
<RAOF> Amaranth: That sounds like X just hasn't loaded any input drivers.
<Amaranth> RAOF: why would changing the kernel cause that?
<RAOF> Dunno?
<RAOF> Did you happen to change anything else at the same time?
<RAOF> Can you flip the keyboard into raw mode and VT switch?
<Sarvatt> if you move the mouse, switch to a vt and come back is the mouse in a different spot?
<RAOF> Of course, you can only switch to a VT if (a) X has loaded a keyboard driver or (b) you've raw-mode'd the keyboard :)
<Sarvatt> chvt over ssh
<RAOF> Well, that too.
<Sarvatt> looks like page flipping might be a problem on agp radeons too, need to keep an eye out on ati freeze reports and have them try disabling it
<Sarvatt> darn, vish isn't here
<Sarvatt> I remember him saying his rv515 was freezing on .38
<Sarvatt> may end up having to make that disable pageflip on palm patch disable unconditionally by default
<RAOF> Sarvatt: Do we have any metrics on that?  Obviously my radeon hardware is perfectly happy with pageflip.\
<Sarvatt> nope, just something to keep an eye on for now
<Sarvatt> ati bugs must be going to other packages, hardly anything in natty
<Sarvatt> compiz/unity soaking up all our bugs? :P
<RAOF> >:)
<Sarvatt> here's one potentially https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/725580
<ubot4`> Launchpad bug 725580 in xserver-xorg-video-ati (Ubuntu) "black screen on boot on radeon 9200 (affects: 2) (heat: 347)" [Undecided,Incomplete]
<Sarvatt> info->ChipFamily <= CHIP_FAMILY_RV350 would cover a big chunk of the AGP's
<RAOF> Heh.
<Sarvatt> err can just do all agp directly instead of chip families if it turns out to be the case, yeah i need to get off the pc for the night :P
<Sarvatt> info->cardType == CARD_AGP
<Sarvatt> hmm https://bugzilla.kernel.org/show_bug.cgi?id=30052#c10 and https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/727620 seem to conflict
<ubot4`> bugzilla.kernel.org bug 30052 in Video(DRI - non Intel) "Fails to start X with intel+Ati video, whith modeset=1" [Normal,New]
<Sarvatt> ahh acer, bah :)
#ubuntu-x 2011-03-10
<evilvish> Sarvatt: hey o/ 
<evilvish>  <Sarvatt> I remember him saying his rv515 was freezing on .38
<evilvish> Sarvatt: i think i'v narrowed the issue down to kernel .35 , either due to  drm/radeon/kms: add missing copy from user (or) (drop after 2.6.35) drm/radeon/kms: add ioport register access (or) Add support for the ATIF ACPI method to the radeon driver
<evilvish> but this random X freeze is really not being easy to catch :s
<RAOF> Aah, cargo-culting x86-64 assembler.
<RAOF> It's the way of the future :(
 * tseliot got "Transfer aborted.  Data connection closed" when uploading a package to a PPA...
<Sarvatt> tseliot: try using upload.ubuntu.com instead of ppa.launchpad.net as the fqdn in ~/.dput.cf?
<tseliot> Sarvatt: wouldn't this make my package end up in Ubuntu?
<Sarvatt> i used to get that a lot from ppa.launchpad.net and switched mine over
<tseliot> ah
<tseliot> thanks for the tip :)
<Sarvatt> tseliot: launchpad might have just gone read only?
<Sarvatt> thought i read a mail about maintenance today
<Sarvatt> Starts: 09.00 UTC 10th March 2011
<Sarvatt> Expected back by: 10.30 UTC 10th March 2011
<tseliot> yes, I read that email too
<Sarvatt> wonder if they meant EST instead of UTC lol
<Sarvatt> nah its up
<tjaalton> yeah it was down earlier
<Sarvatt> RAOF: forgot to bump debian/videoabiver so all the drivers with old xsfbs in ubuntu-x-swat/ppa think they need abi 9
<Sarvatt> (good thing we staged that in a PPA eh?)
<tseliot> that was the idea ;)
<tjaalton> changes were not pushed to git, so hard to review them
<tseliot> ah
<tjaalton> though it's a bit late to complain about that :)
<codemagician> bjsnider, hi. I'm still getting crashes using the Nouvea drivers
<codemagician> bjsnider, i get an error in the logs "Detected GPU lockup"
<bjsnider> codemagician, are you starting to believe you made a bad choice of video cards?
<codemagician> bjsnider, i thought you had the same card?
<bjsnider> i have the same gpu, but a different card
<codemagician> bjsnider, do you think its hardware related or software?
<codemagician> or maybe something is corrupt with my install
<bjsnider> yes to all 3
<codemagician> what's the best approach to solving this
<soreau> Sarvatt: ping?
<Sarvatt> soreau: heya, whats up?
<soreau> There is a bug in xorg-edgers repo that breaks xv on r3-5xx cards. Installing ddx master manually fixes the issue.
<Sarvatt> natty?
<soreau> The problem is that there is a colored pattern of green and pink when playing xv video in any player
<soreau> No, 10.10
<soreau> I have this issue ob rv350 and someone else has it on x600
<soreau> on*
<Sarvatt> dropped maverick in there because I can't keep up with the updates on top of work so it hasn't been updated in quite some time :(
<soreau> Aw :/
<Sarvatt> sounds like it was fixed upstream in the ddx though
<soreau> Yea upstream is fine
<Sarvatt> i'll update it real quick
<soreau> Is there any way we could update it at least until natty official release?
<soreau> Thank you Sarvatt 
<soreau> But, I thought all these updates were automated ..
<Sarvatt> they can't be automated anymore for maverick and earlier because the packaging has changed so much in natty
<soreau> Oh wow
<soreau> Yea a lot of stuff is changing
<soreau>  *cough*unity implemented with compiz*cough*
<Sarvatt> hmm, it might not even have built for longer than I thought on maverick, what version are you using?
<soreau> Sarvatt: version of what?
<Sarvatt> ati
<Sarvatt> the last few uploads of it on maverick failed to build
<soreau> hm
<soreau> I have master currently installed..
<soreau> let me see what's in the repo
<soreau> ii  xserver-xorg-video-ati                 1:6.14.99+git20110214.a9a59717-0ubuntu0sarvatt2~maverick
<Sarvatt> soreau: ok new one uploaded, hopefully it works!
 * soreau tries
<soreau> Sarvatt: I see no updates with apt-get update/upgrade 
<soreau> from xorg-edgers
<soreau> Does it take awhile?
<Sarvatt> yeah probably 45 minutes or so on average
<Sarvatt> looking now
<Sarvatt> i386 should be published but amd64 just started building
<bjsnider> Sarvatt, is 1.10 in natty yet?
<Sarvatt> not the final 1.10 nope
<bjsnider> what's the delay?
<Sarvatt> needs a FFe and testing
<Sarvatt> it's ~50 packages, not that minor of an upgrade or anything
<bjsnider> well, it's an alpha distro
<Sarvatt> RAOF: can you push your xserver 1.10 stuff to git when ya get a chance?
<Sarvatt> that doesn't stop the world from ending whenever people can't upgrade for an hour :P
<Sarvatt> looks like I need to disable pageflip on my HD 5770 for unity to work too
<Sarvatt> oh hmm, it's working after a vt switch and back
<Sarvatt> thats only with xorg-edgers, archive is fine
<Sarvatt> wow what the heck, https://bugs.launchpad.net/bugs/259219 is affecting software-center now?
<ubot4`> Launchpad bug 259219 in software-center (Ubuntu Natty) (and 3 other projects) "Broken TLS support in libGL.so (affects: 50) (dups: 13) (heat: 148)" [High,Triaged]
<Sarvatt> soreau: any luck? i'll try to keep ati in maverick up to date, its mesa and libdrm causing all the headache
<soreau> Sarvatt: I take it you haven't been glancing in #radeon
<Sarvatt> oh nope, good to hear
<soreau> Sarvatt: It's working fine now here too
<soreau> (I knew it would, after this update)
<soreau> Thanks again :)
<Sarvatt> should just backport xserver 1.10 to maverick and pull in all of the changes so it can be updated at the same time, hmm.. it will mess with so many components I have no clue about like utouch though
<jcristau> software-center uses GL?
<Sarvatt> unity backtraces sure are fun to read http://sarvatt.com/downloads/gdb.txt
<Sarvatt> err.. https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/732809
<ubot4`> Launchpad bug 732809 in mesa (Debian) (and 1 other project) "mesa update to 7.10.1-0ubuntu1 breaks ipython matplotlib (affects: 1) (heat: 6)" [Unknown,New]
<jcristau> this seems insane.
<RAOF> Sarvatt, jcristau: Not insane; libGL has just been accidentally working for ages.
<RAOF> I'd wager that's bug #259219
<ubot4`> Launchpad bug 259219 in software-center (Ubuntu Natty) (and 3 other projects) "Broken TLS support in libGL.so (affects: 111) (dups: 17) (heat: 214)" [High,Triaged] https://launchpad.net/bugs/259219
<RAOF> As far as I can tell, anything that's been dlopening libGL since about mesa 7.0 has been working by accident.
<jcristau> and you're saying not using initial-exec doesn't fix it?
<RAOF> I can't seem to get gcc to *not* build a TLS_STATIC library.
<RAOF> man gcc suggests that PIC should do the trick, but it doesn't appear to.
<jcristau> what's TLS_STATIC?
<RAOF> There are two TLS models; static and dynamic.  Static is for when you can guarantee that all your symbols will be avaliable at program start time, and does all the TLS initilaisation an allocing there.
<RAOF> Dynamic is more dynamic, and works with (among other things) dynamic loading.
<Sarvatt> why now? talloc removal?
<RAOF> Yup.
<RAOF> Well, we're _noticing_ it now becaues libGL now links in libstdc++, which also has some TLS.
<RAOF> As you see from that bug, it's always been broken for people using libstdc++ & libGL dynamically.
<jcristau> right, ok
<jcristau> and does TLS_STATIC flag show up?
<jcristau> add 'where' in that sentence
<RAOF> Yeah, in the output of readelf.
<RAOF> Oooh.
<jcristau> ah, DT_FLAGS
<RAOF> Loooks like the final mesa build I kicked off actually built with TLS and without TLS_STATIC.
<jcristau>   FLAGS                0x0000000000000012
<RAOF> Now, to remember precisely what I did there :/
<jcristau> and 0x10 is DF_TLS_STATIC.  ok.
<RAOF> It appears that throwing -fpic in addition to -fPIC at gcc actually causes it to *not* build TLS_STATIC libraries.
 * RAOF verifies this with another build
<RAOF> Ah, good.  And a quick check of the other libraries in /usr/lib finds mesa libraries as the only ones with TLS_STATIC in DT_FLAGS.
<RAOF> Ok.  So, I'm wrong.  It's not gcc's fault, I've just missed some assember somewhere.
#ubuntu-x 2011-03-11
<RAOF> Hello, x86-64 assembly reference.  Do you have 400 pages worth of instruction definitions?  You do?  Guess it's lucky there's code already written!
<bryceh_> dang sun, get out of my eyes and off my monitors
<bryceh_> RAOF, did you see bug 732809?
<ubot4`> Launchpad bug 732809 in mesa (Debian) (and 1 other project) "mesa update to 7.10.1-0ubuntu1 breaks ipython matplotlib (dup-of: 259219)" [Unknown,New] https://launchpad.net/bugs/732809
<ubot4`> Launchpad bug 259219 in software-center (Ubuntu Natty) (and 3 other projects) "Broken TLS support in libGL.so (affects: 121) (dups: 28) (heat: 300)" [High,Triaged] https://launchpad.net/bugs/259219
<bryceh_> ah that's just the TLS bug, nevermind :-)
<RAOF> bryceh_: I did indeed ;)
<RAOF> And, barring assembly, I've got it done locally.
<bryceh_> pity no feedback yet on bug 702090.  did I go overboard with the paint-by-numbers directions and scare everyone off?
<ubot4`> Launchpad bug 702090 in xserver-xorg-video-intel (Ubuntu Natty) (and 6 other projects) "i965gm GPU lockup if vesafb is left loaded (EIR: 0x00000010 PGTBL_ER: 0x00000100) - *ERROR* EIR stuck: 0x00000010, masking (affects: 72) (dups: 57) (heat: 520)" [High,Incomplete] https://launchpad.net/bugs/702090
<bryceh_> apw, from my limited testing the vesafb kernel doesn't appear to *cause* issues near as I can tell.  If you wanted to just roll it out, we get enough automatic gpu error reports I think it would become pretty clear within a couple days whether it has eliminated the issue.  We should notice a flattening of the curve and no further bug reports filed with these codes.
<RAOF> I WIN! (At causing glxinfo to segfault)
<RAOF> And if you don't clobber registers mesa assumes aren't clobbered, glxinfo doesn't segfault either!
<RAOF> Ahem.  And if you actually preserve the other registers, glxgears works, too.
<bdrung> hi, my new sandbybridge system has frequent gpu lockups (bug #733006). is there something that i can do (test)?
<ubot4`> Launchpad bug 733006 in xserver-xorg-video-intel (Ubuntu) "[sandybridge] GPU lockup 1a28f5a9 () (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/733006
<RAOF> bdrung: Is that before or after mesa 7.10.1?  There were lots of sandybridge fxxups in that.
<bryceh_> looks like it - version.libgl1-mesa-glx: libgl1-mesa-glx 7.10.1-0ubuntu1
<bryceh_> bdrung, unfortunately your gpu dump has a 00's for the error codes
<bryceh_> [   49.302005] [drm:init_ring_common] *ERROR* render ring initialization failed ctl 00000000 head 00000000 tail 00000000 start 00000000
<bryceh_> "render ring initialization", haven't heard of that one before
<bryceh_> bdrung, so here are the things I'd suggest testing, in no particular order:
<bryceh_> * boot an older kernel if you still have one installed.  That can help identify if it's a drm regression
<bryceh_> * downgrade mesa.  Like raof says it has some changes for sandybridge.  Conceivably those changes could carry bugs too
<bryceh_> bdrung, the above two are especially useful if this is a regression from it used to work right in the past
<RAOF> * upgrade mesa; I think xorg-edgers is usable at the moment, and upstream's always more interested in bugs not fixed in the bleeding-edge.
<bryceh_> * try the intel-drm-next kernel - http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/ - which will either identify if there might be a fix upstream, or else demonstrate it's an upstream bug
<bryceh_> ok I am told I have a tired demanding pregnant wife needing some attention, so gtg
<bryceh_> bdrung, hopefully the above helps.  Also keep filing apport bugs, sometimes it'll catch error codes when you're getting a string of 0's.
<bryceh_> bdrung, there are a couple other people with similar error=0x00000 types of bugs for various chips, it's possible they're related.  I hesistate to send them upstream without more specifics but if we get enough reported will do so
<bryceh_> l8r
<Sarvatt> bdrung: try booting with with drm_kms_helper.poll=0 additionally please :)
<Sarvatt> hmm, I guess updating lucid/maverick in xorg-edgers wont be that big a deal in the end, I just didn't want to backport the libdrm-nouveau1a rename since I'd have to rebuild crap like plymouth in there when the one built against 2.4.17 nouveau abi works fine but its just plymouth
<RAOF> Bah.  When are those darned new Sony notebooks coming out?
<bryceh_> check it --> http://www.bryceharrington.org/cgi-bin/upstreamer.cgi?bug=728823
<bryceh_> attachment forwarding is partly in there to but it's sloooowwww so left it disabled for now
<RAOF> Funky!
<RAOF> Doh!
<RAOF> Stupid IA32 assembler.
<bryceh_> apw, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/733096
<ubot4`> Launchpad bug 733096 in xserver-xorg-video-intel (Ubuntu) "[q45] GPU lockup 32b1ab02 (EIR: 0x00000010 ESR: 0x00000010 PGTBL_ER: 0x00000002 IPEHR: 0x01000000) (affects: 1) (heat: 6)" [Undecided,New]
<ricotz> RAOF, hi
<ricotz> RAOF, did you see issues like these yet? nvidia-blob: http://enyo.zakx.de/~angelos/docky.png -- intel: http://img713.imageshack.us/i/docky.png/
<bdrung> good morning. i will try all your suggestions and report back.
<bdrung> bryceh_: the drm-intel-next kernel crashes with an ops while booting
<bryceh_> bdrung, the drm-next branch might be a bit more stable
<bdrung> bryceh_: that crashes too (general protection fault)
<bryceh_> bdrung, the fact that it's crashing is probably interesting and may be relevant on your original issue.  hope you're taking notes
<bdrung> bryceh_: nope, but screenshots ;)
<bdrung> now i am trying xorg-edgers
<bryceh_> have I mentioned today how much I hate the intel video driver's bugginess?
<bdrung> no and i have to agree
<bdrung> i had to start Windows to verify that the hardware is ok and that it's only a software problem
<bdrung> bryceh_: xorg-edgers brought no improvement
<bdrung> still gpu lockups
<bdrung> right after login
 * bryceh_ nods
<bryceh_> well, xorg-edgers won't make a difference if it's a kernel drm issue, which is what it's starting to sound like
<bryceh_> I'm curious about the oops and the gpf
<bryceh_> if those are unrelated that would be seriously unfortunate
<bryceh_> more likely though, they are different reactions to the same or similar fundamental issue
<bdrung> bryceh_: are they stored somewhere on the disk? will apport report them?
<bryceh_> you could look in /var/crash - if that's empty apport won't report them
<bryceh_> I *think* that apport might neglect to report them since they're not stock kernels, but I'm not sure
<bryceh_> you can look in /var/log/kern.log* to see if those files show the errors
<bryceh_> if not, I'd suggest rebooting to those kernels and capture dmesg
<bdrung> how should i capture dmesg if they crash on booting?
<bdrung> and the second question is: what workaround can i use to avoid those crashed to have a chance to run apport?
<jcristau> netconsole
<bdrung> what command do i need to report these problems?
<bryceh_> bdrung, a photo to capture the dmesg output showing the OOPS or fault would be a starting point
<bryceh_> sometimes you can ssh in and grab it
<bryceh_> if you can't ssh in, that would suggest a deeper kernel issue
<bryceh_> like, ssh with an ethernet cable, if wireless hasn't kicked in yet
<bdrung> wow, launching the drm-next kernel in recovery mode works. i have a console and can run dmesg
<bryceh_> for workarounds, if you snag the file from /var/crash/ that corresponds to the crash and copy it to another machine, there are ways to file it from the other machine
<bdrung> here's the dmesg output of drm-intel-next: http://paste.ubuntu.com/578782/
<bryceh_> [   11.620556] Process plymouthd (pid: 346, threadinfo ffff88041edfa000, task ffff88041b2ec440)\
<bdrung> so plymouthd died?
<bryceh_> looks like it
<bryceh_> could try booting with splash disabled, see if that makes the crash go away
<bryceh_> or uninstall plymouth (if that still works)
<bdrung> how is the splash disabling parameter called?
<bryceh_> I think you just delete 'splash' from the kernel cmdline
<bryceh_> linux	/boot/vmlinuz-2.6.38-4-generic root=UUID=2b238928-f3f1-4074-b551-2cceff54c6a4 ro   quiet splash vt.handoff=7
<bdrung> i copied all crash files from /var/crash to this machine.
<bryceh_> so you'd just go into grub (hold down left shift during boot), trim out 'splash', and boot
<bryceh_>        apport-cli [ --save file ] symptom | pid | package | program path | .apport/.crash file
<bryceh_> APPORT_IGNORE_OBSOLETE_PACKAGES=true apport-cli <foo.crash>
<bryceh_> ^ that should be the magic to get the report to file from your other machine
<bdrung> apport-cli complains that the crash doesn't belong to an not installed package
<bryceh_> hrm, yeah I should have added I'd never gotten that magic to work right myself
<bryceh_> fwiw, the .crash file is largely text... you can upload it to one of your bug reports for reference.  I think I should be able to extract the errors from the file myself.
<bryceh_> I don't like doing that in general, but for you...  ;-)
<bdrung> removing plymouth let the drm-intel-next kernel boot and it's currently running without locking up
<bdrung> so i can report the bug on the main machin
<bdrung> e
<bryceh_> sweet
<bryceh_> bdrung, ok, so sounding like a kernel/plymouth type of bug.
<bdrung> but i can't report the crashes because apport complained that the package are not ubuntu packages
<bryceh_> yeah, like I mentioned earlier
<bryceh_> just attach the .crash files to the bug report, and I'll sort it from there
<bdrung> bryceh_: i could pastebin them
<bryceh_> it's getting a bit late for me, I'd prefer if you attached them to one of your bug reports, and I'll look at it tomorrow
<bryceh_> (3:30am... need to hit the sack soon)
<bdrung> bryceh_: should i file it against the kernel package or intel?
<bryceh_> kernel
<bryceh_> make sure to tag it 'natty'
<bryceh_> actually, if you know how, I'd suggest filing it against both 'linux' and 'plymouth'
<bdrung> k, will do that
<bdrung> bryceh_: bug #733321 reported and crash logs attached
<ubot4`> Launchpad bug 733321 in plymouth (Ubuntu) (and 1 other project) "[sandybridge] GPU lockups and other crashes (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/733321
<Sarvatt> bdrung: go figure you have the screwed up board mentioned here too http://www.phoronix.com/scan.php?page=article&item=intel_sandy_speed&num=1 :(
<bdrung> Sarvatt: can you give me the pointer to the phoronix command that triggers the issue?
<bdrung> Sarvatt: i have the same board (with an b3 stepping)
<Sarvatt> just booting was screwed up for them, i'm trying to find any discussion on what the actual problems were
<bdrung> Sarvatt: my system runs fine with the drm-intel-next kernel (after only one plymouth related boot crash -> bug #733321)
<ubot4`> Launchpad bug 733321 in plymouth (Ubuntu) (and 1 other project) "[sandybridge] GPU lockups and other crashes (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/733321
<bdmurray> bryceh_: I'm still seeing bug 726807
<Sarvatt> bdrung: even without drm_kms_helper.poll=0 ?
<ubot4`> Launchpad bug 726807 in xserver-xorg-video-ati (Ubuntu) "drawing of drop down boxes produces artifacts temporarily (affects: 1) (heat: 479)" [High,Triaged] https://launchpad.net/bugs/726807
<bdrung> Sarvatt: not tested yet
<Sarvatt> it looks like 2.6.38-rc8 should work if drm-intel-next works
<ricotz> Sarvatt, hi
<ricotz> Sarvatt, did you hear about some cairo breakages (with transformation matrizes) lately?
<Sarvatt> ricotz: afraid not, whats up?
<ricotz> Sarvatt, http://enyo.zakx.de/~angelos/docky.png
<evilvish> Sarvatt: hey, i recall you mentioned to use for the x freeze: $ echo 0x001ee62d | eu-addr2line -e /usr/lib/debug/lib/libdrm_radeon.so.1.0.0   
<evilvish>  and echo 0x001ee5da ; echo 0x001d35da ; echo 0x001d362d
<evilvish> Sarvatt: should that be before the freeze or after? 
 * evilvish forgot.. :s
<ricotz> Sarvatt, this happens for people on archlinux and gentoo lately, which seems to be cairos fault or the mono 2.10 bindings
<evilvish> i got this without those echo lines Â» http://launchpadlibrarian.net/66142834/gdb-Xorg-2.6.35-6.7-generic.txt and after echo Â» http://launchpadlibrarian.net/66142892/gdb-Xorg-2.6.35-6.7-generic-echo.txt
<ricotz> Sarvatt, but i suspected cairo, mesa or xserver
<Sarvatt> real fix for jcastro's pageflip problem - http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=fdc315a19a2c33da29dd87d4ca88f4e4407bd42d
<bryceh_> Sarvatt, what was jcastro's bug #?
<bryceh_> hm, bug 715330 maybe?
<ubot4`> Launchpad bug 715330 in xserver-xorg-video-ati (Ubuntu) (and 2 other projects) "Freeze after login with KMS enabled on Radeon HD6310 (affects: 2) (heat: 124)" [High,Confirmed] https://launchpad.net/bugs/715330
<bryceh_> yep
<Sarvatt> yep, beat me to it (was digging through mail)
<Sarvatt> also he's working on a fix for the AGP pageflip problem https://bugs.freedesktop.org/show_bug.cgi?id=35183 \o/
<ubot4`> Freedesktop bug 35183 in DRM/Radeon "system freezes with 2.6.38-rc kernel and kms pageflip enabled" [Normal,New]
<bryceh_> Sarvatt, ok flagged it for JFo
<Sarvatt> awwh he changed it from Not-reported-usefully-by: Michael Larabel @ phoronix to Article-written-by: Michael Larabel @ phoronix
<bryceh_> hehe
<bryceh_> Sarvatt, feel free to close the -ati task if you think there's nothing more needed to be done on our end (unless you think it's worth leaving open just for tracking it)
<cnd> bryceh_, heads up: I have asked for a FFe for XInput 2.1 support in xinput (the utility) (bug 733536)
<ubot4`> Launchpad bug 733536 in xinput (Ubuntu) "Add XInput 2.1 support to xinput utility (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/733536
<cnd> I'm outta here now though :)
<cnd> see you later
<bryceh_> cnd, ok thanks for the notice
<Sarvatt> ricotz: please dont tell me it's https://bugs.launchpad.net/bugs/259219 too :)
<ubot4`> Launchpad bug 259219 in software-center (Ubuntu Natty) (and 3 other projects) "Broken TLS support in libGL.so (affects: 202) (dups: 66) (heat: 688)" [High,Triaged]
<Sarvatt> ricotz: so whats needed to reproduce that docky problem?
<ricotz> Sarvatt, unlikely that bug :P -- you would need mono 2.10, so not reproduceable on ubuntu/debian that easy
<ricotz> looks like it is a mono/docky problem perhaps a change in the cairo bindings, pretty weird though
#ubuntu-x 2011-03-12
<bdrung> Sarvatt: re bug #733321 - the drm-intel-next driver does not crash when running phoronix-test-suite
<ubot4`> Launchpad bug 733321 in plymouth (Ubuntu) (and 1 other project) "[sandybridge] GPU lockups and other crashes (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/733321
<bjsnider> ricotz, will the gnome-shell from the ppa in natty be ubuntu-ized with appindicators and so forth?
<ricotz> bjsnider, hmm, i dont know, gnome-shell has its own implementation of that
<bjsnider> gnome-shell has its own appindicators code?
<ricotz> yeah, i think so, functional combined with the message tray
<ricotz> havent really followed the changes lately
<tjaalton> seems like you don't follow the planets :)
<bjsnider> ricotz, i thought you were a part of the team involved in that ppa?
<bryceh_> tjaalton, quite the saga
<tjaalton> bryceh_: yep :)
<bryceh_> tjaalton, how do you think things will end up?
<bryceh_> seems like people aren't finding common ground, I wonder if they'll all just go on getting madder and madder.
<tjaalton> bryceh_: "in fire"
<tjaalton> :P
<tjaalton> (Kosh in B5)
<bryceh_> heh
<tjaalton> actually
<bjsnider> bryceh_, are you talking about this: http://www.markshuttleworth.com/archives/654?
<tjaalton> I did like owen taylor's post
<tjaalton> http://blog.fishsoup.net/2011/03/11/what-does-the-user-see/
<bryceh_> bjsnider, yeah plus the ones by dneary, aaron, and now this lecture by jeff
<bryceh_> makes my brain hurt :-)
<bjsnider> i would like to know if this agreement between jon mccann and ted gould in 2008 over appindicators really happened
<tjaalton> problem is only a fraction of the discussions are archived, and people tend to remember different things
<bryceh_> yep
<bjsnider> it sounds like the kind of thing that should have been written down in a contract if it did take place. would mccann really have said "you guys go off and solve this problem and we'll accept the code when you're done"?
<bryceh_> well, I know ted well.  And I know he is anything but shy about talking about ideas, even to people who disagree.  Indeed he *loves* arguing with people.
<bryceh_> so I can totally believe that they *did* talk
<bjsnider> with no witnesses, nothing on paper, only handshakes
<bryceh_> otoh, ted's not really a 'lets make a contract' type... he'll more often than not go off and do things as he thinks they should
<bryceh_> anyway, I don't know
<ScottK> bjsnider: The thesis that they talked in 2008 and nothing happened for 2 years is at odds with the facts.
<ScottK> The work didn't start in earnest until ~ Lucid's UDS in Nov 2009.
<bjsnider> ScottK, canonical went off and really did develop the code, i understand that
<ScottK> bjsnider: Yes, but not without trying collaboration first.
<ScottK> There were Gnome people at the UDS discussion and it was decided to discuss the spec at FDO.  
<ScottK> Reading that discussion, which is public, I don't get the feeling the Gnome side of the discussion was particularly open or serious.
<bryceh_> ScottK, I think I was at that meeting too, and seem to recall it that way too
<bjsnider> did gnome participate in that fdo discussion?
<ScottK> Yes.
<ScottK> But not very seriously, IMO.
<ScottK> The fact that Canonical's Gnome and KDE had compatible implementations appear at the same time makes a good case for collaboration was done where there was collaboration to be had.
<ScottK> I'm not holding Canonical up as perfect, they aren't, but it's certainly not the way certain people are trying to portray it.
<bjsnider> ScottK, now you need to write a 5k word blog post about it
<ScottK> No.  I commented on Waugh's post.  That's as far as I care to get dragged into it.
<bjsnider> i haven't gotten that far down yet
<bjsnider> did waugh get fired by canonical or did he leave on his own?
<ScottK> Many of the criticisms of (the Ayatana part of) Canonical are very valid.  
<ScottK> No idea.
<bjsnider> i mean does he have an ax to grind?
<ScottK> I think he's definitely got a slanted perspective.  No idea if that's why.
<ScottK> The fact that they require copyright assignment and insist all work be one on LP makes collaboration very difficult.
<ScottK> Of course Gnome insists all work be done in Gnome Git, so they're equally difficult in that regard.
<bjsnider> and didn't they insist that all discussion take place on their ml?
<ScottK> (Look into the history of Zeitgeist's rejection from Gnome)
<ScottK> That's a non-Canonical example where many of the same introspective issues in Gnome seem to be at work.
<bryceh_> Gnome has lots of rather strict requirements for stuff like that, which is why we never had Inkscape join Gnome
<bjsnider> yes,, why bother with their strict requirements when we have strict requirements of our own to worry about
<bryceh_> heh
<bryceh_> well, at the time the requirement was that you must use cvs and bugzilla, and we were wanting svn and some better bug tracker
<ScottK> Canonical has strict requirements for Canonical funded work.  Very different than requirements for getting into Ubuntu.
<bryceh_> yep
<tjaalton> so maybe that was the reason to keep it out of gtk+..
<tjaalton> it= the lib..indicator
<bryceh_> well, it wouldn't surprise me if it came down to a control issue at some level or other.  If it were merely a communications problem or technical issue, those seem much more straightforward to solve.
<bjsnider> maybe the problem is canonical doesn't have enough core gnome devs working for it directly then. because then it would be in their control. subject to shuttleworth's decisions
<tjaalton> but that wouldn't be collaboration :)
<bryceh_> maybe the real question here is does the tangible value of collaboration outweigh the perceived value of control?
<ScottK> If you care about user experience, I don't think collaboration is optional.
<bryceh_> I agree, but that appears not to be a universally held view...
<ScottK> Users should be able to use applications in their DE of choice without having to spend a lot of time thinking about what toolkit or open source project it was developed in.
<ScottK> bryceh_: Agreed.
<ScottK> Although to be fair to Canonical, I think they care about this in the context of Ubuntu users.
<ScottK> I think it's an open question though how much they really care about the broader free software ecosystem.
 * bryceh_ nods
<bjsnider> otaylor's post seems more open and inviting to collaborators, while shuttleworth's sound like "you've failed me for the last time, admiral".
<ScottK> There are varying degrees of willingness to collaborate in all camps.
<bjsnider> but otaylor's pointing out that the programming resources that went into unity could have been used to improve g-s is also applicable everywhere around linux: why is it that every time someone has a problem with rhythmbox he goes off and creates a new media player? why not make r-b better instead of dummying up something from scratch? do we have to have 47 media players in linux?
<bjsnider> now we'll have a confusing number of shells too i guess
<bryceh_> bah, I don't buy into the competition == inefficient use of resources
<ScottK> Avoiding competition and planning everything out worked out really well for the USSR.
<bryceh_> fact is, when you have a single thingee that everyone contributes to, it inevitably builds up layers of bureaucracy (it has to), and it can get to the point that the activation energy to get into that is way above what it takes to JFDI 
<bjsnider> bryceh_, so you'd like to see 47 xorgs
<bjsnider> and endless flame wars about how "the one i use is the bestest"
<ScottK> cough Wayland cough
<bryceh_> bjsnider, ahem wayland?
<bjsnider> ok, xorg sucks
<bryceh_> bjsnider, Xorg is sort of proof of the premise ;-)
<bjsnider> one competitor is fine
<bryceh_> nah, it's an evolution
<bjsnider> but i could sit here and list all of the media players on linux for the next 5 hours and not finish
<bryceh_> early on you might have 47 different ideas, and that's fine
<bryceh_> but over time those should die off, and the best survive
<ScottK> bjsnider: If you want to avoid a competitor project then you have to be open enough to what others want that they think it's worthwhile to play together.
<bryceh_> (this doesn't always happen)
<bryceh_> if it does, and it boils down to 2-3 good options, that's ok
<ScottK> Media players are a bad example because they are so easy to do (at least badly)
<bryceh_> when you get down to just 1, then you get complacent, bureaucratic, and out of touch.  So it's time to have a bunch of fresh new ideas
<ScottK> http://apachelog.wordpress.com/2011/03/02/how-to-create-a-media-player-in-30-seconds/
<bryceh_> the important thing is to be able to *let go* and let less popular ideas die off
<bryceh_> that's really hard though, especially when it's your own baby that has to die
<bjsnider> ScottK, that post should be destroyed for the good of mankind
<bjsnider> bryceh_, right, so ego is heavily involved in this
<ScottK> I don't care how many media players there are long as at least one doesn't suck.
<bryceh_> bjsnider, in fact ego is an important part
<bryceh_> what else is going to drive someone to spend countless evenings voluntarily creating something?
<bjsnider> money, for one thing
<bryceh_> they have a cool idea and want to see it exist, and have people find value in it
<bryceh_> bjsnider, sure but I'm talking within the context of open source
<bryceh_> and even with money, there's a lot better ways to make money than writing software ;-)
<ScottK> And there are better ways to make money writing software than writing free software, even when you're funded.
<bryceh_> ScottK, like taking money from one of those aforementioned 47 media players?
<ScottK> No.  I think that was just idiotic.
<ScottK> Canonical will lose more money from the bad PR and loss of goodwill than that will ever make the.
<ScottK> the/them
<bryceh_> I think that's a fair observation
<bryceh_> sort of goes back to what I was saying about value of control vs. value of collaboration
<ScottK> http://abock.org/2011/03/10/opensuse-11-4-and-banshee-amazon-mp3 <-- Exhibit A
<ScottK> Gotta run.  Chat with you later.
<bryceh_> there seems to be a rather wide set of opinions on where that balance should lay
#ubuntu-x 2011-03-13
<LLStarks> bryceh_, are there any meaningful tools to test or identify s-video/composite output problems?
<LLStarks> other than xorg.0.log
<bryceh_> LLStarks, dmesg would be more useful for that than xorg.0.log
<bryceh_> there's also some debug stuff you can flip on in the kernel
<LLStarks> okay. thanks.
<bryceh_> drm.debug maybe?  something like that
<bryceh_> yep, "drm.debug=1" boot param
<evilvish> oh no! ^that dumps a lot of info for me.. it wrote in 3 logs and i ran out of /var space in 1hr ;p
<evilvish> i think i'v tracked down my X freeze, it seems like "Add support for the ATIF ACPI method to the radeon driver" started it all.. 
<LLStarks> my xserver hasn't been playing nice with svideo or svideo-to-composite. a whole lot of flickering, no display.
<LLStarks> not looking to saturate my root partition and make things unbootable
<LLStarks> ^_^
<evilvish> LLStarks: there are other options > http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/include/drm/drmP.h?a=mips , i choose 6 since mine seemed like driver/kms thing
<evilvish> LLStarks: i had a lot of ioctl messages, you can try with 1 and then turn it off/ change the option while running too
<evilvish> LLStarks: to turn it off > $ echo 0 | sudo tee /sys/module/drm/parameters/debug
 * evilvish has a separate /var so ioctl overload wasnt a huge issue, just backups dint happen due to lack of space ;p
<LLStarks> anyone here in the know regarding PRIME?
<penguin42> does anyone know why drm-next ppa hasn't been updated for 9 days?
#ubuntu-x 2012-03-05
<FernandoMiguel> nite
<apw> RAOF, hey i have just had another of those X lockups, triggered by touching the edge of teh screen to pull out the launcher
<apw> any suggested triage, before i start restarting bits?
<RAOF> apw: Still there?
<apw> RAOF, yep
<RAOF> apw: Has X crashed, or frozen?
<RAOF> If it's frozen, could you ssh in, attach gdb, and nab a backtrace?
<apw> xserver still there, its in a futex wait
<apw> RAOF, no idea if its X or compiz, or another
<RAOF> Oh, really.
<RAOF> Is compiz in D state by any chance?
<apw> compiz is Sl
<RAOF> Hm.
<apw> RAOF, X appears to be in an intel_drv.so thingy, called out of _CallCallbacks
<RAOF> Ah.  Could you pastebin a backtrace please?
<apw> RAOF, http://paste.ubuntu.com/869540/
 * RAOF is confused.
<RAOF> Could you do the same, with debugging symbols installed?
<apw> RAOF, this is a relativly recent behaviour, and i am pretty sure bjf has also hinted at similar behaviour -- cirtainly this is the third of this behaviour i've seen
<apw> RAOF, where doth i get those
<RAOF> apt-get install xserver-xorg-core-dbg xserver-xorg-video-intel-dbg xserver-xorg-input-evdev-dbgsym
<RAOF> And let's throw in libdrm2-dbg libdrm-intel1-dbg
<RAOF> That looks an *awful* lot like a deadlock caused by a signal handler, doesn't it.
<apw> E: Unable to locate package xserver-xorg-input-evdev-dbgsym
<RAOF> Oh, *ARSE*
<RAOF> Ignore evdev, then.
 * RAOF has a sneaking suspicion that he knows what the problem is.
<apw> something i can type to get confirmation for you
<RAOF> No, I don't think so.
<RAOF> But a backtrace with function names would help me to check.
<apw> http://paste.ubuntu.com/869546/
<apw> RAOF, ^
<RAOF> Had you closed a window shortly before this happened?
<apw> RAOF, i had just touched the left edge about to reel out the launcher
<apw> the odd shadow thing is still there i think
<jcristau> sending events from the sigio handler sounds wrong.
<RAOF> evdev... with a mouse, right?
<RAOF> jcristau: Yeah, I just noticed thatc.
<apw> RAOF, indeed mouse in motion
<jcristau> no wonder it deadlocks
<RAOF> jcristau: Hence my *ARSE* :/.
<RAOF> The wonder is that it deadlocks so infrequently.
<apw> are you allowed to do _anything_ in a signal handler?
<jcristau> apw: not much.
<jcristau> you're supposed to read the input event, queue it, and get the hell out.
<apw> i am supprised reading input is allowed, let alone any of the other milarki
<RAOF> You can write()
<apw> so you can send yourself a hint
<jcristau> signal(7) has a list of functions you're allowed to call
<RAOF> *much* of writing events qualifies; probably something mallocs in a certain case.
<RAOF> I was just incautious and wasn't thinking that ConstrainCursorHarder was called from a signal context.
<jcristau> well in X sending events is not allowed from the sighandler, because it does more than write()
<RAOF> Yeah.
 * apw would be supprised if malloc was safe most of the time
<jcristau> apw: it's not
<jcristau> malloc takes a lock
<jcristau> so if malloc gets interrupted by the signal and you call it again from the handler, it goes boom
<RAOF> Indeed.
<apw> RAOF, its a good job Intel graphics arn't common ... sigh
<RAOF> In this case, probably not malloc; looks like drmIoctl takes out a lock.
<apw> RAOF, yeah you'd hope wouldn't you
<RAOF> Anyway, time to rework this sucker.
<apw> RAOF, need anything mroe from this hang, or shall i kill it off
<RAOF> Kill it with extreme prejudice.
<jcristau> RAOF: is that bug upstream too?
<RAOF> jcristau: No; it's in my code (a prototype of which is languishing on the list)
<jcristau> ok
<RAOF> Would have been nice for someone to point out that CursorConstrainCursor is called in a signal context, though :)
<RAOF> The input code does a scary amount of work in that context.
<jcristau> having annotations in the code about it could be helpful..
<jcristau> but i guess it'd easily get stale
<RAOF> Maybe
<jcristau> maybe sparse could handle that
<RAOF> Well, easily get stale, but the flow of the sigio handler shouldn't change *that* much between releases.
<RAOF> How well does sparse handle calls chained through function pointers?
<jcristau> no idea
<jcristau> i should try and play with it some time
<RAOF> It would seem to be something amenable to static analysis, but as I say, there's a surprising amount of code there.  Fun fact!  It calls into the nvidia blob now.
<jcristau> read input calls into nvidia??
<RAOF> Yes.
<apw> RAOF, i hope you don't mean the intel driver :)
<jcristau> for hw cursor, or something else?
<RAOF> Because read input wraps into ConstrainCursorHarder, and nvidia now has a ConstrainCursorHarder hook.
<jcristau> ah.
<RAOF> To handle the same thing as xrandr's ConstrainCursorHarder hook.
<RAOF> One might think that the xrandr/ subdirectory would be free of the sigio context; you'd be mistaken.
<apw> RAOF, ok just in case i took a gcore of it
<RAOF> apw: Well, I now know of at least one critical bug in my code.
<apw> RAOF, heh well something came out of my hang :)
<RAOF> And with that, dinner.
<ossguy> is this the right place to discuss regressions in X between Ubuntu 12.04 Alpha and Beta?
<ossguy> I did a dist-upgrade this morning (last one was a week ago, before Beta was released) and now it will only start in low graphics mode
<tjaalton> which driver do you use?
<ossguy> sorry, it's radeon
<tjaalton> so no fglrx?
<tjaalton> installed
<ossguy> correct
<ossguy> never installed
<tjaalton> pastebin /var/log/Xorg.0.log
<ossguy> yep, just a sec
<tjaalton> (pastebinit $foo)
<ossguy> sorry, I'm otherwise distracted currently :)
<ossguy> it's at http://ossguy.com/xorg/20120305/1010/Xorg.0.log now
<ossguy> and http://ossguy.com/xorg/20120305/1010/Xorg.0.log.old
<ossguy> (running 2 different kernel versions; I got the same issue with all of them (including -18, which I tried before these))
<tjaalton> dualscreen?
<ossguy> yes
<ossguy> identical model screens
<tjaalton> so which version was the last working one?
<ossguy> neither of the 2 I posted are from working X sessions
<ossguy> I will try to find you a log from a working session
<tjaalton> just try an older kernel abi version
<tjaalton> if you have those installed
<ossguy> how much older do you mean?
<tjaalton> one that works
<ossguy> I have 3.2.0-12, -15, -17, and -18
<tjaalton> so try -12
<ossguy> I've tried the last 3
<ossguy> ok
<ossguy> I will once I'm in a state where I can reboot the system I'm on
<tjaalton> actually, the logfile says it's using 19x12
<ossguy> log from working sessions is here: http://ossguy.com/xorg/20120216/1628/Xorg.1.log
<ossguy> s/sessions/session/
<tjaalton> [    73.483] (II) RADEON(0): Output DisplayPort-0 using initial mode 1920x1200
<tjaalton> [    73.483] (II) RADEON(0): Output HDMI-0 using initial mode 1920x1200
<ossguy> yes, I noticed the screen was the usual res
<ossguy> but I got the box saying it was running in low graphics mode
<ossguy> and there didn't seem to be an easy way to get around it
<tjaalton> huh?
<ossguy> after I did the dist-upgrade this morning, I rebooted the system and X started up with the "you're running in low graphics mode" message
<ossguy> but as far as I could tell, it was running at 19x12 (and the logs confirm this)
<tjaalton> ahah, so xdiagnose fired up for some reason
<ossguy> right (I guess :) )
<tjaalton> well you didn't say it looked normal
<ossguy> also, the screens were in mirroring mode
<ossguy> not side-by-side, as I had configured
<tjaalton> it's a per-user setting
<ossguy> ah, right
<ossguy> ok, so we didn't even get there
<ossguy> any ideas why xdiagnose might have decided to run?
<tjaalton> no..
<ossguy> or how to get it to not run?
<tjaalton> it runs on every boot?
<ossguy> yes
<tjaalton> bryceh: ^ :)
<ossguy> (or maybe a different venue where it's more appropriate to ask this question?)
<tjaalton> no this is fine
<ossguy> ok
<tjaalton> basically it would mean that lightdm had failed to start
<tjaalton> check /var/log/lightdm/*
<tjaalton> oh, dist-upgrade.. check that you have lightdm _installed_
<ossguy> lightdm produced logfiles the last time I started Ubuntu
<ossguy> so I presume it is installed
<tjaalton> ok, check what's in them
<ossguy> [+0.67s] DEBUG: Failed to load session file /usr/share/xgreeters/.desktop: No such file or directory:
<ossguy> [+0.67s] DEBUG: Failed to start greeter
<ossguy> perhaps that is an issue?
<ossguy> I will post the full log; just a sec
<tjaalton> is unity-greeter installed?
<tjaalton> apt-cache policy unity-greeter
<ossguy> sorry, I'm not booted into Ubuntu right now (I'm in a different distro on the same machine)
<ossguy> I can check some apt-related files, though
<tjaalton> check the upgrade log
<tjaalton> dpkg.log
<ossguy> ok
<tjaalton> and you can always chroot into the partition :)
<ossguy> lightdm log here: http://ossguy.com/xorg/20120305/1010/lightdm.log
<ossguy> true; I'd rather not do anything funny there, though :)
<tjaalton> do you have /usr/share/xgreeters/unity-greeter.desktop
<ossguy> no, /usr/share/xgreeters does not exist
<tjaalton> so no /usr/sbin/unity-greeter either?
<tjaalton> grep unity-greeter /var/log/dpkg.log ?
<ossguy> it suggests unity-greeter was removed
<tjaalton> there you go
<tjaalton> never blindly run dist-upgrade
<ossguy> I presume something was unexpected here
<ossguy> ah, ok, good lesson I suppose :)
<ossguy> what's the best/easiest way to get back to working?
<tjaalton> but first upgrade and then see if dist-upgrade would remove stuff
<tjaalton> ubuntu-desktop got removed as well I guess, so install it
<ossguy> yep, looks like it was removed, too
<ossguy> so what was the way I should have done this upgrade?
<ossguy> I mean eventually I want to run "dist-upgrade"
<tjaalton> only when it's not doing silly things
<ossguy> so how should I determine when is the right time to do so?
<ossguy> ok
<ossguy> so in alpha/beta I should expect silly things
<tjaalton> a good indicator is when it's removing *-desktop..
<tjaalton> yes
<ossguy> right :P
<tjaalton> transitions etc
<ossguy> tjaalton: thanks very much for all your help
<ossguy> and for bearing with a dumb user ;)
<tjaalton> yw
<Sarvatt> hmm, haven't seen this input related crash come up before, just hit it http://paste.ubuntu.com/870647/
<bryceh> RAOF, thoughts on bug 931967?
<ubottu> Launchpad bug 931967 in OEM Priority Project "Corrupted graphics after the login until the unity launcher appears" [Critical,Triaged] https://launchpad.net/bugs/931967
<bryceh> I'm assuming it's just that when lightdm hands off to X, the framebuffer isn't zero'd out.  something lightdm should be doing?
<RAOF> I started looking at that, then got pulled into more pressing issues.
<RAOF> What I had was: lightdm draws to the root window.
<RAOF> Or, rather *unity-greeter* draws to the root window.
<RAOF> This should mean that whatever unity-greeter leaves on the display stays there until something else draws; that something else should be compiz.
<RAOF> However, on *some* drivers that isn't happening; it doesn't happen on intel, it does on radeon and nouveau.
<RAOF> Which suggests it might be an EXA issue, or something.
<bryceh> fglrx and -nvidia too aiui
<bryceh> yep, just repro'd on -nvidia
<RAOF> I wonder if RetainPermanent is horribly unimplemented.
<RAOF> What I was going to try is to replace unity-greeter's cairo render-to-root-pixmap code with a straight X11 CopyArea from a pixmap to the root window.
<bryceh> hmm, wonder if unity-greeter has some better debugging output...
<RAOF> bryceh: Hey, you know those xlib-xcb asserts we've been seeing?  Think http://article.gmane.org/gmane.comp.freedesktop.xorg.devel/29102 might have something to do with it?
#ubuntu-x 2012-03-06
<bryceh> RAOF, yeah, sounds plausible
<bryceh> plus I like one-liner patches ;-)
<bryceh> is that patching libxcb or xserver?
<bryceh> dang context-less git patches...
<Sarvatt> should be libx11
<bryceh> hmm neither. 
<bryceh> yep there it is
<bryceh> well, gotta run to a dentist appt.  bbiab
<RAOF> Well, looks like I get to whip up an extra event queue for barriers.  Win.
<tjaalton> whee, bug triage for an hour and my head hasn't exploded yet
<tjaalton> is there a difference in what multimonitor mode is used by default regarding if unity is running or not?
<tjaalton> like, is the default cloned or extended
<tjaalton> seems to be extended on my laptop
<tjaalton> then again, it has .config/monitor.xml..
<tjaalton> meh
<tjaalton> yeah, cloned is the default
<tjaalton> ..but only if the second monitor is plugged in before lightdm starts
<tjaalton> what a nice mess
<seb128> cnd, hey
<seb128> cnd, so gtk guys landed smooth scrolling, etc
<seb128> cnd, that broke mouse wheel scrolling on Ubuntu though
<seb128> cnd, mclasen says to ping some xinput guy
<seb128> cnd, a log is http://pastebin.ubuntu.com/871310/
<seb128> "	scroll valuator 2: vertical, increment -nan"
<seb128> he says the "-nan" is the issue there
<seb128> cnd, I would welcome you help debugging, that blocking the gtk update
<seb128> cnd, http://pastebin.ubuntu.com/871338/ is the xinput for that mous
<seb128> mouse
<seb128> "		  increment: -nan"
<psypher246> rye: ok I'm here
<psypher246> not a huge fan of global menus, they ok when they workl
<rye> hi, people. psypher246 has installed nvidia drivers via jockey, found them not to be good and uninstalled them via jockey gui. 
<psypher246> but they don't work so well
<rye> but the system has nvidia-curent package installed
<rye> psypher246, global menus are more likely to be discussed in #ubuntu-unity :)
<psypher246> i know :)
<rye> and nvidia-current left the blacklisting file so nouveau kernel module was not loadable 
<rye> so the question - should uninstalling binary drivers remove nvidia-current as well?
<tjaalton> rye: yes, it should
<rye> psypher246, please check whether the bug with nvidia-current is already filed
<tjaalton> actually, are you sure the driver is just disabled?
<tjaalton> +not
<tjaalton> unticking the box only disables the driver
<tjaalton> and the bug should be against jockey
<tjaalton> if there is a bug..
<psypher246> tjaalton: yes all I did in jockey was de-activate the recommended driver
<psypher246> last time i did that and rebooted I had no issues, today i had to remove the blacklist file
<tjaalton> psypher246: do it again and if you can reproduce it, file a bug against jockey
<psypher246> ok cool, will do, thanks
<tjaalton> ("ubuntu-bug jockey")
<psypher246> rye: thanks for the help 
<rye> psypher246, you are welcome
<tjaalton> so, re-enable, reboot, disable, reboot
<psypher246> schweet
<psypher246> tjaalton: do you use the nouveau driver at all?
<tjaalton> psypher246: not really
<psypher246> so you have never experienced this issue: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/926714
<ubottu> Launchpad bug 926714 in xserver-xorg-video-nouveau (Ubuntu) "continuous jerky mouse movements while using nouveau driver in 12.04" [Undecided,Confirmed]
<tjaalton> I could verify it though
<psypher246> any attention to the issue would be great thanks. I have more issues with the prop drivers and this is the only thing bugging me on nouveau
<tjaalton> i could pop the gf8600gt in the test box..
<psypher246> tjaalton: thanks, brb rebooting after nv install
<psypher246> tjaalton: ok so I was not able to reproduce the jockey bug. this time when i removed the nvidia driver it deleted the blacklist file as well
<tjaalton> psypher246: ok
<tjaalton> psypher246: so the nouveau bug, it's about the mouse pointer stopping at times?
<psypher246> tjaalton: yes, not just the mouse though, then entire screen freezes, but only it seems like only when the mouse is moving, for instance, if i'm not moving the mouse and wathinvg a video, no freeze, but move the mouse while the video is playing, the mouse and the video freezes
<tjaalton> appears to be fixed on 3.3rc6
<psypher246> tjaalton: is that kernel 3.3rc6
<tjaalton> yes
<psypher246> awesome
<psypher246> did you experience it on earlier kernels?
<tjaalton> haven't tried
<psypher246> ok cool;
<psypher246> you using a kernel PPA or installed it manually?
<tjaalton> mainline ppa
<tjaalton> now the fix needs to be found and backported to 3.2..
<tjaalton> fixed in 3.3rc1 to be exact, and the diff to 3.2 is 116 commits, meh..
<tjaalton> diff to drm/nouveau
<cnd> seb128, ok, I'll take a look today
<seb128> cnd, thanks
<seb128> cnd, did I give you the xinput pastebin output here? I'm not sure now
<cnd> yeah
<seb128> cnd, basically xinput list has "		  increment: -nan"
<seb128> cnd, sorry it has been some hours and I rebooted since so I'm not sure how much details I gave, ping me if you need any debug infos ;-)
<seb128> cnd, that's with evdev btw, but my alps pad on synaptic seems to have the same issue
<cnd> seb128, I have a valid increment here on my macbook trackpad
<seb128> hum
<cnd> and my magic trackpad
<cnd> seb128, can you get me a utouch-evemu device property file?
<seb128> utouch-evemu: command not found
<cnd> figure out the /dev/input/event* node
<cnd> then: evemu-describe /dev/input/event* > device.prop
<seb128> ok
<cnd> apt-get install utouch-evemu-tools
<seb128> cnd, http://pastebin.ubuntu.com/871594/
<cnd> why oh why does paste.ubuntu.com make you go through openid to get the download?
<seb128> yeah, that's annoying
<seb128> I guess it's to avoid sharing files in anonymous way over pastebining
<cnd> seb128, I get an increment of -1.0000 here
<cnd> though the device name is garbled for some reason
<seb128> cnd, ok, that would be correct :p
<cnd> likely a bug in utouch-evemu
<seb128> cnd, do you use fedora? ;-)
<cnd> so I don't really know what's going wrong for you
<cnd> nope :)
<seb128> cnd, it's not only me
<seb128> ricotz has the same issue
<cnd> hmmm
<seb128> and he has it as well on edger with xorg 1.12
<cnd> seb128, can you pastebin your Xorg.0.log?
<cnd> oh, I see the issue with utouch-evemu I think
<cnd> pastebin downloaded with ^M instead of /n as line endings
<seb128> cnd, http://people.canonical.com/~seb128/Xorg.0.log
<cnd> seb128, I don't see anything wrong with the log
<cnd> seb128, the next step would normally be me having to make debug builds with printf's and such
<seb128> cnd, well, tell me what source need rebuild and give me a diff
<cnd> but if you want to try debugging it yourself I can walk you through the steps
<seb128> cnd, I can patch, build
<cnd> ok
<seb128> cnd, bah, it's fine for ubuntu-desktop for pitti and desrt
<seb128> <didrocks> increment: -nan
<seb128> ah, I feel not alone :p
<cnd> heh
<seb128> we are both on x86
<seb128> others are on amd64
<seb128> clue?
<cnd> hmm, maybe
<cnd> I'm on amd64 too
<cnd> let me try on my netbook
<cnd> aha :)
<cnd> I have -nan on my i386 netbook
<seb128> \o/
<cnd> seb128, I'll try to get a fix for this today
<cnd> but if it slips to tomorrow, will that be a problem?
<seb128> cnd, thanks a lot
<seb128> cnd, no, it's just blocking the GTK 3.3.18 upload
<seb128> cnd, but that can wait a day
<seb128> cnd, that gtk is in the ubuntu-desktop ppa if you want to test it
<seb128> they landed multitouch and smooth scrolling
<mvo> (cross-posting from #ubuntu-devel hoping for more results) can someone with a nvidia (either free or proprietary) run  "python /usr/share/pyshared/debtagshw/opengl.py " and tell me the renderer string please? same for the fglrx driver please :)
<cnd> seb128, ok, I hope to write an upstream test case for this issue when I figure out the fix
<cnd> that's what will probably be the blocker timewise
<cnd> but I already have to do it for another bug
<seb128> cnd, can we throw a fix in our package while you write the testcases?
<seb128> cnd, well anyway please let me know when you have a patch so I can test at least locally
<cnd> yeah, it's just a matter of getting work done :)
<seb128> cnd, I will let you work then, thanks a lot of the quick response!
<cnd> sure
<Sarvatt> mvo: that script is missing a recent unity-support-test change http://paste.ubuntu.com/871617/
<mvo> Sarvatt: awsome, thanks
<mvo> Sarvatt: I fix this now
<Sarvatt> sarvatt@kyoko{~}:LIBGL_ALWAYS_SOFTWARE=1 python /usr/share/pyshared/debtagshw/opengl.py
<Sarvatt> INFO:__main__:gl vendor: VMware, Inc.
<Sarvatt> INFO:__main__:gl renderer: Gallium 0.4 on llvmpipe (LLVM 0x300)
<Sarvatt> INFO:__main__:gl version: 2.1 Mesa 8.0.1
<Sarvatt> opengl_supported:  True
<Sarvatt> mvo: 
<Sarvatt> <vanhoof> INFO:__main__:gl vendor: NVIDIA Corporation
<Sarvatt> <vanhoof> INFO:__main__:gl renderer: GeForce GT 440/PCIe/SSE2
<Sarvatt> <vanhoof> INFO:__main__:gl version: 4.2.0 NVIDIA 295.20
<Sarvatt> <vanhoof> opengl_supported:  True
<mvo> thanks a lot!
<mvo> hrm, hrm, this is strange, my opengl.py fails with a "BadMatch" error on fglrx, but it works on all the other ones (X_GLXMakeCurrent fails be be precise)
<jcristau> Sarvatt: are you guys planning on merging src:xorg for precise?  or at least the cve fix?
<tjaalton> jcristau: for sure (cve at least)
<jcristau> ok, cool.
<FernandoMiguel> HALP HALP
<FernandoMiguel> latest 12.04 updates made my screen brightess set to MAX
<FernandoMiguel> anyone recalls where I can ECHO the bright setting?
<RAOF> It's in /sys somewhere, IIRC.
<RAOF>  /sys/class/drm/$your_lvds_thingy.
<RAOF> Unless it's elsewhere, because laptops like to be difficult.
<FernandoMiguel> $ cd /proc/acpi/
<FernandoMiguel> ac_adapter/ battery/    button/     
<FernandoMiguel> it used to be there
<FernandoMiguel> it's broken for a lot of people, it seems
<FernandoMiguel> ill file a bug
<FernandoMiguel> /sys/class/drm$ ll | pastebinit 
<FernandoMiguel> http://paste.ubuntu.com/872170/
<seb128> FernandoMiguel, there are like 5 bugs no need of another duplicate
<FernandoMiguel> :D
<FernandoMiguel> seb128: anyone looking at it?
<seb128> it's a gnome-settings-daemon issue
<FernandoMiguel> any package we can revert ?
<seb128> FernandoMiguel, no, I might look at it tomorrow
<FernandoMiguel> thanks
<seb128> g-s-d
<FernandoMiguel> seb128: can we revert gsd?
<seb128> FernandoMiguel, you can do whatever please you it's your box
<seb128> FernandoMiguel, no need to ask me for permissions ;-)
<FernandoMiguel> -rw-r--r-- 1 root root  461K Mar  2 07:35 gnome-settings-daemon_3.3.90-0ubuntu4_amd64.deb
<FernandoMiguel> seb128: just asking....
<FernandoMiguel> I don't want to go blind here
<seb128> just dpkg -i that
<FernandoMiguel> rebooting
<FernandoMiguel> FYI it's working again
<seb128> thanks
<FernandoMiguel> another user on +1 just reverted to https://launchpad.net/ubuntu/+source/gnome-settings-daemon/3.3.90-0ubuntu4/+build/3253267 and is rebooting
<eruditehermit> hey I was trying to follow the instructions on https://help.ubuntu.com/community/HybridGraphics#Script_for_use_during_bootup but it is not turning my discrete GPU off and it consumes a lot of power. Can anyone help?
<RAOF> Huh.  I'm not surprised that script doesn't work, there's no guarantee that vgaswitcheroo will be available when it runs.
<RAOF> eruditehermit: You should be able to turn off your discrete gpu with echo OFF | sudo tee /sys/kernel/debug/vgaswitcheroo/switch
<RAOF> If that doesn't work, then you've got a system that vgaswitcheroo doesn't support, and... it's difficult.
<eruditehermit> RAOF, it does work when I do it manually
<RAOF> Ok.
<eruditehermit> RAOF, I wanted it to be a startup script
<eruditehermit> RAOF, is there a way to make it work?
<RAOF> There is; let me nab you an upstart script.
<eruditehermit> ok
<eruditehermit> awesome! :)
<RAOF> eruditehermit: http://paste.ubuntu.com/872205/
<eruditehermit> RAOF, what should I do with this?
<Sarvatt> drop it in /etc/init
<Sarvatt> as something.conf
<eruditehermit> thats it?
<broder> uh, i don't think you can use && and || like that in start on blocks
<broder> i think it has to be and/or
<RAOF> Huh.  Something similar worked for me.
<RAOF> Maybe accidentally :)
<broder> i just checked the code - "and" and "or" are definitely the only recognized operators
<eruditehermit> so I just replace && withand
<eruditehermit> and || with or?
<broder> yeah
<eruditehermit> then I just restart
<eruditehermit> and it will do it?
<broder> you can run "sudo initctl reload-configuration; sudo initctl list | grep something" to make sure it gets picked up
<broder> (where "something" is the something in /etc/init/something.conf that you saved the file to)
<eruditehermit> i get
<eruditehermit> vgaswitcheroo stop/waiting
<broder> then yeah, you should just need to reboot
<eruditehermit> ok
<eruditehermit> will brb
<eruditehermit> thanks all
<eruditehermit> did not work
<eruditehermit> :(
<eruditehermit> echo OFF | /sys/kernel/debug/vgaswitcheroo/switch
<eruditehermit> should that be
<Sarvatt> err he meant > yeah
<eruditehermit> echo OFF > /sys/kernel/debug/vgaswitcheroo/switch
<eruditehermit> ok
<eruditehermit> will try again thanks
<eruditehermit> brb
<eruditehermit> success!
<eruditehermit> thanks RAOF, Sarvatt, broder
#ubuntu-x 2012-03-07
<eruditehermit> is there an input channel for ubuntu-x?
<RAOF> What do you mean?
<eruditehermit> for touchpad and keyboard questions
<RAOF> Yes; #ubuntu-x :)
<eruditehermit> I read that multitouch touchpads might work
<eruditehermit> in 12.04
<eruditehermit> I tried letting ubuntu do the right thing but then my mouse doesn't work at all
<eruditehermit> so I had to revert back to psmouse proto=exps
<RAOF> What's your touchpad?
<eruditehermit> well it appears as AlpsPS/2 ALPS DualPoint TouchPad in xinput list
<eruditehermit> I am using a Sony VIAO SA 2011 model
<RAOF> Is there a launchpad bug about this?
<RAOF> cnd is the person most likely to be helpful with touchpads.
<cnd> actually, sforshee may be the best first line of defense :)
<cnd> sforshee wrote the multitouch patches for the ALPS touchpads for Linux
<RAOF> Yeah, I guess he *was* doing the actual re work :)
<cnd> the more people who do input stuff, the more I can shove off onto others
<cnd> RAOF, would you like to work on input stuff :)
<RAOF> Not particularly :)
<RAOF> Actually - you can have me on input, but only as long as you ensure I never need to touch the SIGIO context.
<cnd> RAOF, meh, I can live with that :)
<eruditehermit> what does it mean if the mouse pointer doesn't even appear
<cnd> eruditehermit, what did you try doing?
<cnd> eruditehermit, the mouse pointer hides when you don't move it
<cnd> so it likely means that you aren't moving it :)
<RAOF> cnd: You know that basically every line of the input stack gets called from the gorram SIGIO context, right? :)
<eruditehermit> cnd, Running 12.04 if I boot without kernel params for psmouse I cannot see or use my mouse at all
<cnd> RAOF, no, only the input modules basically
<eruditehermit> even if I move it no mouse pointer appears
<cnd> most of the xserver input stack is run in normal context
<cnd> eruditehermit, that's odd
<eruditehermit> however if I boot with psmouse proto=exps, I can use my mouse but with limited functionality
 * RAOF is just bitter that his pointer barrier work *is* unexpectedly called in the SIGIO context.
<cnd> RAOF, ewww
<RAOF> Indeed.
<RAOF> This is why people report "sometimes the X server freezes when I try to reveal the launcher" - because I'm sending events from SIGIO.
<eruditehermit> cnd, xinput list-props says Device Enabled 1
<eruditehermit> what should I try?
<cnd> eruditehermit, it sounds like you have a kernel driver issue
<cnd> eruditehermit, are you able to ping sforshee earlier in the day?
<eruditehermit> I can try
<cnd> eruditehermit, actually, the best thing would be to file a bug
<cnd> ubuntu-bug linux
<cnd> then subscribe seth forshee
<eruditehermit> cnd, is there a way to determine the actual hardware in the touchpad?
<cnd> eruditehermit, if it's not detecting the make and model automatically, then there's no easy way
<cnd> eruditehermit, do you know that it's an ALPS trackpad?
<eruditehermit> not sure
<eruditehermit> It is telling me
<eruditehermit> AlpsPS/2 ALPS DualPoint TouchPad
<eruditehermit> however I wanted to confirm that it is actually true
<cnd> eruditehermit, then it probably is ALPS
<cnd> I've not heard of accidental identifications
<eruditehermit> ok
<cnd> it would require a device to almost purposefully look like a different one
<eruditehermit> well in that case
<eruditehermit> that is what I have
<eruditehermit> I have a Sony VPCSA-290X
<cnd> eruditehermit, sforshee should know best then, he's worked on the ALPS driver quite a bit
<eruditehermit> ok
<eruditehermit> I will talk to him and file a bug report tomorrow
<eruditehermit> is there a way to check that any events are even being picked up by the driver?
<cnd> eruditehermit, there are lots of diagnostic tools :)
<cnd> when you file a bug report, a utouch-evemu recording would be helpful
<cnd> https://wiki.ubuntu.com/Multitouch/Testing/uTouchEvEmu#Debugging
<eruditehermit> cnd, ok will do
<eruditehermit> thanks!
<cnd> np :)
<RAOF> Dear X: I hate you, and your asynchronicity.  No love, Chris.
<Sarvatt> why the heck do I get flooded with this just closing my lid and reopening it http://kernel.ubuntu.com/~sarvatt/evtest.txt
<RAOF> That's a lot of events for closing+opening :)
<Sarvatt> i always come back to tons of new windows opened these days
<RAOF> Too sensitive touchpad?  Is it reading the screen or something? :)
<RAOF> Good.  That seems to now dependably pass the tests.  Will it do so in a chroot, though.  That is the question!
<RAOF> New question: Do these passing tests mean that the server (a) works, and (b) won't crash on me?  Tune in next time to find out!
<RAOF> Hm.  Well, that *has* fixed both the crashes and the potential deadlocking.  Now, about that runaway memory usageâ¦
<seb128> does anyone here know if cnd got anywhere with the gtk mouse wheel scrolling issue
<seb128> or with the scroll increment being buggy on i386 rather
<seb128> ?
<FernandoMiguel> I only have buggy scrool with mouthpad... usb mouse is fine.... but I'm on x64
<tjaalton> seb128: no idea
<eruditehermit> sforshee, please ping me when you are awake
<eruditehermit> thank you in advance
<FernandoMiguel> evening
<cnd> RAOF, did your pointer barrier stuff get into ubuntu, and is it being used?
<cnd> I'm curious to know what new functionality exists on my desktop :)
<RAOF> cnd: It is in Ubuntu, and it is being used.
<RAOF> It's how the launcher reveal works.
<RAOF> So it's only really being used if you've got the launcher to autohide.
<cnd> ahh
<cnd> RAOF, so what is the algorithm that we settled on?
<cnd> do you have to move a certain distance?
<cnd> or with a certain speed?
<RAOF> To parts:
<RAOF> The barrier is entirely transparent if you hit it above a certain speed.
<RAOF> Once you hit it, it generates events, and the client can then release the barrier at it's will.
<RAOF> You *may* be able to correlate âgenerates eventsâ with me bitching about stuff being called in the sigio context :)
<cnd> heh
<cnd> I hope you aren't trying to generate events on the heap in SIGIO :)
<RAOF> No.  I was blissfully unaware that I was being *called* from SIGIO, and so was sending events to clients from the handler.
<RAOF> This works amazingly often.
<cnd> ahh
<cnd> yeah, SIGIO almost always works
<cnd> sounds like we need to fix SIGIO :)
<RAOF> As in: it didn't fail once on *my* machine.
<RAOF> By âfixâ do you mean âuse a real input handling thread, like nature intendedâ?
<cnd> heh
<cnd> RAOF, do you remember how someone at nokia was attempting to do that?
<RAOF> Signals: 100% of the pain of multithreading, plus a whole lot of stupid restrictions!
<cnd> apparently they hit some nasty problems the further they dug
<RAOF> Yeah, tiago, right?
<cnd> maybe
<cnd> so I guess the work has been abandoned, sadly
<cnd> I think they hit issues when they would update the pointer sprite and/or sprint rendering from the input thread
<seb128> cnd, stop chatting and fixing scrolling ;-)
<cnd> seb128, I am just about to upload!
<seb128> \o/
<seb128> cnd, thanks
<cnd> seb128, did you see my bug?
<seb128> cnd, I just got dobey asking about it :p
<cnd> I subscribed you
<cnd> heh
<seb128> cnd, no ...
<cnd> seb128, I just created it an subscribed you about 10 mins ago
<seb128> let me check emails
<cnd> seb128, I just uploaded
<seb128> cnd, ok, great, https://bugs.launchpad.net/ubuntu/+source/libxi/+bug/949465 right?
<ubottu> Launchpad bug 949465 in libxi (Ubuntu) "XIScrollClass increment value incorrectly handled on 32-bit machines" [High,In progress]
<seb128> cnd, thanks a lot for fixing it, and sorry for being pingy about it ;-)
<cnd> seb128, nah, np :)
<cnd> seb128, I'm going to send the patch to xorg-devel now
<cnd> who should I Cc so gtk devs are aware?
<seb128> gtk-devel-list@gnome.org
<seb128> if you want to Cc them
<cnd> seb128, I'm wary of cross subscribing
<cnd> an entire list
<cnd> but if you think that's the best way, it's not a big deal
<seb128> cnd, mclasen@redhat.com then
<seb128> should be enough
<cnd> ok
<cnd> RAOF, bryceh: I'm about to upload a new xserver with updated input stack from 1.12 and a fix for bug 929408
<ubottu> Launchpad bug 929408 in xorg-server (Ubuntu) "X does not send multitouch touch end events properly" [High,In progress] https://launchpad.net/bugs/929408
<cnd> anything you need me to add in?
<bryceh> cnd, I notice there's a couple patches on the upstream xserver that look worth including
<cnd> bryceh, input related, or otherwise?
 * RAOF would *like* to include a fix for barriers, but that's not yet baked.
<bryceh> input, yes
<bryceh> hang on
<bryceh> 2416ee4a015068359807a10f433e8c54192c78a9 and 38000e7d1f958f5944e641de3e716944a5876d41
<bryceh> fixes for bug fdo #38313, which afaict doesn't affect us, but hard to say for sure
<bryceh> or I should say, s/doesn't affect us/hasn't been reported to us/
<cnd> bryceh, already got them
<cnd> locally in the branch I'm cooking at least
<bryceh> cnd, RAOF, we seem to have a slew of xserver crashes amongst inputty stuff
<bryceh> cnd, excellent
<cnd> bryceh, do they look like one or two bugs?
<cnd> or many?
<cnd> btw, there's currently a memory leak in the server when using gestures
<cnd> which is what I'm fixing for bug 929408
<bryceh> cnd, it sort of feels like there's invalid memory and bad pointers floating about
<ubottu> Launchpad bug 929408 in xorg-server (Ubuntu) "X does not send multitouch touch end events properly" [High,In progress] https://launchpad.net/bugs/929408
<bryceh> i.e., they're not simple NULL pointer deref issues, but oddball stacktraces
<cnd> hmmm
<cnd> RAOF, could they be because of your SIGIO issue?
<cnd> or has that already been fixed?
<RAOF> Some of that *might* be me, yes.
<bryceh> I *suspect* that a lot of these are dupes of the same underlying issue
<cnd> I think we should assume they are due to the SIGIO issue until it's fixed and we still see it
<cnd> because the signature of a SIGIO issue is random corruption :)
<bryceh> RAOF, bug #948858 might be yours?
<ubottu> Launchpad bug 948858 in xorg-server (Ubuntu) "Xorg crashed with SIGSEGV in WriteToClient()" [Medium,New] https://launchpad.net/bugs/948858
<bryceh> RAOF, "Unity crashed when moving the cursor to the top left corner"
<RAOF> Yup, entirely possible.
<bryceh> separate from these crashes, we're also seeing a bunch of SIGABRT bugs, that have crap for traces.  Anyone have a clue on those?
<cnd> bryceh, why are the traces bad?
<bryceh> bug #948733 for example
<ubottu> Error: Launchpad bug 948733 could not be found
<bryceh> cnd, they are all like this:
<bryceh> Stacktrace:
<bryceh>  #0 0x00a20416 in ?? ()
<bryceh>  No symbol table info available.
<bryceh>  Cannot access memory at address 0xbfc714f0
<cnd> hmmm
<cnd> could be memory corruption again?
<RAOF> Maybe?
<bryceh> I haven't seen bug reports with stacktraces like those since maybe a few weeks ago, and there's probably a dozen or so since, if that helps scope things
<cnd> RAOF, if it makes you feel any better, our first implementation of the X gesture extension had the same problem :)
<RAOF> I guess a stacktrace like that could be calling off into random memory...
<cnd> we were emitting gesture events from within the sigio context
<RAOF> cnd: Yeah, I think it's a fairly common thing to want to do.
 * RAOF has fixed the WorkQueue to make this possible.
<bryceh> should I just close them out (assuming there's not something obvious in the traces) and have them re-report after your upload(s)?  Or think they're worth keeping around for further study?
<cnd> perhaps we should add a check in WriteToClient for whether we are in SIGIO context or not
<RAOF> cnd: Not a terrible idea; add a flag to something, hidden behind DEBUG?
<cnd> bryceh, by close them out do you mean ask for confirmation in latest xserver and moving to incomplete?
<cnd> so they autoexpire after 60 days?
<cnd> RAOF, I wouldn't even hide it behind a flag
<bryceh> cnd, I could do that, but I meant close out as in mark fixed and tell them to file new bugs if they still get crashes
<cnd> RAOF, it's not like a check would be heavy weight right?
<cnd> bryceh, it irks me to think about bugs that are marked as fixed when we don't really know they are
<cnd> or at least don't have the submitters verifying
<RAOF> cnd: True.
<cnd> but waiting for the expiration will entail 60 days of bugs hanging around that are probably fixed
<cnd> I don't know how much that factors into your bug wrangling :)
<bryceh> nah if they're incomplete without response they're excluded from my view
<bryceh> I suspect a lot of these crashes are one-time one-off  things though, mostly without reproduction steps, so hard to definitively know they're fixed
<cnd> yeah, even if you're sure
<cnd> as in, think you're sure
<bryceh> on the plus side, apport seems to be catching these crashes ok, so if they're not fixed, people will be able to easily file new ones
<bryceh> anyway, setting to incomplete is fine by me, I'll make it so
<cnd> perhaps with a boilerplate message of: We think your bug has been fixed, but it is not possible to verify based on the information in this bug report. We are moving this bug to fix released. Please re-open if you encounter the bug again."
 * bryceh nods
<cnd> hooray!
<cnd> my integration test passes on the server I'm about to upload
<cnd> bryceh, RAOF: just double checking, you don't have anything else to consider for the upload?
<bryceh> nope
<bryceh> hmm, I could also dupe the bugs up.  that might be tidier
<cnd> yeah
<cnd> though it makes it harder for someone to reopen their specific bug if they hit it
<cnd> if they hit it again, that is
<cnd> they have to undupe, and then reopen
<cnd> but maybe we want them to file a new bug anyways?
<bryceh> they wouldn't need to reopen, just undupe
#ubuntu-x 2012-03-08
<RAOF> cnd: Nope.  I think I've just fixed Mr Barriers, but that should bake for just a tiny bit longer.
<cnd> cool
<Sarvatt> bryceh: so from my own bugs i've filed, i'm getting a segfault, then stuff is happening in the signal handler that is causing a SIGABRT later, and it keeps getting duped to doko's SIGABRT bug by apport even though i dont think its the the same
<cnd> it's uploaded now
<bryceh> Sarvatt, interesting
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/948697
<ubottu> Launchpad bug 948697 in xorg-server (Ubuntu) "Xorg crashed with SIGSEGV in valuator_mask_set_double()" [Undecided,New]
<bryceh> yeah I've noticed with a lot of these stacktraces, that there's a dozen lines of input related goo that happens *after* it enters the abort code
<Sarvatt> thats definitely a segfault, the abort is later but apport only cares about the later stuff
<bryceh> yeah, or see https://launchpadlibrarian.net/95731570/ThreadStacktrace.txt
<bryceh> there's a Sigio one
<RAOF> Huh.
<Sarvatt> bryceh: wait, thats someone elses bug? thats the same bug i'm hitting from the looks of it
<RAOF> You know what we should do?  Block signals after we get a SIGSEGV
<bryceh> yeah that's lp #948792
<ubottu> Launchpad bug 948792 in xorg-server (Ubuntu) "Xorg crashed with SIGSEGV in ___newselect_nocancel()" [Medium,New] https://launchpad.net/bugs/948792
<RAOF> If we're dying we don't want to handle input anyway.
<bryceh> Jeroen's bug
<bryceh> iirc he's able to repro that one fairly reliably
<Sarvatt> its really really hard to reproduce, i only hit it because when my lids closed my touchpad wigs out thinking its getting touched from the lid and it takes like 10 hours closed to hit from what i can see
<bryceh> Sarvatt, hey you're right these stacktraces do look the same
<Sarvatt> both bcm5974 devices too
<cnd> RAOF, so you want to block signals after a SIGSEGV from within a signal handler?
<RAOF> Maybe?
<Sarvatt> i'm amazed he got a crash report for the same thing apport actually retraced, i've filed 3 and all got duped to doko's totally different bug
<RAOF> Once we hit the server abort path we should unhook the SIGIO handler at least.
<cnd> RAOF, I guess the better question is why are we returning from the SIGSEGV handler?
<bryceh> Sarvatt, interesting [291953.349] bcm5974: not enough space for touch events (max 5 touchpoints). Dropping this event.
<Sarvatt> oh i get spammed with those constantly
<RAOF> cnd: I think because we do strange things - particularly, we go through the SEGV handler and then re-raise SEGV so that apport can dump.
<cnd> bryceh, Sarvatt: I wonder if that's due to the memory leak I just fixed
<Sarvatt> except its 8 touchpoints here
<Sarvatt> cnd: that would be freaking awesome
<Sarvatt> i'll switch back to synaptics to check
<cnd> Sarvatt, so that means we got stuck in sigio context long enough that many touchpoints came in before we were able to resize the touch record array
<cnd> though if it's dying at only 8 touch points then you aren't seeing the memory leak
<cnd> because the memory leak is the touch record array growing ad infinitum
<bryceh> cnd, is there a bug # for that memory leak?
<bryceh> oh wait, there is, you mentioned it already
<cnd> yeah
<cnd> it doesn't say it's a memory leak
<Sarvatt> oh it changes
<Sarvatt> [291953.349] bcm5974: not enough space for touch events (max 5 touchpoints). Dropping this event.
<Sarvatt> [291953.349] [dix] bcm5974: unable to begin touch point 6
<cnd> but that's another symptom
<bryceh> bug 929408
<ubottu> Launchpad bug 929408 in xorg-server (Ubuntu) "X does not send multitouch touch end events properly" [High,Fix released] https://launchpad.net/bugs/929408
<Sarvatt> [291958.903] bcm5974: not enough space for touch events (max 8 touchpoints). Dropping this event.
<Sarvatt> [291958.903] [dix] bcm5974: unable to begin touch point 8
<cnd> Sarvatt, that sounds like the server regular context is hung
<cnd> and the input sigio is still working
<RAOF> cnd: Wow.  The xserver build sure is chatty with the new xorg-macros.
<cnd> RAOF, what do you mean?
<cnd> the macros I added for CXX?
<bryceh> cnd, what's the version number for this new xserver?
<RAOF> I wanted to rebuild xorg-gtest, so I pulled the new xorg-macros, because you've made it depend on the newer macros.
<cnd> 1.11.4-0ubuntu5
<bryceh> thanks
<cnd> RAOF, it will still work with the older macros
<RAOF> Someone has apparently added ALL THE WARNINGS to xorg-macros.
<cnd> oh, they weren't there before?
<Sarvatt> RAOF: fun isn't it!
<RAOF> cnd: Not here it didn't; autogen bailed wanting a newer xorg-macros
<Sarvatt> no debian hasn't updated to util-macros 1.16 yet
<Sarvatt> for that reason :)
<Sarvatt> 1.16.1 is a little better
<cnd> RAOF, hmm, I thought it wouldn't require the latest xorg-macros
<cnd> I guess I'll need to double check that
<RAOF> Sarvatt: I pulled trunk.  You mean this is the *less bad* version? :)
<Sarvatt> if you think 1.16.2 with the gtest stuff in it is chatty you should have seen 1.16.0
<RAOF> Win!  That *was* the problem.
<RAOF> cnd: Once again, xorg-gtest is awesome.
<cnd> RAOF, hmmm?
<cnd> what was the problem?
<RAOF> Oh, a problem in the barrier code.
<cnd> ahh, cool
<cnd> RAOF, where are your tests?
<cnd> I want to see how you're using it
<RAOF> Only the first barrier event on the screen edge was getting triggered.  And because xorg-gtest is awesome, it was easy to find and verify.
<cnd> so I can try to provide for us both :)
<cnd> I'm going to add a method to xorg::testing::Test that will create a hierarchy of windows
<cnd> that's next on my plate, since it's needed for testing of touch grabs and selections and such
<RAOF> You can find them in the ubuntu-barrier-tests branch of xorg-server in my alioth repository.
<bryceh> Sarvatt, think https://launchpadlibrarian.net/95610521/ThreadStacktrace.txt is the same?  it's also got that <signal handler> ...fail... ...Device futzing... end style
<bryceh> different stack trace though
<Sarvatt> nope i wouldn't assume it was
<RAOF> cnd: http://anonscm.debian.org/gitweb/?p=users/raof-guest/xorg-server.git;a=summary
<cnd> just when I had already navigated to it...
<Sarvatt> mine *always* segfaults in valuator_mask_set_double
<bryceh> ok
<cnd> RAOF, so it's all in a debian patch?
<cnd> just checking
<RAOF> cnd: Yes.  Because now I'm going to submit MIRs for gtest and xorg-gtest, and this'll be enabled on the buildds.
<Sarvatt> that ones in pixman_region_intersect
<cnd> RAOF, are you planning to push the tests into precise?
<RAOF> cnd: Yes.
<cnd> RAOF, ok, before you do let me get integration tests proposed upstream at least
<cnd> I hope to have that by the end of this week
<RAOF> Integration tests for touch?
<cnd> for anything
<cnd> but the first proposed tests will be for touch :)
<RAOF> Why should these tests block on that?
<cnd> RAOF, actually, I suppose there's no reason they should
<cnd> RAOF, you aren't using evemu replaying are you?
<RAOF> No; just xtest.
<cnd> I guess if you have it working with debuild, then it's good
<cnd> sadly, evemu requires root or special udev rules
<cnd> so we probably can't enable them by default during the build
<cnd> RAOF, why do you have your own main()?
<cnd> instead of linking against xorg-gtest_main
<RAOF> cnd: So I can set options.  Specifically, so I can set the Xorg binary to ../../hw/xfree86/Xorg, and have my own conf file.
<cnd> oh, I see where you set those now
<cnd> I thought you were just providing the default options
<RAOF> Nope.
<cnd> cool
<RAOF> I'd also like to pass -dumbSched to the server; it makes debugging more pleasant.
<cnd> is that not possible with xorg-gtest today?
<cnd> hmmm, I guess not
<cnd> RAOF, if you find the time, xorg::testing::Environment could use a dumbSched boolean option and a generic "extra parameters" option
<RAOF> Yeah, was planning to do that.
<cnd> cool
<cnd> I'm glad it's been helpful :)
<cnd> RAOF, for the SIGIO corruption, maybe --gtest_repeat=-1 for a day on a test machine would help?
<cnd> though I think gtest_repeat may be broken due to it attempting to restart the server each time, and the shutdown not being handled properly
<RAOF> But it's not going to receive SIGIO, is it?
<cnd> ahh, good point
<cnd> because it's XTest
<RAOF> Indeed.  It presumably would with evemu.
<cnd> yeah
<RAOF> cnd: gtest in Debian is going to lose the static lib entirely; I don't think building with -fPIC will be accepted.
<cnd> RAOF, huh?
<cnd> they just dropped the shared lib
<cnd> so is it going to be source only?
<RAOF> Yes.
<RAOF> As Google intended :)
<RAOF> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639795
<ubottu> Debian bug 639795 in libgtest-dev "[libgtest-dev] gtest-config missing" [Normal,Open]
<cnd> interesting...
<cnd> RAOF, I suppose that's ok, but then it raises the question of: how do we find the sources?
<cnd> pkgconfig won't help, will it?
<RAOF> Assume they're in /usr/src/gtest; we could provide a pkgconfig file.
<cnd> but upstream doesn't provide a pkgconfig file, so that won't really help
<cnd> I fear a future where we have to use --with-gtest-source=/usr/src/gtest
<cnd> which then begs the question: should we be doing the same for xorg-gtest?
<cnd> oh well, we'll deal with the fallout when it comes I guess
<RAOF> Yeah.  That won't actually be terrible, though.
<RAOF> Just needs some autofoolery.
<cnd> yeah
<Sarvatt> yay non-crashy Xv fglrx finally released
<bryceh> oh yeah?  sweet
<Sarvatt> the march fglrx is like a week away though, that was the target for precise
<RAOF> I hate it when I realise that something only accidentally works.  Bah!
<jcristau> this gtest stuff sounds like xtrans all over again
<FernandoMiguel> morning
<cnd> RAOF, ping me when you are available, I want to chat with you about gtest
<jussi> hello all!
<jussi> anyone know if there are currently issues witht the nvidia driver in precise? I cant seem to get it to install - see: http://paste.ubuntu.com/874989/
<bryceh> jussi, have you had it installed on that hardware previously?
<jussi> bryceh: yes, updated a few days back and it was gone
<jussi> cant enable anymore
<bryceh> jussi, here's the nvidia bugs reported against precise so far - http://bit.ly/wFEQec
<jussi> bryceh: at first glance, seems similar/same as https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/949330
<ubottu> Launchpad bug 949330 in nvidia-graphics-drivers (Ubuntu) "nVidia driver won't load anymore" [Undecided,New]
<bryceh> jussi, yeah was just looking at that myself
<bryceh> sounds like jockey may be confused
<jussi> bryceh: right. Is there any further info I can provide to help diagnose? 
<bryceh> hmm, doesn't look like nvidia-current has changed in the last couple weeks
<bryceh> jockey did get a change on the 5th (minor stuff), and more major changes on t he 3rd
<bryceh> jussi, perhaps try downgrading to jockey 0.9.6-0ubuntu1?
<jussi> bryceh: forgive me, but how do I actually downgrade? 
<bryceh> three options:  1) apt-get install <package>=<version>
<bryceh> 2) if the .deb is in your /var/cache/apt/archive, then dpkg -i <path-to-deb>
<bryceh> 3) Go to the launchpad page for the package, and go to the version history section, find the version you want and drill down to get the .debs.  Then as in #2.
<jussi> right, Im on it. I assume I want jockey-common?  (not just the kde frontend)
<bryceh> jockey-common and whatever frontend you usually use (jockey-gtk maybe?)
<jussi> nah, its kde :) but yeah. do I need hte dh-modaliases? 
<bryceh> possibly
<jussi> bryceh: ok, it still fails: http://paste.ubuntu.com/875021/
<bryceh> jussi, which version of the nvidia driver did you have installed before?  -current?
<jussi> bryceh: I havent complete memory, but that is what I would usually install, yes.
<bryceh> jussi, alright so we've ruled out a regression in jockey
<bryceh> jussi, can you try purging all -nvidia from your system and then reinstalling it?
<bryceh> (if you haven't already)
<jussi> sure. sudo apt-get remove nvidia* ?
<jussi> or do I need to purge?
<bryceh> sudo apt-get purge nvidia*
<jussi> ok :)
<jussi> The following packages will be REMOVED:
<jussi>   kubuntu-desktop* nvidia-173* nvidia-173-updates* nvidia-common* nvidia-current*
<jussi>   nvidia-current-updates* nvidia-settings* nvidia-settings-updates*
<jussi> curious that the 173 ones are there...? 
<bryceh> in fact I've been wondering if that could be the problem
<jussi> right, do I need to reboot or restart something before attempting again?
<broder> and the -updates ones, too
<bryceh> I'm not great at grokking jockey logs however it keeps talking about 173 like it would prefer to install that
<bryceh> however we don't have a compatible version of -173 yet, so it's uninstallable
<jussi> 01:00.0 VGA compatible controller: NVIDIA Corporation G86 [GeForce 8500 GT] (rev a1)
<jussi> is the HW
<bryceh> hmm
<bryceh> I think that's reasonably modern enough
<bryceh> let's do the purge and then see what jockey thinks you should install
<jussi> ok, purge is done, Ill give jockey a go now.
<jussi> whoa, just got much faster.
<jussi> right, so I can choose current and current updates
<bryceh> you want current
<jussi> ok
<bryceh> (during development the two should be one and the same)
<jussi> it appears to be installing now...
<jussi> right, it installed. let me just reboot
<jussi> bryceh: right, it seems to be working now. Im not sure what caused jockey to install all of the drivers there tbh.
<jussi> Is there any other tests that are needed? or simply case closed forget about it? 
<bryceh> jussi, there was a jockey bug before where it'd prefer -173 over -current.  I think that may be fixed now.  Could be this is just fallout from that.
<jussi> bryceh: ahh that would make sense. I guess I just dont want to leave the situation without a bug report or something if it would be useful for others.
<bryceh> jussi, debugging this with you has been helpful.  I'll keep an eye out for others with the same trouble, and if it appears to be a pervasive problem it may be worth deeper exploration, to see fi we can set up a reproducible case.
<jussi> bryceh: sure. ping me if you need something, I idle here anyway :)
<bryceh> jussi, well what I think we would need is to know how to get your system back into that broken state.  If you have any ideas shout.
<bryceh> -nvidia installs have never been perfect, and the purge trick is well utilized
<jussi> bryceh: one thing I could try that just came to mind, is to see if its a bug with jockey not removing things - ie, if I now go try to install the current-updates, will it remove the current?
<jussi> so if in the past, I tried to install all 3 at different times, but it never actually removed them
<bryceh> I think it can cope with having both installed side by side, but only one will be in use at a time
<jussi> ok
<bryceh> you mention things had been slower, so I wonder if you had -173 loaded
<jussi> it was strange, I had some slowness, as well as a disappearing mouse cursor
<jussi> but not slow enough to really comment on, just a little. 
<bryceh> yeah, sounds like something that could be explained by an old driver
<bryceh> fwiw, bug 949330 appears to be a missing kernel driver, which I think is different from what you saw.  could be a weird dkms build issue (which is not unusual)
<ubottu> Launchpad bug 949330 in nvidia-graphics-drivers (Ubuntu) "nVidia driver won't load anymore" [Undecided,Incomplete] https://launchpad.net/bugs/949330
<jussi> ok. well lets leave it at that for now, if you need more, feel free to ping, I am very willing to help out where I can.
<bryceh> sure thing
<jussi> thanks forall the help :=)
<FernandoMiguel> anyone else having GPU crashes ?
<bryceh> FernandoMiguel, you'd have to be more specific
<FernandoMiguel> bryceh: I've seen traces replace my screen after login, and on shutdown it got locked on another trace
<bryceh> FernandoMiguel, do you have a bug#?
<FernandoMiguel> not yet
<FernandoMiguel> trying to gather info and reproduce it
<bryceh> FernandoMiguel, do you have a pastebin of the trace?
<FernandoMiguel> couldn't capture it
<FernandoMiguel> the 1st one was gone when I moved my mouse
<FernandoMiguel> the other locked on shutdown, so I forced rebooted
<bryceh> FernandoMiguel, alright well I going to be of little use to you without knowing some details ;-)
<bryceh> FernandoMiguel, "yes" people have gpu lockups, kernel crashes, and so on all the time
<FernandoMiguel> I know I know bryceh
<FernandoMiguel> any typs to debug it furhter ?
<FernandoMiguel> or to collect a log of what happened on last boot ?
<bryceh> steps to reproduce are always helpful.  See if you can reproduce it.
<FernandoMiguel> will see on the next shutdown :)
<bryceh> we need to have the trace.  You can check dmesg or /var/log/kern.log, etc.
<bryceh> file bug reports via 'ubuntu-bug linux'
<bryceh> or 'ubuntu-bug xorg' if you're certain its X failing.  Sounds like a kernel BUG or some such though, if it's printing on the screen
<FernandoMiguel> k
<bryceh> if it is a gpu lockup, then an i915_error_state.txt is required
<bryceh> if it is an X server crash, then we want a full backtrace from gdb
<FernandoMiguel> its on kern.log
<FernandoMiguel> http://paste.ubuntu.com/875270/
<FernandoMiguel> filing a bug now
<bryceh> aha
<bryceh> cifs
<bryceh> FernandoMiguel, so, looks like you had a filesystem error, perhaps related to crypto
<bryceh> FernandoMiguel, you'd be wanting to speak with the kernel folks then
<FernandoMiguel> ill
<FernandoMiguel> danka
<bryceh> no prob
* bryceh changed the topic of #ubuntu-x to: Before asking for help here, please file a bug report using 'ubuntu-bug xorg'.  See http://wiki.ubuntu.com/X/Reporting for tips.
<RAOF> cnd: Pong about gtest.
<cnd> RAOF, let me get back to you
<cnd> about to start a meeting
<RAOF> :)
<glosoli> Who is responsible for Ubuntu FGLRX ? 
<cnd> RAOF, ok, I am ready to chat :)
<cnd> so xorg-gtest is undergoing a huge change so that it can be built by projects instead of using precompiled libraries
<glosoli> Anyone knows who is reponsible of fglrx being 2 versions out of date ? 
<cnd> RAOF, I don't know if we should be including it in main for the LTS
<bryceh> cnd, does anything depend on it?
<bryceh> or, do you anticipate we'll be having large numbers of users running it?
<cnd> bryceh, not yet, but RAOF wants to upload an xorg-server with tests that use it
<bryceh> can it be an optional dependency in that case?
<cnd> bryceh, I guess the bigger issue is that RAOF has asked for a MIR of xorg-gtest, but I don't think we can commit to support of xorg-gtest as it exists today
<bryceh> in terms of security updates you mean?
<cnd> any updates, really
<cnd> I'm concerned about how we have a stack of precompiled libs
<cnd> that upstream gtest says is the wrong way to do things
<cnd> if the libstdc++ abi changes, we might be caught it a bad place
<cnd> or something like that
<bryceh> ah, gotcha
<bryceh> however once the LTS is shipped, it's unlikely libs would go through ABI changes, right?  Plus, you'd have the same problem if it's in universe
<cnd> true
<cnd> yeah, but I don't *have* to support universe :)
<bryceh> anyway, guess it boils down to how RAOF intends to use it.  having it in main does have some cost to it, but I don't think it's an unreasonable amount if there's sufficient value.
<cnd> yeah, I suppose it will be ok
<bryceh> there's lots of X packages we never update post-release, so this would be in good company ;-)
<cnd> heh
<RAOF> So, I'd quite like the tests to ship in the xserver.
<RAOF> They *are* currently optional; they'll only build if xorg-gtest is installed.
<RAOF> I guess there's not a high risk that the barrier tests get broken by post-release updates, so it's not terrible if they're not built on the buildds.
<RAOF> cnd: So, if you don't want to support xorg-gtest in main, then I can live with that.
<cnd> RAOF, I think it may be ok, but there will not be any further updates to xorg-gtest in precise
<cnd> I guess that's an assumed thing since we're past FF anyways
<cnd> meh, I'm getting my thoughts twisted in knots
<cnd> I think it'll be fine
<RAOF> Yeah.  What sort of bugs are we likely to see in xorg-gtest that require an SRU? :)
<cnd> heh
<cnd> so I've spent the entire day so far trying to get gtest to build inside a project
<cnd> I'm getting close
<cnd> I think I have xorg-gtest itself all figured out
<cnd> now I'm trying to convert xorg-gtest
<RAOF> What problems were you running in to?
<RAOF> I build gtest as a part of the xserver tests, and it's no biggy.
<cnd> RAOF, just trying to get it all set up "correctly"
<cnd> the google example Makefile is not very good...
 * RAOF does need to add the autofoo to allow you to specify the source directory.
<RAOF> But I did it the cheater's way, by adding gtest-all.cc to _noinst_SOURCES :)
<cnd> RAOF, you can see my work in progress at: http://cgit.freedesktop.org/~cndougla/xorg-gtest/log/?h=source
<RAOF> Looks good.
<RAOF> You'll still be shipping a pkg-config file, right?
<cnd> no
<cnd> what would be in it?
<RAOF> The version, at least.
<cnd> hmmm
<RAOF> You could also include the path to the source directories.
<cnd> how would you encode the path to the source directories?
<RAOF> As a pkg-config variable.
<cnd> you can define arbitrary vars?
#ubuntu-x 2012-03-09
<RAOF> Yup.
<cnd> hmm, ok, that will help with xorg-gtest
<cnd> though we still have to do gtest.m4 since gtest doesn't ship a pkgconfig
<RAOF> Right.
<cnd> RAOF, do you know if there's any standard name for a source dir in a pkgconfig file?
<RAOF> I don't think so.
<cnd> I'm using sourcedir
<RAOF> Sounds reasonable.
<cnd> RAOF, how do you get the variables out of a pkgconfig file?
<cnd> PKG_CHECK_MODULES only does CFLAGS and LIBS
<cnd> IIUC
<RAOF> pkg-config --variable=$VARIABLE $PACKAGE
<cnd> ok
<cnd> so you have to do it a bit manually
<RAOF> So you'll be doing something like âXORG_GTEST_SRC_DIR = $(shell $(PKG_CONFIG) --variable=sourcedir xorg-gtest)
<RAOF> Yeah, a little manually.
<RAOF> You can hide it behind your m4 macro, though.
<cnd> yeah
<eruditehermit> sforshee, hey are you about?
<sforshee> cnd, I just took a look at the bug that I think was filed by eruditehermit (bug 950496). From playing back the evemu-record capture everything looks normal. I updated the bug; if there's any other useful information he could supply please add a comment.
<ubottu> Error: Launchpad bug 950496 could not be found
<sforshee> cnd, that should be bug 950469
<ubottu> Launchpad bug 950469 in linux (Ubuntu) "mouse doesn't work with AlpsPS/2 DualPoint driver" [High,Confirmed] https://launchpad.net/bugs/950469
<cnd> sforshee, interesting
<cnd> thanks
<cnd> though if it worked for you, I'm not real sure what could be wrong
<sforshee> cnd, the first time I played it back it was from on my desktop and the pointer started moving all over the place :)
<sforshee> I'll know better than to do that again
<cnd> heh
<apw> bryceh, about?  am looking for a relativly safe (perhaps quite low resolution) edid for some testing, as in the binary data for one
<apw> bryceh, as i believe they have checksums right ?
<bryceh> apw, heya
<apw> bryceh, hey, i sent you an email on the edid thing
<bryceh> apw, just read it -- awesome!!
<apw> cool
<bryceh> apw, sure I can dig up edids for you
<apw> bryceh, i probabally don't need it now, i used my existing one
<apw> bryceh, which i deliberatly corrupted in the text fields
<bryceh> apw, ah ok.
<apw> bryceh, then loading it, triggered a checksum warning so i think it worked at least at a basic level
<bryceh> apw, if I have time today I'll bang on it a bit myself
<apw> bryceh, i am hoping you'll be able to load a low res edid into something and show it restricts resolution or something
 * apw only has a 1024x600 display here with him, rather annoyingly
<bryceh> apw, would be awesome if we could get this in for P, but I agree given the late date it might be safer to leave to Q.  What more would need done to get it into the P kernel?
<apw> bryceh, i am sure the patch is not yet 'ready' pretty sure it leaks memory, but overall its pretty safe looking, so i think with some twiddling we could get it up to scratch (assuming you find value in it)
<apw> bryceh, and i think if you find value in it we can get it in
<bryceh> ok
<apw> bryceh, as it is pretty benign if its not used
 * bryceh nods
<bryceh> as it happens there is an active bug right now I've been looking at, where the user's monitor is providing crap edid
<bryceh> apw, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/927155
<ubottu> Launchpad bug 927155 in xserver-xorg-video-intel (Ubuntu) "[snb-m-gt2+] Viewsonic VA2012w not correctly detected (Invalid EDID)" [Undecided,Incomplete]
<apw> bryceh, yeah if it "fixes" that sort of thing, then its even easier to justify it as effectivly a bug fix
<bryceh> exactly
<bryceh> I can definitely scare up a few such bugs.
<bryceh> I probably also have a kvm or two here that truncates edid, which this will fix.
<Sarvatt> oh man, Viewsonic VA2012w
<Sarvatt> i had that same monitor and the EDID got killed on it too
<apw> Sarvatt, as in the thing just decided to forget its own edid ?
<apw> bryceh, is that popey on that bug?
<bryceh> apw, yup
<Sarvatt> apw: yeah, there was a problem where the edid would get corrupted when using them on nvidia gpu's with some  buggy windows drivers
<apw> Sarvatt, the mind boggles, i'd expect them to be r/o in hw
<Sarvatt> you can rewrite those viewsonic ones from that era, i remember having to do that a bunch of times
<apw> bryceh, RAOF, while i remember, once you have put an edid in there it is pinned, you echo an empty line into there to let it be replaced by the real edid again
<apw> bryceh, ok i think its actually not leaking there is some background blob management
<apw> bryceh, i think it should be adding edid/ on the firmware filename though for safety, other than that its prolly close
<bryceh> apw, ok.  got it loaded on a system.  
<apw> bryceh, although it easy to see how one could automatically fix broken edids with this, letting udev check bad ones and replace them, its not clear how the 'all 0xff' case can be fixed
<bryceh> yeah.  probably still would require some manual user action
<Sarvatt> ah hah finally found the magic that fixed my old viewsonic,  Power up the monitor connected to the VGA and DVI outs both. Once fully powered up, power the machine back down, disconnect the monitor from the power outlet for ~30 seconds, and boot up with only the DVI input connected.
<bryceh> Sarvatt, I also found an edid.exe on the viewsonic site
<Sarvatt> this was like 5 years ago so memory was fuzzy, that really reset the edid on my viewsonic
<apw> bryceh, anyhow, having reviewed it i am happier its something we can accept, if your testing is good, i'll work on getting the prefix added for next week
<bryceh> no directions on how to use it though.
<bryceh> apw, excellent.  I'll plan on banging on it in the meantime.
<apw> bryceh, only three cycles ... sigh
<apw> Sarvatt, that is some arcane magic indeed
<Sarvatt> apw: yeah asked him to try it, those viewsonics from around 2006 when they first started doing the 20" widescreens were so crappy
<Sarvatt> google viewsonic bad edid
<Sarvatt> its full of fun
<apw> bryceh, it'd would be good to know if get-edid can get the edid when the kernel bit bashing cannot... i guess in the short term udev could use that to fill it in :/
<apw> bryceh, allllll assuming the edid is useful once you've 'rit it in your testing
<bryceh> right
<apw> and did it, did it, did it?  /me needs to drink less coffee
<bryceh> yeah I've been finding get-edid isn't super reliable.  Maybe only 10-25% of the time do we get something worthwhile
<bryceh> sorry, got called away to breakfast
<apw> heh, i am just starting on the G&Ts so i'll stop making sense shortly
<bryceh> well deserved!
 * Sarvatt is jealous
<apw> yeah its been one of those weeks, though my not wanting to work has gotten me on these 'small' tasks which got you your edid kernel ...
<apw> and leann about 4 wi's closed ...
<bryceh> ok, why am I not finding the edid file
<bryceh> ok, it's there on an -ati system but not an -nvidia??
<bryceh> find /sys/devices -name edid gives nothing there.  weird
<bryceh> moving on... intel next
<apw> bryceh, oh, only tested it only intel myself, but it comes from common code
<apw> bryceh, so i would expect them all to express one
<bryceh> yeah nfi with the nvidia box.  I'll have to investigate that more
<apw> /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/edid
<apw> bryceh, binary drivers by accident perhaps
<bryceh> could be
<bryceh> well, I mean it definitely has a binary driver loaded.  could be it just doesn't provide edid.  I'll try with nouveau
<apw> didn't the installer get changed back in 'o' or something to install them by default
<apw> doesn't the nvidia binary driver supply its own way to futsz with the edid ...
<Sarvatt> yea or at least it did at one point
<apw> bryceh, so .... the ultimate question, does it work
<cnd> RAOF, if you want a MIR for gtest without shipping the precompiled libs, then we'll have to do a FF exception to get the latest xorg-gtest in
<cnd> after I get stuff reviewed and merged on #xorg-devel
<bryceh> apw, well...  the edid file is empty (but get-edid is able to read it)
<mlankhorst> noon
<bryceh> heya mlankhorst 
<mlankhorst> hi :)
<bryceh> apw, ok so copying in edids seems to work ok, except on the nvidia system where it doesn't work even if -nvidia is uninstalled.
<bryceh> apw, and on one system I get the proper resolutions, so it hasn't broken it.  I'm not 100% certain the written edid is overwriting the old though.
<bryceh> apw, third system is unable to detect the proper resolutions across the kvm, so is a great candidate for testing the fix.  However, so far the edid doesn't appear to take effect, I just get vesa modes.
<bryceh> in all cases I'm using edid gathered from get-edid and assuming that's a valid blob
<apw> bryceh, cirtainly when i hexedit'd the one i had, it started saying there was an edid checksum erorr
<bryceh> apw, so, I think I can give a light confirmation that it works so far.  I'll play with it more next week to get a stronger confirmation.
<apw> bryceh, sounds good.  i am done now for the week anyhow, lets catch up monday
<bryceh> sounds good
<cnd> bryceh, whot has picked up the clickpad patches and has an attempt at fixing the clickaction vs clickpad issue
<cnd> he wants to merge it all for this release of synaptics
<bryceh> ok
<cnd> if that happens, we will probably want to go with upstream
<cnd> but that means re-enabling the clickpad stuff, but hopefully in a better working form
<cnd> should I propose an FFe for it?
<cnd> or reopen the first FFe?
<cnd> or?
<bryceh> either way, reopen the first one if that'd save you some time
<cnd> ok
<Sarvatt> the first FFe got approved, maybe thats good enough? :P
<cnd> yeah, I was wondering the same, but one factor in an FFe approval is timin
<cnd> timing*
<cnd> so I think we can't rely on the earlier approval
<eruditehermit> sforshee, hey
<sforshee> eruditehermit, hi
<eruditehermit> sforshee, so my kernel driver is working but my mouse isn't moving?
<sforshee> eruditehermit, that's how it looks to me. In fact, I played back your capture and watched my pointer move :)
<eruditehermit> lol
<eruditehermit> sforshee, any ideas why?
<sforshee> eruditehermit, not yet. X seems to see your touchpad, so I don't know what's happening.
<sforshee> apport-collect didn't attach the xorg log though
<sforshee> can you attach /var/log/Xorg.0.log from a session when the mouse doesn't work?
<eruditehermit> http://paste.ubuntu.com/
<sforshee> and if cnd has any ideas of what to look at, I'm all ears
<eruditehermit> err
<eruditehermit> http://paste.ubuntu.com/876687/
<eruditehermit> so I have sections where my mouse was proto=any
<eruditehermit> and sections where it was proto=exps
<eruditehermit> its really hard to give you a completley clean log
<eruditehermit> since I need my mouse!
<eruditehermit> lol
<eruditehermit> can't pastebin stuff without it
<eruditehermit> lol
<cnd> sforshee, are any evdev device properties set for alps trackpads?
<sforshee> Using input driver 'evdev' for 'ImPS/2 Generic Wheel Mouse'
<cnd> evdev properties aren't captured by evemu yet
<sforshee> this is when the mouse isn't working?
<sforshee> eruditehermit, ^
<cnd> sforshee, I bet that's when it is working
<sforshee> that's what I think
<eruditehermit> that is when it is working
<eruditehermit> ok
<eruditehermit> tell you what
<eruditehermit> I'll reboot
<eruditehermit> with the mouse not working
<eruditehermit> VT switch
<eruditehermit> cp log
<eruditehermit> then reboot again
<eruditehermit> brb
<eruditehermit> sforshee, cnd: http://paste.ubuntu.com/876712/
<sforshee> cnd, why would X not be using the synaptics driver?
<Sarvatt> eruditehermit: umm, xorg-edgers, might be broken
<Sarvatt> is xserver-xorg-input-synaptics installed?
<cnd> eruditehermit, you're using xorg-edgers?
<Sarvatt> i've been too focused on precise to keep up with edgers lately
<Sarvatt> hmm xserver-xorg-input-evdev in edgers doesn't work right now too from the looks of it
<Sarvatt> since it thinks the input abis are the same
<eruditehermit> ah
<eruditehermit> I forgot about edgers
<eruditehermit> let  me ppa-purge
<Sarvatt> ppa-purge wont work because you're on x86_64, will take a lot of manual downgrades :(
<eruditehermit> wait what?
<eruditehermit> :(
<eruditehermit> brb
<Sarvatt> i'm just gonna upload upstream evdev and synaptics driver updates, too many friggin patches to fix and check for this late on friday night :)
<Sarvatt> (to use ubuntu branches)
<eruditehermit> disregard bug
<eruditehermit> I'm stupid
<eruditehermit> =p
<eruditehermit> xorg-edgers
<cnd> eruditehermit, I'm glad we figured it out :)
<cnd> thanks!
<cnd> be sure to move the bug to invalid if you haven't already
<eruditehermit> I will
<eruditehermit> also
<eruditehermit> it seems the pointer acceleration and sensitivity can't be set via gnome
<eruditehermit> is that known?
<Sarvatt> eruditehermit: really sorry about that, didn't realize edgers was broken because i stopped using it for the past few weeks to test precise stuff, uploaded new checkouts now though
<Sarvatt> i'm waiting for mesa to settle the heck down wrt the autoconf changes on master before going back to it, redoing the packaging every other day gets old when there isnt enough time in a day as it is :)
<sforshee> cnd, what do the the acceleration and sensitivity sliders actually change? Is it something that trickles down to the kernel driver?
<Sarvatt> eruditehermit: which ones, the ones in the mouse or the touchpad tab?
<cnd> sforshee, I think gnome is broken
<cnd> it doesn't do anything for me either
<cnd> but I've never taken the time to look into it
<sforshee> cnd, the acceleration one seems to make a difference on the macbook air at least
<cnd> it doesn't work for my magic mouse
<cnd> it may work for synaptics but not evdev?
<sforshee> when alps is working correctly it's using synaptics
<cnd> yeah
<cnd> maybe eruditehermit was seeing the issue while he was using evdev?
 * sforshee boots up his crappy old dell to see what happens
<eruditehermit> Sarvatt, the ones in mouse
<cnd> those would be the ones for evdev then
<cnd> eruditehermit, please file a bug for that and paste it here
<cnd> I can mark it as a bug that needs to be looked at by beta 2
<eruditehermit> cnd, err I've got to run now
<eruditehermit> cnd, will be back later
<cnd> ok
<eruditehermit> I need to understand what to file so I will ask questions
<cnd> sure
<eruditehermit> bbl
<eruditehermit> thanks for all the help!
<sforshee> eruditehermit, the acceleration slider seems to have an effect on this dell with an alps touchpad
<sforshee> i still have no idea what the sensitivity slider is supposed to be changing
<Sarvatt> eruditehermit: really though, is xserver-xorg-input-synaptics installed? it doesn't look like it is from your log
<Sarvatt> AlpsPS/2 means its in synaptics mode and should be using -synaptics
<Sarvatt> its ImPS/2 when its in the old mode that needs evdev
<cnd> sforshee, eruditehermit was referring to the slider in the mouse tab
<cnd> I think :)
<sforshee> cnd, that would explain it :)
<Sarvatt> also acpi_osi=Linuxi is a typo
 * sforshee -> EOW, have a good weekend everyone
<mlankhorst> Sarvatt: generally just want to mimmick windows..
<Sarvatt> sforshee: dont suppose you know any magic to fix DFS on wl? :P brcmsmac is so horrible
#ubuntu-x 2012-03-10
<eruditehermit> cnd, hey
<cnd> eruditehermit, howdy
<eruditehermit> so a couple of things
<eruditehermit> there are 2 sets of acceleration and sensitivity settings in gnome
<eruditehermit> mouse and touchpad
<eruditehermit> what am I supposed to change as a user
<eruditehermit> if I change the mouse stuff, does it only apply to non touchpad things?
<eruditehermit> i.e. usb mice
<cnd> eruditehermit, correct
<cnd> well, I'm not a gnome developer
<cnd> but I believe that to be correct
<eruditehermit> hrm
<eruditehermit> so I think the touchpad accel and sensitivity work
<eruditehermit> however, they are really high by default
<eruditehermit> the sensitivity
<eruditehermit> especially
<eruditehermit> as in the lowest sensitivity is really high
<cnd> what does accel vs sensitivity mean to you?
<cnd> I don't really know the difference
<eruditehermit> accel means that if I move my finger fast, I should be able to move my mouse further than if I do it slowly
<eruditehermit> a dynamic sensitivity?
<cnd> ok
<eruditehermit> does that make sense?
<cnd> yeah
<cnd> so I don't know exactly who's default is bad
<cnd> X synaptics input module, or gnome
<cnd> probably X synaptics, because the gnome default feels fine here
<cnd> so X synaptics should have picked up on some property of your device and set a different scaling factor
<eruditehermit> I liked the defaults that the psmouse proto=exps provided
<eruditehermit> as far as accel and sensitivity
<eruditehermit> is there a way to query that information
<eruditehermit> and set it to be the same
<eruditehermit> also is there a way to obtain more than the gnome gestures
<eruditehermit> how do I find out if the touchpad accepts 3 finger touch
<cnd> eruditehermit, no real way to query the exps defaults
<cnd> exps used the X evdev driver
<cnd> which has a different way of handling acceleration and sensitivity
<cnd> eruditehermit, 3 finger gestures are disabled by default in ubuntu because they are reserved for, and may be used by, unity
<cnd> unfortunately, the only 3 touch gesture in unity is broken right now
<cnd> but it's being fixed :)
<cnd> however, you can manually override this if you want
<cnd> synclient ClickFinger3=2
<cnd> synclient TapButton3=2
<cnd> will enable middle click emulation through tapping and clicking (if you have a clickpad)
<eruditehermit> tapping and clicking?
<cnd> on the touchpad
<eruditehermit> so if I click with 3 fingers on the touchpad
<eruditehermit> I will get middle click?
<eruditehermit> wow
<eruditehermit> lol
<eruditehermit> it worked
<eruditehermit> are there ways to make 3 finger gestures?
<cnd> eruditehermit, what do you mean?
<eruditehermit> how does one make this persist?
<eruditehermit> swipe left with 3 fingers closes a program
<eruditehermit> lets say
<eruditehermit> or something like that
<cnd> if you're using unity, you have to live with the unity gestures
<cnd> it won't allow you to configure them
<cnd> if you're not in unity
<eruditehermit> what are the unity gestures?
<cnd> you can use the utouch-geis API
<cnd> the only three touch unity gesture is dragging the window and spread/pinch to maximize/unmaximize
<cnd> but that gesture is broken right now
<eruditehermit> ah
<eruditehermit> so zooming will be gesture enabled
<Sarvatt> eruditehermit: Option "ClickFinger3" "integer" and Option "TapButton3" "integer"
<eruditehermit> where do I put that?
<Sarvatt> http://paste.ubuntu.com/876835/
<Sarvatt> save that as /etc/X11/xorg.conf
<eruditehermit> ah
<eruditehermit> xorg really needs a persistent settings mechanism
<eruditehermit> I thought the point was to remove xorg.conf
<eruditehermit> also
<eruditehermit> /etc/init/vgaswitcheroo.switch
<eruditehermit> not being executed anymore
<Sarvatt> has to have a .conf extension doesn't it?
<eruditehermit> err
<eruditehermit> thats what I mean
<eruditehermit> .conf
<eruditehermit> seems very temperamental
<eruditehermit> brb
<eruditehermit> let me test
<Sarvatt> darn idr isn't around, was going to ask if there were any plans to cherry-pick all these intel commits to 8.0 branch anytime soon
<eruditehermit> hmm
<eruditehermit> that script in /etc/init/vgaswitcheroo.conf isn't working
<eruditehermit> is there a way to see if it is being called?
<eruditehermit> and if it is being called, if its working
<eruditehermit> I swear it was working a few days ago
<eruditehermit> hey, does anyone have experience with hybrid graphics?
<Sarvatt> plenty of experience hating it but only on nvidia/intel lenovo where its possible to pick the gpu in the bios, none with ati/intel here
<eruditehermit> Sarvatt, so remember that init script we worked on a few days ago
<Sarvatt> that was RAOF but yeah
<eruditehermit> Sarvatt, it stopped working
<eruditehermit> yeah collectively
<eruditehermit> also
<eruditehermit> whenever I wake up from suspend my power consumption goes up a lot
<eruditehermit> as if the discrete gpu is switched on again
<Sarvatt> sudo service vgaswitcheroo start fix it?
<eruditehermit> however vgaswitcheroo reports DIS as off
<Sarvatt> ah yeah i have no clue, sounds like it doesnt work over a S3 :(
<eruditehermit> Sarvatt, sudo service vgaswitcheroo start works
<eruditehermit> but its not working on bootup
<Sarvatt> the machines canonical certifies that i have to care about are pretty much just business class ones and dell/lenovo only use ati/intel on consumer class ones
 * Sarvatt has a strange perspective i guess :)
<eruditehermit> hrm
<eruditehermit> do you know about getting fglrx to work with this?
<eruditehermit> supposedly it works
<Sarvatt> tseliot is the best person to ask about that, he wrote the scripts fglrx uses
<Sarvatt> but he wont be around till monday CET
<eruditehermit> btw you said ppa-purge is broken?
<Sarvatt> yeah, it doesn't know about multiarch
<Sarvatt> it just tries to purge the native arch packages and leaves the :i386 stuff which breaks things bad
<eruditehermit> so how do I go about doing this properly?
<Sarvatt> http://paste.ubuntu.com/877015/
<Sarvatt> thats what i use to purge edgers, but you it'll install some crap you dont have installed now
<Sarvatt> like -dev packages
 * Sarvatt really needs to fix ppa-purge one of these days...
<Sarvatt> cairo libdrm and mesa :i386 packages really screw it up
<Sarvatt> since anyone with wine installed has that
<eruditehermit> hrm
<eruditehermit> it doesn't quite work
<Sarvatt> which is like everyone that cares to use edgers
<eruditehermit> it has some more dependencies that break it
<Sarvatt> had even more packages than that installed?
<eruditehermit> libpixman-1-dev/precise libpixman-1-0/precise libpciaccess-dev/precise libpciaccess0:i386/precise
<eruditehermit> and more
<eruditehermit> everytime I add one
<eruditehermit> it complains about more
<eruditehermit> lol
<Sarvatt> oh yeah pixman is new
<Sarvatt> since i purged it last
<Sarvatt> add libpixman-1-dev/precise libpixman-1-0/precise libpixman-1-0:i386/precise libpciaccess-dev/precise libpciaccess0/precise libpciaccess0:i386/precise to it
<eruditehermit> yep that did it
<eruditehermit> I was missing one of them
<eruditehermit> lol
<Sarvatt> cool beans, sorry about the trouble, its such a pain in the ass
<Sarvatt> forgot ricotz updated those two libs today
<eruditehermit> oh thank you so much for putting up with my questions
<eruditehermit> sorry about bothering you guys
<eruditehermit> the things not working on my laptop are slowly being fixed
<Sarvatt> i uploaded new synaptics and evdev that should work but they still haven't built
<eruditehermit> touchpad finally works a year after I bought it
<Sarvatt> yeah sforshee fixed alps to not suck
<Sarvatt> that was freaking awesome :)
<eruditehermit> yeah
<eruditehermit> that fixed so many laptops
<eruditehermit> finally multitouch on linux
<Sarvatt> like all dells in the past year
<eruditehermit> all dells in the past 3 years
<eruditehermit> so the broken parts on my machine are hybrid GPU
<Sarvatt> well alps wasnt used across the whole line till sandybridge, was rare before that
<eruditehermit> light sensor
<eruditehermit> and power consumption
<Sarvatt> that was like entirely rc6 being enabled by default
<eruditehermit> well
<eruditehermit> I still have issues
<eruditehermit> with my hybrid GPU turning on randomly
<eruditehermit> and even with all the power savings
<eruditehermit> it still only gets 3hrs
<eruditehermit> vs 5-6 on windows
<eruditehermit> which is a lot better than the 1hr I was getting
<eruditehermit> =p
<eruditehermit> also
<eruditehermit> how to make video players use intel vaapi
<eruditehermit> and flash plugin to use vaapi
<Sarvatt> sudo apt-get install i965<tab>
<Sarvatt> oh flash i dont think that uses vaapi at all
<Sarvatt> but the va 965 drivers are a separate package now
<eruditehermit> do you mean sudo apt-get install i965*
<eruditehermit> also I have that driver installed
<eruditehermit> but my CPU usage spikes when playing videos
<Sarvatt> i965-va-driver is what you need to make va work
<Sarvatt> the package name
<eruditehermit> yeah I have that
<Sarvatt> that should totally be a recommends or suggests..
<eruditehermit> it should be a depends
<eruditehermit> lol
<eruditehermit> not sure why someone wouldn't want it
<Sarvatt> agreed :)
<Sarvatt> because they use fglrx and want to save 50kb disk space?
<eruditehermit> or do suggests get pulled automatically
<Sarvatt> people are weird
<Sarvatt> recommends do i think
<eruditehermit> then recommends is fine
<eruditehermit> so if someone wants to remove it they can
<eruditehermit> but by default it should be installed
<Sarvatt> Uncompressed Size: 28.7 k
<Sarvatt> even less than i thought
<Sarvatt> 2.7kb compressed size on the livecd
<eruditehermit> so how do I test if it is being used when I play a video?
<Sarvatt> think i'll file that bug :)
<Sarvatt> eruditehermit: what playback app?
<eruditehermit> lets say totem
<eruditehermit> or vlc
<Sarvatt> depends on which you're using, its enabled different ways
<Sarvatt> hmm
<Sarvatt> totem is weird, i think that uses gstreamer-vaapi
<Sarvatt> vlc is weird too
<Sarvatt> you go to INPUT codecs
<Sarvatt> and check the use gpu accelerated decoding
<Sarvatt> vainfo will tell you what your gpu supports
<Sarvatt> and hope your videos arent like mine encoded in h264 hi10p profile that cant be accelerated by any gpu
<Sarvatt> (anime)
<Sarvatt> i'm not sure how you make sure the upstart script is used every boot though
<Sarvatt> i thought it ran every script in /etc/init/ at boot, maybe the radeon hasn't loaded when it tries to run?
<Sarvatt> (sometimes, making it racy)
<Sarvatt> there might be a conditional you can throw in there to make it wait until its ready, lessee
<Sarvatt> no, i remember what RAOF pasted you waited until radeon loaded
<Sarvatt> maybe add the vgaswitcheroo stuff to /etc/init/plymouth.conf?
<Sarvatt> hmm no radeon is usually modprobed by xserver which would be well after plymouth starts sometimes, especially in a dual gpu scenario
<Sarvatt> err lightdm i meant there instead of plymouth
<Sarvatt>            and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
<Sarvatt>  would be satisfied by the intel being ready
<eruditehermit> hrm
<eruditehermit> why wouldn't the upstart script work as is?
<eruditehermit> it should wait for both intel and radeon
<Sarvatt> radeon being modprobed isnt enough, it takes a long time to finish loading, we hit bugs with that many times in the past
<eruditehermit> ah I see
<Sarvatt> (just thinking out loud, might be wrong)
<eruditehermit> it doesn't wait till its finished?
<eruditehermit> it fires off scripts after they just start?
<Sarvatt> nope it just checks if its loaded before running and probably runs the same time that its modprobed, can ya paste it?
<broder> it's not critical that the radeon card be turned off *immediately*, right?
<eruditehermit> the script?
<broder> so just add a sleep 3 or something
<Sarvatt> broder: nope
<Sarvatt> oh yeah, friggin easy solution!
<broder> :)
<Sarvatt> eruditehermit: do what he says, add a sleep 3 :)
<Sarvatt> friday night, beer oclock, brain not working obviously
<eruditehermit> http://paste.ubuntu.com/877036/
<eruditehermit> like that?
<Sarvatt> eruditehermit: perfect
<eruditehermit> so is there a way to do stuff before suspend and after resume
<eruditehermit> I want to turn all GPUs on and then off on resume
<Sarvatt> have ya googled vgaswitcheroo suspend?
<broder> eruditehermit: put http://paste.ubuntu.com/877039/ in /etc/pm/sleep.d/00_vgaswitcheroo
<broder> possibly chmod +x it
<broder> you did say that echoing OFF back into the switcheroo node fixes it, right?
<eruditehermit> I think so
<eruditehermit> well I'll do an ON first
<eruditehermit> then off
<Sarvatt> eruditehermit: its gstreamer0.10-vaapi
<Sarvatt> for totem
<Sarvatt> i'm not sure if its automatic that it'll use it though, probably is
<eruditehermit> hmm I already have that too
<Sarvatt> tjaalton: wth is that package name? :P
<eruditehermit> but weird
<eruditehermit> power usage goes from 13W to 26W when playing videos
<Sarvatt> eruditehermit: not surprised, i dont recommend using vaapi at all :)
<eruditehermit> how come?
<Sarvatt> vaapi is a joke, it uses as much cpu as software rendering
<Sarvatt> plus you're running the gpu at higher voltages/clock speeds because its being used
<eruditehermit> hmm
<eruditehermit> my system is running at 13-15W
<eruditehermit> need to get it to 8-10W to match windows
<Sarvatt> its nothing like vdpau on nvidia where the cpu isnt stressed 
<eruditehermit> Linux kernel is power hungry
<eruditehermit> ok
<eruditehermit> let me test my new startup script
<eruditehermit> brb
<eruditehermit> thanks Sarvatt, broder
<Sarvatt> increase the sleep if it doesnt work, 3 seconds really should be plenty though
<eruditehermit> lol
<eruditehermit> so it works!
<eruditehermit> but another annoyance I forgot about
<eruditehermit> brightness settings do not persist
<eruditehermit> nor do bluetooth being on/off
<Sarvatt> its more like X starts at 8 seconds into the boot on a fast ssd, radeon hasnt finished loading by then, a second later its not ready and there is corruption on the screen from the plymouth->x transition before it was ready that was a problem
<Sarvatt> oh cool
<eruditehermit> so many things don't persist
<eruditehermit> xinput settings too
<Sarvatt> eruditehermit: thats what you get for buying a linux unfriendly sony :)
<eruditehermit> does it persist on other machines?
<eruditehermit> actually this machine has been pretty good
<eruditehermit> Dell's were a lot worse
<eruditehermit> their mice drove me crazy
<eruditehermit> this mouse was usable even with psmouse
<eruditehermit> err
<eruditehermit> proto=exps
<Sarvatt> they're like the only oem besides apple that doesnt have any vested interest in making linux work, fujistsu would be number 2 close behind them in bios bugs and lack of platform drivers taking care of those things :)
<eruditehermit> surprising that everything mostly works then
<eruditehermit> just the ati thing
<eruditehermit> and then general linux kernel power hungry ness
<Sarvatt> yea that ati thing is a problem for everyone, hybrid graphics are annoying :)
<eruditehermit> I guess the light sensor isn't hooked up
<eruditehermit> but the rest of it works
<Sarvatt> no driver for it im sure
<eruditehermit> honestly dell had shitty laptops last year
<eruditehermit> actually everyone did
<eruditehermit> when I got this
<eruditehermit> I wanted something small and light
<eruditehermit> everyone was making big and heavy
<eruditehermit> this year people have caught on
<eruditehermit> ultrabooks
<eruditehermit> choice was apple
<eruditehermit> and sony
<Sarvatt> yeah agreed
<Sarvatt> i went apple
<eruditehermit> and sony was lighter/more powerful
<Sarvatt> but the only other option was sony
<eruditehermit> even apple at the time
<eruditehermit> only had the air
<eruditehermit> air was 3lbs
<eruditehermit> pro was 4.5
<eruditehermit> mine is 3.5 with the power of the pro
<Sarvatt> oh ok i waited till june for sandybridge airs, those are awesome :)
<eruditehermit> I got it february
<Sarvatt> but yeah GPU blows
<Sarvatt> i have a 17" laptop with a gtx 460m for that
<eruditehermit> lol its good in windows
<eruditehermit> i have an i7!
<eruditehermit> i7 and discrete GPU
<Sarvatt> that you cant use?
<eruditehermit> at 3.5lbs
<eruditehermit> well
<eruditehermit> I can use it in windows
<Sarvatt> :(
<Sarvatt> yeah
<eruditehermit> getting it to work with fglrx is the trick
<eruditehermit> would be cool if X could hot swap GPUs
<Sarvatt> the thing is, ati only cares about people who ship linux and have the oems escallate problems to them
<eruditehermit> read something on phoronix yesterday about it being a possibility
<Sarvatt> which pretty much wont ever be sony
<eruditehermit> HP and dell have nice ultrabooks now
<eruditehermit> more choice
<Sarvatt> i like ux31 atm personally
<eruditehermit> but really
<eruditehermit> brightness not being remembered
<eruditehermit> that isn't a sony problem
<eruditehermit> its a gnome problem right?
<eruditehermit> or x
<Sarvatt> no thats actually a bios problem afaik
<Sarvatt> i could be wrong
<Sarvatt> the brightness level isnt stored anywhere on your system
<Sarvatt> its up to the bios to remember what you were at before, is it right on the next POST?
<eruditehermit> I just have to lower it on every boot once gnome is up
<Sarvatt> if its bright again on the bios screens the next boot linux wouldn't be what you blame
<eruditehermit> do you have any experience with fglrx at all?
<eruditehermit> I am going to try something crazy
<Sarvatt> hardly any
<eruditehermit> lol
<eruditehermit> to USE it
<Sarvatt> i used it maybe 1 hour in my life :P
<Sarvatt> just to see if new driver releases worked
<eruditehermit> with nvidia
<eruditehermit> can you switch GPU without restarting X?
<Sarvatt> no
<eruditehermit> well
<Sarvatt> you cant do that on anything due to how X works
<eruditehermit> lets see how fglrx does
<eruditehermit> brb
<eruditehermit> hrm
<eruditehermit> failure
<eruditehermit> the fglrx package in precise seems old
<eruditehermit> and not to work with hybrid
<Sarvatt> it is old, because the one that works properly was released 2 days ago, the goal is to have the one released next week in final precise
<eruditehermit> next week?
<eruditehermit> they are releasing another one
<Sarvatt> or the week after, sometime soon
<Sarvatt> they got delayed for the feb release
<eruditehermit> I see
<Sarvatt> jan release was still as broken as the one in there now
<eruditehermit> the link is down
<eruditehermit> on their website
<Sarvatt> was no feb release, feb catalyst was released 2 days ago
<eruditehermit> for 12-2
<Sarvatt> safe to say if its broken in the precise one it'll still not work though :(
<eruditehermit> if it is broken in 11-11 in precise?
<eruditehermit> hopefully they fixed it all to work
<eruditehermit> seems like it does a lot of moving of other libs around
<eruditehermit> regular libgl etc
<Sarvatt> its just a minor increment to the 12-2 one coming out real soon now, they skipped the february release and released an early version of marches for 12-2
<eruditehermit> yeah
<Sarvatt> you can build your own version from the ati.com one easily though no need to use the distro packages
<eruditehermit> any idea where to get it from?
<Sarvatt> like --build Ubuntu/precise
<eruditehermit> their link is down
<Sarvatt> http://www2.ati.com/drivers/linux/amd-driver-installer-12-2-x86.x86_64.run works for me
<eruditehermit> Duplicate headers received from server
<eruditehermit> wow it works with wget
<eruditehermit> chrome barfs for some reason
<Sarvatt> one sec uploading it
<Sarvatt> oh ok
<Sarvatt> the website is all kinds of messed up in chrome here
<Sarvatt> had to pick the driver with the keyboard
<eruditehermit> yeah
<Sarvatt> ./amd-driver-installer-12-2-x86.x86_64.run --buildpkg Ubuntu/precise it is
<Sarvatt> it doesnt work on i386
<Sarvatt> another reason it probably hasnt been uploaded by now
<eruditehermit> --buildandinstallpkg is what I use
<eruditehermit> lol
<Sarvatt> http://ubuntuone.com/1UXKtX6u65jOGDrNpyWHyY if you didnt manage to get it
<Sarvatt> gotta use my 50gb ubuntuone storage somehow
<eruditehermit> wget was able to get it for me
<eruditehermit> strange that chrome didn't like it
<eruditehermit> I thought it was down
<Sarvatt> Version 19.0.1061.1 dev
<Sarvatt> working fine there
<eruditehermit> 19???
<eruditehermit> lol
<eruditehermit> I have 17
<Sarvatt> oh i must be 2 days ahead of you then
<Sarvatt> dev channel :)
<eruditehermit> stable is 17 still
<eruditehermit> lol
<eruditehermit> but yeah
<eruditehermit> chrome was at version 2 a few days ago
<eruditehermit> ok
<eruditehermit> time to try new fglrx
<eruditehermit> brb
<Sarvatt> looks like that went well :)
<tjaalton> Sarvatt: the -vaapi part?blame ustream :)
<Sarvatt> well i tried to install gstreamer-vaapi like the source package name :)
<Sarvatt> was more complaining about the 0.10 part
<Sarvatt> but yeah thats how gstreamer crap is namespaced just my own screwup
<tjaalton> yep
<tjaalton> besides, it triggers bug 946742
<ubottu> Launchpad bug 946742 in intel-vaapi-driver (Ubuntu) "Shotwell crashes on start with gstreamer0.10-vaapi" [Undecided,Confirmed] https://launchpad.net/bugs/946742
<Sarvatt> oh FUN
<tjaalton> fixed in upstream master, but would rather know which commit
<Sarvatt> http://cgit.freedesktop.org/vaapi/intel-driver/log/ is taking forever to load
<Sarvatt> at least its hard to hit, have to purposefully install 2 things to hit it
<tjaalton> nah, just browse with nautilus to a folder where you have videos :)
<Sarvatt> i965-va-driver and the gstreamer0.10-vaapi thing
<tjaalton> oh
<tjaalton> yeah
<Sarvatt> i like how cedarview pvr va crap doesnt even work with it that you went out of your way to add it for :P
<Sarvatt> tjaalton: hmm nautilus is fine here
<Sarvatt> on snb
<Sarvatt> video folder, thumbnails arent killing anything
<Sarvatt> was gonna bisect but need to reproduce first :)
<Sarvatt> shotwell is just giving generic video thumbnails, bah
<tjaalton> ok, fails here
<Sarvatt> http://ubuntuone.com/6BjApmzC9kzm1HyQSVm8fB (the one to the right of to the cursor)
<Sarvatt> what kinda videos do you have? avi?
 * Sarvatt browses to the NAS where all his videos are
<tjaalton> guess I tried it with bigbuckbunny
<tjaalton> meh, resume fail
<Sarvatt> argh i think i did something so it didnt thumbnail videos and cant remember what it was
<tjaalton> ok so is it unity fail when I get a blank screen, but the pwd dialog is obviously working
<Sarvatt> oh
<Sarvatt> shotwell-video-thumbnailer: gen6_mfd.c:844: gen6_mfd_avc_ref_idx_state: Assertion `frame_idx < (sizeof(gen6_mfd_context->reference_surface) / sizeof((gen6_mfd_context->reference_surface)[0]))' failed.
<tjaalton> and the mouse cursor changes when it's moved around
<Sarvatt> i got that to stderr launching it in a terminal, thats from intel-driver
<tjaalton> yeah, unity replace fixed it..
<tjaalton> or not
<tjaalton> Sarvatt: yeah that's the one
<Sarvatt> http://cgit.freedesktop.org/vaapi/intel-driver/commit/src/gen6_mfd.c?id=368731d104da84605fcf6683d6ce014916fe76b0
<tjaalton> looks plausible
<Sarvatt> only commit that touched that function between the two versions but yeah
<Sarvatt> doesn't apply easy to test :)
<tjaalton> yeah I tried something and came to the same conclusion.. not easy to just pull something..
<tjaalton> so I asked the author if there's going to be a release soon but he didn't reply
<Sarvatt> git cherry-pick 99ded53e66af1903f1d58ffbc24404d435a6de84; git cherry-pick 99ded53e66af1903f1d58ffbc24404d435a6de84 gets it to apply easily
<Sarvatt> got it building now, wish i could make it crash
<Sarvatt> but still i should be able to tell if that assertion is gone
<tjaalton> right
<Sarvatt> no assertion after cherry-picking those two
<tjaalton> hehe, thanks
<tjaalton> you can rest now :)
<Sarvatt> http://ubuntuone.com/6R5dmBssdYVJtouXzcciv6 if you want to check it
<Sarvatt> i965-va-driver and libva are in collab-maint and a friggin nightmare to update
<Sarvatt> as bad as libxcb was a year ago
<tjaalton> nightmare how?
 * Sarvatt is spoiled by X packages
<Sarvatt> changes have to git in git, autoreconf via a patch?
<Sarvatt> err have to go in git
<Sarvatt> or did that change too..
<tjaalton> oh
 * Sarvatt absolutely hates autoreconf via a patch
<Sarvatt> like wacom in debian
<tjaalton> yeah that's stupid
<tjaalton> another thing is importing tarballs when upstream uses git..
<tjaalton> like, what?
<Sarvatt> the git-buildpackage workflow?
<Sarvatt> aka nouveau?
<Sarvatt> xterm
<Sarvatt> oh xterm doesnt use git nevermind :)
<tjaalton> well it should work fine with upstream branches from upstream git
<Sarvatt> ricotz: tell me if i broke input on edgers :)
 * Sarvatt isnt using it and apparently evdev was broken before
<Sarvatt> tjaalton: hmm so the actual driver  is in libva-intel-vaapi-driver not i965-va-driver
 * Sarvatt only installed i965-va-driver testing shotwell
<Sarvatt> so disregard my saying i didnt hit the assert :)
<Sarvatt> no clue what triggered it then
<ricotz> Sarvatt, havent updated to your uploads yet ;), and the scrolling-brokenness was on the gtk3 side which was fixed in git master
<ricotz> Sarvatt, maybe you have an opinion to add https://bugs.launchpad.net/ubuntu/+source/libpciaccess/+bug/950985
<ubottu> Launchpad bug 950985 in libpciaccess (Ubuntu) "FFe: Sync libpciaccess 0.13-1 (main) from Debian unstable (main)" [Undecided,New]
<Sarvatt> http://ubuntuone.com/6kx60S7s3RixNNpIuw6aea is libva-intel-vaapi-driver
<eruditehermit> Sarvatt, still about?
<FernandoMiguel> darn..... compiz/unity are fighting over Alt+Tab control :/
<eruditehermit> hello!
<eruditehermit> Sarvatt, you about?
#ubuntu-x 2012-03-11
<RAOF> Sarvatt: One of the races you'll hit with that upstart script is that module loading order isn't necessarily deterministic; if radeon comes up before intel, it's the primary framebuffer (at the time the intel comes up), so vgaswitcheroo won't turn it off.  A sleep should fix that, though ;)
<eruditehermit> hey
<Sarvatt> ricotz: 0.13 might not be a good idea, wont build on powerpc
<eruditehermit> sforshee, hey
#ubuntu-x 2013-03-05
<shadeslayer> hi, I'm trying to switch cards using vga_switcheroo and this script : http://paste.ubuntu.com/5587116/
<shadeslayer> but as soon as I tell it to switch to the IGD, and I restart X, the screen gets blanked
<shadeslayer> s/blanked/turned off/
<shadeslayer> dmesg : http://paste.ubuntu.com/5587114/ and Xorg.log http://paste.ubuntu.com/5587115/ 
<shadeslayer> any ideas?\
<shadeslayer> switching from intel to radeon seems to work
<mlankhorst> shadeslayer: macbook?
<shadeslayer> yeah
<shadeslayer> I finally have efi + radeon working, just don't know why switching doesn't work
<shadeslayer> mlankhorst: is the script fine? that's my first concern
<mlankhorst> https://www.youtube.com/watch?v=7MvQyHYKq8Q there :)
<mlankhorst> oops wrong channel :PP
<mlankhorst> shadeslayer: let me check
<shadeslayer> hehe
<shadeslayer> mlankhorst: okay
<mlankhorst> script looks fine
<mlankhorst> shadeslayer: you could try recent kernel + http://cgit.freedesktop.org/~mlankhorst/linux/commit/?id=ae7b687c2a57ec50a9d3dde7b0a80a262fdc8c89
<shadeslayer> I'll give it a try, but I'm stepping out for an hour, so will get back to you on this
<shadeslayer> mlankhorst: works for me, except my dmesg is full of backtraces
<shadeslayer> http://paste.ubuntu.com/5587658/
<mlankhorst> no surprises there
<shadeslayer> oh, why so?
<mlankhorst> was getting the same, it's probably harmless
<shadeslayer> I see
<shadeslayer> well, there's just one small issue left then, something about efivars which I don't remember
<shadeslayer> probably because I didn't compile the kernel properly
<shadeslayer> mlankhorst: so any chances this will land in the ubuntu kernel at some point this cycle?
<mlankhorst> dno, not a kernel dev and it's a ugly hack, i got it from sforshee
<shadeslayer> ah :)
<tjaalton> wth, built xserver 1.14 with old video abi + whot's input fix branch, but lightdm refuses to start it. runs fine standalone
<mlankhorst> anything suspicious?
<tjaalton> not really
<mlankhorst> nothing in xorg log?
 * mlankhorst has had fun today fixing a vblank regression
<tjaalton> xorg log looks normal
<tjaalton> the greeter isn't running, that would explain it
<tjaalton> actually, the xorg log is refreshed/created only when I _stop_ lightdm
<tjaalton> oh well, I don't need it
<tjaalton> for testing this stuff
<tjaalton> yeah, touch bug fixed
<mlankhorst> \o/
<tjaalton> or not :/
<mlankhorst>  /o\
<tjaalton> :)
<ogra_> stop teasing !
<tjaalton> well, it took quite a bit of beating to actually get stuck, and it could be different this time
<tjaalton> ogra_: should an external mouse still work perfectly?
<ogra_> yes
<tjaalton> when touch is hung
<tjaalton> I kinda forgot
<tjaalton> anyway, this time it doesn't
<ogra_> even onboard works if you use the floating button
<tjaalton> but, if it's (just) a hung client this time, it should be recoverable
<tjaalton> *** Error in `X': corrupted double-linked list: 0x43bed1a8 ***
<ogra_> you should be ablet to still workj in apps and so on, usually just the taps arent recognized by compiz bits
<tjaalton> ha
<ogra_> yay
<tjaalton> drawing the desktop background is somehow broken with 1.14, dunno why
<tjaalton> windows leave a trace there
<tjaalton> anyway
<tjaalton> let's see if it's just the client (unity) that gets hung..
<tjaalton> I also get errors from grail about "touch N failed to be rejected"
<tjaalton> gnome-terminal crashes the server/driver
<tjaalton> hum, actually starting it shuts the xserver down cleanly, wth
<tjaalton> oh well, don't need that either
<tjaalton> same thing with xterm
<tjaalton> ...
<tjaalton> k, works better as the user :)
<tjaalton> lightdm started to work after a vt change, but it's still easy to crash the server
<mlankhorst> valgrinddd
#ubuntu-x 2013-03-06
<shadeslayer> hi, when trying to run shank using the drivers from xorg-edgers it says it can't find the R600 driver, presumably because I'm on am64 and it uses i386 libs
<shadeslayer> and I can't install the i386 drivers because keyboard-configuration is arch any
<shadeslayer> any ideas how to fix?
<RAOF> Why can't you install the i386 drivers? They should be installable.
<shadeslayer> because xserver-xorg-core:i386 depends on keyboard-configuration:i386, but there is no keyboard-configuration:i386
<shadeslayer> http://paste.kde.org/688472/
<RAOF> Why are you trying to install xserver-xorg-core:i386? All you need for 3D is the mesa drivers - libgl1-mesa-glx:i386 and what it recommends/depends on.
<shadeslayer> don't I need  xserver-xorg-video-radeon:i386 ?
<shadeslayer> because I get : libGL error: failed to load driver: r600
<RAOF> One reason you'll get that is if you don't have the appropriate libgl1-mesa-dri installed.
<RAOF> But, as it probably says, âLIBGL_DEBUG=verbose glxinfoâ will get more information.
<RAOF> Or just throwing LIBGL_DEBUG=verbose into your environment.
<shadeslayer> aye, that's what I'm doing
<shadeslayer> RAOF: http://paste.kde.org/688484/
<shadeslayer> I think you're right
<RAOF> shadeslayer: So, âlibGL error: dlopen /usr/lib/i386-linux-gnu/dri/r600_dri.so failed (/usr/local/games/shank/bin/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /usr/lib/i386-linux-gnu/libLLVM-3.2.so.1))â is the interesting bit.
<RAOF> As you can see, you've *got* the r600_dri.so driver; however, there's a problem somewhere in its dependencies.
<shadeslayer> I see
<RAOF> Oh!
<RAOF> Of course.
<RAOF> It's trying to load /usr/local/games/shank/bin/libstdc++.so.6 as your libstdc++, but that's the wrong version.
<shadeslayer> oh
<shadeslayer> :<
<RAOF> So, try moving that out of the way.
<RAOF> Or just deleting it.
<RAOF> You've got a perfectly functional libstdc++.so.6 in /usr/lib/i386-linux-gnu, so unless shank has done something *utterly insane* like patching their libstdc++, deleting their copy should work.
<shadeslayer> yeah
<shadeslayer> it does work :)
<shadeslayer> bah
<shadeslayer> stupid game
<shadeslayer> it didn't work on the intel card, doesn't work on the ATI card
<shadeslayer> http://wstaw.org/m/2013/03/06/plasma-desktopnQ5646.png
<llstarks> shadeslayer, having fun with powerxpress/enduro?
<RAOF> shadeslayer: I wonder if you need the dxtn library for i386? libtxc-dxxtn-s2tc0:i386?
<shadeslayer> llstarks: heh :)
<shadeslayer> I'm not sure if it's a powerexpress, it's whatever Apple used for the 8,2 MBP
 * mlankhorst yawns
<mlankhorst> morning
<shadeslayer> RAOF: libtxc-dxtn-s2tc0:i386 is already installed
<hyperair> force s3tc compression on using driconf?
<shadeslayer> do I need to restart X or just the game after I do that?
<shadeslayer> hm
<shadeslayer> hyperair: fwiw I don't have that option on the ATI card
<hyperair> oh
<hyperair> just the game.
<shadeslayer> well, driconf doesn't give me an option to force s3tc compression
<hyperair> weird
<hyperair> oh well
<llstarks> shadeslayer, oh that's gmux
<tjaalton> hah, got a good backtrace of the crash with the touch fix branch
<tjaalton> phew..
<tjaalton> took a lot longer to crash this time
<mlankhorst> tjaalton: would it be reproducable with a macbook touchpad?
<tjaalton> mlankhorst: dunno
<tjaalton> maybe, if you set it absolute, and so it registers a click on every touch :)
<tjaalton> maybe needs to mimick a touchscreen otherwise as well
<tjaalton> hmm so what are the multitouch gestures again?
<tjaalton> since I'm seeing something strange here...
<mlankhorst> three fingers was adjusting window iirc, 4 was dash
<tjaalton> aka. they only work when the single touch is locked..
<tjaalton> ah, no.. works
<tjaalton> ok, now on to the crazy intel backports..
<tseliot> ricotz: hi, I think you spoke with bryce saying that the versioned dep on nvidia-current in nvidia-cuda 5 needs to be unversioned to work with virtual-packages. Can you explain exactly what package you were referring to?
<ricotz> tseliot, i am not remembering the package right now, but afair some lib package has a versioning dep on nvidia > 304.xx
<ricotz> which breaks the installation with edgers nvidia-313
<tseliot> ricotz: can it be libcuda?
<ricotz> and having all those provides/conflicts is kind of bad
<ricotz> it should get some thinking to avoid those
<ricotz> let me see
<tseliot> ricotz: provides/conflicts in nvidia or in cuda?
<ricotz> in the nvidia packaging
<tseliot> right, tumbleweed mentioned that too
<ricotz> this is pretty bad, imo there should be one "Provide: xorg-driver-binary-blob" or something
<tseliot> but we need the drivers manager to be able to easily switch between nvidia drivers, without complaining when trying to install a driver other than the one you have already installed
<ricotz> to unify amd/nvidia in some way
<ricotz> the manager should be able to pick the package directly nvidia-304, -313 and so on
<ricotz> sorry, i don't have insight in how they get picked currently
<tseliot> yes, what I mean is, for example the user has already installed 304, then he decides to install 313
<ricotz> ok, so?
<tseliot> but without the conflicts/replace/provide stuff, apt will give an error since the packages conflict with one another
<ricotz> both will provide the virtual package
<tseliot> I'm pretty sure I tried that in the past and it didn't work
<ricotz> "xorg-driver-binary-blob"
<ricotz> i see
<tseliot> I can try again in case memory is failing me but I think I've already tried that path
<ricotz> ok
<ricotz> havent tried it myself yet
<tseliot> ricotz: BTW, I've made some changes to the packaging of 313 so as to make the creation of new flavours easier
<tseliot> https://github.com/tseliot/nvidia-graphics-drivers/commit/e62fccf6ab50161026e1d2c75199f7ff03e26a4e
<tseliot> https://github.com/tseliot/nvidia-graphics-drivers/commit/1d503d498b0de824974693b50ca7fe7f68d14291
<ricotz> tseliot, thanks, will resync it with 304 and 313 in edgers when i get to it
<tseliot> ricotz: I'm also uploading the latest 313 as we speak
<ricotz> 313.26?
<tseliot> yep
<tseliot> ricotz: I've tried with dummy packages and the whole conflicts/replace/provides works with a metapackage (at least with apt, not with dpkg). This is great news!
<mlankhorst> tjaalton: I guess it's about the series of 7 and series of 12 on ml?
<tjaalton> mlankhorst: yep
<mlankhorst> so I just grab canonical-x ppa for all drivers and cherry pick those patches into my xserver?
<ricotz> tseliot, ok :)
<mlankhorst> tjaalton: mind if I stuff 1.14 in canonical-x?
<tjaalton> mlankhorst: huh? it's in there?
<tjaalton> already
<mlankhorst> oh 1.14 was released
<mlankhorst> this morning
<tjaalton> oh that
<tjaalton> yeah, go for it
<mlankhorst> boo, site is down
<mlankhorst> tjaalton: well since x1.14 won't be in raring, I'm just going to keep changelog updated with the ppa for now. I'm also using some self generated tarball for xorg 1.14, seems the site is down :/
<tjaalton> hmm, not 100% sure if you can change the tarball once we push it to the main repo
<tjaalton> then again, there should be .1 at some point, with these touch fixes
<mlankhorst> well I expect 1.14.0 not to be the version we'll upload :)
<tjaalton> or the final set, without crashers :)
<tjaalton> right
<tjaalton> git.fd.o doesn't work either
<mlankhorst> annarchy is down, i cant ssh to it
<mlankhorst> blergh can't rebase to test on my macbook now, thing broke :(
<tseliot> ricotz: also, make sure you check the latest commit for 313 in my git repository (I've fixed an issue in my previous changes)
<tseliot> ricotz: *latest commits
<ricotz> tseliot, alright
<mlankhorst> oh finally got x1.14 set up now
<Duke`> latest xorg-intel-video driver in xorg-edgers (2013-03-01) is totally broken for i945 GM x_x
<mlankhorst> tjaalton: what is the easiest way to reproduce the hang?
<Duke`> and the previous one (2013-02-26) was not very good too
<mlankhorst> erm the touch hanging :)
<tjaalton> mlankhorst: read the upstream bug :)
<tjaalton> afk ->
<mlankhorst> oh fd bugzilla still works
<mlankhorst> tjaalton: yeah I can reproduce it on my macbook :)
<mlankhorst> it's a lot easier to crash with valgrind enabled too! :D
<mlankhorst> ugh hold on i might have removed the flavor
 * mlankhorst reinstalls xserver-xorg-core to be sure
<tjaalton> ah cool
<tjaalton> with multitouch synaptics?
<mlankhorst> yeah
<tjaalton> ok
<tjaalton> so this is with 1.13 or patched 1.14?
<mlankhorst> 1.14.0 + the input patches
<tjaalton> ok, did you try the original bug?
<tjaalton> maybe the new one isn't touch specific then
<tjaalton> since I can still use touch gestures
<mlankhorst> I think it's separat
<tjaalton> yeah
<bryce> where we at with mesa 9.1?
<mlankhorst> Fire when ready?
<tjaalton> well the slow blur with dash on intel would be nice to get fixed
<bryce> any reservations to including it in 13.04?
<tjaalton> but we could FFe it
<tjaalton> not really
<tjaalton> maybe even get 9.1.1 in time
<bryce> mm, that'd be nice
<mlankhorst> but packaging for 9.1 is done
<tjaalton> I'd like to review it one more time though, there is the -dev package mess on debian for instance
<tjaalton> that kano is so vocal about
<bryce> heh
<bryce> pushed the "fix" for the drm race condition
<bryce> (I quote fix because I think it just works around the problem by adding sleep.  But this may be the best we can do on the X side.)
<tjaalton> bryce: it doesn't fix it
<tjaalton> I tried a similar patch, and even when it doesn't give that error message it can fail
<tjaalton> too bad though..
<ogra_> https://plus.google.com/hangouts/_/914b5784e52c5967784eae44e4b138a346b1ff90?authuser=0 post UDS drinking hangout ... 
<tjaalton> ogra_: is there a live feed to watch with popcorn? :)
<tjaalton> no beer at hand :/
<ogra_> i donmt think so, you have to participate with beer :)
<tjaalton> dammit
<bryce> tjaalton, on the contrary, the testing has shown when the message shows up, it does result in a working system
<tjaalton> which message?
<bryce> setversion 1.4 failed
<tjaalton> you mean _doesn't_ show up?
<bryce> no
<tjaalton> I'm confused then :)
<tjaalton> that would mean when it fails to open the drm device the system works?
<bryce> real simple:  I uploaded a patch that works around the issue.  Testers confirm their systems now boot and work reliably (although sometimes with slight delay due to the sleeping)
<bryce> yep, that seems to be what's happening.  I don't understand why, but there are multiple confirmations it's true.
<tjaalton> I'm just reading the commit msg
<bryce> tjaalton, there's ample logs there now if you want to study further
<tjaalton> I know the logs :)
<bryce> tjaalton, you're just wanting to diss my fix?  ;-)
<tjaalton> which show that when "setversion 1.4 failed" is on them it will fail
<tjaalton> nono
<tjaalton> I believe it'll make it harder to hit
<tjaalton> so it's definitely good to have _something_
<tjaalton> I'll edit my first comment: "it doesn't fix it completely". there :)
<bryce> well, thus my quotes.  "fix"
<tjaalton> ah, true
<bryce> the problem seems deeper than X tho
<bryce> I'm not sure there's more we can do *in X* than this
<tjaalton> me neither
<mlankhorst> I could mess up the kernel :P
<tjaalton> please do
<tjaalton> :)
<mlankhorst> but I'd need a good way to reproduce the issue first
<bryce> at least this gives us clearer error messages (error codes!) and improves the situation for users
<tjaalton> there was some option to fully disable plymouth (removing splash isn't enough) on the cmdline, also maybe get some proper tracing from the kernel or such
<bryce> i seem to remember early on several people tried switching off plymouth but it didn't make a difference.  Maybe they didn't do it "fully" enough tho.  *shrug*
<RAOF> mlankhorst: You're not in #ubuntu-mir, but moving to Mir dma-buf is one of my upcoming tasks. âº
<tjaalton> "adam" on that bug hit some nouveau issue
<tjaalton> bryce: removing 'splash' isn't enough, i was told
<tjaalton> there's also some plymouth.debug option
<tjaalton> but maybe it is just a race inside drm. one guy said on a bug that removing 'splash' made it fail every time
<tjaalton> too bad the system that fails for me 7 out of 10 bootups is my main desktop..
<tjaalton> which has a surprisingly long uptime of 11 days now :)
<mlankhorst> can I reproduce it after removing/re-inserting the module somehow/
<tjaalton> how do you remove a kms module?
<tjaalton> is it possible?
<mlankhorst> oh I have a script for that
<tjaalton> alright
<mlankhorst> first you do echo 1 > /sys/class/vtcon/*1/unbind
<mlankhorst> then rmmod probably works
<mlankhorst> although maybe just binding/unbinding would be enough
<tjaalton> hmm some of the crashes might be hybrid races too
<tjaalton> that airlied has not seen
<tjaalton> yet
<mlankhorst> actually binding/unbinding might be easier to test
<mlankhorst> tjaalton: and I suspect hybrid might mess up if it loads the modules in the wrong order, for example nouveau first instead of i915, but this is just speculation, maybe I was just hitting the same race as before
<tjaalton> should we create a wikipage or something to track this? it might need a diagram or two about what happens between kernel loading and xserver being up?
<tjaalton> mlankhorst: could be
<mlankhorst> i think tomorrow I'll just try to make some test case that doesn't involve booting to trigger
<tjaalton> that would be great
<mlankhorst> and then probably fix it
<tjaalton> maybe udev plays a part in it too
<mlankhorst> some strategic placed sleeps in the kernel might make it easier to hit :p
#ubuntu-x 2013-03-07
<mlankhorst> aha, so the wrong password on sudo does go somewhere if you have mail set up!
<mlankhorst> ubuntu : Mar  7 11:45:51 : mlankhorst : 1 incorrect password attempt ; TTY=pts/7 ; PWD=/home/mlankhorst/nfs/linux ; USER=root ; COMMAND=/usr/bin/make me a sandwich
<xnox> mlankhorst: http://xkcd.com/838/
<mlankhorst> but mine ended up in my mail somehow!
<xnox> mlankhorst: read the alt-text on the image. santa is *copied* on var/spoll/main
<xnox> s/main/mail/ =)
<mlankhorst> ah
<leshaste> hi
<leshaste> vdpauinfo 
<leshaste> display: :0   screen: 0
<leshaste> Failed to open VDPAU backend libvdpau_r600.so: cannot open shared object file: No such file or directory
<leshaste> how do I fix that?
<leshaste> in lubuntu 12.10
<mlankhorst> just ignore
<leshaste> it fills up my terminal window randomly as well
<leshaste> I assume whenever chromium tries to play a video?
<mlankhorst> it's non-fatal
<leshaste> sure :)
<leshaste> apt-file search libvdpau_r600.so says it doesn't exist
<mlankhorst> it only gets generated if you compile mesa yourself
<leshaste> oh.. so it's just a packaging error?
<mlankhorst> and have vdpau enabled in it
<mlankhorst> nah we just don't ship it
<mlankhorst> mesa 9.1 is the first one that works sort of correctly with mplayer2
<leshaste> I mean the appearance of the error is due to something changing though
<leshaste> as it wasn't there before some apt-get upgrade
<leshaste> of course I can't remember which one
<mlankhorst> probably flash plugin updating
<leshaste> that will be it
<leshaste> good spot!
<leshaste> lubuntu gives an amazing number of errors/warnings in the terminal
<leshaste> so I suppose I can ignore one more set :)
<mlankhorst> but I think it won't work, since you probably need to implement vdpau interop first..
<leshaste> sorry what won't work?
<mlankhorst> flash + vdpau
<leshaste> ok.. flash does work here so that is something
<mlankhorst> like I said it's non-fatal
<leshaste> ok thanks
<leshaste> oh it looks like adobe dropped linux support?!
<leshaste> http://www.adobe.com/software/flash/about/
<mlankhorst> it's still supported for chrome, just not firefox
<mlankhorst> unless you add pepper api support to firefox, I suppose
<user99999> hello
<user99999> how to change mouse dpi?
#ubuntu-x 2013-03-08
<seb128> tjaalton, hey
<tjaalton> seb128: yo
<tjaalton> ah
<tjaalton> :)
<tjaalton> I know what you want
<seb128> tjaalton, how are you?
<tjaalton> great
<seb128> tjaalton, I'm building -intel from git, I was wondering if I can just ./configure && make and cp the binary
<seb128> or do we have distro patches I should keep
<tjaalton> no patches
<seb128> want to test the fix for that sna bug
<tjaalton> right
<seb128> ok, great, thanks
<tjaalton> I tried to identify the commit but wasn't sure
<seb128> tjaalton, I think it's
<seb128> commit c6a59bee3bf5f42147f75a714f2b9aa26590329e
<seb128>     sna: Disable read-read optimisations
<seb128>     
<seb128>     There is still a lurking issue, so punt on the optimisation for now.
<seb128>     
<seb128>     Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61628
<seb128>  
<ubottu> Freedesktop bug 61628 in Driver/intel "[ilk] Corrupted rendering of page previews in Firefox with >xf86-video-intel-2.20.18" [Normal,New]
<seb128> the bug pointed is the one Chris Wilson mentioned
<tjaalton> oh cool, didn't know it was upstream
<seb128> tjaalton, read https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1144558/comments/9 ? ;-)
<ubottu> Launchpad bug 1144558 in xserver-xorg-video-intel (Ubuntu Raring) "Images corruption in firefox when using "sna"" [High,In progress]
<seb128> tjaalton, in any case building so I will have an update soon
<tjaalton> yep
<tjaalton> ugh, fglrx dkms packages aren't purged when upgrading from 12.04 with hw that the driver doesn't support anymore
<tjaalton> bug 1073634
<ubottu> bug 1073634 in xorg-server (Ubuntu) "iMac: Screen resolution not working after upgrade to 12.10" [Undecided,New] https://launchpad.net/bugs/1073634
<tjaalton> it's not that, guess fglrx itself is still installed
#ubuntu-x 2014-03-05
<superkuh> Hi. Does anyone know of a guide or reference for configuration of and compilation of the X stack (xorg-server most specifically) on Ubuntu? So far I am working off of http://edzeame.wordpress.com/2012/09/18/112/ and http://www.x.org/wiki/Building_the_X_Window_System/ . 
<superkuh> Alternately, xorg-edger's used to provide the packages I need. But they were deleted from the repos after support for lucid was dropped (https://launchpad.net/~xorg-edgers/+archive/ppa/+build/1852863). If one of you guys happened to know where copies of these exist I would be very, very appreciative.
<mlankhorst> superkuh: simply use the debian x repository with the ubuntu branch and build with the debian build system :P
<mlankhorst> or use the xorg-edgers stuff
<superkuh> Thanks for the tip. I will try.
<superkuh> Already I've found better documentation using those search terms than I had previously in 2 days of searching.
#ubuntu-x 2014-03-07
<mlankhorst> darkxst: yes
#ubuntu-x 2015-03-02
<tseliot> ricotz: 346.47 builds fine with buildfix_kernel_3.18.patch applied and linux 3.19
<tseliot> # dkms status
<tseliot> nvidia-346, 346.47, 3.19.0-7-generic, x86_64: installed
<ricotz> tseliot, the question wasn't if it still builds with it, but it this patch really needed ;)
<tseliot> ricotz: if I remember correctly, the driver builds without but then it fails at runtime
<ricotz> tseliot, hmm, did you report this upstream?
<tseliot> I don't remember the exact error (drm bus something)
<tseliot> no, but I assume they are already aware of that
<ricotz> tseliot, ok, did you check if it still fails without the patch?
<tseliot> ricotz: not yet. I've only used a chroot for today. Tomorrow I'll see if it boots
<ricotz> tseliot, alright
#ubuntu-x 2015-03-06
<furkan> hey everyone, i was wondering, is there any chance that Vivid will be released with Xorg 1.17? the current package still appears to be 1.16
<furkan> there's a glyph corruption bug with GLAMOR that i'm running into a lot, and it appears to be fixed in 1.17
<furkan> i haven't tested it myself, but i'm just judging based on the resolved bug report: https://bugs.freedesktop.org/show_bug.cgi?id=81930
<ubottu> Freedesktop bug 81930 in Driver/glamor "[glamor] misrendered glyphs" [Normal,Resolved: fixed]
<tjaalton> furkan: there's a ffe bug open about it
<smallfoot-> Is there any systemd session to run Wayland?
<furkan> tjaalton: do you have a URL so i can follow any updates on it?
<furkan> tjaalton: i guess this is what you were referring to? https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1424980
<ubottu> Launchpad bug 1424980 in xorg-server (Ubuntu) "[ffe] xorg-server 1.17" [High,New]
<furkan> so fglrx is the culprit, again... AMD really needs to get with the program
#ubuntu-x 2015-03-07
<tjaalton> yes
#ubuntu-x 2016-03-08
<liketechnik> Is it save to install these drivers on my everyday system which I need for work?
<zao> Sounds a bit unwise.
<zao> Consider another OS installation maybe?
<liketechnik> ok
<liketechnik> would it be possible to test inside a virtual machine
<liketechnik> Or do I need real hardware?
<tjaalton> huh?
<zao> Interesting followup question, heh.
<zao> Nothing ill towards the project, but if you ask yourself "should I do <X> to mission critical machines", the answer should most likely be "probably not".
<tjaalton> what was "these drivers"?
<zao> tjaalton: Considering I'm here because of the Vulkan drivers from NV/Intel, probably those.
<zao> Guessing from your questions that there's probably more to this project than that PPA :)
<tjaalton> certainly
<ricotz> tjaalton, hi, do you have mesa 11.2 rc3 somewhere already?
<tjaalton> ricotz: in debian git
<tjaalton> I can't build the ubuntu version on my skylake, because of https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.8/+bug/1553174
<ubottu> Launchpad bug 1553174 in llvm-toolchain-3.8 (Ubuntu) "mesa llvmpipe tests fail on Skylake" [Undecided,New]
<tjaalton> though it would still be possible to push it to a ppa
<ricotz> tjaalton, I see, yeah push it to some ppa
<ricotz> e.g x-staging?
<tjaalton> that was the plan
<ricotz> great
<tjaalton> building
<tjaalton> failed
<tjaalton> botched merge
<tjaalton> new version building
<tjaalton> failed on powerpc
#ubuntu-x 2016-03-09
<furkan> so tjaalton i submitted that bug report last night
<furkan> and just a general question... today the status of the bug was changed to confirmed
<furkan> and it says that the change was made by a bot
<furkan> but it looks like it was made by an actual person (Brad Figg)
<furkan> how does that work?
<furkan> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1554371
<ubottu> Launchpad bug 1554371 in linux (Ubuntu) "[Regression] Volume keys not working after suspend/resume" [Undecided,Confirmed]
<furkan> seems like Brad has a linkedin profile, so somehow i doubt it's an elaborate ploy to make the bot seem like an actual person :)
<tjaalton> furkan: a script run by brad, business as usual
<furkan> so he didn't actually confirm my bug then, did he? i don't see how that could be done by a script?
<furkan> or does the script just scan the uploaded log files for some sort of errors?
<furkan> i'm just curious how this works
<tjaalton> every new kernel bug is handled like that
<furkan> oh i see
<marlinc> Test
#ubuntu-x 2016-03-10
<alkisg> Hi, I'm a developer of a software called epoptes.org. At some dialog I want to display to the user something like:
<alkisg> VGA card: i915 [15ad:0405]
<alkisg> I.e. the driver that manages the card, and its pci-id, if it exists (I think e.g. in raspberry pi it doesn't exist).
<alkisg> What's the best way to get that info via shell, even if xorg isn't running? Currently I'm using lspci, but it's not doing a very good job...
<alkisg> I was thinking of checking something under /sys
<alkisg> /sys/devices/pci0000:00/0000:00:0f.0# cat uevent 
<alkisg> DRIVER=vmwgfx
<alkisg> PCI_CLASS=30000
<alkisg> PCI_ID=15AD:0405
<alkisg> That would be fine for my needs, but I'm not sure which /sys path to check there, it's too different in various systems that I check
<alkisg> Would `find /sys/ -name boot_vga` show me the path I'm interested in?
<tjaalton> probably not the best place to ask :)
<tjaalton> but that might be a start
<alkisg> Thank you tjaalton, I'll test that in 20-30 systems and see if it's solid enough
<tjaalton> and then you get a hybrid
<tjaalton> where it doesn't necessarily show what you mean
<alkisg> I don't mind if it shows the wrong vga in multi-vga systems
<tjaalton> k
 * alkisg tries: cat $(find /sys/devices -name boot_vga -printf %h)/uevent
<alkisg> One problem only so far, under virtualbox, uevent doesn't have a DRIVER= line.... while `lspci -nn -k | grep -A 2 VGA` does show "Kernel modules: vboxvideo".
<alkisg> In all the other 20 systems, no problems whatsoever :)
<alkisg> I'm testing with an ancient trident card under 16.04. I don't get a DRIVER= line in the uevent file and Xorg.7.log tells me that it couldn't load the "trident" module.
<alkisg> Then I run "modprobe tridentfb" and I do get a DRIVER line etc.
<alkisg> Questions...
<alkisg> 1) Does that mean that no drivers were managing the card until I ran modprobe tridentfb?
<alkisg> 2) Should I expect the card to work better after modprobe tridentfb?
<alkisg> 3) Should I put that modprobe tridentfb somewhere in e.g. /etc/modules so that it's automatically loaded on boot?
<tjaalton> trident doesn't have a kms driver, not sure tridentfb makes anything better
<alkisg> So which module makes that card work by default, is it modesetting_drv?
<alkisg> fbdev?
<alkisg> vesa?
<alkisg> ...all of the above? :D
<tjaalton> vesa
<tjaalton> check the xorg log
<alkisg> It reports all those 3
<tjaalton> modesetting only loads on drivers that do kms
<tjaalton> look closer
<alkisg> looking... :)
<tjaalton> if you have tridentfb loaded the it's probably fbdev on x
<alkisg> http://paste.debian.net/413858/
<alkisg> I'm still not sure... in this log, I haven't loaded tridentfb
<tjaalton> vesa
<alkisg> And I see all of the 3 above
<tjaalton> and modesetting & fbdev are unloaded
<tjaalton> so vesa remains
<alkisg> So it tries the modules in turn, and keeps one of them...
<alkisg> Thank you very much tjaalton, that cleared some things for me 
<alkisg> x11perf -putimagexy500 results: 54 rep/sec on tridentfb, 6 rep/sec on vesa
<alkisg> On such slow PCs it does make the difference of "usable vs unusable"
<alkisg> ...unfortunately metacity can't start under tridentfb, so... unusable :D
<alkisg> Same for s3fb, it's 10 times faster than vesa, but crashes metacity
<tjaalton> why don't you have x-x-v-trident installed?
<alkisg> Thanks for the hint, I thought all of the x-x-v* were installed by default but apparently they aren't, installing...
<tjaalton> only for kms-capable hw, plus fallback drivers
<alkisg> That epoptes dialog where we're showing the client info is a very nice place to notify sysadmins about obsolete hardware or missing drivers etc
<alkisg> I'll see to it that we make it very visible when a driver is missing
<tjaalton> all hw without a kms driver is obsolete :)
<alkisg> Do I need to have xserver-xorg-legacy installed to run with non-kms drivers?
<tjaalton> yes
<alkisg> ty, installing... (maybe those legacy drivers should depend on it?)
<tjaalton> maybe
<alkisg> Meh, the big difference in putimage was due to "modprobe tridentfb" making xorg start with 8bpp as the default, not 24bpp...
<alkisg> After forcing 24bpp, the putimage results are similar with or without tridentfb (and metacity etc are much more stable)
<alkisg> It does sound lame to have 0.7 putimages / second in e.g. tnt vanda though, the card's bandwidth should be hundreds of times faster than that...
<alkisg> trident: 8bpp => 50 putimage/sec, 16bpp => 20 putimage/sec, 24 bpp => 6 putimage/sec
<alkisg> With 16bpp it's not crashing and it's fast enough to be usable
<ricotz> tjaalton, hi, I wondering why intel-gpu-tools is not maintained by xorg team
<tjaalton> ricotz: what do you mean?
<ricotz> this package https://packages.qa.debian.org/i/intel-gpu-tools.html
<tjaalton> Maintainer: Debian X Strike Force <debian-x@lists.debian.org>
<tjaalton> hmm maybe mine is old
<ricotz> oh, I misread that then
<ricotz> there is 1.14 release
<tjaalton> let's update it then
<ricotz> tjaalton, might require python-docutils and libxv-dev
<tjaalton> new build-deps?
<ricotz> tjaalton, yes, but I am looking at git master
<tjaalton> configure at least passed fine
<tjaalton> and built too
<ricotz> rst2man
<ricotz> in a clean chroot? ;)
<tjaalton> yes
<tjaalton> sbuild
<ricotz> the manpages are not built without rst2man
<tjaalton> -rw-r--r-- root/root       641 2016-03-10 21:30 ./usr/share/man/man1/intel_aubdump.1.gz
<tjaalton> bollocks :)
<ricotz> hmm, https://launchpadlibrarian.net/247417011/buildlog_ubuntu-xenial-amd64.intel-gpu-tools_1.14+git20160310.3e2443f8-0ubuntu1~16.04~ricotz0_BUILDING.txt.gz
<ricotz> checking for rst2man... no
<ricotz> checking for OVERLAY_XVLIB... no
<tjaalton> those are not new things
<ricotz> I warned you though ;)
<tjaalton> there is no rst2man
<tjaalton> btw
<ricotz> python-docutils: /usr/share/docutils/scripts/python2/rst2man
<tjaalton> oh sorry
<tjaalton> riiht
<tjaalton> +g
<tjaalton> intel-gpu-overlay isn't installed, needs manual handling
<tjaalton> and it's only built on x86
<ricotz> only on x86?
<ricotz> intel-gpu-tools: /usr/bin/intel-gpu-overlay on x86_64
<ricotz> (maybe a fixed buildsys problem)
<tjaalton> hmm
<tjaalton> 1.14 checks the arch before checking for xvlib
<ricotz> https://launchpadlibrarian.net/247418929/buildlog_ubuntu-xenial-amd64.intel-gpu-tools_1.14+git20160310.3e2443f8-0ubuntu1~16.04~ricotz1_BUILDING.txt.gz
<tjaalton> x86 archs so _64 too
<tjaalton> anyway, since it actually is installed that means I don't need to adjust anything
<tjaalton> and it already was built just without xvlbi
<tjaalton> -lib
<tjaalton> bah
<furkan> tjaalton: did you notice that some fonts look sort of bold/fuzzy after upgrading to Xorg 1.18?
<furkan> https://www.dropbox.com/s/mbl5z6y4zqtplpe/fuzzyfont1.png?dl=0
<furkan> i just upgraded and restarted my PC
<furkan> the font on the buttons is messed up
<furkan> and "60 Hz", and "Aperture Priority Mode"
<furkan> for the dropdown menus, i wonder if it's because the 2 strings are being rendered on top of each other
<tjaalton> probably freetype update breaking it
<furkan> because when i click on the dropdown
<furkan> and the choices appear, the fonts look normal
<furkan> seems to happen with dropdowns and buttons
<furkan> same thing w/ calculator
<tjaalton> on intel hw?
<furkan> radeon
<tjaalton> k
<tjaalton> file a bug
<tjaalton> actually no
<tjaalton> this is freetype
<furkan> do you see the same thing in calculator?
<furkan> if you switch to scientific mode you get the dropdown menus for degrees/radians
<furkan> when you click the dropdown and the choices appear, the fonts are normal
<furkan> but after you select one, it goes fuzzy
<tjaalton> file a bug against freetype
<furkan> alright
<tjaalton> unless there is already
<tjaalton> i use a custom build to revert a change
<furkan> xorg 1.18 just hit yesterday
<furkan> so it might not have been noticed by many people yet
<tjaalton> it's not caused by it
<furkan> i mean the bug itself could be in freetype, but it must have been triggered by the xorg update because that's what i just updated
<furkan> ok actually i had an update to freetype as well
<tjaalton> try reverting that
<tjaalton> sounds like you haven't updated in quite a while then
<tjaalton> https://lists.ubuntu.com/archives/xenial-changes/2016-February/007209.html
<furkan> yeah actually i was using a mirror that was out of date
<furkan> i had picked a mirror that was nearby
<furkan> then realized today that i wasn't getting the xorg update so i switched to a different one
<furkan> ok reverted back to libfreetype6_2.5.2
<furkan> will see what happens
<furkan> ok yeah, still the same problem
<furkan> actually in january or february i had added the x-staging ppa to try out xorg 1.18, and i had noticed this then as well
<furkan> i dunno if there are any other packages that got pulled down from that ppa
<furkan> packages which could have contributed
<tjaalton> test a daily live that's old enough
<furkan> like a daily live CD?
<tjaalton> yes
<furkan> is there an archive of those?
<tjaalton> http://cdimages.ubuntu.com/daily-live/
<tjaalton> 20160307 should be old enough
<furkan> oh great, yeah it should be
<furkan> ok it works fine with 20160307
<furkan> i guess after 2 years, it's time for a clean installation
<furkan> i've been upgrading releases since 14.04, there must be dirty config files that have been left over along the way or something
<furkan> after that last dist-upgrade, my volume buttons don't work at all, even after a fresh boot
<furkan> but they worked with the live CD
<furkan> i guess this time i'll stick with 16.04 for as long as i can
<furkan> tjaalton: i just realized i totally confused myself - the whole point of trying the older image was to verify the absence of the bug
<furkan> does the 20160310 build contain xorg 1.18?
<furkan> ok yeah it does (just checked the manifest)
<furkan> i'll try that out to make sure that it's not a problem with my configuration
#ubuntu-x 2016-03-11
<furkan> tjaalton: i just tested out the 20160310 live image, and the bug is reproducible
<furkan> looking at the diff between the manifests, i don't see any possible culprit other than xorg?
<furkan> tjaalton: looks like this is probably the issue, and there is a fix released in xserver git https://bugs.freedesktop.org/show_bug.cgi?id=94246
<ubottu> Freedesktop bug 94246 in Driver/glamor "Text shadow is rendered incorrectly on Radeon R7 260X" [Normal,Resolved: fixed]
<furkan> glamor bug
<furkan> if this is it, that should really be backported into a point release
<furkan> these are the 2 patches:
<furkan> https://cgit.freedesktop.org/xorg/xserver/commit/?id=b05ae79ee3bebef9790c97eedc033d1ffb3ec39a
<furkan> https://cgit.freedesktop.org/xorg/xserver/commit/?id=a3e681eafa5355b8bb3b099d47983f14f0d5e197
<furkan> i'll test them
<furkan> actually it looks like it might depend on some previous patches as well
<tjaalton> furkan: oh right, forgot glamor..
<tjaalton> furkan: mind filing a bug?
<furkan> tjaalton: sure, will do
<furkan> but i haven't tested the patch
<furkan> did an apt-get source and was manually merging those two patches but noticed some other discrepancies in the code
<furkan> wasn't really in the mood of breaking anything tonight
<furkan> so based on that, it seems there have been other patches to the same functions in question, so it may require a bit of fiddling to backport
<tjaalton> sure
<alkisg> nouveau@riva-tnt2: x11perf -putimagexy500 -eschertilerect500 -repeat 1
<alkisg> 2000 reps @   4.4646 msec (   224.0/sec): 500x500 tiled rectangle (216x208 tile)
<alkisg> 4 reps @ 8389.1916 msec (     0.1/sec): PutImage XY 500x500 square
<alkisg> ==> how is it possible for a single putimage to need 20 seconds?!
<tjaalton> don't ask me
<tjaalton> where do you get this crap hw?
<furkan> probably from an archaeological dig :D
<alkisg> Greece, that's all we have here :D
<tjaalton> sorry to hear that
<alkisg> For some reason normal operations like menus animations, scrolling windows, watching youtube etc is extremely slow on all the old graphics cards that I've tried
<alkisg> With e.g. windows 2000, it isn't so; it's something specific to the linux implementation
<alkisg> I don't know if it'd be worth it to try and troubleshoot it, to find which code paths are so slow etc...
<alkisg> Difference like from e.g. 1 fps on linux, to 30 fps on windows
<alkisg> Tested in 10 cards or so, so I don't think it's just driver-specific
<furkan> have you tried the proprietary driver (if it's still supported)?
<tjaalton> it's not
<alkisg> Not recently (it would need 8.04), but I did try intel hardware as well
<tjaalton> oh
<tjaalton> nvidia
<furkan> wait what, windows 2000?
<furkan> what kind of CPU do you have?
<alkisg> We're the IT support center of 300+ schools, we have a lot of CPUs available for testing,
<furkan> because i occasionally use windows 7 and 10, and i find that window operations in linux are much more CPU intensive
<furkan> like moving around a window can cause CPU usage to spike to 30-40%, resizing a window can cause 90%+ CPU usage
<alkisg> so currently I'm testing with the windows-2000 -era hardware that they have, we're using them as linux thin clients
<furkan> whereas with windows 7+, CPU usage is negligible
<alkisg> Right, that's what I notice too
<furkan> i think Xorg is just really inefficient
<alkisg> But why? Too many buffers being copied around?
<furkan> i don't know but i think that's part of what Wayland will fix
<furkan> and Mir, on the Ubuntu side
<alkisg> I really can't see why a putimage would need 20 seconds, last I tried implementing that in assembly back in 1995 we could easily do 60 fps...
<furkan> i think there is a build of Ubuntu 16.04 available with Unity 8, maybe you can try it if it's compatible with your hardware
<furkan> Unity 8 uses Mir
<tjaalton> no it won't be
<furkan> but it's a big work-in-progress right now
<furkan> oh, my mistake then
<alkisg> Would e.g. wayland or mir be compatible with intel 855?
<tjaalton> at least I don't think nouveau has any support for ancient hw
<tjaalton> alkisg: no idea
<alkisg> ...or nouveau + geforce 400mx, stuff like that
<tjaalton> i don't know if it needs more than just kms support
<tjaalton> first thing to check is if nouveau is used
<tjaalton> the kernel module
<alkisg> In e.g. 16.04 and geforce 400mx, it is... I'll download a wayland or mir cd to test with...
<tjaalton> with current debian sid on intel skylake & wayland, for instance resizing the terminal is abysmally slow
<tjaalton> it's like 2fps
<alkisg> Meh :)
<alkisg> Another idea could be vnc@directfb to reuse those old clients... maybe it would be faster...
<furkan> alkisg: i wonder if you guys would just be better off buying raspberry pis
<furkan> raspberry pi 3 might be more powerful than your hardware, and consumes much less power
<furkan> not sure how expensive electricity is over there, and how much it would offset the cost
<alkisg> School eletric bills are paid centrally, so they don't care about that
<alkisg> When we do have 100â¬ per client, we're upgrading P4's with something like ASROCK QC5000M motherboard + 4 GB RAM
<alkisg> (all in one, 1900 passmark score for its kabini cpu)
<alkisg> It's like 100 times faster than raspberry pi 3
<furkan> ok i see, yeah kabini and 4GB RAM is better than rpi for sure
<furkan> do you use ubuntu with the kabini boxes?
<alkisg> so far we've been using equivalent intel-based boards (with IDE connectors), but they're not available anymore, so we ordered our first kabini one some days ago, it hasn't arrived yet
<alkisg> We'll start testing it in a week or so
<furkan> oh ok, i have a kabini box running ubuntu and it works really nicely
<alkisg> Some teacher reported that his recent amd board didn't work with 64bit ubuntu after 14.10, and he needed 32bit instead
<alkisg> (usb + lan didn't work at all on the live CDs etc)
<furkan> that could be for any number of reasons... i remember i had an issue with an intel machine where the onboard Realtek LAN wasn't working properly, and it's because for some reason the wrong kernel module was being loaded
<furkan> i built the driver from source and it worked fine after that
<alkisg> Haha ok s3virge wins, 4 reps @ 15587.4967 msec (     0.1/sec): PutImage XY 500x500 square
<alkisg> That's like one putimage per hour :D
 * alkisg is trying to find some ancient graphics card that goes faster in debian wheezy (before xaa was killed) compared to ubuntu xenial... and can't find any!!!
<tjaalton> furkan: it wasn't too hard to backport the font fixes afterall
<tjaalton> seems to work
<furkan> oh, nice :)
<furkan> did you still want me to file that bug report? i was still going to do it a bit later
<tjaalton> please
<furkan> tjaalton: done https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1555960
<ubottu> Launchpad bug 1555960 in xorg (Ubuntu) "Some text (in buttons, dropdown menus) renders incorrectly" [Undecided,New]
<furkan> i could have sworn that somewhere on that page there was an option to indicate that an upstream fix has been committed
<furkan> but i can't find it
<tjaalton> thx
<furkan> np
<furkan> glamor performance is really coming along nicely, it's been getting faster with every xorg release
<tjaalton> i was meant to let skylake fall back to modesetting+glamor but other bugs prevent that
<furkan> i'm looking forward to 1.19, it looks like eric put in some pretty nice improvements while doing his work on the raspberry pi driver
<tjaalton> uploaded
<furkan> to x-staging?
<tjaalton> no
<tjaalton> xenial
<tjaalton> the bugfix i mean
<furkan> hmm maybe it hasn't propagated to my mirror yet
<tjaalton> lucky if it has even built yet..
<tjaalton> it'll take a day to hit your mirror
<furkan> oh haha
<furkan> btw remember when you said i must have not updated for a quite a while
<furkan> the mirror i was using hasn't been updated since mid-february
<tjaalton> same thing with fi.a.u.c
<furkan> and i think that might be the most popular mirror around here
<furkan> (hosted at a university nearby)
<furkan> come to think of it, i think that might be the mirror being used in our lab, so we might not have been getting security updates for the past month :o
 * furkan ssh's in
<tjaalton> I hope you use security.u.c
<tjaalton> as everyone should
<furkan> what's that?
<tjaalton> security.ubuntu.com
<tjaalton> see sources.list
<furkan> oh ok
<furkan> checking now, we use an apt-cacher
<furkan> looks like we use the generic ca.archive.ubuntu.com mirror
<furkan> are you suggesting that i add a separate line for security.ubuntu.com?
<tjaalton> no
<tjaalton> should have already
<tjaalton> even if you use a mirror the default sources.list uses security.u.c for security updates
<tjaalton> unless you've fumbled that
<furkan> i'm gonna pastebin this to make sure, i'm not the one who set up this particular server
<tjaalton> i'm talking about the client
<tjaalton> i don't care what you mirror :)
<furkan> oh this server is acting as the apt-cacher for all the computers in the lab
<tjaalton> k
<furkan> http://pastebin.com/M9QwcPJV
<furkan> i don't see "security" anywhere in here
<furkan> well there is trusty-security, but points to ca.archive.u.c
<tjaalton> i don't know how apt cacher works
<furkan> that's just the sources.list file
<furkan> apt-cacher just sets up an HTTP server and serves the cached packages
<tjaalton> then you can hit issues like mentioned
<furkan> ok i see, i'm looking at my sources.list at home and i see the difference
<furkan> deb http://security.ubuntu.com/ubuntu/ xenial-security multiverse main universe restricted
<furkan> i will modify the server, thanks for the heads up
<furkan> basically all the clients have their source.list set up to point to the apt-cacher
<furkan> and the apt-cacher uses its own sources.list to retrieve/cache the packages and serve them to the others
<tjaalton> ok
<tjaalton> I just host a local mirror
<tjaalton> of debian & ubuntu
#ubuntu-x 2016-03-12
<furkan> tjaalton: did you see this? https://lists.x.org/archives/xorg-announce/2016-March/002681.html
<furkan> Looks like those glamor fixes have been merged into 1.18.2
<furkan> also "glamor is updated to use OpenGL core profiles if available, which should improve memory usage and performance on modern hardware"
<mamarley> Will 1.18.2 go in Xenial?
<tjaalton> furkan: knew that it was going to be released yes
<tjaalton> I'll upload it to staging
<tjaalton> and sid of course
<furkan> tjaalton: i just installed it
<furkan> very nice CPU usage improvement, with my "ritual" test that i do after every xorg update
<furkan> which is to open up top in a terminal
<furkan> and then open up a nautilus window and drag it around the screen like a madman
<furkan> 1.18.1, i was getting about 33%, 23%, and 15% between Xorg, compiz, and nautilus
<furkan> after installing 1.18.2 and rebooting, now it's down to around 25/15/5
<furkan> still pretty bad compared to windows, but good progress
<furkan> i imagine it'll continue to get better if eric wants to get X to run smoothly on the rpi, with that kind of hardware he'll need all the CPU optimizations he can get
<furkan> tjaalton: interesting bug though, i have a stray cursor just sitting there on my secondary display (which is rotated)
<tjaalton> furkan: file it, i'm not here atm
<furkan> will do after some more experimentation
<furkan> well i restarted lightdm and now it's gone, so i guess it might not be easy to reproduce
<furkan> also noticed another bug where some grey text in firefox is rendered in red... back to normal after downgrading to 1.18.1
<furkan> would help to be able to do a bisect, if that's possible
#ubuntu-x 2016-03-13
<furkan> tjaalton: when you're around, can you let me know how i should file a bug for x-staging?
<furkan> and btw i asked in #radeon if anybody else noticed the red text issue
<furkan> 17:15	<airlied>	furkan: sounds like a possible bug with the core profile support
<furkan> i've never had any luck building xorg myself though... i've always had issues with dependencies and some multiarch stuff, but if you have any tips that will make it easy i could rebuild and test without the core profile support
<TheK__> Is there a reasonably safe way to test the new vulkan drivers on 14.04 ?
<TheK__> I'm looking at https://launchpad.net/~canonical-x/+archive/ubuntu/vulkan
<TheK__> but it states "maybe in the future". 
#ubuntu-x 2017-03-06
<mamarley> ricotz: A user sent me an email stating that he can't install the nvidia-304 package on Xenial because the application of "buildfix_kernel_4.3.patch" fails.  Since you uploaded that I thought I would let you know.
<tseliot> mamarley: is that different from my patch
<tseliot> ?
<mamarley> Not sure, I wasn't involved with uploading that one.
<tseliot> ok
#ubuntu-x 2017-03-09
<tjaalton> xserver 1.19.2 and mesa 17.0.1 in ppa:canonical-x/x-staging, migration to zesty next week
<mamarley> tjaalton: Does that include glvnd?  (And does it work with the NVIDIA driver?)
<tjaalton> no
<tjaalton> not going to happen in 17.04
<mamarley> OK
#ubuntu-x 2017-03-10
<alkisg> With this device, 00:02.0 VGA compatible controller [0300]: Intel Corporation Sky Lake Integrated Graphics [8086:1912] (rev 06) 	DeviceName:  Onboard IGD 	Subsystem: ASUSTeK Computer Inc. Skylake Integrated Graphics [1043:8694]
<alkisg> ...after updating to xserver-xorg-hwe-16.04, I got a virtual second monitor that doesn't exist, and I have to turn it off manually...
<alkisg> xrandr --output eDP-1 --off 
<alkisg> I saw this on another user as well
<alkisg> Where would I report it? xserver-xorg-video-intel?
<alkisg> (otherwise, the non-existing eDP-1 gets to be my default monitor, where the panel is, and I only get a wallpaper in my real monitor)
<tjaalton> kernel
<alkisg> tjaalton: ugh, thank you :)
<tjaalton> just install the edge kernel to see if it's affected
<alkisg> Thanks, will do
<alkisg> quick solution => sudo dpkg-reconfigure grub-pc => video=eDP-1:d
<michael-vb> Hello, I filed https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/1671377 to get a libdrm git commit applied to the Zesty libdrm2 package.  It fixes a crash which affects me.  Would be great if someone could say something to that.
<ubottu> Launchpad bug 1671377 in libdrm (Ubuntu) "Crash in VirtualBox with libdrm/intel, fixed in git" [Undecided,New]
<tjaalton> I'd prefer a new upstream release, there's still plenty of time
<michael-vb> Shame, it would make my life simpler not to have to work with a self-patched version.  But of course, it is your call.
<michael-vb> I suppose you would have noticed if other people were filing bugs about strange crashes in libdrm, so I can only assume that not many people are affected.
<tjaalton> right, haven't
<michael-vb> Ah well.  Six weeks since the last libdrm release, and recent release intervals of a few weeks each.  Except 2.4.71.  But still some hope.
<tjaalton> i'll have a look next week
<michael-vb> Thanks.
<michael-vb> Right, already Friday afternoon...
<furkan> tjaalton: do you plan on making the xorg 1.19.2 builds available for xenial as well, in x-staging? i wouldn't mind testing it out
<tjaalton> furkan: no, you'll get them eventually via -hwe-16.04
#ubuntu-x 2018-03-05
<RAOF> tjaalton: Hey, can I upload a libglvnd fix so that Mir doesn't crash?
<tjaalton> RAOF: sure, go ahead
<RAOF> tjaalton: -2ubuntu2 uploaded and in salsa. That patch would be correct to add to Debian, too, but is less important there.
<RAOF> Any thoughts?
<tjaalton> RAOF: send upstream :)
<tjaalton> a pull req on github
<tjaalton> and thanks
<RAOF> tjaalton: the patch is cherry-picked from my upstream PR ð
<tjaalton> ah, good :)
<tjaalton> I'll poke kyle to make a new release before bionic is out
<tjaalton> well, soon
<gp> I am using Ubuntu 16.04 and amd RX580. The drivers installed with the latest installer do not let me adjust my monitor options. Can anyone help me out? I am not sure where to start
<gp> http://termbin.com/y3hb
<gp> Well finally got the right name for the amd driver but now I'm stumped
<gp> [    16.715] (II) Module amdgpu: vendor="X.Org Foundation"
<gp> [    16.715] 	compiled for 1.19.3, module version = 1.3.99
<gp> [    16.715] 	Module class: X.Org Video Driver
<gp> [    16.715] 	ABI class: X.Org Video Driver, version 23.0
<gp> [    16.715] (EE) module ABI major version (23) doesn't match the server's version (20)
<gp> [    16.715] (II) UnloadModule: "amdgpu"
<gp> [    16.715] (II) Unloading amdgpu
<gp> [    16.715] (EE) Failed to load module "amdgpu" (module requirement mismatch, 0)
<gp> http://termbin.com/aoa8
<tjaalton> you need to install xserver-xorg-core-hwe-16.04
<gp> tjaalton: <3
<tjaalton> to upgrade the hwe stack, see https://wiki.ubuntu.com/Kernel/LTSEnablementStack
<tjaalton> amdgpu-pro doesn't support the stock pkgs anymore
<gp> Man, complicated.  Thanks for the direction... hopefully get it going now
<tjaalton> it's what you'd get when installing with a 16.0.4.{2,3,4} image
<gp> I installed from 16.0.4.4 but server cd. So that's my problem
<tjaalton> right
<gp> Mod probe should pick up the pro driver automatically now right?
<gp> It was just a version mismatch causing it to unload
<tjaalton> guess so
<tjaalton> that mismatch is from the x driver, not kernel
<gp> waiting on the image to rebuild... i was almost out of hair to pull =P
<gp> tjaalton: you're the best. turns out with the hwe stack i don't need the amd proprietary drivers either =)
<tjaalton> cool
#ubuntu-x 2018-03-06
<RAOF> tjaalton: Good news, everyone!
<tjaalton> libglvnd commit merged?-)
<RAOF> tjaalton: Kindly drop the Mir EGL platform patch to mesa at your leisure.
<tjaalton> oh!
<tjaalton> nice
<tjaalton> I'll do that once the next rc/release arrives
<tjaalton> which is long overdue
<RAOF> tjaalton: Also that. But that glvnd commit actually just means that EGL won't crash when trying to use Mir clients; it doesn't make Mir clients *work* :)
<tjaalton> ha, ok
<tjaalton> RAOF: btw, do you mean all the patches, or just egl-platform-mir.patch?
<RAOF> tjaalton: All the patches, yes. egl-platform-mir, egl-platform-rs, khr_platform_mir.
<tjaalton> ok cool
<tjaalton> hmm after bionic we're able to sync mesa, who'd have thought :P
<tjaalton> not that it actually gives anything, and "loses" history
<RAOF> tseliot: Is nvidia/intel hybrid expected to work in Bionic now (or soon?). There's no obvious way to power down the nvidia card.
<tseliot> RAOF: I am working on it right now. I am going to drop bbswitch in favour of nouveau + vgaswitcheroo. It works here, but it needs a little work
<tseliot> so, soon ;)
<RAOF> Cooll, cool.
<RAOF> Will that also work with the binary driver? I quite like full performance ;)
<tseliot> RAOF: so, you will be using nvidia+intel by default, then you can type in "sudo prime-select intel", reboot, and you'll only have intel. Then "sudo prime-select nvidia", reboot, and nvidia will be back
<RAOF> Rad.
<RAOF> I mean, it'd be nicer without the reboot, but just working fully again will do for now ð
<tseliot> RAOF: this is how it works: when you run "sudo prime-select intel", that will blacklist nvidia, then a systemd service will load nouveau if nvidia is not loaded, then nouveau makes it possible to use vgaswitcheroo, and a systemd service (or a udev rule) will switch off the iGPU
<tseliot> RAOF: I'm really working around a bug in systemd: https://github.com/Witko/nvidia-xrun/issues/32
<tseliot> plus GDM has no way to run scripts when you log out
<RAOF> Ah, yeah. That's not fixed?
<tseliot> not really
<RAOF> Do you even need the vgaswitcheroo bit? As far as I can tell the nvidia driver appears to power down the card when it is unloaded.
<RAOF> I guess if you've got a mux?
<tseliot> RAOF: even then, I can't unload nvidia because of logind
<tseliot> and no, no mux here
<RAOF> Right.
<RAOF> Huh. logind doesn't appear to be holding nvidia open here.
<RAOF> But Xorg is, and so is budgie-wm.
<RAOF> Although I'm using lightdm.
#ubuntu-x 2018-03-07
<tjaalton> tseliot: i've assigned you on some nvidia file conflict bugs
<tseliot> tjaalton: ok, thanks
<tseliot> tjaalton: they are not using my driver in LP: #1753796
<ubottu> Launchpad bug 1753796 in nvidia-graphics-drivers-390 (Ubuntu) "Conflict between libglx-mesa and nvidia-390 on Ubuntu 18.04 (pre-release)" [Undecided,New] https://launchpad.net/bugs/1753796
<tjaalton> ha
<tjaalton> that was easy then :)
<tseliot> yep
<tseliot> the fact that I can't use an i386 chroot for testing is very annoying though
<tjaalton> no need to, because of multiarch
<tjaalton> no need for i386 chroot I mean
<tseliot> yes, but still, the best way to test i386 is on i386
<tjaalton> ricotz: uploaded capnproto with M-A fix, since I just hit that issue myself :P
<ricotz> tjaalton, thanks
<ricotz> tjaalton, am I correct that mir support in mesa is going away?
<tjaalton> yes
<ricotz> ok
<tjaalton> but I'll wait for next mesa rc before uploading that
<tjaalton> tseliot: the file conflict with nvidia-340 is only seen on multiarch I think, and reproduceable on a chroot
<tjaalton> amd64 version provides also 32bit libs but doesn't divert them?
<tseliot> tjaalton: yes, I'm working on that, and on other fixes
<tjaalton> ok, great
<ricotz> tseliot, hi, why don't you apply the same packaging layout of 390 to 340?
<tseliot> ricotz: because 340 doesn't support glvnd
<tseliot> and I haven't worked on a non-glvnd solution for the new packaging yet
<tseliot> (which I am going to need for 16.04 anyway)
<ricotz> tseliot, ok, but this shouldn't prevent you to split up the package the same way
<tseliot> it won't
<tseliot> I'm just very busy, trying to get hybrid graphics sorted out
<ricotz> also multiarch would work
<ricotz> I see
<tseliot> tjaalton: the new release should fix that
#ubuntu-x 2019-03-04
<tjaalton> tseliot: what's the eta for getting 418 in disco?
<tseliot> tjaalton: I'll have it in a PPA this week. As for the archive, probably next week
<tjaalton> ok, cool
<tjaalton> someone was asking me about it
#ubuntu-x 2020-03-02
<ricotz> tseliot, hi, are you aware of https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-440/440.59-0ubuntu0.19.10.1
<tseliot> ricotz, no, I hadn't seen that. thanks
<ricotz> yw
<ricotz> tseliot, I assume you are onto 440.64 already?
<tseliot> ricotz, I will upload it in Focal first
<ricotz> ok
<ricotz> tseliot, https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-440/440.59-0ubuntu0.19.10.2/+build/18788030
#ubuntu-x 2020-03-03
<tseliot> ricotz, it succeeded. not sure why it took so long
<ricotz> tseliot, I asked for a re-try a few moments ago
<tseliot> ricotz, I wonder what happened
<ricotz> I assume some launchpad issue
<tseliot> ricotz, thanks for restarting the build
