#ubuntu-x 2006-08-31
* Starting logfile irclogs/ubuntu-x.log
<rodarvus> Mithrandir, I'd like to prepare an email today (I've started doing this, already)
<rodarvus> and send to you, distro-team@ on the end of the day
<rodarvus> giving the current status of X on edgy, what needs to be fixed, and some ideas for edgy+1, X work is not so ad-hoc on next release cycle
<rodarvus> s/Xwr
<rodarvus> s/X work/so X work/
<Mithrandir> rodarvus: we'll have to have somebody who actually fixes X bugs until release.
<Mithrandir> I don't know the server or driver for shit, but I know a bit about the libs and xkb and the apps.
<rodarvus> I think we can split, then
<rodarvus> server and drivers are the part I know best
<Mithrandir> I'd be ok with that at least.  We need to get it ack-ed by mdz, but I can't really see that being a problem.
<rodarvus> (and which I enjoy most working with, to be sincere)
<rodarvus> *nods*
<Mithrandir> the server and drivers scare me. :-)  Apps and libs are almost cozy.
#ubuntu-x 2006-09-01
<Ubugtu> New bug: #58446 in imake "imake crashed somewhere" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58446
<Ubugtu> New bug: #58448 in xorg "Display blanking/freezing using PCI/AGP ATI 9250" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58448
<Ubugtu> New bug: #58452 in xorg "[EDGY]  (EE) module ABI major version (0) doesn't match the server's version (1)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58452
<Ubugtu> New bug: #58425 in xserver-xorg-driver-i810 (main) "consistent crash on logout, restart or shutdown from X" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58425
<crimsun> makedepend (src + binary) should be removed for edgy
<crimsun> (executable now provided in xutils-dev)
<Ubugtu> New bug: #58505 in xorg (main) "upgrade from dapper misses xorg dependencies" [Wishlist,Needs info]  http://launchpad.net/bugs/58505
#ubuntu-x 2006-09-02
<Ubugtu> New bug: #58541 in xserver-xorg-driver-ati (main) "libGL warning: 3D driver claims to not support visual 0x4b" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58541
<Ubugtu> New bug: #58600 in xorg "wacom configuration kills gok" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58600
<Ubugtu> New bug: #58619 in xorg-server "Xv does not work well with compiz" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58619
<Ubugtu> New bug: #58622 in xorg-server "compiz:  firefox autoscrolling cursor leaves trailing marks" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58622
<Ubugtu> New bug: #58621 in xkeyboard-config (main) "Italian Keyboard layout broken" [Untriaged,Needs info]  http://launchpad.net/bugs/58621
<Ubugtu> New bug: #58645 in xorg "Misdetection of Logitech Mouse M-BA47 as ExplorerPS/2" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58645
#ubuntu-x 2006-09-03
<Ubugtu> New bug: #58689 in xterm "keymap not (completely) honored" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58689
<Ubugtu> New bug: #58691 in xorg "rgb.txt missing" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58691
<Ubugtu> New bug: #58700 in xorg "Xorg metapackage version is wrong in edgy" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58700
<Ubugtu> New bug: #58719 in xorg "White screen of death on ati radeon mobility 9000" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58719
<Ubugtu> New bug: #58721 in xorg "Matrox MGA200 doesn't work after upgrade from Dapper to Edgy" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58721
<Ubugtu> New bug: #58741 in linux-restricted-modules-2.6.17 "symbolic link libXvMCNVIDIA.so missing in package nvidia-glx" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58741
#ubuntu-x 2007-08-27
<ubotu> New bug: #134523 in linux-restricted-modules-2.6.22 (restricted) "Xorg crashes when running glxgears (dup-of: 130325)" [Undecided,New]  https://launchpad.net/bugs/134523
<ubotu> New bug: #38260 in linux-restricted-modules-2.6.15 (restricted) "random crashes with nvidia drivers using kubuntu" [Medium,New]  https://launchpad.net/bugs/38260
<ubotu> New bug: #23117 in linux-restricted-modules-2.6.15 (restricted) "errlor loading fglrx module" [Medium,Invalid]  https://launchpad.net/bugs/23117
<ubotu> New bug: #27610 in linux-restricted-modules-2.6.15 (restricted) "Breezy's fglrx driver freezes computer when enabled" [Medium,Fix released]  https://launchpad.net/bugs/27610
<ubotu> New bug: #33792 in linux-restricted-modules-2.6.15 (restricted) "fonts not rendered correctly with nvidia driver (amd64)" [Medium,Invalid]  https://launchpad.net/bugs/33792
<ubotu> New bug: #17550 in xkeyboard-config (main) "[xk-c]  new logitech layout" [Medium,Invalid]  https://launchpad.net/bugs/17550
<ubotu> New bug: #135062 in xserver-xorg-input-mouse (main) "mouse pointer moves cursor while typing" [Undecided,New]  https://launchpad.net/bugs/135062
<tormod> hi, will somebody package ati 6.7.192-1 today?
<tepsipakki> it's already in debian
<tepsipakki> all you need to do is to ease the xserver dependancy
<tepsipakki> my pbuilder box is out-of-order :/
<tepsipakki> so I'm unable to build it before tomorrow (since I had to stay home today)
<tormod> tepsipakki: thanks
<ubotu> New bug: #135077 in gnome-panel (main) "screen resolution has changed to 800x600 max." [Undecided,Incomplete]  https://launchpad.net/bugs/135077
<tormod> tepsipakki, if I use a gutsy pbuilder I don't get your newer xserver-xorg-dev. Is it important to build against the newer xserver version? I guess I'll wait till I get to my gutsy machine...
<tepsipakki> hmm, that should be in gutsy
<tepsipakki> but I don't think that's important anyway
<tormod> the ubuntu12  ? maybe I need to update my pbuilder.
<tepsipakki> 12ubuntu2 actually, there was an update already :)
<tepsipakki> but not by me
<tormod> yes I just had to update the pbuild base.tar.gz
<ubotu> New bug: #135080 in xorg (main) "Black screen on Inspiron 6400 Desktop Install" [Undecided,New]  https://launchpad.net/bugs/135080
<ubotu> New bug: #135093 in xserver-xorg-video-intel (main) "xserver-xorg-video-intel does not work with 845G" [Undecided,New]  https://launchpad.net/bugs/135093
<bryce> morning
<tepsipakki> hey bryce 
<ubotu> New bug: #134982 in xserver-xorg-input-synaptics (main) "Mouse pointer freezes after opening up a new gdm login" [Undecided,Confirmed]  https://launchpad.net/bugs/134982
<ubotu> New bug: #135107 in xorg (main) "Gutsy > Tribe 5 X.org fails to detect proper resolution" [Undecided,New]  https://launchpad.net/bugs/135107
<bryce> I started recording some of my thoughts regarding what should be done for solving bug 3731 - https://wiki.ubuntu.com/X/AutodetectMonitorFrequency
<ubotu> Launchpad bug 3731 in xorg "Xorg resolution falling back to 640x480 and/or 800x600 when h/v freqs incorrect" [Critical,Confirmed]  https://launchpad.net/bugs/3731
<tepsipakki> bryce: exactly
<tepsipakki> the current way of things is quite error-prone
#ubuntu-x 2007-08-28
<ubotu> New bug: #135181 in xserver-xorg-video-i810 (main) "[Gutsy]  Inspiron 510m needs 915resolution for 1400x1050 native resolution" [Undecided,New]  https://launchpad.net/bugs/135181
* Starting logfile irclogs/ubuntu-x.log
<ubotu> New bug: #135211 in xserver-xorg-video-amd (universe) "Laggy and sloppy cursor" [Undecided,New]  https://launchpad.net/bugs/135211
<ubotu> New bug: #135212 in xserver-xorg-video-amd (universe) "Blank or grey chars in font rendering" [Undecided,New]  https://launchpad.net/bugs/135212
<ubotu> New bug: #135218 in xorg-server (main) "segfaults in VESAPreInit, corrupt mode list" [Undecided,New]  https://launchpad.net/bugs/135218
<ubotu> New bug: #66982 in arts (main) "Sound server fatal error: cpu overload, aborting (dup-of: 68659)" [Undecided,Confirmed]  https://launchpad.net/bugs/66982
<ubotu> New bug: #70083 in arts (main) "aRTS uses 100% CPU and freezes whole computer on KDE startup (dup-of: 68659)" [Undecided,New]  https://launchpad.net/bugs/70083
<ubotu> New bug: #135273 in xorg-server (main) "gusty - xserver-xorg-core - wrong device permissions on /dev/dri/card0 (crw-rw----) instead of (crw-rw-rw-)" [Undecided,New]  https://launchpad.net/bugs/135273
<ubotu> New bug: #87028 in xorg (main) "Thinkpad X60s (also T60, R60): changing the screen brightness blanks screen" [Undecided,Fix released]  https://launchpad.net/bugs/87028
<bryce> tepsipakki: btw, if you have a new ati package but the computer's still down, I'd be happy to build it for you
<tepsipakki> sure, just grab the source from experimental and change xserver-xorg-core-dev build-dep
<tepsipakki> thanks :)
<bryce> ok, no other changes?
<tepsipakki> nope
<tepsipakki> rest was from upstream
<bryce> xserver-xorg-dev (>= 2:1.2.99.902) ?
<tepsipakki> that works
<tepsipakki> or just 2:1.3.0.0
<bryce> http://people.ubuntu.com/~bryce/Testing/ati/
<bryce> jcristau: should dpkg-reconfigure -phigh xserver-xorg ever return -i810 now?  Or should it be returning -intel?
<tepsipakki> bryce: depends what discover says
<bryce> see bug 135141
<ubotu> Launchpad bug 135141 in xorg "Gutsy: Intel should be preferred over 810" [Undecided,New]  https://launchpad.net/bugs/135141
<bryce> I'm unable to reproduce it on my intel laptop, but am upgrading it to latest and will re-check
<tepsipakki> discover-data still maps some pci-id's to i810
<bryce> should we just collect their pciid and add it to discover-data?
<tepsipakki> the id is there (if he gets i810), it just needs to be changed to intel
<tepsipakki> maybe evaluate if i810 could be dropped altogether
<bryce> I've heard there is hardware that still needs i810, but I don't know for certain what they are
<tepsipakki> some video issues with older ones IIRC, but that could've changed since
<bryce> do you think we should just switch them all over, and then deal with whatever breaks after that?
<tepsipakki> I think kyle has best knowledge what's issues there are, if any :)
<bryce> ah true
<bryce> alright, I'll ask this guy for his lspci and talk to kyle about it later
<tepsipakki> btw, I've looked at what fedora has done to their composite hacks. There's EXA-backports, and support for zero-copy tfp etc
<tepsipakki> hopefully tomorrow I'll have a box at work for testing that
<bryce> cool
<bryce> today I think I'll start going through that backports list I made and do more flagging
<bryce> lunch.  bbiab
#ubuntu-x 2007-08-29
<ubotu> New bug: #125396 in xorg (main) "Xorg 100% CPU during scrolling gnome-terminal" [Undecided,New]  https://launchpad.net/bugs/125396
<ubotu> New bug: #128067 in ubuntu "Cannot locate mem resource (while booting kernel) (dup-of: 54294)" [Undecided,New]  https://launchpad.net/bugs/128067
<ubotu> New bug: #94352 in linux-restricted-modules-2.6.20 (restricted) "atheros wifi card drop connection and low signal (dup-of: 94148)" [Undecided,New]  https://launchpad.net/bugs/94352
<bryce> tepsipakki: I've gone through the whole backport list and reviewed all the patches and marked the ones I think should be backported, those that shouldn't, and those that I'm still not sure on:  https://wiki.ubuntu.com/X/Fixes_to_Backport
<tepsipakki> looks good
<jcristau> bryce: i810 vs intel doesn't matter for us as we're just shipping i810 as a symlink
<mvo> jcristau: did I miss some background here? the i810 <-> intel drivers are quite different, no?
<jcristau> mvo: "us" == debian here. sorry
<mvo> aha, ok
<mvo> jcristau: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/122979/comments/20 <- there seem to be issues with intel on some older chips with video playback
<ubotu> Launchpad bug 122979 in xserver-xorg-video-intel "[aiglx] [intel] [r300]  Video playback is buggy under Compiz" [High,Fix released]  
<mvo> I guess you are affected by this if you ship i810 as a intel symlink?
<mvo> I can reproduce the crash just fine with "intel" on my i830M chipset
<jcristau> yeah, probably
<mvo> just curious, what was the reason to not ship i810 at all?
<jcristau> it's abandoned upstream
<jcristau> so i don't think we'd want to ship it in lenny
<mvo> ok
<ubotu> New bug: #135463 in xserver-xorg-video-ati (main) "Radeon Mobility 7500 does not detect video projector" [Undecided,New]  https://launchpad.net/bugs/135463
<ubotu> New bug: #77765 in xserver-xorg-video-intel (main) "startx fails with Edgy" [Undecided,Invalid]  https://launchpad.net/bugs/77765
<ubotu> New bug: #75586 in xserver-xorg-video-intel (main) "vga-out get different resolution than the LCD display of a laptop" [Undecided,Incomplete]  https://launchpad.net/bugs/75586
<tepsipakki> bryce: I modified the Fixes_to_Backport page a bit, added a link to bug 125269
<ubotu> Launchpad bug 125269 in xorg-server "[PATCH]  Fix Xorg rendering when using a Composite Manager" [High,Fix committed]  https://launchpad.net/bugs/125269
<ubotu> New bug: #135509 in xkeyboard-config (main) "update xkb-data to include latest keyboard layouts" [Undecided,New]  https://launchpad.net/bugs/135509
<ubotu> New bug: #135512 in xorg (main) "exit from screensaver preview will crash X" [Undecided,New]  https://launchpad.net/bugs/135512
<ubotu> New bug: #135557 in xserver-xorg-video-intel (main) "Screen dimensions of external monitor not correct on X server startup (intel driver)" [Undecided,New]  https://launchpad.net/bugs/135557
<mvo> bryce: do you know of a way to communicate with the nvidia people other than their forums? I would like to get informaiton on bug #130325
<ubotu> Launchpad bug 130325 in xorg "glxgears, 3d apps, crash X when using compiz-fusion (gutsy) (nvidia-glx-new 9755)" [Undecided,Confirmed]  https://launchpad.net/bugs/130325
<jcristau> mvo: talk to aaronp on #xorg-devel?
<mvo> jcristau: thanks, that sounds like a good plan
<tepsipakki> there should be a new driver in next month
<tepsipakki> don't know what it will fix/break though :)
<mvo> beta freeze is 20th sep for gutsy
<mvo> that is going to be difficult to sneak in a new one I think (but if it fixes this issue, who knows)
<ubotu> New bug: #135589 in xserver-xorg-video-ati (main) "6.7.192-1ubuntu1 3d completely screwed" [Undecided,New]  https://launchpad.net/bugs/135589
<ubotu> New bug: #114911 in xserver-xorg-video-intel (universe) "xfmedia crashes while playing with "received an X Window System error."" [Undecided,New]  https://launchpad.net/bugs/114911
<jcristau> mvo: indeed, just tested xv on a i815 and it doesn't work. sigh
<mvo> jcristau: yeah :/
<bryce> tepsipakki: thanks
<bryce> mvo, yeah one of the nvidia drivers is active in Xorg
<bryce> mvo, he's aaronp on #xorg-devel if you'd like to get in touch with him directly
<jcristau> s/drivers/developers/ :)
<bryce> er whoops
* bryce needs to stop drinking decaf
<mvo> bryce: I haven't approached him yet as I wanted to wait for you first :) 
<mvo> bryce: have you talked to him yet (generally I mean)?
<bryce> yes, via irc and fdo bugs, not in person yet
#ubuntu-x 2007-08-30
<mvo> bryce: do you mind if I upload a new displayconfig-gtk soonish
<bryce> mvo, please do!
<bryce> mvo, yes I just asked glatzor about if we could do a new release yesterday
<bryce> I've done an initial 'does it apply' test for all the fixes proposed for backporting:  https://wiki.ubuntu.com/X/Fixes_to_Backport
<ubotu> New bug: #96943 in wine (universe) "wine doesn't work because of 3D driver (VIA) (dup-of: 43154)" [Undecided,New]  https://launchpad.net/bugs/96943
<ubotu> New bug: #135738 in xorg (main) "DisplaySize setting not honored" [Undecided,New]  https://launchpad.net/bugs/135738
<tepsipakki> yay, pixman got accepted
<bryce> http://arstechnica.com/journals/linux.ars/2007/08/29/ubuntu-xorg-maintainer-demonstrates-bulletproof-x
<bryce> tepsipakki: btw I've rolled a new xorg-server including the portion of patches that applied cleanly
<tepsipakki> bryce: sweet, do you need a sponsor?-)
<bryce> heh, need a tester first ;-)
<tepsipakki> bah :)
* Starting logfile irclogs/ubuntu-x.log
<tormod> bryce, btw can you add the verbosity patch from bug fdo 10238?
<bryce> tormod, on brief look it looks sane enough.  What's it needed for specifically?
<tormod> bryce, to see in the log if/why edid fails
<bryce> ok
<bryce> yes I'll include it with the next set of patches.  I've added this to my todo list
<tormod> bryce, maybe don't use the whole patch, but the pieces he proposes for inclusion.
<bryce> ok I'll review it in detail
<tormod> bryce: running -12ubuntu3feisty now. vesa does not segfault anylonger. Still failed with the old xorg.conf, then removed sync ranges and then it started, although in wrong mode :)
<bryce> interesting!
<tepsipakki> wow
<tormod> is there any easy way to force vesa without having a xorg.conf?
<tepsipakki> it doesn't use that?
<bryce> tepsipakki: well the x autodetect would kick in if the xorg.conf is missing
<bryce> tormod, I don't know of a method to force it to use vesa other than with an xorg.conf
<tormod> this is a X700, which usually would use ati. I force vesa to reproduce the X1?00 problems.
<tepsipakki> bryce: right, so it should use vesa
<tepsipakki> ahh
<tormod> I'll just strip my xorg.conf, needs Device and a minimal Screen section.
<tepsipakki> btw, I cleaned up the -intel bugreports a bit yesterday.. some 10+ bugs closed
<tepsipakki> -ati deserves the same
<bryce> awesome :-)
<bryce> btw, I've been gathering changelog info for recent uploads at https://wiki.ubuntu.com/XorgRecentChanges to help with triaging
<bryce> I'm planning once the xserver backports are done, and bulletproofx is turned on and working, to go through and do some major triaging
<tepsipakki> cool
<tormod> bummer - with a minimal xorg.conf it crashed again :(
<tepsipakki> btw, fedora has ati-6.7.192
<tepsipakki> tormod: but possibly for another reason
<bryce> is fedora running it straight or do they include any patches?
<tepsipakki> straight
<bryce> interesting
<tormod> tepsipakki: looks the same in the log, but I'll do some gdb
<tepsipakki> releases are coming so quickly
<tepsipakki> hum, should bug 54650 be closed now?
<ubotu> Launchpad bug 54650 in xserver-xorg-video-ati "GCC SSP breaks xorg-server" [High,Incomplete]  https://launchpad.net/bugs/54650
<tepsipakki> since the current xserver doesn't disable ssp anymore
<bryce> tepsipakki: yeah sounds like
<bryce> tepsipakki: want me to close it or do you want to?
<tepsipakki> I can do it.. I'll mark the gcc part as invalid
<bryce> ok cool, thx
<tormod> should I rebuild vesa with the new xserver-xorg-dev ?
<tepsipakki> probably doesn't matter
<tormod> hmm gdb is funny again, doesn't say where in vesa it crashes.
<tormod> I mixed up the packages again, seems like my vesa is not debug build...
<tormod> why does some x packages make a -dbg package and some not?
<tormod> segfaults at the very same place :(
<tormod> actually good that it is at the same place at least :)
* tormod goes eating
<tormod> if someone wants to help out debugging (remotely?) I'll be back
<tepsipakki> bryce: what do you think is sufficient time between a ping and marking the bug closed?-)
<bryce> bdmurray gives 30 days; I generally have been allowing 90 days
<tepsipakki> ok, I'll honour that
<bryce> sometimes I'll close after 30 days if it looks like the bug is extremely incomplete and I sense there's little chance of anything productive coming out of waiting
<bryce> whereas for bugs that at least some useful debuggable info exists, I'll wait additional time
<tepsipakki> yep, makes sense
<tormod> what's the best fd,o bug reference for that vesa problem?
<tormod> bug fdo 12105?
<tepsipakki> that's one, but I remember there being another one too (could be wrong)
<tormod> for the backported-1.4-to-1.3-to-feisty debs, can I get them hosted somewhere? if they get popular, they'll fill my 50MB/day quota,
<tormod> tepsipakki: (from #xorg-devel) yes I can put the fixed vesa up on XorgOnTheEdge.
<tepsipakki> cool
<bryce> tormod: certainly, I'd be happy to upload them to my people.ubuntu.com...Testing page if you'd like
<tepsipakki> bryce: I'll upload a new vesa shortly
<bryce> btw, I just put in for a discover-data change that will switch -i810 to -intel across the board by default
<tepsipakki> there's a oneliner for the fedora mode-heuristics patch, which should fix the crash
<tormod> bryce, you can find the new vesa for feisty in http://tormod.webhop.org/linux/bryce/
<tormod> the backport xorg-server is uploading...
<tormod> I guess xserver-xorg-core{,-dbg} and -dev should be enough?
<bryce> tormod: excellent, yes that should probably suffice
<bryce> tormod: let me know when they're finished uploading and I'll mirror them.
<bryce> tormod: I can also put out a call for testers on the X Tester forum if you'd like
<tepsipakki> tormod: just to be sure, does this debdiff look identical to yours? http://users.tkk.fi/~tjaalton/vesa.debdiff
<tormod> tepsipakki: yes they are the same.
<tepsipakki> cool, I'll upload now
<tormod> bryce: upload done, please get them. yes please call for testers. I'll update XorgOnTheEdge.
<bryce> ok great
<bryce> syncing...
<tormod> bryce: can you give me the url for my packages?
<bryce> sure, http://people.ubuntu.com/~bryce/Testing/xorg-server-backports-feisty/
<bryce> (still syncing)
<bryce> tormod: finished syncing
<tormod> bryce: thanks I saw that a while ago :) the wiki is updated. did you post on the forums?
<bryce> working on a post now
<tepsipakki> I'm off to bed, tomorrow I'll attack the ati-bugs more, gnite
<bryce> tepsipakki: excellent
<bryce> tormod: posted - http://ubuntuforums.org/showthread.php?p=3282357&posted=1#post3282357
#ubuntu-x 2007-08-31
<tormod> good night
<ubotu> New bug: #83320 in xserver-xorg-video-i810 (main) "display remains blank after closing and re-opening the lid" [Undecided,Confirmed]  https://launchpad.net/bugs/83320
<ubotu> New bug: #78372 in xserver-xorg-video-nv (main) "Dell Inspiron 9400: backlight off after resume from suspend" [Undecided,New]  https://launchpad.net/bugs/78372
<bryce> tested applicability of fedora patches:  https://wiki.ubuntu.com/X/Fixes_to_Backport#preview
<ubotu> New bug: #70121 in linux-restricted-modules-2.6.17 (restricted) "Screen off after resume on desktop" [Undecided,New]  https://launchpad.net/bugs/70121
<ubotu> New bug: #68391 in xorg-server (main) "Regression: Brightness up restarts X in Edgy with Asus V6J" [Undecided,Fix released]  https://launchpad.net/bugs/68391
<ubotu> New bug: #57147 in xserver-xorg-video-i810 (main) "Screen is garbled after lid close & open on Thinkpad Z60m" [Medium,Confirmed]  https://launchpad.net/bugs/57147
<ubotu> New bug: #52777 in xserver-xorg-video-i810 (main) "laptop thinkpad X60s switch screen doesn't work" [Undecided,Incomplete]  https://launchpad.net/bugs/52777
<ubotu> New bug: #136288 in xorg (main) "After restart X in Gutsy cannot CTRL+ALT+F7" [Undecided,New]  https://launchpad.net/bugs/136288
<ubotu> New bug: #134633 in linux-restricted-modules-2.6.22 (restricted) "xorg.conf borked after installing nvidia-glx-new (dup-of: 98641)" [Undecided,Invalid]  https://launchpad.net/bugs/134633
<tepsipakki> kylem: is the mesa in feisty-proposed going to be released soon?
<ubotu> New bug: #34856 in mesa-utils (main) "glxgears undocumented" [Medium,Fix released]  https://launchpad.net/bugs/34856
<ubotu> New bug: #34867 in mesa-utils (main) "glxgears -fullscreen doesn't listen for ESC" [Low,Confirmed]  https://launchpad.net/bugs/34867
<ubotu> New bug: #39911 in mesa-utils (main) "glxinfo reports false negative (dapper)" [Low,Fix released]  https://launchpad.net/bugs/39911
<ubotu> New bug: #81756 in xserver-xorg-video-intel (main) "Does not work on a Intel DG965WG with i965" [Undecided,Fix released]  https://launchpad.net/bugs/81756
<ubotu> New bug: #93832 in xserver-xorg-video-intel (main) "screen "melts", no output displayed" [Undecided,Fix released]  https://launchpad.net/bugs/93832
<ubotu> New bug: #135715 in xorg (main) "X Should Use Logrotate" [Undecided,New]  https://launchpad.net/bugs/135715
<kylem> bryce, are you going to be at XDS?
<bryce> yup, you?
<bryce> -> breakfast.  bbiab
<ubotu> New bug: #136292 in xorg (main) "GDM resolution too high with intel 865g graphics, max modeline too high" [Undecided,New]  https://launchpad.net/bugs/136292
<bryce> tepsipakki: any news on the -ati front?
<bryce> jcristau: are you aware of fedora's xorg-x11-server-1.2.0-selinux-awareness.patch patch?  We're not going to include it for ubuntu since we don't have selinux working yet, but kees suggested debian may be interested in it.
<keescook> actually, seems like x.org should take such a patch really
<bryce> since half the xorg team work for redhat, I'd be surprised if they didn't already know about it.  ;-)
<bryce> btw, do we care about IA64?
<bryce> eh, probably not
#ubuntu-x 2007-09-01
<ubotu> New bug: #134431 in xserver-xorg-driver-nv (main) "LiveCD initial GUI broken" [Medium,Triaged]  https://launchpad.net/bugs/134431
<bryce> I've gone through all of the fedora patches - https://wiki.ubuntu.com/X/Fixes_to_Backport
<bryce> I'm running a build of all the patches that applied and configured cleanly
<ubotu> New bug: #134271 in compiz (main) "mpeg-1 playback does not work (dup-of: 111257)" [Medium,New]  https://launchpad.net/bugs/134271
<ubotu> New bug: #134272 in totem (main) "theora playback does not work (dup-of: 111257)" [Low,New]  https://launchpad.net/bugs/134272
<tepsipakki> bryce: the fedora mesa-patch supercedes our copy
<tepsipakki> keescook: selinux-support is going in xserver 1.5
<tepsipakki> http://wiki.x.org/wiki/Releases/7.4
<ubotu> New bug: #31009 in xserver-xorg-driver-ati "Targa Traveller 826 - built-in LCD not recognised by x-server (dup-of: 22985)" [Unknown,Fix released]  https://launchpad.net/bugs/31009
<ubotu> New bug: #136615 in xserver-xorg-video-intel (main) "X server crashes on suspend to RAM after recent Gutsy update" [Undecided,New]  https://launchpad.net/bugs/136615
<bryce> tepsipakki: ah, ok.  Looks like it's going to take a bit of massaging to get it in
<bryce> tepsipakki: I would appreciate it if you could go through that wiki page and flag patches that you know should or shouldn't be included, and the ones I included but that I wasn't sure about if you have an opinion on them
<tepsipakki> bryce: sure
<tepsipakki> bryce: btw, did you look at the fedora xserver specfile? The patches are grouped in different categories, and the ones that are redhat-specific should probably be left out
<bryce> ah, no I didn't
<tepsipakki> xserver-1.3.0-newglx-offscreen-pixmaps.patch is a new version of 120-...
<bryce> is that the tfp patch?  it looked rather small to be the tfp stuff, but I didn't see another patch that looked like it.
<tepsipakki> also, the patch order can be seen from the specfile
<tepsipakki> and changelog :)
<bryce> good point
<tepsipakki> so, the mesa-patch needs to be applied before exa-update and newglx...patch
<bryce> ok
<tepsipakki> mesa-patch conflicts with patches 21, 125, 126, 127
<tepsipakki> they all can be commented out
<bryce> excellent
<tepsipakki> 21 only affects arches Ubuntu doesn't support
<tepsipakki> and in fact, 125-127 can be dropped since they are ours :)
<tepsipakki> hmm, add patch 43 to the list
<bryce> 43 as one to drop?
<tepsipakki> as one conflictiong
<tepsipakki> -o
<bryce> ok
<tepsipakki> leaving that out the mesa/exa/newglx-patches applied fine
<bryce> did you update the ordering as well?
<tepsipakki> the mesa-patch removes some files, one of which 43 touched
<tepsipakki> I just put those three as 133/134/135 (mesa/exa/newglx)
<tepsipakki> I'll continue with the rest tomorrow :)
<bryce> awesome.  I'll kick off a build myself with these changes.
<bryce> Btw, this morning I also started drafting up a X Quick Check list for our testers:  https://wiki.ubuntu.com/X/Testing/QuickCheck
<bryce> next I'm working on one for gamers
<bryce> https://wiki.ubuntu.com/X/Testing/GamerTest
#ubuntu-x 2007-09-02
<ubotu> New bug: #136699 in xorg (main) "VESA Driver Doesn't Support Widescreen Modes" [Undecided,Confirmed]  https://launchpad.net/bugs/136699
<bryce> http://hardware.slashdot.org/article.pl?sid=07/09/01/201200
<ubotu> New bug: #136729 in xserver-xorg-driver-ati (main) "My graphic card has no more acceleration 3D" [Undecided,New]  https://launchpad.net/bugs/136729
<ubotu> New bug: #136754 in xserver-xorg-video-intel (main) "Object flashing problem on intel driver with enabled desktop effects." [Undecided,New]  https://launchpad.net/bugs/136754
<ubotu> New bug: #136772 in xorg (main) "XQuickCheck:  2007-09-02 NicolChieffo" [Undecided,New]  https://launchpad.net/bugs/136772
<ubotu> New bug: #136779 in xserver-xorg-video-intel (main) "Xorg driver intel freeze the console when switching from X" [Undecided,New]  https://launchpad.net/bugs/136779
<ubotu> New bug: #136781 in xserver-xorg-video-intel (main) "Xorg driver intel has broken playing movies capability" [Undecided,New]  https://launchpad.net/bugs/136781
<ubotu> New bug: #136441 in ubuntu "Gutsy Lenovo T61 Intel 965 Graphics text mode install screen corruption (dup-of: 127008)" [Undecided,New]  https://launchpad.net/bugs/136441
<ubotu> New bug: #136782 in xorg (main) "1680x1050 not recognized on Ubuntu Gutsy Tribe5" [Undecided,New]  https://launchpad.net/bugs/136782
<ubotu> New bug: #136784 in xorg (main) "X crashes and returns to log-in when starting certain games" [Undecided,Incomplete]  https://launchpad.net/bugs/136784
<tormod> bryce, hi, I have built -12ubuntu4 for Feisty. Would you like to mirror them? Same place as last time.
<tormod> bryce: btw, you still have feisty in your changelog :)
<ubotu> New bug: #136824 in xserver-xorg-video-savage (main) "segfault in SavageSwitchMode when ppracer switches mode" [Undecided,New]  https://launchpad.net/bugs/136824
<bryce> tormod: excellent; what was the url again?
<bryce> tormod, we're working on a new version incorporating fedora's mesa7 stuff, that hopefully should be up in the next few days
<tormod> bryce: http://tormod.webhop.org/linux/bryce/
<tormod> why does Fedora have so many patches - why is it not upstream? Is it in upstream git?
<jcristau> partly
<bryce> I think many are backports, a few are redhat-specific, but yeah it seems like a number of these patches ought to be passed upstream
<bryce> ...syncing...
<bryce> done
<tormod> bryce, thanks. Can you move that vesa driver up from the -12ubuntu3 directory? 
<bryce> sure
<bryce> done
<ubotu> New bug: #136853 in xserver-xorg-video-siliconmotion (main) "[Gutsy]  multiple regressions since Feisty" [Undecided,New]  https://launchpad.net/bugs/136853
<tormod> Q-FUNK: ideally we should have one bug report per issue- they can have different reasons and fixes.
<tormod> Q-FUNK: have you tried the xserver-xorg-core-12ubuntu4 ?
<tormod> Q-FUNK: xserver-xorg-core 1.3.0.0.dfsg-12ubuntu4 that is :)
<tormod> Q-FUNK: it has many fixes backported from 1.4
<Q-FUNK> 2:1.3.0.0.dfsg-12ubuntu2 is the latest currently available here
<Q-FUNK> where can i find ubuntu4 ?
<tormod> Q-FUNK: https://wiki.ubuntu.com/XorgOnTheEdge in general
<Q-FUNK> let's see...
<Q-FUNK> ah, so just before 1.4 will release and 2 months off kde.  i often wonder if ubuntu might wanna consider skewing its own release date, at times
* tormod tries Sauerbraten which might crash his machine
<Q-FUNK> ok, installed 12ubuntu4
<Q-FUNK> let's see if it improves anything :)
* tormod survived the latest Sauerbraten, but the screen was just black
<Q-FUNK> 12-4 solves the issue of dpms that never wakes up :)
<Q-FUNK> doesn't solve the vcons switching issue.
<tormod> Q-FUNK: good. which of the issues was seen on amd?
<Q-FUNK> both
<Q-FUNK> sbalnaev has been wondering why for the last weke or so, as he's trying to complete the integration of support for -amd based products in LTSP
<tormod> can you ask him to try -12ubuntu4 as well?
<tormod> please file a bug on bugs.freedesktop.org with server logs etc
<bryce> tormod: thanks
<tormod> bryce: for what? :)
<ubotu> New bug: #136857 in xserver-xorg-driver-ati (main) "exa crashes when desktop effects are active plus flickering issues" [Undecided,New]  https://launchpad.net/bugs/136857
<bryce> for getting the testing on 12ubuntu4
<tormod> bryce: np, thanks for making it.
<bryce> it's quite exciting hearing about slews of bugs that these backport packages fix
<ubotu> New bug: #34584 in xserver-xorg-driver-ati (main) "screensaver flicker ati (dup-of: 22045)" [Medium,Fix released]  https://launchpad.net/bugs/34584
<tormod> good night!
<bryce> night!
#ubuntu-x 2008-08-25
<bdmurray> bryce: bug 180654 looks like it could be fixed released but the upstream bug is still open
<ubottu> Launchpad bug 180654 in xserver-xorg-driver-ati "[r100] rendering artifacts: intermittent vertical lines on right side of round shapes" [Unknown,Confirmed] https://launchpad.net/bugs/180654
<bryce> ok, looking
<bryce> yep, fix released
<tseliot> federico1: any comments on my reply? http://bugzilla.gnome.org/show_bug.cgi?id=546969
<ubottu> Gnome bug 546969 in Screen resolution "The GUI components do not always reflect the current situation" [Normal,Unconfirmed] 
<federico1> tseliot: hmmm, is there a way in which we could detect that a configuration will not apply correctly?  if not, could you add some code to compare the proposed configuration with what we actually got, and present an error message if they are different?  something like "your hardware or graphics driver didn't allow the specified configuration"
<tseliot> federico1: AFAIK there's no way to see it in advance since it might depend on the driver (e.g. a bug), or on some weird display/tv model
<federico1> ugh
<federico1> tseliot: ok, then we definitely need to tell the user what happened
<federico1> otherwise he'll click "apply" and things won't seem to work
<tseliot> federico1: ok, that would be possible but doing some detection stuff would still be necessary. I can do that
<federico1> tseliot: cool
<tseliot> federico1: ok, I'll write another patch with the warning
<federico1> tseliot: thanks!
<tseliot> bryce, tjaalton: to which package would you assign this bug report? https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/260867
<ubottu> Launchpad bug 260867 in xorg "Bad video signal after upgrading to Interpid" [Undecided,Incomplete] 
<tseliot> nvidia-common?
<bryce> yep, that'd be better than xorg
<tjaalton> or nvidia-96, if it's going to get support for 1.5
<tseliot> I have assigned it to both packages
<bryce> tseliot: ok I've done some updating to the patch and emailed it back to you to review
<bryce> tseliot: it seems there's been some changes upstream that need accounting for
<bryce> I've tried to integrate your code in a bit better, but it could probably be done better
<tseliot> bryce: I've just sent you a new patch
<bryce> tseliot: ok cool
<bryce> hmm
<bryce> yeah that's basically what I extracted.  See the patch I sent back to you which I feel is a bit cleaner patch
<bryce> since it deletes only 1 line of existing code, in theory it should be easier to maintain as upstream code changes
<bryce> (I've a feeling upstream won't be accepting use of python code for this, so we will be maintaining this patch a while; may as well make our lives simpler for us ;-) )
 * bryce -> lunch bbiab
#ubuntu-x 2008-08-26
<tseliot> bryce: you're right, I didn't pay enough attention to your patch. I guess it's because it's 1:11 AM here ;)
<bryce> ah, no prob.  I'll get it built and stuff, maybe we can test and/or commit tomorrow
<tseliot> bryce: ok, great
<tseliot> and good night
<bryce> tjaalton: I've updated notes on http://bryceharrington.org/X/PkgList/versions_current.html; let me know if you disagree with any of it
<dholbach> hi guys
<dholbach> what would you think about running a session at Ubuntu Developer Week?
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep still has some free slots and I'm sure people would be interested in learning more about what you do
<bryce> dholbach: I did one last time
<dholbach> bryce: how did it work out? are you guys interested in running another one?
<bryce> dholbach: well, we didn't get any helpers, mostly people were just asking about X status, and for help with their X problems
<bryce> so, I don't have an interest in doing another myself, but maybe someone else would
<dholbach> ah I see - did you pimp your TODO section enough and talk a bit about stuff that people could get involved with?
<bryce> certainly, and explained how to get involved, pointed out low hanging fruit that'd be easy for newbs to make a difference at, etc.
<dholbach> OK... I'm not going to pester you much more :)
<dholbach> in my sessions I'm going to point to harvest a lot, I hope that people will drive fixes toward you guys that way :)
<bryce> I think mostly people were just interested in what upcoming features there were going to be in the next release, so I think they got useful info out of it, but that could be taken care of with just a blog post or two ;-)
<bryce> yeah I've not been able to make much use of harvest so far
<bryce> by default it displays too much data - I think what I'd love to see is a variant that displays only the several dozen Xorg packages
<dholbach> hang on
<dholbach> bryce: do you have a team that is bug contact for the X packages?
<bryce> yep, it's 'x-swat' iirc
<dholbach> ubuntu-x-swat?
<bryce> https://bugs.edge.launchpad.net/~ubuntu-x-swat/+packagebugs
<bryce> ubuntu-x-swat
<dholbach> just a sec
<dholbach> bryce: http://6b62lx
<dholbach> err
<dholbach> bryce: http://tinyurl.com/6b62lx
<bryce> ah perfect, thanks
<tjaalton> wow, that looks nice
<dholbach> bryce: you could run a session called "the perfect contributor" :-)
<bryce> I'd just point to tjaalton and be done, I think
<dholbach> ok ok, I said I'd stop pestering you :)
 * dholbach hugs bryce
 * dholbach hugs tjaalton too
 * bryce hugs dholbach
<bryce> thanks for the harvest help, I was thinking I'd need to do some major hacking, this'll be extremely handy
<dholbach> bryce: I wrote a small script that generates the "harvest url" from the +packagebugs page: https://lists.ubuntu.com/archives/ubuntu-devel/2008-August/026118.html
<dholbach> that's not perfect or anything - the long term plan is to use seeds, but I'm just so busy right now that I didn't manage to start hacking on that
<tjaalton> bryce: :D
 * bryce nods
<dholbach> you could add that tinyurl to your GettingInvolved page
<dholbach> so people triage the page every now and then
<bryce> yeah, although the first place I'll slot it in is at http://bryceharrington.org/X/Reports/status_current.html
<dholbach> ok... works for me :)
<bryce> bbl
<dholbach> sleep tight
<dholbach> see you
<tjaalton> bryce: btw, now that evdev is used for keyboards and mice, we could be able to drop kbd and mouse from -input-all
<tjaalton> hm, that doesn't buy us a lot of diskspace after all
<tjaalton> :)
<tjaalton> joystick and evtouch are just as small
<bryce> well, every bit helps
<bryce> but will people need them perhaps, if evdev proves problematic?
<tjaalton> they can install those afterwards
<tjaalton> I think it's safe to say that evdev just works
<tjaalton> merging intel
<tjaalton> jcristau: was there a proper patch for the Xv issue on G45?
 * Ng perks up at mention of G45 ;)
<tjaalton> Ng: 2.4.1 aka 2.4.2 on the way
<Ng> \o/
<Ng> I'm getting a weird thing where the display drops out every so often (in that my tv blinks and shows the signal information again, like it switched video modes)
<Ng> it happens more on DVI than HDMI, but other than that I have no useful information about it, there's certainly no log entries anywhere
<crevette> hi there
<Ng> I'm worried that it might be something with the northbridge itself, when I was installing the board I picked it up by the thing's heatsink and I may have disloged it a bit :/
<tjaalton> Ng: nah, those things should be robust
<Ng> tjaalton: the heatsink definitely had more movement in it after I'd done that. I'm worried I might have cracked a solder joint or something ;)
<crevette> is there some known corruption problem with intel latest driver on intrepid?
<tjaalton> crevette: probably
<crevette> the chipset is 945
<bryce> crevette: bug #?
<bryce> crevette: what sort of corruption?  got a screenshot/photo?
<crevette> I can do that tonight when I'll be at home
<tjaalton> hm, enabling greedy migrationheuristic doesn't help anymore
<crevette> I didn't opened a bug yet
<tjaalton> bryce: the greedy patch for intel hasn't been applied since 1.5 came along (it crashes), and setting the option by hand doesn't seem to help improving the performance at all. so, what about dropping the patch from the diff?
<bryce> tjaalton: I figured we'd need to drop it eventually, so yeah
<tjaalton> I've forgot already; why don't we use XAA?
<bryce> EXA is the future!
<tjaalton> heh
<bryce> well, there were some bugs / mis-features which intel said they'd not support on XAA anymore
<tjaalton> well, EXA performance doubled with backported EXA changes from xserver master
<tjaalton> ah right
<bryce> wasn't it video compositing stuff or something?
<tjaalton> something like that
 * crevette keeps with ubuntu defaut config to support the future
<crevette> :)
<crevette> but the performances are not here :)
<jcristau> +   pI830->TexturedXvEnabled = xf86ReturnOptValBool(pI830->Options, OPTION_TEXTURED_VIDEO, FALSE);
<jcristau> tjaalton: just add || OVERLAY_NOEXIST(pI830) there
<jcristau> tjaalton: and, updating the patch description and the manpage to say this option defaults to off would be nice
<tjaalton> jcristau: heh, right. Now that I tried with the default settings (textured video on) on my i965, I didn't notice any problems
<tjaalton> but I should probably get a more demanding clip
<tjaalton> right. no problem running an episode of Fifth Gear
<tjaalton> what the hell made it work this good?-)
<tjaalton> so I guess that patch could be dropped as well
<tjaalton> at least disabled for now to see if people complain
<tjaalton> jcristau: so; +   pI830->TexturedXvEnabled = xf86ReturnOptValBool(pI830->Options, OPTION_TEXTURED_VIDEO || OVERLAY_NOEXIST(pI830), FALSE); ?
<jcristau> no
<tjaalton> argh :)
<jcristau> pI830->TexturedXvEnabled = OVERLAY_NOEXIST(pI830) || xf86ReturnOptValBool(stuff);
<tjaalton> makes more sense. anyway, I'll leave it disabled for now
<Q-FUNK> howdy!
<Q-FUNK> isn't today archive day?
<tjaalton> Q-FUNK: AIUI mon, wed, fri are
<Q-FUNK> ah
<Q-FUNK> was wondering what was going on with -geode sync from debian
<tjaalton> no idea..
<tedg> Hey guys, can you tell me about fast-user switching on Intrepid.
<tedg> I'm getting an X error from GDM.
<tedg> And from the log it looks like the nVidia driver can't initialize the kernel module?
<tedg> Seems odd that it could once, but not the second time.
<tedg> In general, is fast-user switching working in current Intrepid?
<tseliot> bryce: can you upload this, please? https://bugs.launchpad.net/ubuntu/+source/envyng-core/+bug/260862
<ubottu> Launchpad bug 260862 in envyng-core "Update EnvyNG in Intrepid" [Undecided,New] 
<tseliot> bryce: so that I can ask an archive admin about envyng-core and screen-resolution-extra?
<bryce> sure
<tseliot> bryce: thanks, let me know when it's done so that I can bug an admin before feature freeze ;)
<crevette> hey
<crevette> new intel driver seems to be better
<crevette> better performances at least
<crevette> hey, there is not comosited launch animation on gnome-panel
<crevette> composited
<tormod> bryce, are you interested in imagemagick?
<bryce> sure
<tormod> I was wondering if I should try to merge 6.4 which fixes some Ubuntu bugs
<tormod> but there are diffs not described in the changelog :(
<tormod> would you review it if try? before FF?
<bryce> certainly
<bryce> tseliot: btw envyng-core is uploaded
<tseliot> bryce: thanks a lot
<tormod> bryce, you had something to merge changelogs, right?
<bryce> yep
<bryce> http://bryceharrington.org/ubuntu/merge_changelog
<tormod> thanks!
<james_w> bryce: sorry, but I very much doubt I'll be able to review anything before feature freeze
<bryce> yay, mesa 7.1 released
<bryce> tseliot: found a problem in the screen-resolution-extra stuff - email sent
<tseliot> bryce: thanks for reporting. I'll have a look at it
<tseliot> bryce: does it solve the problem if you replace time.time() with str(time.time()) ? line 259
<tseliot> in screenresolution-mechanism.py
 * bryce tries
<bryce> that solved the error
<bryce> let's see if it updated things correctly
<tormod> bryce: Imagemagick got messy. Found out a sync was probably better, but it needs some changes to BFS. Don't understand while my PPA build failed during dh_install.
<tormod> s/while/why
<bryce> ok looks like it worked and updated xorg.conf correctly.  Rebooting to see if the Screen Resolution settings take too
<bryce> tormod: ah too bad
<tseliot> bryce: great
<bryce> hmm
<tormod> bryce: see bug #188773
<ubottu> Launchpad bug 188773 in imagemagick "please merge imagemagick 7:6.4.3.2.dfsg1-1 from Debian experimental (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/188773
<tormod> it's a bit awkward that I don't have intrepid myself...
<tormod> the most important bug fix here was for bug #178575
<ubottu> Launchpad bug 178575 in libexif "bad orientation tag causes gthumb to show strange value" [Undecided,Confirmed] https://launchpad.net/bugs/178575
<tormod> exif data is lost on image transformation
<bryce> hmm
<bryce> tormod: yeah I agree getting that patch upstream is probably the best way to go
<bryce> tormod: I don't think you can sync it otherwise
<bryce> tseliot: I put up some additional screenshots 8a-10
<tormod> bryce: we have to wait for the patch to go upstream before syncing?
<bryce> tormod: unless there is a reason why that patch is unimportant, yes the folks that do syncs would probably require it to be a merge
<bryce> tseliot: and http://bryceharrington.org/ubuntu/ScreenRes/screens-11.png
<tormod> because it's cosmetic? typo in documentation?
<bryce> right
<bryce> tseliot: sweetness :-)
<tormod> I'll add that.
<tseliot> bryce: the fact that it outputs the "Error" word is just the output of the logging library, nothing to worry about
<tseliot> bryce: I'm glad to see that it works
<bryce> tseliot: notice that in the console output there's info msgs that are labeled Errors which really aren't - is there a way to clean that up?
<bryce> ok, so it seems to generally work
<tseliot> bryce: yes, I think it's in the mechanism. Let me have a look
<bryce> tseliot: it's a bit irritating that the Screen Resolution tool has to block until the python tool completes, and I think some users may get confused about that, but I don't think there's an easy way around that
<bryce> but something we may want to think about
<bryce> anyway, once you get that time.time bug fix in, I think this is good to go
#ubuntu-x 2008-08-27
<bryce> tseliot: mind if I blog about this?  :-)
<tseliot>  bryce: sure, have fun ;)
<tseliot> bryce: as regards blocking the interface, I guess there's no way to solve it unless we mess with threads.
<bryce> yep
 * tormod says goodnight
<tseliot> and we don't want to mess with threads with GTK... trust me
<bryce> oh believe me, I know
<tseliot> heh
<tseliot> oh, I've found the line which makes it output "Error". It's in policyui.py. I won't touch the code now since I'm 100% sure that I would screw it up (1:11AM)
<tseliot> I've found another thing I'll have to correct. I'll fix it all tomorrow
<bryce> ok cool
<tseliot> good night
<bryce> http://bryceharrington.org/drupal/node/61
<bryce> tseliot: so commenters on the blog feel that the wording would be better "please log out and log in again" instead of "please restart the Xserver"
<tseliot> bryce: ok, it can be changed
<bryce> (http://bryceharrington.org/drupal/node/61)
<tseliot> bryce: would this be ok? "Operation Complete. Please log out, log in again and use Monitor Resolution Settings again in order to apply your settings." 
<james_w> tseliot: hi, is "use Monitor Resolution Settings again in order to apply your settings." what they are already trying to do?
<tseliot> james_w: if you set a screen to the left of the other but the framebuffer is not enough
<tseliot> you will have to set the virtual resolution and restart the xserver
<tseliot> however, in so doing the settings will be lost
<tseliot> and you will get cloned screens unless you use the GUI again
<tseliot> and this time the settings will be applied immediately
<james_w> tseliot: yes, so I think the message should indicate they should try again
<james_w> in order to be clear that they don't need to hunt for another tool and try something else.
<james_w> perhaps my point isn't clear?
<tseliot> james_w: good point. can you suggest a better message then?
<tseliot> better than what we have in the app now, I mean
<james_w> "Operation Complete. Please log out, log in again and retry the current operation"?
<james_w> if they get it when clicking "Apply"
<james_w> you probably want to ask a few more people though, as that may not be clear enough
<tseliot> yes, that's when they get it
<james_w> perhaps it needs two sentences.
<tseliot> ok
<tseliot> let's use yours and wait for more feedback
<bryce> hmm
<bryce> hard to express that without it sounding funky for the user
<bryce> it shouldn't say Operation Complete because then it sounds like the whole operation might be complete (which clearly it will not)
<bryce> hmm "Please log out and log back in again.  You will then be able to use Monitor Screen Resolution to setup your monitors"
<tseliot> bryce: right
<bryce> yeah I think more feedback would be nice
<bryce> maybe ask mpt, he usually has well thought out input to give
<tseliot> ok
<james_w> yeah, he'll be around soon
<james_w> what would be ideal would be if it could add a one-run item to the user's session that started the capplet in the configuration they have chosen,
<james_w> could it write a monitors.xml.desired, and then behave differently if one existed?
<bryce> I was wondering about that
<bryce> james_w: btw do you know why the revert dialog patch got dropped?
<james_w> bryce: I think it got dropped when the capplet was merged upstream
<james_w> I don't think it was because seb didn't like it though, so we could resurrect it.
<bryce> well I'm surprised because seb128 had been adamant about having that implemented.
<james_w> maybe I'm wrong then
<james_w> you should ask him when he returns
<bryce> I guess it doesn't matter.  I see he did the merge so if he still wanted it I guess he'd have ported it forward or talked to you or I about it.
<bryce> you know, I never got an answer why upstream didn't like that
 * bryce shrugs
<bryce> anyway, time for bed.  cya.
<tseliot> night bryce
<james_w> night bryce 
<tseliot> james_w: what we can do (and what I used to do in URandr, a program of mine) is write a script and add it to the gnome-session or kde-session so that it applies the settings without having to use that program again
<tseliot> a shell script
<james_w> tseliot: yeah, that would be good
<james_w> I think it would be better modifying the capplet itself to do it, but using the session would be good
<tseliot> james_w: this would make settings permanent though
<tseliot> james_w: maybe something can be done with gconf
<bryce> is composite still limited to a max virtual of 2048x2048?
<jcristau> what?
<bryce> http://lists.freedesktop.org/archives/xorg/2007-August/027634.html - i915 is limited to 2048x2048 w/ 3d still I assume, but are newer chipsets at 4kx4k?
<jcristau> that limit is way higher for 965+ afaik
<bryce> hmm, I thought so but on my 965 the default virtual is still limited to 2048x2048.
<bryce> I'm digging through the -intel source code to figure out if there's a reason why it's still limited to that
<bryce> ah http://lists.freedesktop.org/archives/xorg/2008-April/035007.html
<shenki> can i get someone to take a look at https://bugs.launchpad.net/bugs/259129
<ubottu> Launchpad bug 259129 in xserver-xorg-input-synaptics "synaptics (almost) crashes in recent kernels" [Undecided,New] 
<shenki> with the switch to .27 kernels, more people will be seeing the error in their logs
<tseliot> bryce: can you upload envyng-qt, please? The links to the source are in this file: http://albertomilone.com/ubuntu/envyng-intrepid/list.txt
<tseliot> to intrepid, I mean
<jcristau> shenki: will be fixed in the next version
<bryce> jcristau: I'm gathering we simply need a patched mesa (or mesa 7.1) - LP #146859
<ubottu> Launchpad bug 146859 in xserver-xorg-video-intel "No dri for virtual screen greater than 2048x2048" [High,In progress] https://launchpad.net/bugs/146859
<shenki> jcristau: yes, that's what i said in the bug report. any idea when the next version will be uploaded?
<tjaalton> shenki: tomorrow
<bryce> tseliot: sure; do you have the fixed screen-resolution-extra ready to go?
<jcristau> shenki: it doesn't matter...
<jcristau> the kernel fixes things up anyway
<shenki> jcristau: it doesn't matter?
<tseliot> bryce: yes, but I would like to test what I did
<bryce> tseliot: ok cool
<shenki> well, yes and no. it doesn't crash, but the touchpad driver sits there complaining about loosing sync every now and then
<shenki> tjaalton: thanks
<jcristau> shenki: that's unrelated
<tjaalton> bryce: looks like it's not that simple to fix
<shenki> jcristau: ok. where does that come from?
<jcristau> bryce: #146859 is about i915..
<jcristau> shenki: dunno. kernel or hardware bug.
<jcristau> bryce: oh, unless there's some other unrelated discussion in it
<tjaalton> bryce: sorry, didn't know there _was_ a patch for that (and the hard bit would be to go beyond 4kx4k)
<bryce> jcristau: I gather the mesa patch discussed there is for all drivers; I could be wrong though (only one cup of coffee so far)
<bryce> morning tjaalton
<jcristau> the mesa patch there only touches i965
<bryce> right
<bryce> bah I need more coffee
<bryce> jcristau: do you know when debian will be packaging mesa 7.1?
<tjaalton> g'morning bryce
<tjaalton> I could update the mesa git
<jcristau> bryce: whenever i find time for it
<bryce> tjaalton: btw I notice some patch posting activity on the Xcb list, but not seeing if the rearchitecting work we need for fixing those locking problems is coming in yet.  I've emailed bart to check, but if it doesn't come through, I'm wondering if we should disable libxcb
<bryce> tjaalton: that'd be great
<jcristau> (kinda working on it now, but dunno when it'll be ready)
<tjaalton> bryce: hum, sounds drastic.. what locking bugs are there now that java is fixed?
<jcristau> meh. forgot to set DEB_BUILD_OPTIONS :/
<bryce> tjaalton: #185311 has a lot of assertions from users that $random_app doesn't work unless my libx11-noxcb package is used
<jcristau> the only one i know about is some vmware shit
<tjaalton> checking..
<bryce> there's fewer recent comments though.  Maybe the latest java version isn't as badly afflicted
<tjaalton> java 6-07 at least should be fixed
<bryce> ok
<bryce> well guess I won't worry about it then
<tjaalton> :)
<bryce> I think the bulk of the apps have been java based
<tjaalton> yeah..
<tjaalton> I've packages a lot of math apps locally (matlab, mathematica..), and they all tend to ship a java runtime of their own, but work just fine if the dir is linked under /usr/lib/jvm :)
<tjaalton> so they all get the latest java that is installed
<bryce> the last comment in that bug mentions cinelerra which I guess is C
<bryce> but user didn't indicate how they got it.  cinelerra appears to roll their own .deb packages outside ubuntu
<tjaalton> bah, got to put the tux on and get ready for the stage.. ->>
<tjaalton> bbl
<bryce> cya
<bryce> tseliot: uploaded
<tseliot> bryce: thanks a lot.
<tseliot> I'll have to ask an admin, right?
<bryce> tseliot: probably
<bryce> tseliot: try asking slangasek
<tseliot> bryce: ok
<tseliot> I'm updating my laptop so as to try screen-resolution-extra. Testing shouldn't take long
<tseliot> bryce: I talked with james_w about making screen resolution-extra apply the settings automatically after the login
<bryce> tseliot: ah?
<tseliot> bryce: I did something similar in URandR
<bryce> it'd be great if we could do that; it'd simplify the workflow
<tseliot> bryce: by adding either a shell script to the GNOME session or something with gconf (if possible)
<tseliot> what do you think?
<bryce> I'd need to see the implementation, but in principle it sounds good
<tseliot> bryce:
<tseliot> I can make Python create the script
<tseliot> as I used to do
<tseliot> or I can do it in C
<tseliot> since the C part has access to all the details
<bryce> yeah best to do it in C probably
<tseliot> e.g. which display is on the left of which, etc.
<tseliot> ok, one more task to do in C. I'll experiment a bit then and show you something soon. But of course we should focus on what currently works (or should work) ;)
<bryce> great, and agreed
<james_w> I agree
<bryce> the sooner we can get the current stuff in front of testers, the sooner we'll be able to get this in main and switched on for everyone
<tseliot> right
<james_w> Making the capplet itself do it would be good I think, as I think it would work better in failure situations, and makes it easier for the user to tweak.
 * tseliot nods
<tseliot> bryce: ok, I have fixed every problem I'm aware of, however the C program still outputs Error:  Failure running /usr/share/.../policyui.py
<tseliot> Close
<tseliot> I guess it's because I make the python script exit with an error status so that the C part can understand that it doesn't have to apply the settings
<tseliot> other than this, the other output and the bugs are gone
<tseliot> bryce: I think that the only way to get rid of that error output is calculate the framebuffer size in C and execute the Python script only if necessary
<tseliot> the C code is already there and I'm sure that we can reuse it
<tseliot> what do you think?
<bryce> sure
<bryce> ok, well that Error stuff isn't visible to users so I guess it's just a minor irritant
<tormod> tedg: ping
<tseliot> bryce: would it be ok if I changed Section: contrib/x11 into Section: utils/x11 in the control file?
<tseliot> Riddel asked me to change contrib yesterday
<tedg> tormod: pong
<tedg> tormod: Let's not both update xscreensaver this time :)
<tormod> tedg: right :) be my guest 
<tormod> I am running a little out of time, so if you can...
<tedg> tormod: Okay, I will do it.
<tormod> thanks
<tormod> as you see, 5.07-1 is not released yet, because Jose Luis is travelling etc, but it's good as done.
<tormod> if you see something that should be fixed in Debian, please tell me.
<tedg> tormod: Okay, thanks.
<tseliot> bryce: BTW the fixes are all in my bzr branch: /~albertomilone/screen-resolution-extra/main
 * tseliot > dinner. Bbl
<tormod> how does the X server actually choose the driver nowadays?
<tormod> re bug #261977
<ubottu> Launchpad bug 261977 in xorg-server "nv is chosen even if it doesn't support the card" [Undecided,Confirmed] https://launchpad.net/bugs/261977
<jcristau> tormod: it's all there in hw/xfree86/common/xf86AutoConfig.c 
<tjaalton> are the *.ids used anymore?
<jcristau> yes
<jcristau> but if that fails, it goes to videoPtrToDriverName()
<tjaalton> ah
<jcristau> and, case 0x10de: case 0x12d2:   return "nv";
<jcristau> i think it's saner on master
<jcristau> and it'll fall back to vesa
<tjaalton> there should be a similar bug about nv (ie. dupe)
<bryce> tjaalton: btw I filed the outstanding sync requests.  having some troubles updating the versions page due to fdo timeouts
<tjaalton> bryce: oh, that's why it looks so funny?-)
<bryce> yeah
<bryce> tjaalton: btw, do you have any thoughts on what to do about 207409?
<bryce> tjaalton: personally I suspect most of the cases they're having an X problem, and they remember that once long ago (pre-autoconfigure) running dpkg-reconfigure fixed something, and they want their current issue to be fixed that way again, only it's not clear that dpkg-reconfigure would work any better
<bryce> also the whining is not winning any points with me
<tjaalton> bug 207409
<ubottu> Launchpad bug 207409 in xorg "There is no user interactive menu method to configure xorg.conf from a shell" [Wishlist,Incomplete] https://launchpad.net/bugs/207409
<tjaalton> sigh..
<bryce> yeah
<tjaalton> wontfi
<tjaalton> x
<bryce> would the idea in comment #46 even be doable?
<bryce> I imagine the postinst script is too wedded to debconf to be used separately like that
<tjaalton> it doesn't have to use debconf.. they are free to write an app of their own
<tjaalton> which would generate the xorg.conf
<tjaalton> curses based or whatever !gnome
<bryce> so "You're welcome to try putting the postfix script into a new package separate from xorg that uses curses or whatever to generate an xorg.conf for you.  I think you overestimate the likelihood that it'd actually be able to fix these problems, but I could be wrong.  In any case, since it'll be a new package, it's no longer an xorg issue.  Closing." --> WONTFIX ?
<jcristau> bryce: sounds good
<tjaalton> yeah \o/
<tjaalton> case closeed
<tjaalton> -e
<bryce> alrighty.
<bryce> deed is done.
<bryce> next dirty deed on the todo list... killing displayconfig-gtk...
<tjaalton> dirty deeds done dirt cheap ;)
<tormod> thanks all for the info above
<tormod> I remember vaguely some discussion on xorg ML about a commit that was reversed because(?) it would "help" third-party drivers like nvidia. It was speculated that whore distributions would cherry-pick it anyway. Is that done?
<jcristau> tormod: it's not about helping nvidia
<tormod> jcristau: ok I probably remember wrong then
<jcristau> it's about whether x.org supports the nvidia driver. which they don't.
<tjaalton> yep..
<tormod> I understand Debian and Ubuntu do then. But this was maybe in 1.6?
<tormod> anyway back to that bug, what should be done?
<jcristau> i'm pretty sure debian doesn't support the nvidia driver
<jcristau> at least i'm not going to ship that patch
<tjaalton> ubuntu tries to..
<tjaalton> which, looking at the bug count, isn't doing that great
<jcristau> tjaalton: i think they're wrong, but it's none of my business, so.. :)
<tormod> should nvidia ship .ids files then?
<tjaalton> tormod: no
 * tormod tries to look at that file referenced above, but freedesktop.org seems broken
<tjaalton> jcristau: yeah, I'm thinking that applying that patch could generate some bad press
<jcristau> tjaalton: less than reverting to 1.4 for intrepid because of no fglrx ;)
<tjaalton> jcristau: hehe, true
<tjaalton> mesa merge done
<tjaalton> and pushed
<bryce> yay!  you rock
<tjaalton> pitti made a couple of uploads a while back, and I added those changes too (mesa now in git, since changes keep piling up)
<tjaalton> clearly faster to merge with a VCS
<tjaalton> jcristau: dpkg-source complains about the mesa tarball.. files that are symlinks in the git tree and nonexistent in the tarball
<tjaalton> {r200,r300}/radeon_screen.c mainly
<jcristau> tjaalton: hmm?
<jcristau> no such files here
<tjaalton> jcristau: in git?
<jcristau> sounds like your git tree isn't clean
<jcristau> git clean -dnx?
<tjaalton> right, that would remove those
<jcristau> git clean -dfx to actually do it
<tjaalton> yep, works
<tjaalton> maybe I'll be able to upload the new synaptics tomorrow.. and start fixing the evdev s/model/rules/ mess
<tjaalton> though that means touching many packages
<bryce> btw, FF is in 1.5 hrs
<tjaalton> oh, I thought there were plenty of hours left :)
<bryce> apparently slangasek is selecting 00:00 UTC instead of 23:59 UTC as "Aug 28th"
<tjaalton> well, that just means I have to upload synaptics now :)
<tjaalton> the rest are just patches
<bryce> tjaalton: lemme know if we need FFe's for any particulars, I can ask at the meeting
<bryce> (or feel free to ask yourself on #ubuntu-x when they get to me)
<bryce> er
<tjaalton> -meeting
<bryce> s/-x/-meeting/ :-P
<tjaalton> oh it's underway
<bryce> yeah they're going in reverse-alpha by screenname so I should be after calc
<tormod> for syncs, is it enough to have archive-admins subscribed before FF?
<bryce> tormod: I *think* so
<tormod> bryce, can you do something for bug #192772, it's assigned to rtg but he doesn't seem to be reliable
<ubottu> Launchpad bug 192772 in linux-wlan-ng "please merge linux-wlan-ng 0.2.9+dfsg-1 from Debian main unstable" [Low,Fix committed] https://launchpad.net/bugs/192772
<tormod> if you can subscribe archive-admins it should be fine. if he ever gets to my patch later that's fine.
<bryce> tormod: hm, I'd be more comfortable if you talked to slangasek directly.  Or if you're certain you just want a sync, file a new bug requesting a sync and sub ubuntu-archive to that
<tormod> bryce: I don't think I can sub ubuntu-archive, a dev must do it
<tormod> ok I'll give slangasek a try
<bryce> if you file a new bug for the sync request, or add a comment at the end of the bug that clearly states a sync request, I'd be happy to sub them
<tormod> thanks, I'll do that if I don't hear from slangasek on #ubuntu-devel
#ubuntu-x 2008-08-28
<Ng> g45 seems happy with 2.6.27 and the latest -intel package :)
<tjaalton> ok, synaptics uploaded..
<tjaalton> zzz ->
<tormod> now where did tedg go?
<tormod> it's not allowed to leave irc before FF :)
<bryce> heh, tedg is not much of an irc guy ;-)
<bryce> if you have IM, he tends to respond better to that (or email)
<tormod> thanks for the hint. you know what timezone he's in?
<tormod> I thought IRC was IM :)
<bryce> he's in texas, which I think is -5 or -6
<bryce> er -6 or -7
<tormod> is he a day or night worker?
<bryce> pretty much.  ain't we all?
<bryce> ;-)
<bryce> actually I don't know for certain; I think he's a morning type guy, and he has a young son so he probably can't work all hours of the day like he'd probably like
<bryce> he's obsessive about checking email though
<tormod> I'll try mail then :) thanks
<tjaalton> bryce: looks good
<tjaalton> hm, I wonder if xserver should depend on evdev
<tjaalton> or xserver-xorg should depend on 'x-x-i-all | x-x-i-evdev | x-x-i-ABI'
<tseliot> bryce: did you try screen-resolution-extra?
 * Ng pokes at the changelog for -intel 2.4.2 to see if it's interesting ;)
<tjaalton> Ng: our 2.4.1 is basically 2.4.2
<tjaalton> only upstream change is the version string
<Ng> ah, sweet :)
<Ng> I gave it a quick test out last night on the new box and it seemed fine :)
<tjaalton> nice
<tjaalton> so, the new mesa broke stuff for intel at least
<tjaalton> compiz doesn't start etc.
<jcristau> tjaalton: with the new server?
<tjaalton> jcristau: old one
<jcristau> there's a chance the new one will fix this
<tjaalton> ah
<tjaalton> k, I'll build it then
<jcristau> configure will check for inputproto 1.4.4
<tjaalton> crap
<tjaalton> I had 1.9.xx installed
<tjaalton> patch added, now building..
<tjaalton> yeah, I got compiz back
<tjaalton> hm, my xserver locked hard
<tjaalton> or maybe the display just went blank
<tseliot> tjaalton: lucky you... with the new driver my my Intel card makes the screen flicker
<pwnguin> as of last week, my laptop just sits black
<pwnguin> not an X thing, a power cord thing =(
<tjaalton> pwnguin: btw, the wacom crash is due to the new driver
<tjaalton> old one works for me
<pwnguin> "works"
<tjaalton> hotplug works
<pwnguin> do i need to check my email?
<tjaalton> and doesn't crash the server
<tjaalton> I replied to the bug, that's all
<tjaalton> and found a dupe
<pwnguin> i haven't yet figured out how to communicate with upstream effectively
<pwnguin> they've basically said reporters need to send email to the list and then they'll create reports themselves (if they feel so inclined)
<tjaalton> no-one replied to my question about input properties
<jcristau> is upstream more than magnus?
<tjaalton> jcristau: you mean commit 5e847c1d4fc30a0d would fix the problem of choosing a driver which doesn't support the device instead of just falling back to vesa?
<jcristau> tjaalton: it should
<tjaalton> cool
<tjaalton> wacom upstream is some Ping guy
<tjaalton> magnus has been active, but no posts from him in a while
<pwnguin> danny kuwaka (sp?) has been engaging linuxwacom lately, mostly in the form of sax2 patches
<soren> It's Kukawka.
<soren> Well, presuming we're talking about the same guy :)
<pwnguin> yea
<pwnguin> i think i'll just call him danny, because i dont know any others
<pwnguin> i know a couple soren's but only one danny :)
<soren> pwnguin: Really? That's a rather unique statistic, I think :)
<tjaalton> ok, so my laptop screen doesn't wake up
<tjaalton> hrm, will test another kernel
<tseliot> tjaalton: and my laptop doesn't boot at all with 2.6.27
<tjaalton> tseliot: fun :)
<tseliot> tjaalton: a lot...
<tseliot> furthermore I can't do mouse clicks by tapping on my touchpad any more
<tjaalton> tseliot: since when?
<tseliot> tjaalton: today
<tjaalton> logfile
<tseliot> tjaalton: http://pastebin.com/m4923e04a
<tjaalton> tseliot: so you've ran intrepid on it before the update?
<tseliot> tjaalton: yes, sure
<tjaalton> well, you should be able to change the setting on the fly with xinput
<tseliot> hmm,,, it wasn't installed
<tjaalton> it's not a strict dependency
<tseliot> tjaalton: how can I change the settings with xinput?
<tjaalton> tseliot: http://who-t.blogspot.com/2008/07/input-device-properties.html
<tjaalton> I don't have a touchpad though
<tjaalton> so haven't tested it
<tseliot> ok, thanks
<tjaalton> man xinput helps as well
<tjaalton> tseliot: you could also try to downgrade the driver to see if it works with the old version
<tseliot> tjaalton: sure
<tjaalton> could be that the driver defaults have changed
<tseliot> tjaalton: yes, reverting to 0.14.7 solved the problem
<tseliot> also with the intel driver 2.3.2 the screen doesn't flicker
<tjaalton> tseliot: what chip do you have?
<tseliot> tjaalton: Compiz doesn't work with either version
<tjaalton> try if the latest xserver is built
<tjaalton> and published.. probably not
<tseliot> tjaalton: it says intel 945GM/GMS/GME, 943/940GML
<tjaalton> ok, 965 doesn't flicker
<tjaalton> or, when should it flicker?
<tjaalton> I don't do multihead
<tseliot> tjaalton: it flickers with 2.4.1 with a single display
<tseliot> with no virtual resolution set
<jcristau> weird. doesn't here.
<jcristau> hrm
<jcristau> i'm wrong
<jcristau> actually it does
<tseliot> jcristau: glad to know that I'm not the only one ;)
<jcristau> 2.4.1 didn't (i think), 2.4.2 does
<jcristau> 2.4 did, too :)
 * jcristau bisects
<tseliot> tjaalton: any links to the new xserver?
<tjaalton> tseliot: available on archive.u.c
<tjaalton> ok, my screen doesn't wake up with .26 or .27, but does with .24
<tjaalton> and the mouse pointer isn't crazy either
<tjaalton> with .24
<jcristau> 48d4b0ae is the culprit
 * Ng spies talk of flickering
<Ng> I wonder if that's the same thing I'm seeing
<tseliot> federico1: I'm looking for the name of the connected output in the display capplet (e.g. VGA, LVDS[1], etc.). Is "output->name" what I'm looking for? "output->display_name" should the label (e.g. Samsung 204b) while "output->name" is VGA, etc., right?
<superm1> bryce, any updates on your end from AMD by chance?
<tjaalton> superm1: 1.5 will be released next week, so hopefully the Sep version supports it
<superm1> tjaalton, unfortunately from the feedback i've heard it looks like it's a lot of work to rework on their end, and i've yet to see any of the private betas even touch on the subject
<tjaalton> superm1: hm, too bad
<tjaalton> even so, going back to 1.4 is not an option IMHO
<superm1> tjaalton, yeah so i'm just hoping at this point that more positive words might have been received from bryce's channels.  
<superm1> what i don't get is that they really should have seen this coming
<superm1> these changes have been in xorg-server's git for a long time
<tjaalton> yep.. nvidia has supported it since March or so
<superm1> in an email, i quote "We only recently found about the major changes"
<superm1> so yeah...
<tjaalton> umm, right
<tjaalton> head-in-the-sand
<federico1> tseliot: yeah, I think output->name is just what xrandr(1) would report
<bryce> superm1: sorry, what I've heard seems to be about the same as what you've heard
<superm1> bryce, well right now i'm crossing my fingers hoping that they can just throw a ton of man power at it and get it done soon
<jcristau> a ton of manpower sounds like too much
<bryce> superm1: yeah sounds like it's top priority for them right now
<bryce> superm1: there's a release meeting tomorrow, and colin suggested we discuss the potential of an -fglrx SRU there
<superm1> bryce, i'll listen in on the meeting, you know what time it's at?
<bryce> superm1: 15:00 GMT I think, on #ubuntu-meeting.  let me verify
<bryce> yep  - http://fridge.ubuntu.com/node/1619
<superm1> yeah i should be able to make that i believe
<bryce> tseliot: you about?
<tseliot> bryce: I'm here. Did I miss anything?
<bdmurray> tseliot: I'm looking for a bug with a bad xorg.conf
<tseliot> bdmurray: with X-Kit?
<bryce> tseliot: heya.  brian is working on hooking up your xorg.conf validator script to run automatically on bug submissions
<tseliot> bryce, bdmurray: fantastic!
<bdmurray> well, to process existing bug reports ;)
<tseliot> bdmurray: would you like me to send you a text file with the tests performed on all the bug reports?
<bdmurray> tseliot: I wanted to know if you knew of a bug # with a bad one
<tseliot> bdmurray: sure, let me check
<bdmurray> or if you have the librarian url I can find the bug
<tseliot> bdmurray: 106632 or 103839
<tseliot> bdmurray: I've got other ~160 bugreports
<tseliot> bryce, superm1: BTW the switch to kernel 2.6.27 killed one more NVIDIA driver (173)
<bdmurray> tseliot: okay, if I need to test more I'll let you know :-)
<superm1> tseliot, ugh really?
<tseliot> bdmurray: ok
<superm1> tseliot, failed to compile, or what's the deal?
<tseliot> superm1: yes, it failed to compiled. Then I applied the patch, compiled and I got this: http://www.nvnews.net/vbulletin/showthread.php?t=118595
<tseliot> superm1: I can't even modprobe the module...
<tseliot> nooo, another NVIDIA beta driver was released...
<bryce> "Intrepid - The (unintentionally) fully FOSS Ubuntu release"
<tseliot> bryce: yes, that's how it will end up
<superm1> haha
<superm1> tseliot, i dont see any new ones listed on http://www.nvidia.com/Download/Find.aspx?lang=en-us ?
<superm1> oh nvm on nvnews.net 
<superm1> not on nvidia.com yet
<tseliot> yep, it's here: http://www.nvnews.net/vbulletin/showthread.php?t=118602
<superm1> yeah this situation for all these binary drivers is pretty bad it seems right now...
<superm1> other than nvidia 177 i suppose
<tseliot> bryce: improving communication with NVIDIA wouldn't be a bad idea (as you did with AMD)
<tseliot> bryce: by "you" I mean Canonical
<bdmurray> tseliot: 106632's attachments passed for me
<tseliot> bdmurray: yes, and it is valid
<tseliot> hmm...
<bdmurray> tseliot: okay, I thought you mentioned that as an example of a bad one.  I found that 103839 did have a bad one though
<tseliot> bdmurray: yes, it has a broken reference to a monitor section which doesn't exist
<bdmurray> right, so 106632's are good and 103839 has a bad one
<tseliot> bdmurray: yes, right
<bdmurray> Okay, I think my script is sound, I'll start processing some next week I think.  I've a long weekend this weekend.
<tseliot> bdmurray: great. Let me know if there is something you would like me to change in X-Kit.
<bryce> hey bdmurray, I like using the "incomplete with response" to review replies to the -ati bugs to filter down to ones I need to look at.  But often I am just asking another question (like, attach /var/log/Xorg.0.log).  Is there a way to bump an incomplete bug back to 'incomplete without response', aside from moving it to New and then back to Incomplete?
<tseliot> bryce, superm1: I got driver 173 back with another patch
<superm1> tseliot, you wrote it, or got it from somewhere?
<tseliot> superm1: I took it from Kanotix
<superm1> ah that was pretty quick of him to come up with a patch
<tseliot> yep
<tjaalton> I think he had that for some time
<superm1> now remind me briefly; are -71 and -96 broken because of similar reasons, or xorg server 1.5?
<tseliot> xorg 1.5
<superm1> so a lot less likely to be fixed anytime very soon
<tseliot> yes...
<superm1> what's the plan of attack for those packages then?  i mean it doesn't make sense to offer them via jockey right now does it?
<tseliot> I can hijack the modaliases files for those drivers
<superm1> well or just have jockey not depend on those until they are fixed?
<superm1> i mean that's basically what's going on right now for fglrx
<tseliot> yes
<superm1> and i suppose have nvidia-common not support them etc
<tseliot> oh and I forgot that I can't touch the modaliases since we need them to know which cards are not supported
<tseliot> so that maybe nvidia-common can detect them and change the driver to nv in case of dist-upgrade
<tseliot> we could do the same with ati cards
<superm1> well the fat lady hasn't sung yet on ati cards, but yeah that's a possible solution
<tseliot> yes, it was just an idea
<tseliot> and we don't know what NVIDIA will do and when
<tseliot> superm1: I have fixed a problem in nvidia-settings
<superm1> tseliot, what problem?
<tseliot> it set the background colour to white
<tseliot> in the glx frame
<superm1> is that not desirable?
<tseliot> not with dark themes
<superm1> ah yeah.  
<tseliot> that frame looked like a big white rectangle here
<superm1> do you need sponsorship on that?
<tseliot> yes, please
<tseliot> let me upload the package to my website
<superm1> you have a debdiff somewhere I can apply and upload?
<superm1> make sure to submit this patch to nvidia too
<tseliot> on their forums?
<superm1> ideally yes.  if they aren't responsive, i've got other channels i can submit it too
<tseliot> superm1: http://albertomilone.com/ubuntu/nvidia/nvidia-settings_173.14.09-1ubuntu3.debdiff
<tseliot> superm1: I have just commented out a few lines
<superm1> that debdiff seems a bit sizable for "just commented out a few lines"? 
<tseliot> superm1: a file was auto-generated
<tseliot> and didn't go away after a debclean
<superm1> ugh i forgot how annoying this package is; it doesn't use a patch system at all
<superm1> i'm going to add in a patch system so this doesn't get lose in cruft
<tseliot> superm1: shall I upload the whole source then?
<superm1> tseliot, no it's okay, i'll factor your changes directly into a .patch in debian/patches and then add you to the changelog manually
<tseliot> ok thanks
<superm1> okay tseliot uploaded 
<tseliot> superm1: thanks a lot
<superm1> tseliot,  np.  you should find a core-dev sponsor for that nvidia-drivers-173 soon too.  my boss was bugging me about that this morning when he upgraded to 2.6.27 ;)
<tseliot> superm1: I'll make DKMS apply the patch only with 2.6.27 so as to keep compatibility with 2.6.26. Your boss will be happy about this ;)
<superm1> :)
<tseliot> superm1: how do you handle upgrades to new versions of the driver with DKMS?
<superm1> you remove the old version with dkms remove
<superm1> and then install the new version with dkms add/install/build
<tseliot> superm1: it's what I do but the directories of the old versions still remain in /var/lib/dkms/nvidia even though they are almost empty
<superm1> what's still there?
<tseliot> For example, these directories: 2.6.26-5-generic  build
<tseliot> and this broken link:  lrwxrwxrwx 1 root root   25 2008-08-03 16:49 source -> /usr/src/nvidia-173.14.09
<tseliot> superm1: oops, I didn't set remove|upgrade in the case loop
<tseliot> my bad
<tseliot> (in the prerm)
<tseliot> there was only remove
<superm1> oh, yeah i ran into that a while back on fglrx too
<tseliot> superm1: patch for nvidia-settings submitted to NVIDIA: http://www.nvnews.net/vbulletin/showthread.php?t=118640
<tseliot> good night
<superm1> tseliot, okay great :)
<superm1> tseliot, let me know if that gets ack'ed by them in the next week or two
<superm1> if not i'll bring it up via my channels
<tseliot> superm1: ok, I subscribed to that thread so as to be notified via email. I'll let you know how it goes
<superm1> ok
<superm1> nigth
 * tseliot > bed
#ubuntu-x 2008-08-29
<Ng> is intrepid generally working for 965 folks?
<Ng> 55fps from glxgears and compiz won't run
<Ng> hmm, although it'll run now
<bryce> bdmurray: your scripted -ati test request has proven quite fruitful
<bryce> http://people.ubuntu.com/~brian/complete-graphs/xserver-xorg-video-ati/plots/xserver-xorg-video-ati-fullyear-open.png
<tjaalton> Ng: upgrade your xserver-xorg-core
<Ng> tjaalton: apt isn't offering me any updates for that
<Ng> ii  xserver-xorg-core            2:1.4.99.906-2ubuntu2        Xorg X server - core server
<Ng> also, I guess I'd still need mvo's package of evdev git to get scrollwheel emulation via hal?
 * Ng really hopes that can be included somehow
<tseliot> tjaalton: can you upload these files, please? http://albertomilone.com/ubuntu/newlrm/pitti/lista_ia.txt
<tseliot> tjaalton: 173 now works with kernel 2.6.27 while 177.70 fixes a regression in text rendering
<Ng> argh, laptop completely froze when I locked the screen
<Ng> nothing in logs, and the highly computationally taxing screensaver I use is "Blank Screen" ;)
<tjaalton> Ng: yep, works with the hardy kernel
<tjaalton> don't let the screen to fall asleep
<Ng> tjaalton: erk
<Ng> tjaalton: any idea what it is?
<tjaalton> seems like glxgears doesn't count the fps correctly, it's very smooth even though it's <50fps
<Ng> I dunno, compiz feels a bit sluggish too
<tjaalton> compared to?
<Ng> before the upgrade
<tjaalton> which upgrade :)
<tjaalton> hardy -> intrepid?
<Ng> hardy->intrepid. it's hard to be sure though, because all my compiz settings were eaten by the upgrade, so none of my tweaks of things like switching workspaces are the same now
<Ng> but 3d oddness is a lot less important than hard lockups ;)
<tjaalton> compiz sluggishness is probably because EXA doesn't preserve enough memory for offsceen pixmaps
<tjaalton> around 12MB for my resolution
<Ng> ah ok
<Ng> do you know if there's a bug report for the screensaver lockup thing?
<tjaalton> its not a screensaver problem
<wgrant> Ah, is that why my laptop started hardlocking and sometimes panicking on resume today?
<tjaalton> the screen doesn't know how to wake up when blanked
<tjaalton> umm, driver/kernel, or whatever
<tjaalton> anyway it seems to be a kernel problem
<tjaalton> and I don't know if it has been filed yet
<Ng> tjaalton: sure, I didn't mean to suggest gnome-screensaver was locking the machine
<Ng> but whatever it is, it's pretty deep because it really does seem to hardlock - no capslock, no magic sysrq
<tjaalton> but ssh works
<Ng> that I haven't tried yet
<wgrant> I've had a small amount of disk access while it has been otherwise apparently dead. So it's not a full kernel lock generally.
<Ng> it's almost lunchtime, I'll poke at it a bit then (since I need to lock while I go out anyway) and I'll file something if I can't find it
<Ng> hmm
<tjaalton> works here. nothing in the xserver log or dmesg
<tjaalton> its probably in the intel drm code
<tjaalton> .26 is equally broken
<Ng> I'm gonna try setting my screensaver to something other than blank screen and turn off all the display sleeping stuff
<wgrant> Do people know about the Synaptics... issues?
<tjaalton> wgrant: what issues? I don't have one
<wgrant> tjaalton: Since upgrading about 10 hours ago, I can't click.
<wgrant> And the vertical scrolling region is very thing.
<wgrant> And the touchpad tab is gone from the Mouse capplet.
<wgrant> (probably because the XInput device name is different)
<wgrant> s/thing/thin/
<wgrant> And I can click fine with the physical buttons, but not by tapping.
<tjaalton> you had SHMConfig in xorg.conf?
<wgrant> I didn't.
<tjaalton> the driver has apparently changed some defaults
<tseliot> tjaalton: did you see my message about the drivers?
<tjaalton> tseliot: yes, downloaded
<tjaalton> I'm at a seminar though :)
<wgrant> It seems to be a "SynPS/2 Synaptics TouchPad" rather than "Synaptics Touchpad" now.
<wgrant> The latter is hardcoded into g-s-d.
<tseliot> tjaalton: ah, ok, I just wanted to be sure. No hurry
<tjaalton> wgrant: what settings did the capplet allow you to change
<tjaalton> ?
<wgrant> tjaalton: Turning on and off (touchpad, tapping, horizontal scrolling, vertical scrolling).
<tjaalton> you can do that with xinput
<wgrant> I tried to work out how.
<tjaalton> the driver (and xserver etc) now support input properties
<wgrant> Oh.
<wgrant> It's not in the manpage.
<wgrant> But I see it on the command line.
<tseliot> wgrant: I have the same problem: https://bugs.launchpad.net/bugs/262292
<ubottu> Launchpad bug 262292 in xfree86-driver-synaptics "[intrepid] clicking is not working after merging" [High,Confirmed] 
<tseliot> wgrant: the fact that 2 touchpads show up depends on the fact that one is hardcoded in the xorg.conf
<wgrant> tseliot: I've been subscribed since I noticed it.
<wgrant> tseliot: Yep, I noticed that after I removed my xorg.conf earlier.
<tseliot> oh, right
<wgrant> tjaalton: How do I know which properties I can use?
<tseliot> wgrant: xinput list-props <device> ?
<wgrant> I get just one.
<wgrant> 	Device Enabled:		1
<wgrant> And I can set anything I want.
 * wgrant checks the driver source.
<wgrant> I also have some very strange graphical glitches with -intel on login and when new windows are created.
<tseliot> wgrant: does the screen flicker?
<tseliot> it does in my case with 2.4.1
<tseliot> jcristau: did you say that you found what is causing the problem ^ ?
<tjaalton> wgrant: it should work like that
<wgrant> tseliot: It gets strange lines flashing up, and sometimes looks uninitialised for a fraction of a second.
<tjaalton> wgrant: the props
<wgrant> tjaalton: Yes, but brute-force isn't an effective way of working out what to set.
<tjaalton> I mean there should be more props listed
<tjaalton> my evdev is too old to test it with my mouse
<wgrant> Am I looking for something like "MaxTapTime" or "Synaptics Tap Time"? I see too many different names.
<Ng> ok, lunchtime, I'm going to lock the screen and see what happens! ;)
<wgrant> "Connection reset by peer"
<Ng> tjaalton: sooo, X immediately crashed when my screensaver activated ;)
<Ng> I suspended from gdm when it restarted, and it then refused to resume
<Ng> but I don't see anything in the Xorg.0.log.old, it says something about suspending AIGLX for a vt switch, but there's no information about a crash
<wgrant> Aha.
<wgrant> tjaalton: I applied the latest rev from upstream git, and I can now click.
<wgrant> The scrolling region is still smaller, but at least it's mostly functional.
<wgrant> Setting those through xinput didn't do any good - I can't get any effect with it.
<wgrant> Oh, so it was deliberately turned off. I see.
<wgrant> http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=fb98432436c5e1cc69b5f4b84f625e3700e51e04, which was reverted in http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=3d39926875446ef80dc7c23e1e90ce776c911f13.
<Ng> tjaalton: filed it as bug 262605
<ubottu> Launchpad bug 262605 in xserver-xorg-video-intel "[intrepid] X locks up or crashes when screensaver activates" [Undecided,New] https://launchpad.net/bugs/262605
<Ng> I put it against -intel, but that's a guess ;)
 * Ng puts screensaver and power settings back to normal.
<Ng> time to see if the machine really does stay alive with ssh, from my iphone ;)
<Ng> tjaalton: yep, the machine is still alive. I was able to kill -9 X and restart gdm and log back in
<tjaalton> Ng: that's not the same I'm seeing
<tjaalton> killing X doesn't bring the screen back
<Ng> it wouldn't die from SIGTERM, but SIGKILL seemed to do the trick. It didn't actually come back to life until I restarted gdm though
<Ng> which is a bit weird, but this whole thing is weird
<Ng> and I noticed I get an oops on boot relating to IRQs
<Ng> which can't possibly be a good thing ;)
<Ng> tjaalton: I noticed something weird just now, I locked the screen on a typical "I'm walking away from my desk" reflex, then logged in and kill -9'd X, gdm came back of its own volition this time, I rebooted at gdm and instead of usplash I got a purple mess, hit ctrl-alt-f1 and instead of being a regular console I had some kind of higher resolution framebuffer thing going on
<Ng> I dunno if that's a side effect of the modesetting jazz, or if something is trying to make me use a framebuffer console I don't want
<Ng> I notice the boot messages are trying to run v86d for fb stuff
<Ng> tjaalton: do you see bug 262600 too?
<ubottu> Launchpad bug 262600 in linux "[intrepid] OOPS while booting 2.6.27 on Thinkpad X300" [Undecided,New] https://launchpad.net/bugs/262600
<Ng> bleh, installing v86d just causes X to stop working
<Ng> tjaalton: I disabled compiz and I can lock my screen now ;)
<Ng> security > bling :)
<kees> also, battery life > bling.  :)
<bryce> tseliot: I've done the paperwork to get x-kit and screen-resolution-extra into main - #262775, #262778
<tseliot> bryce: great, thanks a lot :-)
<bryce> you might take a quick look at them and make sure I didn't list anything incorrectly
<bryce> also, if you want to put out a new release with that time.time() bugfix, I can upload that today
<tseliot> bryce: yes, please. The new release is in my bzr branch
 * tseliot has a look at the 2 reports
<bryce> thanks uploaded
<tseliot> bryce: in both reports: Packaging system (debhelper/cdbs/dbs) ? cdbs
<bryce> tseliot: ahh, ok please update
<tseliot> bryce: ok, done
<bryce> patched gnome-control-center is uploaded
<bryce> tseliot: once the packages enter main, then I'll put a Recommends on it
<bryce> but at least now if people manually install screen-resolution-settings they can test it
<tjaalton> tseliot: umm, you've changed the 173 tarball?
<tseliot> tjaalton: yes, because I had to add a patch
<tseliot> and that broke the orig tarball
<tseliot> since patches are in debian.binary
<tjaalton> tseliot: somehow I got two tarballs, same name, different size
<tseliot> tjaalton: one has a -1 added to the version
<tseliot> otherwise debuild would have complained about a missing orig tarball
<tjaalton> you can add stuff outside debian/
<tjaalton> no need for a new tarball
<tjaalton> or am I missing something?-)
<tseliot> tjaalton: debuild complained about not being able to represent the changes or something like that
<tjaalton> ok, the other tarball was because of wget failing to finish the download
<tjaalton> uploaded
<bryce> yesterday I'd taken the goal of just upstreaming one -ati bug, but unfortunately hardly any of the remaining -ati bugs are ready to upstream.  So I ended up triaging through almost the full list.  Knocked out quite a few invalid/fixed/misfiled though
<bryce> http://people.ubuntu.com/~brian/complete-graphs/xserver-xorg-video-ati/plots/xserver-xorg-video-ati-halfyear-open.png
<tjaalton> heh, that's impressive
<tjaalton> just like it should be
<bryce> I think we can easily achieve <100 by Intrepid release
<tseliot> tjaalton: ok, thanks
<bryce> I noticed tormod had asked for info on 8/8 for a bunch, so on 9/8 whichever ones received no response can be expired
<bryce> similarly, bdmurray did a request for testing against intrepid on 8/14, so unanswered ones can be expired 9/14 
<bryce> I've been upstreaming a bunch, so I'll go through those and pull in fixes so we can close as many of those as possible
<bryce> tjaalton: btw there's been a purge request on xserver-xgl to remove it from universe
<tjaalton> bryce: woohoo \o/
<bryce> :-)
<tjaalton> Ng: btw, try the older intel driver if it crashes too
<Ng> tjaalton: ok, right after I figure out why 2.6.27 has killed my ethernet port ;)
<tjaalton> heh
<bryce> tjaalton: is read-edid not available for amd64?  (bug #242043)
<ubottu> Launchpad bug 242043 in read-edid "read-edid not availabe for amd64" [Undecided,New] https://launchpad.net/bugs/242043
<bryce> (doesn't seem to be installable on my amd64 so I'm going to confirm it)
<tjaalton> so it seems.. last change 2.5y ago
<bryce> pitty, oh well
<tjaalton> and the one before that in 2002
<tjaalton> when there was no amd64..
<tjaalton> Currently, get-edid builds against a customized lrmi (Linux Real Mode Interface - homepage), and thus can only be used on x86 systems (not even 64-bit). 
<tjaalton> http://www.polypux.org/projects/read-edid/
<tjaalton> heh, a new version was released on 25th, but still doesn't build on !x86
<bryce> I like read-edid a lot.  I wish it were more actively maintained.
<bryce> hmm, 1.4.2 doesn't have any significant improvements.  Basically just changing maintainer, adding an exit code on failure, and a lot of autoconf fussing
<bryce> so not really worth merging
<bryce> bdmurray: btw, tormod and I de-blacklisted compiz for ATI-gfx laptops
<bryce> bdmurray: in Hardy and up until now, compiz would refuse to work if you had a laptop with an ATI graphics card
<bryce> due mainly to a lot of bugs in the -ati driver
<bryce> bdmurray: anyway, we expect that for *most* cards this change will be fine; people can switch compiz back on, happiness.
<bryce> bdmurray: however note that there are probably some remaining bugs, and we may start seeing a pickup of bugs about compiz + ATI laptops, so keep an eye out for them
#ubuntu-x 2008-08-30
<wgrant> tjaalton: Are input-device properties meant to actually work on Intrepid? I can see that you've patched xinput and libxi to support them, but xinput can't seem to talk properly.
<wgrant> (upstream xinput seems to want XI2 support to do anything with input properties... does the server only return them if it detects that the client knows about XI2?)
<tjaalton> wgrant: it should work, the properties stuff has been backported to XI 1.5
<tjaalton> but I have to double-check it when I have more bandwith
<tjaalton> our evdev doesn't support it yet, that's known
<wgrant> Ah.
<wgrant> And I guess that somebody will need to teach Synaptics about it.
<wgrant> I can see a 'Device Enabled' property, and that's all.
<tjaalton> it should support it as well
<wgrant> Which doesn't appear in any of the listings that I've seen on the web.
<tjaalton> I'll try my experimental evdev driver to make sure the plumbing is ok
<tjaalton> yeah, evdev works so the synaptics driver is botched somehow
<tjaalton> gone ->
<wgrant> See you.
<wgrant> Thanks.
<tjaalton> wgrant: you could try patching out "#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 3", then it should work
<tjaalton> from src/properties.c
<tjaalton> wgrant: don't bother, I'll upload a new version
<wgrant> tjaalton: Boom.
<wgrant> tjaalton: dlopen: /usr/lib/xorg/modules/input//synaptics_drv.so: undefined symbol: SetProperty
<tjaalton> great
<wgrant> Indeed.
<wgrant> So it does really need the new XI?
<wgrant> Or is just getting confused?
<tjaalton> I think it's the latter
<tjaalton> anway, I'll revert the patch for now
<tjaalton> that's what you get without hardware to test on
<tjaalton> although, in this case loading the driver would've been enough
<wgrant> I'll poke at it a bit and try to get it working.
<tjaalton> for evdev to make it work with XI 1.5 the only thing it needed was to rip off the #ifdef's
<wgrant> Brb, restarting with a hopefully-fixed driver.
<tjaalton> and Bool SetProperty is defined in synaptics.c, that's why I think it's a problem with the driver code
<wgrant> It's defined in properties.c, actually.
<wgrant> Which probably wasn't being linked in.
<Q-FUNK> ok, got around upgrading my development Geode workstation to Intrepid and I confirm:  odd artifacts where the cursor is, using -geode on X 1.5
<wgrant> tjaalton: Right, got it.
<wgrant> properties.o wasn't being linked in.
<wgrant> Which probably means that src/Makefile.in wasn't being regenerated.
<tjaalton> wgrant: yeah I saw the same..
<tjaalton> I'll fix the package, again, shortly
<wgrant> tjaalton: Running automake fixes it, and produces just a tiny diff.
<wgrant> And it works excellently.
<wgrant> Thanks.
<tjaalton> wgrant: excellent :)
<tjaalton> dinner->
<wgrant> tjaalton: You wouldn't be able to upload the fix for bug #262292 as well, would you?
<ubottu> Launchpad bug 262292 in xfree86-driver-synaptics "[intrepid] clicking is not working after merging" [High,Triaged] https://launchpad.net/bugs/262292
<tjaalton> wgrant: yep
<wgrant> tjaalton: It is fixable through xinput now, but it's still annoying.
<tjaalton> yes, it's been reverted upstream too
<wgrant> And it for some reason won't let me set the necessary property to have the right number of items.
<wgrant> What odd behaviour.
<wgrant> I'm trying to override the tap actions through xinput, but it will only accept 6 arguments for that property, when it needs (and has initially) 7. If I give it a different name, it will accept 7 fine.
<wgrant> Is that likely to be a driver or server bug?
<tjaalton> I'm not sure, there are some limitations to the settings that can be changed atm
<wgrant> I can change it fine, just not to the right length.
<wgrant> No error is given, but it doesn't take effect, and watch-props doesn't see it.
<tjaalton> maybe a driver bug
<wgrant> Ah.
<wgrant> It seems that anything that wants more than one will accept only one less than it should actually take.
 * wgrant pokes in the code.
<tjaalton> jcristau: does autoreconf generate config.h.in?
<jcristau> yeah, autoheader does, iirc
<tjaalton> I'll autoreconfify synaptics, and noticed that the file is changed
 * wgrant deletes lots of =
<wgrant> tjaalton: I've located and am fixing the off-by-one property issue, so xinput will be useful on it shortly.
<wgrant> Will you accept such a patch?
<tjaalton> wgrant: excellent
<tjaalton> sure, if it works properly after that. You should also send it to xorg@ :)
<wgrant> Of course, I shall.
<wgrant> Testing now.
<wgrant> Neeeed mooore baaandwidth.
<tjaalton> I've got maybe 5kt/s
<wgrant> I've 64Kbps for another day or two.
<wgrant> kt?
<tjaalton> oops
<tjaalton> KB/s
<wgrant> Ow.
<tjaalton> GPRS ftw
<wgrant> Sounds expensive.
<wgrant> But I guess you're not in .au.
<tjaalton> nah, maybe 10EUR /month
<tjaalton> 3G (~128Kbps) where there is coverage
<tjaalton> built-in adapter in the laptop :P
<wgrant> 1.5c/KB on some of the more common plans here.
<wgrant> For both 3G and GPRS.
<tjaalton> uh
<wgrant> It would go down a bit if you were to get a few hundred megabytes. But it's still very expensive.
<wgrant> OK, now I've tested this trivial patch, and it works well.
<tjaalton> cool, post it somewhere
<wgrant> You need to delete a total of two characters.
<wgrant> Line 458, line 470. >= should be just >.
<wgrant> (src/properties.c)
<tjaalton> if (prop->size >= MAX_CLICK and MAX_TAP?
<wgrant> Yep.
<tjaalton> ok, the driver built fine, uploading
<tjaalton> three uploads in one day
<wgrant> Thanks!
<tjaalton> which is nice, Top10 here I come :)
<wgrant> Heh.
<tjaalton> so, send the patch to xorg@lists.freedesktop.org
<wgrant> Any particular format/subject?
<wgrant> I guess I'll check the archives.
<tjaalton> I don't think it matters much
<jcristau> 'git format-patch origin/master; git send-email' works
<jcristau> i think xorg@ is subscriber-only though
 * wgrant is rejected, so subscribes.
 * wgrant -> bed
<wgrant> Thanks for the uploads today, tjaalton.
<tjaalton> wgrant: thanks for testing, and patches :)
#ubuntu-x 2008-08-31
<wgrant> Well, that was remarkably painless.
<tjaalton> tseliot: hi, do you have an idea why my box didn't build the nvidia module for .27-2 kernel?
<tjaalton> on upgrade
<tseliot> tjaalton: no, I don't. It happened to me too.
<tjaalton> ah:)
<tseliot> having a log would help
<tseliot> s/would/might/
<tjaalton> it was a "partial upgrade" so nothing in term.log
<tseliot> usually DKMS checks the availability of the module at boot too
<tseliot> therefore if the module hadn't been built before it should have tried to build it at boot time
<tseliot> a bug in DKMS?
<tseliot> I'll ask superm1
<tjaalton> or maybe the kernel lacks something?
<tjaalton> packaging
<tseliot> tjaalton: all dkms needs is the headers and the compilers. Let's see if we can reproduce the problem, maybe with .27-3
 * tseliot > bbl
<BacuX> jajajajaja
<BacuX> che groxy culey
<BacuX> @roulette
<james_w> tseliot: https://launchpad.net/bugs/262027 <- could that be the reason that nvidia didn't build the updated modules?
<ubottu> Launchpad bug 262027 in synaptic "Synaptic Erroneously Reports Success on Fail" [Undecided,New] 
<tseliot> james_w: yes, it can be that
<james_w> I'm just talking to the user now, he's going to reassign the bug, as I don't think it's a bug in synaptic
<tseliot> james_w: right
<tormo1> I have a hang here, maybe with compiz. I can ssh in and there's no CPU usage. Is it normal that compiz sits in finishScreenDrawing() ?
 * tormo1 asks in #compiz also
<james_w> tseliot: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-control-center/+bug/260350 <- is that due to "Virtual" not being set?
<ubottu> Launchpad bug 260350 in gnome-control-center "Intrepid Cannot change resolution on laptop with Intel gfx adapter" [Undecided,New] 
<james_w> sorry, I leave you in peace after this one.
<tseliot> james_w: no problem ;)
<tseliot> yes, setting the virtual resolution would be the solution
<james_w> thanks, I'll mention that.
<james_w> the current Intrepid packages will tell the user that?
<james_w> and optionally do it if screen-resolution-extra is installed?
<tseliot> james_w: no package will warn the user that he needs to set virtual to 2674x1080
<tseliot> screen-resolution-extra will do it for him/her after warning him/her
<james_w> great, thanks
<tseliot> you're welcome
<james_w> I don't really know what to say to https://bugs.launchpad.net/bugs/260069 so if someone here has an opinion I would appreciate it if you could add something to the report.
<ubottu> Launchpad bug 260069 in gnome-control-center "gnome-display-properties does not display EDID info" [Undecided,New] 
<tseliot> james_w: it looks like something we should mark as wishlist
<james_w> yeah, I agree, but I had no idea if it was something that's a good idea or a bad one
<tseliot> that might be needed in some cases and nvidia-settings does it already. It's doable and can be useful. I would like to hear bryce's opinion on this though
<tseliot> good night
 * tseliot > bed
#ubuntu-x 2009-08-24
<Laney> Greetings!
<Laney> Who is to blame if g-a-p says that I can't have compiz but I actually can?
<hyperair> Laney: afaik g-a-p tries to run the compiz script, and if it doesn't work, it says you can't have it =\
<hyperair> try running the compiz script? maybe you got a blacklisted pci-id or something
<Laney> I see jockey, and then compiz attempts to start and then dies
<Laney> but compiz --replace works fine
<hyperair> eh?
<hyperair> did you manually install compiz or anything?
<hyperair> in all the ubuntu packages, compiz is a script that calls compiz.real --replace
<hyperair> plus a few other options
<Laney> no
<hyperair> try checking
<hyperair> otherwise debug the script, if it's crashing halfway
<Laney> metacity 4eva
<hyperair> lol
<Cyberkilla> Hello, is anybody there?
<Cyberkilla> Hello, does anyone here know anything about the nvidia drivers in  karmic a4?
<Cyberkilla> For some reason, 185.18.31, 185.18.36 and 190.x.x give me  artifacts, then system crashes (laptop resets itself).
<Cyberkilla> I had to revert to 185.18.14.
<Cyberkilla> It is an NVidia GeForce 8400M GT, inside of a Sony Vaio VGN-AR41E  laptop
<Cyberkilla>  Hello, is anybody there?
<Cyberkilla> 12:56 < Cyberkilla> Hello, does anyone here know anything about the nvidia drivers in   karmic a4?
<Cyberkilla> For some reason, 185.18.31, 185.18.36 and 190.x.x give me   artifacts, then system crashes (laptop resets itself).
<jcristau> you said that already.
<Cyberkilla> I had to revert to 185.18.14.
<Cyberkilla> It is an NVidia GeForce 8400M GT, inside of a Sony Vaio VGN-AR41E   laptop
<Cyberkilla> I know
<Cyberkilla> I didn't think anyone was listening
<jcristau> repeating the same thing 15 minutes later won't make people listen
<Cyberkilla> Aww
<Cyberkilla> I can't find anybody who knows about it. I was referred to this room, on the off-chance.
<Q-FUNK> https://bugs.launchpad.net/bugs/417518
<ubottu> Launchpad bug 417518 in xserver-xorg-video-geode "Sync xserver-xorg-video-geode 2.11.3-2 (main) from Debian unstable (main)." [Wishlist,Confirmed]
<Cyberkilla> hmm
<mac_v> hi... could someone instruct me how to set the kernel setting mentioned in comment #7 https://bugs.freedesktop.org/show_bug.cgi?id=23386 ? do i just have to add> radeon.modeset=1 at the end of the line or do i have to also add the i915.modeset=1 mentioned in the X wiki?
<ubottu> Freedesktop bug 23386 in Driver/Radeon "Artifacts with cairo dock 2.0 [openGL]" [Normal,New]
<mac_v> i tried with just radeon.modeset=1 and noticed that my system became very , i mean horribly sluggish
<Q-FUNK> could someone ACK this sync?
<tjaalton> mac_v: no, i915 refers to the intel driver. modesetting makes radeon slow, it's being worked on upstream
<mac_v> tjaalton: ah , ok... thanx :)
<tjaalton> Q-FUNK: just subscribe ubuntu-archive to the bug
<Q-FUNK> ok
<tjaalton> Cyberkilla: use nvidia-bug-report.sh to file it upstream, not much we can do about it
<Cyberkilla> hmm
<Cyberkilla> When would I do this? Presumably whilst in the midst of the chaos.
<Cyberkilla> I'd have to install the crazy drivers again.
<Cyberkilla> I'll see what I can do.
<tjaalton> or use the nvidia forums
<Cyberkilla> So, nobody has complained of this yet?
<tjaalton> not here anyway
<Cyberkilla> Someone said it might be a missing dependency in the package.
<tjaalton> check if you have nvidia-glx-185 installed
<Cyberkilla> Not a missing on on my system, but something odd with the way they made the packages. But, I don't see why it would only affect me in that case.
<Cyberkilla> I do. Or rather, I did have everything installed.
<tjaalton> regressions in that driver are not unheard of...
<Cyberkilla> I've had to go back to 185.18.14
<Cyberkilla> The sad thing is, it affects me in every new driver I've tested: 185.18.31, 185.18.36 ("stable") and one of the 190.x.x packages.
<mac_v> tjaalton: do you happen to have the bug# for the upstream radeon issue?
<tjaalton> no
<mac_v> tjaalton: thanx :)
<mac_v> after installing from xorg-edgers ppa , do i have to run "dpkg-reconfigure" ?
<jcristau> no
<mac_v> jcristau: thanx :)
<tjaalton> that command is irrelevant in karmic
<MTeck> How can I see what display driver I'm using?
<mzz> MTeck: I'd normally look at /var/log/Xorg.0.log, but it might depend on why you want to know
<MTeck> mzz: just what package is being used
<mzz> MTeck: I'd look at /var/log/Xorg.0.log to find the file name of the driver used, then use dlocate or something to find the corresponding package name
<mzz> I'm an ubuntu newbie, the dlocate half of this may be suboptimal
<jcristau> should be pretty much xserver-xorg-video-${name_of_driver}
<mzz> and yes, I'd expect that to be true, but I didn't want to say so in case there's some exception.
<MTeck> jcristau: that's why I was trying to figure out what driver(s) I'm using
<jcristau> easiest is probably 'grep _drv /var/log/Xorg.0.log'
<MTeck> hrm - I'm not even using -fbdev - I thought that was pretty mcuh always needed
<MTeck> thanks
<MTeck> http://pastebin.ubuntu.com/258950/
<jcristau> right, so intel.
<MTeck> little grep line was nice and easy :)
#ubuntu-x 2009-08-25
<Q-FUNK> re
#ubuntu-x 2009-08-26
<kazade> hi all, this bug: https://bugs.edge.launchpad.net/ubuntu/+source/gdm/+bug/419126 has cropped up in Karmic after recent updates, and my spidey sense says it's to do with recent DRM updates rather than GDM... anyone have any ideas?
<ubottu> Launchpad bug 419126 in gdm "gdm loops after logging in" [Undecided,New]
<bryce_> kazade, yeah sounds like an X crash due to the new mesa git snapshot
<kazade> heh, well at least I know not to run my updates tonight ;)
<kazade> bryce, you there?
<bryce> yes
<kazade> just wanted to apologise for not reporting that ATI bug sooner. I figured it was something I'd done. It was only when I saw the other reports that I realized it wasn't just me
<kazade> normally I would have reported it
<bryce> kazade, no prob.  yeah I know how much reporting bugs can be a pita
<kazade> I'm kicking myself now :(
<kazade> You know when something happens, and you just think, "oh that was weird" and then carry on and forget about it :/
<kazade> have you had any luck tracking down the cause?
<bryce> kazade, haven't really looked yet, but we're about a week behind upstream's latest so perhaps it's already fixed there
<kazade> ah ok
<bryce> kazade, I see xorg-edgers now has a newer version you could test if you want
<kazade> bryce, someone in the bug report tried xorg-edgers less than an hour ago, he said it made no difference
<bryce> ok
#ubuntu-x 2009-08-27
<directhex> okay then. evdev_drv.
<directhex> for whatever reason, an unmolested xorg is deciding that this mouse is a simple 5-button (i.e. left right plus clickwheel) mouse. this is wrong. i know i've had it right in the past, with mangled xorg
<directhex> question is, why's it wrong and what can i do about it?
<jcristau> what does /proc/bus/input/devices say about that mouse?
<jcristau> also evtest on that device (/dev/input/eventX)
<directhex> jcristau, http://paste.debian.net/45132/
<directhex> jcristau, i need to kill X for evtest don't i
<jcristau> shouldn't be necessary these days
<directhex> the evtest command certainly lists more buttons than xev is responding to
<directhex>     Event code 275 (SideBtn)
<directhex>     Event code 6 (HWheel)
<directhex> and so on
<jcristau> except for synaptics devices, but even then vt switching should be sufficient
<directhex> http://paste.debian.net/45133/
<jcristau> what version of evdev is this btw?
<directhex> jcristau, whatever ships in jaunty
<directhex> jcristau, and i think i see where it's going wrong... the mouse device (event6) is not actually registering anything at all. the mouseemu device (event5) is - but it lacks buttons
<directhex> i have no idea what or why mouseemu is
<directhex> wait, that was it... purging the mouseemu package
<directhex> so why on earth was that installed, and why does it break multi-button support?
<tjaalton> because you installed it? nothing depends on it
<tjaalton> make that "no package"
<directhex> i definitely didn't explicitly install it
<directhex> /var/log/installer/syslog:Aug 25 16:11:49 ubuntu ubiquity: Setting up mouseemu (0.16-0ubuntu3) ...
<directhex> officially not my fault
<tjaalton> it's a laptop?
<directhex> no, it's not - but it might have been misdetected as such?
<tjaalton> could be
<directhex> jms@osc-bigmac:~$ laptop-detect -v
<directhex> We're not on a laptop (no relevant hint found)
<directhex> d-i/source/hw-detect/hw-detect.sh:# Install mouseemu on systems likely to have single-button mice
<directhex> .....
<tjaalton> heh
<directhex> what a naive check
<tjaalton> so file a bug against hw-detect
<jcristau> it's stupid that installing that package breaks a real mouse though..
<tjaalton> it is
<directhex> it seems the package's priority is to add buttons to a 1-button mouse. i doubt they tested it in a 9-button scenario
<directhex> tjaalton, in your opinion, better to file a bug against hw-detect regarding installing mouseemu inappropriately, or against mouseemu for breaking multi-button mice?
<ScottK> directhex: I vote for both.
<directhex> ScottK, ja wol!
<directhex> Bug #419935 filed
<ubottu> Launchpad bug 419935 in hw-detect "hw-detect wants to install mouseemu on Mac when it really shouldn't" [Undecided,New] https://launchpad.net/bugs/419935
<tjaalton> yeah, that works
<bryce> morning
<jg> afternoon bryce 
<bryce> jg, hello
<jg> bryce: I see you inflicted new bits on me this afternoon...
<jg> bryce: so far, so good...
<jg> bryce: I thought glxgears was supposed to end up getting throttled to VR...
<jbarnes> it'll go faster if it can render frames faster than refresh
<jbarnes> but it shouldn't tear
<jg> jbarnes: ah, thanks.
<jg> jbarnes: I see no tearing.
<LLStarks> hey bryce. does shutterworth's word overrule a 'denied for karmic'?
<bryce> LLStarks, eh?
<LLStarks> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/377090/comments/24
<ubottu> Launchpad bug 377090 in mesa "[i945gm] (Needs kernel 2.6.31) DRI2 swapbuffers" [Wishlist,In progress]
<LLStarks> from mark with love.
<bryce> jeeze
<bryce> jbarnes, hey, where are we at with the dri2 swapbuffer stuff?
<jbarnes> bryce: just updated that bug :)
<jbarnes> LLStarks pointed me at it
<bryce> jbarnes, how mature is the stuff?  Is it currently pretty stable or would it destabilize things a lot if we merged it right now?
<jbarnes> I wouldn't recommend it for karmic
<jbarnes> bryce: it would be good to have in edgers though
<jbarnes> but I'd just wait until it lands
<jbarnes> shouldn't be long now before those branches are merged into master of the various repos
<LLStarks> if i was to use the bits that are already implemented and then supplement the dri2 branches from proto and xserver, would that be sufficient for a testing enviroment?
<jbarnes> yeah that should be enough
#ubuntu-x 2009-08-28
<LLStarks> bryce, the bug component statuses should be updated.
<bryce> LLStarks, go ahead
<LLStarks> incomplete?
<bryce> LLStarks, yeah the bug is sort of a mess
<bryce> LLStarks, to be honest it seems not too useful to have a bug open for a development branch still in work upstream
<LLStarks> well, i had been under the impression that most of the branch merges indicated component readiness
<LLStarks> at any rate, i think the bug is necessary considering how huge the implementation is.
<LLStarks> it requires the tracking of multiple code trees
<LLStarks> and i'm sure mark would like to track this for lucky lemur.
<bryce> I disagree, I think using bugs to track upstream code branches gives little value
<bryce> but whatever
<bryce> for the first time in as long as I can remember, we presently have fewer -intel bug reports than -nvidia
<superm1> bryce, did you see what i uploaded for that -nvidia problem?  i think it should take care of it..
<bryce> superm1, yup sure did, thanks for that :-)
<superm1> and my you're up late
<superm1> (although i should speak for myself)
<bryce> I'm getting a new -ati upload ready.  I've tested it out and it seems pretty solid so far
<MindVirus1> Hello. I'm running Karmic right now on an Intel 945GME. Could someone help me get direct rendering?
<MindVirus1> "direct rendering: No (LIBGL_ALWAYS_INDIRECT set)" is what  Iget.
<MindVirus1> *I get.
<jcristau> don't set LIBGL_ALWAYS_INDIRECT.
<MindVirus1> I didn't set it.
<estan> hey folks. is the 2.6.30 kernel from karmic copied to the x-updates repo in the same way that it is for the edgers repo?
<estan> i mean for jaunty.
<estan> seems not.
 * estan installs 2.6.30.3 debs instead.
<tjaalton> karmic has .31
<Duke`> is Sarvatt on hollidays?
<bryce> Duke, I've not seen him in a long time
<kazade> bryce, you know that GDM looping bug on R600? Alex Deutchers's R600 3D patch alone fixes the issue, I've updated the bug report. Obviously I don't know which part of the patch fixes it though...it's a big patch
<kazade> s/Deutcher/Deucher :)
#ubuntu-x 2009-08-29
<LLStarks> bryce, i think the new intel 2.8.1 driver broke x for every edgers/testers user on intel hardware
<LLStarks> it superseded the 2.8.0 git
<LLStarks> and i can't reach sarvatt
<bryce> broke X in what way?
<LLStarks> can't boot x at all
<LLStarks> that is, the intel module won't load
<LLStarks> i don't remember the exact message
<bryce> where are you seeing "every edgers user"?  is there a bug id# for this?
<bryce> 419126?
<LLStarks> if i can't boot x with the stable intel driver in a ppa environment, others will probably be the same.
<LLStarks> and no, i don't think bug 419126 applies
<ubottu> Launchpad bug 419126 in xserver-xorg-video-ati "X fails to start up after mesa+git update - gdm loops after logging in" [High,Confirmed] https://launchpad.net/bugs/419126
<LLStarks> the problem was definitely the intel driver since i could boot x after downgrading to the ppa
<bryce> LLStarks, tormod posted a new 2.8.1 based snapshot, try again.
<LLStarks> lemme try
<tormod> good to see it come to use that quickly :) it's from trunk not from 2.8.1 if that is unclear
<bryce> tormod, seems 2.8.1 caused xorg-edgers users to update to the version on karmic, without updating their mesa/libdrm I guess, which I suppose causes an inconsistency of some sort
<bryce> tormod, btw I'm preparing to update our -ati
<bryce> tormod, the version I'm going to be updating to is sitting in my personal ppa currently
<LLStarks> tormod, can i mix that driver you uploaded with xorg 7.5?
<LLStarks> bryce, i've been using sarvatt's xorg-testing ppa
<tormod> so they got mesa/libdrm from xorg-edgers and -intel from karmic?
<LLStarks> with the super xorg crack.
<bryce> tormod, I believe so.  "they" == LLStarks btw
<LLStarks> well, my logs suggested a conflict
<LLStarks> drm was probably too new
<tormod> LLStarks, you can pick the same git version form xorg-edgers or card-drivers
<tormod> sorry no new intel in card-drivers
<tormod> LLStarks, oh I see xorg-testing... you probably need the -ntel rebuilt there
<LLStarks> yeah, i'm test the new xserver
<LLStarks> sarvatt said the abi was different
<tormod> yeah make sure you get all your stuff from there, mixing will be bad
<LLStarks> lemme try restarting x
<tormod> bryce, ati fc74e119 ?
<tormod> based on xorg-edgers? I just superseded it now btw.
<tormod> there are lots of commits these days, in -ati  and mesa :)
<tormod> glxgears is broken atm ...
<tormod> on my card at least
<bryce> tormod, yes based on your xorg-edgers package
<bryce> tormod, I don't mind lagging xorg-edgers a bit, since presumably whatever was in xorg-edgers has had some bugs shaken out
<bryce> gives some room for cherrypicking
<tormod> bryce, absolutely, right now xorg-edgers is a bit broken for r400 cards...
<tormod> the old fc74e119 seems to be fine here at least
<tormod> btw do you know about when Brian thinks to branch mesa 7.6?
<tormod> since we have a trunk snapshot in karmic now...
<bryce> nope I sure don't
<bryce> guess we could ask him... maybe if it isn't branched by next week I could drop him an email
<bryce> tormod, btw I put in for a FFe for all this stuff and got it approved today
<bryce> ref. bug 420803
<ubottu> Launchpad bug 420803 in xserver-xorg-video-ati "FFe for updating -ati/mesa/libdrm git snapshots until their individual releases" [Wishlist,Confirmed] https://launchpad.net/bugs/420803
<tormod> bryce, sounds good. there is a lot of activity now, optimizations and fixes, when things calm down this gonna be pretty good
<bryce> agreed, I'm looking forward to it
<bryce> currently I'm preparing a mass emailing for bug reporters to test this -ati and see which of our bugs can be closed with it :-)
<bryce> maybe we can get -ati down from the #1 most bug reports slot
<tormod> thanks for the bug link - you mention libdrm 2.4.13 - I missed it because cgit is broken
<tormod> but it's too late for to look at it now - good night
<bryce> night
<tormod> oh actually I'll just cherry pick the one commit I am missing. TGIF
<bryce> tormod, btw note that in -ati debian disabled the patch system so I'm not sure your patch 199 is getting turned on
<cdE|Woozy> X just froze after resume on karmic :/ (gm45) http://pastebin.ubuntu.com/261407/
<cdE|Woozy> filed bug #421032, if anyone is interested
<ubottu> Launchpad bug 421032 in xserver-xorg-video-intel "[GM45] task xorg/i915 blocked after resume" [Undecided,New] https://launchpad.net/bugs/421032
#ubuntu-x 2009-08-30
<Rocket2DMn> hey bryce , what package should i file the new bug against for a blank desktop on login
<Rocket2DMn> you think it goes against mesa or compiz?
<Rocket2DMn> its just the desktop that is blacked out, the gnome panels still show
<maco> hola, any change on https://lists.ubuntu.com/archives/ubuntu-x/2009-February/000412.html ?
<LLStarks> bryce, i'm experiencing debilitating hangs
<LLStarks> i want to rule out whether the graphics are involved
<bryce> Rocket2DMn, your video driver
#ubuntu-x 2010-08-30
<Sarvatt> hmm, shadow branch of xf86-video-intel seems to have more problems than just KMS+fbdev. glx and changing resolutions dont work on 945
<RAOF> Bah!  Plymouth killing X seems to have returned!
<RAOF> Hm.  How was clutter ever working?
<RAOF> Hey, is there someone here running stock Maverick mesa on an intel chip?  I'd like the (pastebinned) output of glxinfo.
<tjaalton> RAOF: I am, you'll get it in 30min after I get to work first
<tjaalton> RAOF: http://pastebin.com/9e3m7EcL
<vish> RAOF: 7.9 dint work either... and seems mutter is also failing/crashing X with the latest xorg not related to the mesa update , also with stock update
<vish> rather stock maverick xorg
<RAOF> vish: Hm, odd.
<RAOF> vish: Because mine is working just fine* (modulo stupid clutter bugs)
<vish> RAOF: yeah totally odd, previously when i started testing , mutter would work fine , now with the maverick stock mutter just crashes X
<RAOF> Got a backtrace?
<vish> i if i just do a mutter --replace , i get back to the gdm
<vish> yeah , i just downloaded the latest daily , gonna do it now :)
<RAOF> Note you'll probably want to attach gdb to X
<vish> k.. 
<vish> \
<ion> /
<jcristau> |
<ion> ââââââ
<vish> oopsie! :D
<vish_> RAOF: got the backtrace for the mutter crashing x: http://paste.ubuntu.com/485793/
<vish_> it happens consistently, all i  need to do it start mutter --replace and once mutter starts, try to focus on a different window
<RAOF> Hm.
<vish_> and bam! X crashes
<RAOF> What version of xserver-xorg-video-ati?
 * RAOF 's âdon't crash Xâ patches seem to have some unhandled edges.
<vish_> -ati is 1:6.13.1-1ubuntu4
<RAOF> Bah.
<vish_> i'll file a separate bug with that backtrace
<RAOF> Thanks.
<RAOF> You're probably hitting an edge case fixed in 6a2c8587
<vish_> hehe, yeah, i seem to gather a lot of X bugs ;p the benefitss of using ati \o/
<vish_> btw, bug 626743
<ubot4> Launchpad bug 626743 in xserver-xorg-video-ati (Ubuntu) "[RV515] Running Mutter causes X to crash (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/626743
<vish_> RAOF: ^ thats the bug ,attached the gdb too.. Thanks for looking into tis :)
<vish_> this*
<asac> Sarvatt: can you please use the maverick packaging with egl etc. to update mesa in xorg-edgers?
<asac> thanks!!!
<asac> we need this to figure if we need to do upstream fixes/code
<RAOF> asac: There's a 7.9 snapshot in sarvatt's PPA.
<RAOF> https://edge.launchpad.net/~sarvatt/+archive/mesa
<RAOF> If I can chase down the couple of regressions it's mostly what I'll be aiming for a FFe for.
<asac> RAOF: hmm. so the versioning in xorg-edgers is bogus? it has 7.9+
<asac> e.g. i cannot use the ppa where i copied it to ;)
<RAOF> Yeah, bogus versioning.
<RAOF> 7.9 hasn't been released yet.
<asac> sigh
<asac> so my ppa is unusable now
<asac> please update the mesa in xorg-edgers with all the packaging ;)
<RAOF> You could delete the 7.9+â¦ version from the PPA and wait a couple of hours before copying the 7.9
<asac> if thats too hard let me know and i can create one new
<asac> RAOF: that doesnt work
<asac> unless ppa learned that now
<RAOF> It doesn't?
<asac> no
<asac> deleting doesnt remove it from history
<asac> so you can never upload something lower ;)
<RAOF> I'll throw something into ppa:raof/mesa-egl
<asac> RAOF: cool!!
<RAOF> Oh, do you want it for maverick or lucid?
<RAOF> asac: should be in ppa:raof/mesa-egl now.
<RAOF> And with that, it's good night from me!
<Sarvatt> asac: thats why i havent updated mesa in edgers in almost a week, working out the packaging of all this new stuff and i've been more worried about the one that might go into maverick :) edgers is significantly different, uses llvm and enables lots of other things for testing like vmware
<Sarvatt> sorry about the versioning problem, I bumped it to a + by mistake when I was working out some automated scripts and its too big a deal convincing people to downgrade and not get stuck at the + version :)
<Sarvatt> things changed so much in mesa 7.9, i had to fork the packaging well before any of the egl stuff was introduced and was waiting until the final decisions were made for pulling 7.9 into maverick to rework it. sorry you used edgers on arm, if I had known I would have warned you about all of that :(
 * Sarvatt tries to figure out how to get piglit to ignore nv50_screen_get_param:192 - Unknown PIPE_CAP messages
<Sarvatt> oh that was surprisingly easy
<mvo> does anyone mind if I upload https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/614993/+attachment/1529476/+files/xorg-server_1.9.0-0ubuntu2.debdiff ? context is bug #614993
<ubot4> mvo: Bug 614993 on http://launchpad.net/bugs/614993 is private
<ubot4> Launchpad bug 614993 in xorg-server (Ubuntu) (and 1 other project) "10.04 -> 10.10 upgrade fails: pkgProblemResolver::Resolve generated breaks: Holding Back xserver-xorg-video-nouveau rather than change xorg-video-abi-8.0 (affects: 13) (dups: 8) (heat: 103)" [Critical,In progress]
<Sarvatt> mvo: oh hmm, thats supposed to be in Breaks: already, debian had the same problem
<Sarvatt> looks like its only there in unstable not experimental
<Sarvatt> http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=commit;h=9c8080d06c457932d3bfec021c69ac000aa60120
<mvo> Sarvatt: aha, great. I change it to a breaks and upload then ? 
<Sarvatt> sounds good!
<mvo> uploaded, thanks for the pointer
<Sarvatt> thanks mvo, i'll push it to git when ya do
<mvo> I adjusted it a bit, we don't need most of the diff from debian as we e.g. do not have -vga anymore and our -v4l seems to work with -video-8, but its universe now. anyway, the upload should fix the upgrade for us :)
<Sarvatt> yeah v4l is the important one, it was dropped from xserver-xorg-video-all so it probably doesn't try to upgrade it right away and holds back the new abi. apt ordering is such a headache :)
<vish> Sarvatt: can a single package be downgraded? like only xserver-xorg-video-ati  instead of the whole xserver?
<Sarvatt> whatcha mean?
<vish> not sure if the new mesa 7.9 from your ppa works , since latest xserver-xorg-video-ati cause problem
<Sarvatt> like you have edgers updated and want to downgrade ati  to the one in the archive?
<mvo> Sarvatt: apt ordering> yeah!
<vish> s
<vish> Sarvatt: actually Bug 626743 , probably prevents me from testing your ppa and mesa 7.9 , so i was wondering if i could downgrade  xserver-xorg-video-ati alone and test your ppa again..
<ubot4> Launchpad bug 626743 in xserver-xorg-video-ati (Ubuntu) "[RV515] Running Mutter causes X to crash (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/626743
<Sarvatt> vish: yeah nothing special there, ya probably have the old deb in /var/cache/apt/archives/ even
<Sarvatt> by my ppa do you mean the one with just mesa 7.9 in it?
<vish> yeah..
<vish> cool, just making sure if doing that would actually work.. before i bork something else ;)
<Sarvatt> yep it'll work
<Sarvatt> bryceh: this graph has gone nuts :) http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-maverick-workqueue.svg
<Sarvatt> wow, nouveau is in good shape - http://sarvatt.com/downloads/piglit/nouveau/
<bjsnider> according to someone over in the gnome-shell channel, the .52 blob fixes the performance issues with gnome-shell and nvidia
<bjsnider> that's a very small sample size, just one person, but that's something nvidia left out of the changelog
<Sarvatt> were they using gnome-shell via xephyr? because that would be in the changelog
<bjsnider> what does it say about that?
<Sarvatt>    - Fixed a bug that caused extremely slow rendering of OpenGL
<Sarvatt>      applications on X screens other than screen 0 when using a compositing
<Sarvatt>      manager.
<bjsnider> i doubt they're using screens other than 0
<bjsnider> it's possible that guy is though
<bjsnider> Sarvatt, have you got that packaged for lucid yet?
<Sarvatt> yep, looks like I forgot to patch that latest upload to lucid yesterday but i fixed it up about an hour ago, dont think it's built yet
<Sarvatt> amd64 is, i386 is in the middle of building now
<bjsnider> i don't think you need the 185 transitional packages since if they're using lucid they already had those packages in the main repo
<Sarvatt> crazy people - https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/626557
<ubot4> Launchpad bug 626557 in nvidia-graphics-drivers (Ubuntu) "package nvidia-current 195.36.24-0ubuntu1~10.04 failed to install/upgrade: trying to overwrite '/etc/OpenCL/vendors/nvidia.icd', which is also in package nvidia-glx-256 0:256.52-0ubuntu1~karmic~nvidiavdpauppa1 (affects: 1) (heat: 6)" [Undecided,New]
<Sarvatt> oh read that backwards, thought they were installing the karmic package on lucid :)
<bjsnider> that bug is because nvidia-current doesn't conflict with nvidia-glx-256
<bjsnider> they just need to ppa-purge. basically it's a support request
<tseliot> err... what's nvidia-glx-256 and where does it come from???
<Sarvatt> tseliot: in the middle of filing a FFe for nvidia-graphics-drivers 256.52, unless you already had one lined up?
<tseliot> Sarvatt: I don't think we'll need a FFE for that. If it's just bug fixes, it should be fine
<tseliot> either I'd like to discuss this with Nvidia first though (on Friday)
<Sarvatt> oh ok
<Sarvatt> glad I asked first :)
<tseliot> :-)
<Sarvatt> well I got one all written up and a clean package if we do end up needing it
<tseliot> Sarvatt: good, thanks for your work.
<vish> RAOF: in case you miss the bugmail, i downgraded and tried various versions, the problem was actually xserver-xorg-video-ati (1:6.13.1-1ubuntu3)  and CLUTTER_VBLANK=none helps mutter but not unity..
 * vish lets RAOF sleep ;)
<Sarvatt> ok mesa is going gallium only for r300 in the next update in edgers, think i'll replace swrast_dri.so with the llvmpipe enabled swrastg_dri.so as well. the rest will be shipped in /usr/lib/dri/gallium in dri-experimental so people can at least test manually adjusting paths
 * Sarvatt wonders if conflicts/replaces libgl1-mesa-dri-gallium is enough for libgl1-mesa-dri-experimental in edgers
<Sarvatt> ricotz: heads up that ia32-libs will be all kinds of screwed up now, I'm sorry about that :(
<Sarvatt> here is the new file layout - http://sarvatt.com/downloads/filelist_mesa_edgers.txt
<Sarvatt> I put a big notice detailing the changes on the main xorg-edgers/ppa page
<Sarvatt> RAOF: are you sure about nouveau-vieux being in dri-experimental? considering nvidia isn't planning on updating -96 to support xserver 1.9 it seems pretty important to have it easily available
<ricotz> Sarvatt, thanks for the heads up
<ricotz> Sarvatt, so is gallium disabled for nouveau even if the experimental package is installed?
<Sarvatt> nope, if you install libgl1-mesa-dri-experimental it's there
<Sarvatt> i was just fudging it and installing it in libgl1-mesa-dri before
<ricotz> ok, to the ordered search paths are still set?
<ricotz> to7so
<ricotz> ok
<Sarvatt> yeah everythings in /usr/lib/dri now except the few things that conflict with classic mesa naming (r600, i915, swrast gallium)
<Sarvatt> and those are all in /usr/lib/dri/gallium, no more --with-dri-searchpath crap
<Sarvatt> i dont fancy setting up diversions and replaces: will completely bust downgrades
<ricotz> alright, i will look at it
<Sarvatt> if libgl1-mesa-dri-experimental has replaces: libgl1-mesa-dri to overwrite the -dri ones and you remove libgl1-mesa-dri-experimental later it'll just delete all those drivers and not reinstall the -dri ones :(
<jcristau> Sarvatt: yeah so you need Breaks+Replaces
<jcristau> oh wait.
<jcristau> you want to provide the same files in both?  then you probably need conflicts.
<Sarvatt> i want to transition people using libgl1-mesa-dri-gallium over to libgl1-mesa-dri-experimental
<Sarvatt> think i saw a specific section about that situation in the policy manual, going to go over it again
<Sarvatt> argh, forgot mesa needs that latest libdrm commit now
<Sarvatt> intel bugs are getting out of control, someone just submitted 11 identical crash reports in a row that didn't auto dupe :)
<Sarvatt> oh he's still not done
<Sarvatt> RAOF: what was it in mesa that needed dpkg-dev (>= 1.15.6) again?
<Sarvatt> oh yeah, symbol patterns in dpkg-gensymbols.. ugh
<Sarvatt> and double fun, gettext in lucid is too old to just do a dpkg backport :)
#ubuntu-x 2010-08-31
<RAOF> Sarvatt: So, the question with nouveau_vieux is twofold: (1) Do we actually have the CD space to ship it by default, and (2) is it stable enough?
<RAOF> With bonus (3): do we really want to add this feature by default after beta :)
<alf__> Hi! Are there any experimental packages for Mesa 7.9 somewhere?
<vish> alf__: there is a mesa7.9 ppa from Sarvatt  , might be what you are looking for
<alf__> vish: Great, thanks!
<RAOF> alf__: There's also xorg-edgers if you don't care to follow what will (hopefully!) be in Maverick, or ppa:raof/mesa-egl.
<ari-tczew> Sarvatt, around?
<Sarvatt> tseliot: 256.52 got rereleased as 256.53 and marked stable it looks like - http://www.nvidia.com/object/linux-display-ia32-256.53-driver.html . also got a little patch to make nvidia work on 2.6.36 i'm going to throw in the x-updates package - http://sarvatt.com/downloads/patches/nvidia-2.6.36-ioctl.patch
<Sarvatt> no announcement on nvnews.net forums about it and no nvidia-settings tag in git yet though
<tseliot> Sarvatt: yes, I had noticed the new release on phoronix but I wasn't aware of the existence of that patch. I'd still prefer to wait until I talk to Nvidia about the driver
<Sarvatt> no worries, I'm going to hold off updating x-updates anyway since its the same driver and I dont want conflicting orig.tar.gz's in there :)
<tseliot> good
<Sarvatt> 1.3kb in kernel/nv-kernel.o and the version change in the makefile is the only difference
<tseliot> it's likely that they simply marked the driver as stable by adding some signature
<ari-tczew> Sarvatt, after upgrade to nvidia 256.52 from x-updates, my gdm won't login
<Sarvatt> what do the logs say?
<Sarvatt> i'm guessing could not find nvidia kernel module?
<Sarvatt> do you have headers installed for the kernel you booted? did dkms install it right?
<bjsnider> everything's fine here, so it's specific to his system
<ari-tczew> Sarvatt, it's not nvidia issue
<Sarvatt> what kernel are you using?
<ari-tczew> Sarvatt, -19.28
<ari-tczew> Sarvatt, http://paste.ubuntu.com/486339/
<bjsnider> Can't open /home/ari/.profile
<Sarvatt> yah that just says it failed, check /etc/gdm/:0.log or /var/log/Xorg.0.log?
<ari-tczew> but .profile file exist!
<bjsnider> is it executable?
<ari-tczew> bjsnider, I don't know. here is it: http://paste.ubuntu.com/486341/
<bjsnider> well i don't know if that's the cause of the problem or not
<bjsnider> mine has 755 permissions
<bjsnider> the content of the file is fine
<ari-tczew> bjsnider, I can't check this one now, because I'm on windows xp now.
<bjsnider> line 34 of /etc/gdm/Xsession says test -f "$HOME/.profile" && . "$HOME/.profile"
<bjsnider> so it seems like it's stopping at that point because that command didn't return the right results
<bjsnider> so you need to go back into ubuntu and fix that file
<bjsnider> i suppose
<tseliot> Sarvatt: does the radeon DDX driver in xorg-edgers cause problems with Unity?
<Sarvatt> am I on he right track here for backporting mesa to lucid which doesn't have regex support in dpkg-gensymbols? http://pastebin.com/THW7gA74 I haven't been able to find any info on what to do in this situation in any of the library packaging guides and just went off of what was done in libdrm-radeon1
<jcristau> just don't mention the private symbols in the symbols file
<Sarvatt> and man, sandybridge is in *rough* shape. managed to get a KMS+intel ddx desktop up eventually but GL is rendering all black
<Sarvatt> oh, even easier then! thanks
<jcristau> especially for a ppa where nothing should be built against it anyway
#ubuntu-x 2010-09-01
<RAOF> Man, moving i8{4,5}5 to VESA is going to cut down on the bug reports.
<tseliot> Sarvatt: where's the patch for nvidia to enable compatibility with kernel 2.6.36 that you mentioned yesterday?
<jcristau> RAOF: so you're moving those to vesa?  not trying your luck with ickle's shadow branch?
<RAOF> jcristau: I think post-beta is a little bit late for trying my luck :).  There are shadow-branch packages in a PPA.
<ScottK> How's i865 looking on Maverick?
<ScottK> Seems ~as good as Lucid (which for this system isn't too bad).
<ScottK> I'd be curious what the forecast is for i865 support to the next LTS?  I'd sort of assumed I'd have to leave this system at Lucid, but Maverick live session works very well.
<jcristau> too early to tell i think
<Sarvatt> <Sarvatt> ScottK: should potentially be better off than lucid but i'd be interested in hearing your experience with it if you do try it :) I think 865 is the only 8xx remotely working right these days
<Sarvatt> guess I got booted there
<ScottK> Just after I said that I got a X crash on logout.
<ScottK> So it's not quite there yet.
<Sarvatt> wasn't lucid working for you?
<ScottK> Lucid is working.
<ScottK> I'm doing this from a maverick live session.
<Sarvatt> RAOF: ugh, copyfb patch is what's making sandybridge not work with 2.12.0-1ubuntu3, its not that its fixed in git its just that I dropped the patch in the git ones
<ricotz> Sarvatt, hi, are you planning some upload to the edgers ppa?
<Sarvatt> ricotz: yeah going to fix up mesa today
<ricotz> i need to delete the lucid package of cairo, and upload it again
<ricotz> this copying from the primary archive seems to mess something up which prevents ia32libs to build
<ricotz> Sarvatt, the mesa package for maverick is ok?
<Sarvatt> ricotz: yup
<ricotz> Sarvatt, i think deleting a package takes sometime until it is really gone?
<Sarvatt> yeah check ppa.launchpad.net/xorg-edgers/ to see when it really goes away
<ricotz> Sarvatt, to clean up a bit - do you think the hardy,intrepid,jaunty packages can go?
<Sarvatt> tormod wants to keep those, I suggested that too many times :)
<ricotz> mhh, he is not around to ask again ;-)
<Sarvatt> that was before we could filter by release and we got a space bump, i don't really mind anymore :)
<ScottK> Sarvatt or RAOF: Would you please look at Bug #628077 and let me know if there is any additional information I should collect before I bail out of this live session?
<ubot4> Launchpad bug 628077 in xserver-xorg-video-intel (Ubuntu) "Intel i865 crash on logout with KDM (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/628077
<ricotz> Sarvatt, yeah, sure, but they are quite old and not to edgers-like anymore
<Sarvatt> ScottK: hmm, odd, had the same problem in lucid and we backported a commit that fixed it but thats already in 1.9.0
<ScottK> Sarvatt: This is at least slightly different since that one only failed for non-admin users.  This failed in the live session so it was for an admin user.
<Sarvatt> ah the gpu did hang
<ScottK> Do let me know if there's anything else I can add.
<Sarvatt> ScottK: there are probably *many* of the same bug report already, will try to dig into the others and dupe it, shouldn't need more info
<ScottK> Thanks.
<Sarvatt> did you use KMS with lucid?
<Sarvatt> it should have defaulted to that unless you explicitly disabled it in case you dont know
<ScottK> Yes.  I did.
<ScottK> (I did use default)
<Sarvatt> ScottK: If you want it to just work for the moment I suggest using the fbdev X driver instead of intel
<ScottK> OK.  I'm not upgrading that machine yet, so I'll just wait and see.
<ricotz> Sarvatt, are you using mutter with edgers nouveau?
<Sarvatt> ricotz: nope just compiz
<ricotz> ok, compiz is fine, but mutter (gnome-shell) has some greater issues
<ricotz> i hope your mesa update will solve some things
<Sarvatt> i need to fix the symbols for the lucid version and refresh the osmesa patch, will be a few hours because i'm doing some bug triage and trying to get a machine running now
<Sarvatt> ugh, 865 is in bad shape like the rest of 8xx on maverick it looks like, duping about 30 bugs to one now with the same hang
<ricotz> Sarvatt, alirght, keep in mind cairo is missing now until i'll upload it again
<ricotz> or isnt mesa depending on it?
<tseliot> Sarvatt: where's the patch for nvidia to enable compatibility with kernel 2.6.36 that you mentioned yesterday?
<Sarvatt> http://sarvatt.com/downloads/patches/nvidia-graphics-drivers-lucid-backport.patch
<Sarvatt> wait wrong patch
<Sarvatt> http://sarvatt.com/downloads/patches/nvidia-2.6.36-ioctl.patch
<Sarvatt> ricotz: nope mesa doesnt need cairo
<tseliot> Sarvatt: Thanks. I asked as I think I'll upload the new driver today
<Sarvatt> \o/
<Sarvatt> thanks tseliot, that should stop a bunch of bug reports :) (LP: #616023) is one for the new abi problem
<tseliot> Sarvatt: yes, also I'll make sure to disable the workaround in Jockey
<Sarvatt> bryceh: any idea whats going wrong with the graphs? http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-maverick-workqueue.svg
<Sarvatt> think its too late to get a new intel-gpu-tools snapshot into maverick? not having to run intel_error_decode on every bug report to decode PGTBL_ER would be nice :)
<Sarvatt> then again i'm starting to memorize what each one means
<Sarvatt> need to make arsenal script one of these days that grabs i915_error_state.txt from every bug, decodes it with intel_error_decode and puts the first 15 or so lines into the bug info
<Sarvatt> ricotz: updating mesa now
<ricotz> one sec
<ricotz> Sarvatt, i want to start the rebuilt of ia32libs for lucid first
<ricotz> i still need to wait for the cairo packages to publish
<Sarvatt> let me know when, i'll just upload maverick
<ricotz> Sarvatt, nevermind just push it
<ricotz> the currently broken mesa source would break the ia32lib aswell
<Sarvatt> ah right
<tseliot> Sarvatt: does -ati in edgers require the new xserver? Or will it build against lucid's default X?
<Sarvatt> lucid? hmm
<Sarvatt> tseliot: http://sarvatt.com/downloads/patches/xsfbsrevert.patch
<Sarvatt> will need that + lowering the xserver-xorg-dev build dep in control
<Sarvatt> but it should be fine with that
<tseliot> Sarvatt: thanks a lot
<Sarvatt> ricotz: argh, sorry, now the vmware build is busted on lucid
<tseliot> Sarvatt: http://pastebin.ubuntu.com/486826/ I guess that patch wasn't enough
<Sarvatt> needs an explicit xinerama proto dep there
<Sarvatt> looking now tseliot 
<tseliot> thanks
<Sarvatt> ah darn, you do need xutils-dev
<Sarvatt> it's safe to just use maverick's in lucid though
<Sarvatt> it's just a build time dependency, it wont affect the binaries
<tseliot> are you talking to ricotz now?
<ricotz> Sarvatt, no problem, i dont bother so much about lucid ;)
<Sarvatt> tseliot: nope that was about radeon
<Sarvatt> any most every other x package from git
<tseliot> Sarvatt: ah, thanks
<Sarvatt> tseliot: sorry about that, I update xorg-edgers automatically with scripts and don't bump the build deps most of the time since everything builds against xorg-edgers where I have the updated deps
<tseliot> Sarvatt: np, I appreciate your work and your help
<Sarvatt> ricotz: ok new mesa for lucid with an explicit x11proto-xinerama-dev dep uploaded, its not in xserver-xorg-dev for lucid
<tseliot> err... I guess I'll upload nvidia tomorrow
<Sarvatt> this intel copyfb patch is a mess, I have a feeling its causing a large number of the x-x-v-intel bugs at the moment :(
<bryceh> Sarvatt, yeah I think I know, just been busy and didn't think anyone else was using the graphs :-) ; I'll try to square it away tonight
<Sarvatt> bryceh: no worries at all its not important, I just like to see it go down when i knock out a big chunk :)
<Sarvatt> (or get depressed when knocking out a big chunk doesn't outnumber the incoming bugs)
<Sarvatt> RAOF, bryceh: What do you think about this for making fglrx/nvidia work without an xorg.conf? http://sarvatt.com/downloads/patches/0001-Attempt-to-get-nvidia-and-fglrx-working-without-an-x.patch
<Sarvatt> all thats needed is that darn DefaultDepth
<bryceh> Sarvatt, works for me, but be sure to run it by timo as well; I remember we attempted this once before but ran into some blocker (but I can't remember what it was)
<Sarvatt> the defaultdepth 24 line yeah :( it'd be something for natty anyway
<bryceh> Sarvatt, hey tell me about http://sarvatt.com/downloads/piglit/nouveau/ ?
<Sarvatt> what about it?
<Sarvatt> I dunno what ya mean, got a question about the nouveau results specifically?
<bryceh> what is it? is it a good X test in general?
<bryceh> is it nouveau only, or could we use it for any video driver?  where'd you find it?
<Sarvatt> http://cgit.freedesktop.org/~anholt/piglit/tree/README has a decent description of it
<Sarvatt> oh if you go up a level you'd see the other tests I did, http://sarvatt.com/downloads/piglit/
<Sarvatt> its used to spot regressions in mesa, it's pretty sweet
<Sarvatt> when they spot major bugs they add test cases to it to make sure it doesn't regress and such
<Sarvatt> can run it on any driver, that one was just nouveau specifically
<bryceh> is it hardware specific at all?  i.e. is there value on running it on several different radeon cards or would it produce the same results in all cases?
<jcristau> yes
<Sarvatt> yeah it's really hardware specific, the results aren't comparable across generations or anything
<Sarvatt> ati has problems with it, there's a bunch of ati specific tests to work around them in there
<Sarvatt> it'd be nice if the test names mapped to fdo bugs they were taken from more obviously though :)
<cnd> RAOF, I've found a bug in /usr/share/X11/xorg.conf.d/50-synaptics.conf
<cnd> I've cloned the git repo for synaptics
<cnd> should I fix the issue in the file itself in conf/50-synaptics.conf
<cnd> or should I add a patch in debian/patches to fix it?
<cnd> I don't believe the file is shipped by upstream
<Sarvatt> cnd: conf/* is shipped by upstream so patch it is :)
<cnd> oh it is?
<cnd> hrm, I need to poke whot then...
<jcristau> what's the bug?
<cnd> jcristau, the matches for synaptics doesn't specify MatchDevicePath "/dev/input/event*"
<jcristau> that's intentional
<cnd> jcristau, why?
<cnd> whot said it was a bug
<jcristau> because that would break !linux
<jcristau> why is it a problem?
<cnd> ok, bear with me as I explain, it's not obvious
<cnd> two touchpad devices A and B
<cnd> X enumerates A before B
<cnd> they both have a /dev/input/event* node and a /dev/input/mouse* node
<cnd> I want A to use evdev instead of synaptics
<cnd> I set up xorg.conf to do that properly
<cnd> A gets handled by evdev, everything is fine
<cnd> B's /dev/input/mouse* node gets probed by synaptics
<cnd> it doesn't match /dev/input/event* in the synaptics probe function, so synaptics runs the eventcomm AutoDevProbe callback
<cnd> the AutoDevProbe callback finds the first evdev node that isn't grabbed by synaptics
<cnd> in this case, it finds A
<jcristau> i'd argue that the bug is to go trolling random devices when it doesn't like the one it's given
<cnd> one could make that argument
<jcristau> also who has 2 touchpads? :)
<cnd> ummm, I do?
<cnd> I actually have 3 :)
<jcristau> uh
<jcristau> didn't know that existed :)
<cnd> not that I actually use them all at the same time :)
<jcristau> you don't have 3 hands?
<cnd> internal synaptics trackpad, magic trackpad, bamboo touch
<cnd> I'm still trying to grow a third
<jcristau> hehe
<cnd> so yeah, the eventcomm interface probably shouldn't even have an AutoDevProbe callback
<cnd> but I just want to fix things for maverick right now
<cnd> the simplest solution, as pointed out by whot, is to ensure synaptics is only called on evdev nodes through MatchDevicePath
<jcristau> right
<cnd> so I'll just create a patch to add the match clause
<jcristau> in debian i'd like to avoid installing a different file on different archs..
<cnd> oh yeah, hrm
<cnd> that's a paiin
<cnd> jcristau, I could make a patch to not register the eventcomm callback
<jcristau> maybe i can add an option to the driver to disable auto-dev thing, and set that in the xorg.conf.d snippet
<cnd> are you volunteering to fix it? :)
<jcristau> so that a regular InputDevice section still works, but the hotplugged ones don't go crazy
<jcristau> i'd say go with your MatchDevicePath for maverick
<jcristau> i don't know when i'll have time for this
<cnd> sure
<jcristau> are you going to toulouse btw?
<cnd> yep
<cnd> I assume you'll be there/
<cnd> ?
<jcristau> i should get up my ass and look at trains/hotels
<cnd> heh
<cnd> if only I could ride a train there
<cnd> or anywhere for that matter...
<jcristau> seems to be 5h30 from paris to toulouse
<cnd> hmm, that's quite a bit longer than I would have thought
<cnd> though I'm not that familiar with france :)
<jcristau> hmm, or i could take a plane.  flight is 1h10.
<Sarvatt> RAOF: yeah its definitely not hw cursor init it's hanging in, thats just where the log stops normally - http://sarvatt.com/downloads/xorglog-snb.txt
 * Sarvatt kicks the copyfb patch some more.
<Sarvatt> RAOF: so, a refreshed copy-fb applied to xserver-xorg-video-intel git master works. argh! http://sarvatt.com/downloads/patches/101_copy-fb.patch
<Sarvatt> I tried bringing back the changes from that vs our 101_copy-fb.patch to 2.12 but no luck there
#ubuntu-x 2010-09-02
<tseliot> Sarvatt: where did you find nvidia-2.6.36-ioctl.patch? Did you write it yourself?
<Sarvatt> nope, nvnews forum, lets see if I can dig up the post
<tseliot> Sarvatt: ok, it was just to know what to give you credit for in the changelog ;)
<diverse_izzue> hi all. i have an external screen that i've long used with my former laptop, which had an ATI X1400 chip, without issues, using Xrandr. I now have a thinkpad T400s, with intel graphics, running Ubuntu Lucid, and while xrandr detects the display, and lets me turn it on, i simply cannot get it to show an image. ideas?
 * tseliot is finally uploading the new nvidia driver
<seb128> ubuntu bug #623272 seems an xorg-edger issue
<ubot4> Ubuntu bug 623272 in notify-osd (Ubuntu) "Notification's background doesn't show completely (affects: 1) (heat: 6)" [Low,New] https://launchpad.net/bugs/623272
<seb128> could somebody comment on it and reassing,
<Sarvatt> seb128: done, thanks
<seb128> Sarvatt, thank you
<Sarvatt> no problem, sorry you get bugs like that. pixman is going through a rough spot
<Sarvatt> i just fixed that in the ubuntu version but guess I haven't updated it from git in edgers since that fix, whoops
<Sarvatt> RAOF: how about we just change the autoconfig logic for 8xx to use fbdev and leave KMS enabled?
<ScottK> Sarvatt: By 8xx you mean 845/855 or all of them?
<Sarvatt> just making it break instead of adding intel to the list so it tries vesa (and fails) and then fbdev (which'll work with KMS)
<Sarvatt> ScottK: not sure, he wanted to disable KMS on i830, i845g, i855 at the kernel level which would force them over to vesa
<Sarvatt> but it looks like 865 is as bad off as the others now
<ScottK> That wasn't my experience yesterday.
<ScottK> I got the one crash on logout, but the experience during the session was as good or better than lucid.
<Sarvatt> how long did you use it?
<ScottK> I used it for a couple of hours and left the live session up most of the day.
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/614207
<ubot4> Launchpad bug 614207 in xserver-xorg-video-intel (Ubuntu) "[i865] GPU lockup bb778213 (PGTBL_ER: 0x00000029) (affects: 7) (dups: 14) (heat: 107)" [Undecided,Confirmed]
<ScottK> Did theirs work on Lucid?
<Sarvatt> finding tons of duplicates of this from people on 865
<ScottK> OK.  Maybe I'm just lucky.
<Sarvatt> good question :)
<ScottK> All i865 != all other i865, so who knows.
<Sarvatt> most look like crashes while watching videos using Xv if you want to try to break yours
<ScottK> OK.  Next time I'm free to reboot it into a live session.
<Sarvatt> ScottK: I have 2 PPA's that may potentially fix the problem, would you mind giving them a shot at some point? I'll add the info to your bug report if so
<ScottK> OK
<Sarvatt> appreciate it ScottK, sorry to be a hassle :)
<ScottK> No problem.
<ScottK> Sarvatt: I'll go do it now, so I don't forget.
<ScottK> Sarvatt: One problem I have in Maverick that's a carry forward from Lucid is I'm always in 2048 X 1536 after booting.
<ScottK> Sarvatt: I'm up in the live session now, so just let me know what you want me to do.
<ScottK> Sarvatt: I've even got kwin effects including blur (just had to knock it's intensity down a bit).
<ScottK> Sarvatt: Playing youtube videos works nicely. What should I do to break it.
<ScottK> Got your bugmail.  Trying now
<Sarvatt> ScottK: argh, I'm sorry, xchat isn't pinging me for some reason. You got the bug mail with the 2 PPAs?
<ScottK> I did.
<ScottK> Trying it now.
<Sarvatt> any luck with either? the first is versioned lower than the second if you want to try them in order
<Sarvatt> ah ok
<ScottK> Sarvatt: What's the easiest way to make sure I know which one is actually running?
<Sarvatt> hmm
<Sarvatt> well with the first one you won't have a seamless plymouth - X transition
<ScottK> I didn't.
<Sarvatt> yeah thats working then
<ScottK> Successful logout (no crash) with the first.
<Sarvatt> oh boy
<Sarvatt> RAOF: copy-fb patch causing problems on more than just sandybridge here
<Sarvatt> ScottK: knowing if the second works properly will help a bunch also because it has a slightly modified version of the patch causing the issue 
<ScottK> OK.  Trying it now.
<Sarvatt> thanks man, you're confirmed something i've feared since it looks like there are a large number of bugs being caused by that patch :(
<ScottK> Sarvatt: No crash on the second one either.
<Sarvatt> \o/
<Sarvatt> ScottK: thanks!
<ScottK> You're welcome.  Thank you for caring about ancient shit.
<ScottK> bad news though.
<ScottK> enabling desktop effect with #2 froze the system.
<Sarvatt> thats ok, it's not related
<ScottK> OK.
<ScottK> All done then?
<Sarvatt> second one is a newer source than what's going to be in maverick, the refreshed patch only applies to that newer version as-is so just need to bring back some of the changes into our version
<Sarvatt> ScottK: for now, thanks a bunch! I'll let you know when I have an updated package to try if you don't mind, working on it now because it also breaks a machine I'm trying to fix
<ScottK> Excellent.
<Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=c57840b272ba88fddf22484929608431879b0fab looks like a prime candidate for cherry picking if anyone manages to find a bug hitting it :) https://bugs.freedesktop.org/show_bug.cgi?id=29187
<ubot4> Freedesktop bug 29187 in Driver/intel "crash in intel_drv" [Critical,Resolved: fixed]
<Galaxor> Hi.  I'm using 10.04 amd64.  I just added the ppa ppa:ubuntu-x-swat/x-updates and did an apt-cache update.  I want to install the latest nvidia driver, but I did apt-get install nvidia-current, and it said no new updates.  I said apt-cache show nvidia-current and it says version 195, not 256, like I'd hoped.
<Sarvatt> you need to sudo apt-get update then sudo apt-get upgrade, not apt-cache
<Galaxor> The apt-get upgrade does not indicate that it is going to upgrade nvidia-current
<Galaxor> It's only going to upgrade nvidia-173-modaliases nvidia-96-modaliases
<Galaxor> (and some other packages that don't start with 'nvidia-*'
<Galaxor> )
<Sarvatt> try dist-upgrade? what version is installed now?
<Galaxor> 195.36.24-0ubuntu1~10.04
<Galaxor> Isn't dist-upgrade for - like - going from ubuntu 9.10 to 10.04?
<Sarvatt> nah it allows packages to upgrade that bring in new packages
<Galaxor> Well, that gives the same list of packages that it's going to upgrade.  Is it like, if I upgrade those packages then the next round will become available?
<Sarvatt> i'm not sure why it's not showing up, does it offer anything if you sudo apt-get install nvidia-current?
<Sarvatt> (don't let it install if it does)
<Galaxor> nvidia-current is already the newest version.
<Galaxor> is what it says.
<Sarvatt> can ya run this command  in a terminal?
<Sarvatt> sudo apt-get install pastebinit && aptitude show nvidia-current -vv | pastebinit
<Sarvatt> or just put the output from aptitude show nvidia-current -vv on a pastebin somewhere
<Galaxor> http://pastebin.com/52AEfv5h
<Galaxor> (fortunately, I already had pastebinit installed)
<Galaxor> It looks like I have two nvidia-current packages installed -- one from Archive: lucid-updates and one from Archive: now.  The one from Archive: now has not Filename or MD5sum listed.  Does that mean anything?  Or is that just saying "that's what you have installed now", and is normal output?
<Sarvatt> i'm stumped. the extra Archive: now one is normal
<Sarvatt> try opening up synaptic and forcing the version to the newer one and see what happens?
<Sarvatt> or try sudo aptitude install nvidia-current=256.52-0ubuntu0sarvatt3~lucid
<Galaxor> All right, it looks like it's willing to upgrade it in this case.
<Sarvatt> did it have to remove anything?
<Galaxor> It doesn't look like it.  It looks like it'll go cleanly.  Should I do it?
<Sarvatt> just tried it in lucid with that package and it upgraded fine, I have no idea what happened
<Sarvatt> yeah
<Sarvatt> might want to check nvidia-current-modaliases and nvidia-settings versions too while yer at it and upgrade those if they didnt
<Sarvatt> nvidia-settings will be 256.44, no changes between 256.44 and 256.52
<bjsnider> looks like he just hadn't upgraded yet
<bjsnider> he didn't have two different versions installed
<Sarvatt> off to the store for hurricane supplies, whee
<Galaxor> Sarvatt:  Good luck!
<Galaxor> Thanks.
<Galaxor> bjsnider:  Yeah, it was just weird because apt-get upgrade wasn't detecting that these packages had new versions available, even though they showed in aptitude show -vv
<Galaxor> bjsnider:  But if I install them with aptitude and specify the newer versions, it seems to be installing just fine.
<Galaxor> Okay.  I installed the latest nvidia driver and it fixed the xdamage/vino issue, so I'm happy with that.
<Galaxor> but video playback with Xv still does not work.
#ubuntu-x 2010-09-03
<Galaxor> I get a black screen when trying to play video using Xv.  I can switch it to native X11 video just fine, and that's how I've been playing videos.  I've got enough cpu that it hasn't yet been an issue.  Still...
<Galaxor> Oh, that was weird.  It was just that my contrast was set to -1000 in nvidia-settings.  I wonder how it got like that.  Oh well, that's fixed.
<Galaxor> And that concludes the bugs.  My new computer now works perfectly.
<RAOF> Sarvatt|gone: That's a fine idea, too.
<bryceh> heya RAOF
<RAOF> bryceh: Howdie
<artfwo> Hello! I've stumbled upon a bug (actually 2 bugs), introduced by xserver-xorg-input-evdev 1:2.3.2-6ubuntu1. Could anyone experienced take a look?
<artfwo> Bugs in question are bug 41301 and bug 583312
<ubot4> Launchpad bug 41301 in xserver-xorg-input-evdev (Ubuntu) (and 2 other projects) "Mouse clicks stop working sporadically (affects: 41) (dups: 5) (heat: 270)" [Undecided,New] https://launchpad.net/bugs/41301
<ubot4> Launchpad bug 583312 in xserver-xorg-input-evdev (Ubuntu) "Left mouse clicks not being processed (affects: 2) (heat: 16)" [Undecided,New] https://launchpad.net/bugs/583312
<artfwo> Downgrading to xserver-xorg-input-evdev 1:2.3.2-6build1 solves the problem for me
<RAOF> Hm, interesting.
<artfwo> I'm almost certain, that the bug is introduced in debian/100-fix-touchup-problem-on-touchpads.patch
<artfwo> because it does something with switching absolute/relative axes, and my mouse works with absolute axes, judging by Xorg.0.log
<artfwo> but axes have nothing to do with buttons on the other hand, weird
<RAOF> Indeed :)
<artfwo> while I was experiencing the bug, switching mice actually helped
<artfwo> here's what happens, when I plug in the "buggy" mouse http://pastebin.ubuntu.com/487615/
<artfwo> and this is Xorg.0.log for "working" mouse http://pastebin.ubuntu.com/487616/
<artfwo> anyway, A4tech mouse worked okay without the latest patch
<artfwo> I'm thinking of perhaps opening a new bug report for the Maverick behaviour, is it reasonable?
<RAOF> Yes, I think so.
<RAOF> 20 mouse buttons!!!
<artfwo> there are actually only 6 + the wheel :)
<RAOF> I wonder if that's actually a kernel problem, then.
<RAOF> I guess it shouldn't be, if switching evdev versions fixes it.
<artfwo> well, the ubuntu patch could introduce a dependency on "kernel stuff done right"
<artfwo> and in turn, triggered a bug, because of a kernel problem
<RAOF> Hm.
<RAOF> Your A4tech thing is a mouse, not a touchpad, isn't it.
<RAOF> And you've only got one of them, right?
<artfwo> right
<artfwo> but the laptop has built-in touchpad
<RAOF> It looks like X thinks both /dev/input/event12 and /dev/input/event13 are the A4Tech thingy.
<artfwo> also /dev/input/js1 and dev/input/mouse3
<RAOF> js1?
<artfwo> js* are the joysticks
<RAOF> Ah, right.
<RAOF> And you've got one of those plugged in, I presume.
<artfwo> no
<artfwo> with all the USB stuff unplugged, I still get [ 15360.722] (II) config/udev: Adding input device A4Tech USB Full Speed (/dev/input/js0)
<RAOF> Hm.
<artfwo> looks like the mouse is detected as mouse, keyboard and joystick simultaneously
<RAOF> And with 37 axes, and 20 buttons.
<artfwo> but that seems unrelated, because my external USB keyboard also produces lines like [ 15468.588] (II) config/udev: Adding input device Logitech Logitech USB Keyboard (/dev/input/js1)
<artfwo> when plugged in
<artfwo> and... [ 15468.581] (II) Logitech Logitech USB Keyboard: Found 20 mouse buttons
<RAOF> What does âudevadm info --query=all --name=/dev/input/js1â say?
<artfwo> RAOF, http://pastebin.ubuntu.com/487633/
<RAOF> Your keyboard doesn't happen to have a joystick-like thing on it?
<artfwo> only a scrollwheel
<artfwo> but the bug above happens without the keyboard, that's for sure
<artfwo> *with or without
<RAOF> Things just appear weird.
<RAOF> Do you have the a4tech device plugged in now?
<artfwo> yes, with evdev downgraded
<RAOF> What event node is it?
<RAOF> And can you grab the udevadm info for it?
<artfwo> I can, but for which device - js0?
<artfwo> here it is http://pastebin.ubuntu.com/487635/
<RAOF> And, just for the record, this is a pure mouse, right?
<RAOF> The fact that it's got ID_INPUT_KEYBOARD=1 set is a total lie?
<artfwo> I guess so
<artfwo> the mouse hasn't any builtin keyboard
<artfwo> if I query /dev/input/mouse0 this string goes away
<RAOF> Ah.
<RAOF> And I'd wager that one of the (many!) /dev/input nodes has ID_INPUT_TOUCHPAD=1 set.
<artfwo> /dev/input/mouse2 has it
<RAOF> And is the A4tech mouse?
<artfwo> no
<artfwo> I think it's the builtin touchpad
<RAOF> It's your honest-to-goodness touchpad?
<artfwo> right
<RAOF> None of the patches in evdev look particularly suspicious.
<RAOF> This only starts happening after some period of time, yes?
<RAOF> Not straight after startup?
<artfwo> yes, in an absolutely random, but rather short period
<artfwo> I think it's most often triggered by chromium and empathy windows, but also happens in nautilus and gimp
<artfwo> the system is absolutely unusable afterwards. it behaves like the left mouse button is down all the time
<artfwo> keeps selecting bunches of text, or dragging the windows
<artfwo> right & middle continue to work, as well as the wheel
<artfwo> I can alt+tab between windows, catch events in xev, etc.
<artfwo> unplugging the mouse and clicking left button on the touchpad returns everything to normal
<RAOF> artfwo: What architecture are you on?  I'd like to prepare a couple of packages to see which patch is breaking for you.
<artfwo> RAOF, x86
 * RAOF updates his i386 chroot
<RAOF> artfwo: http://cooperteam.net/Packages/xserver-xorg-input-evdev_2.3.2-6ubuntu2~notouchupfix_i386.deb is a first hack at it.
<artfwo> RAOF, installing right now
<artfwo> RAOF, your package made the bug reappear almost immediately
<RAOF> Ok; second one without gesture support.
<RAOF> artfwo: http://cooperteam.net/Packages/xserver-xorg-input-evdev_2.3.2-6ubuntu2~nogestures_i386.deb
<artfwo> okay, let me restart X...
<artfwo> RAOF, it looks like everything's okay now
<ScottK> Now I understand why my mini 10v looks like crap on Kubuntu Maverick: http://blog.martin-graesslin.com/blog/2010/09/driver-dilemma-in-kde-workspaces-4-5/
<ScottK> Any suggestions on how to usefully file bugs/troubleshoot compositing problems for this?
<jcristau> get the kde people to talk to mesa driver devs?
<ScottK> Unlikely to provide much relief on the maverick timeline.
<jcristau> *shrug*
<tseliot> ScottK: I think you can switch to Xrender instead of OpenGL for compositing (as a temporary workaround)
<ScottK> tseliot: Thanks.  I'll try that.
<Sarvatt> every time I read this guys blog I get the impression he thinks everyone not using nvidia proprietary drivers is doing it wrong :)
<Sarvatt> and that its just a matter of getting drivers ready to do opengl 2.0 and not a hardware limitation of hardware thats still shipping today
<jcristau> Sarvatt: and that driver bugs get fixed out of thin air, without anybody reporting issues to the devs
<Sarvatt> yeah especially that
<ScottK> tseliot: Much better.  Thanks.
<tseliot> ScottK: np
<Sarvatt> ScottK: can ya describe "looks like crap"?
<tseliot> no desktop effects
<tseliot> and KDE doesn't look extremely good without them
<Sarvatt> oh they were just disabled completely? they added all that fallback infrastructure and only made it do GL->off instead of falling back to xrender?
<tseliot> yep
<ScottK> Sarvatt: Yes and then when I enable them manually the screen suffers from flashes and incomplete rendering.
<Sarvatt> ScottK: it would be interesting if you could try this with gl composting - https://edge.launchpad.net/~sarvatt/+archive/mesa
<ScottK> Is there anything we can do about getting it to fall back to xrender?  Compositing is pretty essential for the Plasma Netbook interface.
<ScottK> Sarvatt: Sure.  That machine is expendable.
<ScottK> Sarvatt: That machine had an X crash on logout too (945gme).  Could that be affected by the same issue we tested on 865 yesterday?
<Sarvatt> ScottK: yup
<Sarvatt> I've been struggling with fixing that patch but haven't had any luck yet, planning on spending all day today on it
<Sarvatt> oh joy, the blacklists for broken features in KDE specifically don't include -devel in the mesa version string so that mesa might not work right even if it will once its released. if only we could get an RC here soon :(
<Sarvatt> it looks like the only things that work right basically are proprietary drivers, nouveau, i965+ intel if you specifically blacklist blur, r300-r500 ati using gallium only and r600+ ati from mesa git
<ScottK> Interesting experience.
<ScottK> It seems like things are slower, but much smoother than the current mesa.
<Sarvatt> KDE 4.6 is going to be even worse no doubt since it's going opengl 3 that no free drivers implement and backwards compatability isn't planned until 4.7? wow
<ScottK> Sigh.
<Sarvatt> interesting. I thought opengl compositing didn't work at all in 7.8.2?
<ScottK> It was slow enough that I had to disable functionality checks to keep it from disabling effects for being too slow.
<ScottK> No flickering though
<ScottK> Actually after rebooting, its
<Sarvatt> that was with mesa 7.9 that you had to do that?
<ScottK> much better.
<ScottK> Whatever was in your ppa
<ScottK> Actually after rebooting instead of logging out, crashing X, and restarting it's quite snappy
<ScottK> Large blurs will still cause it to suspend effects, but other than that, works reasonably well.
<Sarvatt> what I have in that PPA is what we have in git and are going to try to file a FFe to get into maverick, it fixes quite a lot of bugs. it's due out in final release form by the end of september (and I'm very confident it will hit release on time) but there isn't a release candidate yet :(
<Sarvatt> ScottK: that should be fixed once there is a release candidate of it so the version string doesn't say -devel, it's not applying the blacklist to fix blur because of that from what I'm reading
<ScottK> OK.  That's cool.
<ScottK> Feel free to mention Bug #628930 in your FFe request.
<ubot4> Launchpad bug 628930 in kdebase-workspace (Ubuntu Maverick) (and 1 other project) "Desktop effects not active by default (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/628930
<Sarvatt> ScottK: thanks, I was just going to ask if you knew of any bugs
<Sarvatt> RAOF: ^
<ScottK> Sarvatt: With just blur disabled and your new mesa the system works well again.  I think on the Kubuntu end of things we will pursue disabling just blur by default on netbooks (netbooks will ~all be affected by this).  That and your planned mesa update should get us into a releasable state.
<Sarvatt> ScottK: thats a good idea in general, the blur only works properly on proprietary drivers apparently and that guy didn't want to disable that feature globally because he thinks the majority of people use those where it works :)
<ScottK> There was about a week where it worked on intel.
<Sarvatt> 965+ or your 945?
<ScottK> 945
<ScottK> He changed something between KDE 4.5 RC and final that killed it.
<ScottK> I marked that bug to also affect mesa, FYI, so you have something to fix too.
<Sarvatt> it's glsl only so I can't see how it ever worked on 945, hmm
<ScottK> Dunno.  I sometimes have low standards for 'worked' when running the development release.
<Sarvatt> wow, there are an amazing amount of INTEL_DEBUG env variables in mesa
<Sarvatt> RAOF: oh sheesh, it's X: ../../dix/pixmap.c:118: AllocatePixmap: Assertion `pScreen->totalPixmapSize > 0' failed. breaking sandybridge, didn't we have this problem before?
<Sarvatt> oh hmm, i'm on the 31st iteration of screwing with 101_copy-fb.patch, best check with stock before I say that :)
<ScottK> Sarvatt: mgraesslin says opengl 3 in KDE 4.7 and they aren't dropping any backward compatibility stuff in 4.6.
<seb128> bryceh, hi there
<seb128> bryceh, http://www2.bryceharrington.org:8080/X/PkgList/versions_current.html
<seb128> do you have an updated version of that?
<Sarvatt> seb128: http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/versions-current.html
<bryceh> yeah sorry, I need to get rid of that old link
<bryceh> Sarvatt, sorry I've not yet fixed up that graph...  totally forgot, been mesmerized by launchpad->bugzilla work
<Sarvatt> bryceh: no worries at all man! it's not important or anything
<ScottK> Sarvatt: Would you please have a look at http://blog.martin-graesslin.com/blog/2010/07/blacklisting-drivers-for-some-kwin-effects/ and give me a hand figuring out how to describe i945gme to blacklist the blur effect?
<bjsnider> Sarvatt, will there be nouveau gallium3d in maverick?
<Sarvatt> ScottK: can you blacklist wildcards? :) I bet he doesn't want that
<Sarvatt> bjsnider: it is already, libgl1-mesa-dri-experimental
<ScottK> Sarvatt: No idea.  I'd like to at least get mini 10v blacklisted properly.
<Sarvatt> ugh, really stinks that its so strict, you can break it just using driconf that way :(
<Sarvatt> ScottK: you get it from the OpenGL renderer: line of the glxinfo output
<Sarvatt> i dont have 7.8.2 installed at the moment to give you an exact one
<ScottK> Of course I don't either ....
 * ScottK will revert first.
<Sarvatt> oh there's a comment in the blog - grep KWin::CompositingPrefs::detectDriverAndVersion ~/.xsession-errors
<Sarvatt> the GL renderer and GL version strings
<Sarvatt> sudo ppa-purge -p mesa sarvatt will do it
<Sarvatt> dont have to reboot to get the info
<ScottK> OK.  Back in a few.  Now distracted by another task.
<apparle> are video memory and gart size or different?
<Sarvatt> [Blacklist][Blur]
<Sarvatt> Intel=Mesa DRI Intel(R) 945GME GEM 20100328 2010Q1:-:1.4 Mesa 7.8.2
<Sarvatt> [Blacklist][Lanczos]
<Sarvatt> Intel=Mesa DRI Intel(R) 945GME GEM 20100328 2010Q1:-:1.4 Mesa 7.8.2
<apparle> how to check what is my current video memory size (on board GPU)?
<Sarvatt> ScottK: this is absolutely frigging ridiculous but here you go - http://sarvatt.com/downloads/kdeblacklist.txt
<Sarvatt> thats *just* intel and *just* mesa 7.8.2
<ScottK> Sarvatt: Thanks.
<Sarvatt> GM45 is a weird one and affected by locale..
<Sarvatt> Intel=Mesa DRI Mobile IntelÃÂ® GM45 Express Chipset GEM 20100328 2010Q1 x86/MMX/SSE2:-:2.1 Mesa 7.8.2 is what it should look like
<Sarvatt> plus you have to duplicate every renderer string for every arch
<Sarvatt> since it doesnt show x86/MMX/SSE2 on x64
<Sarvatt> I dont think it'd be wrong at all to just disable it globally and let people enable it themselves if they want it even if upstream doesn't want that, just my opinion though
<ScottK> I was about to ask about that.
<Sarvatt> that way is so fragile, i can get 3 different opengl versions reported on 945GME by changing driconf values
<ScottK> Next time I see him online, I'll ask him about it.
<ScottK> Sarvatt: What's the correct ppa-purge incantation for your mesa ppa?
 * ScottK has never used it before
<Sarvatt> sudo ppa-purge -p mesa sarvatt
<ScottK> Thanks
<Sarvatt> or sudo ppa-purge ppa:sarvatt/mesa
<Sarvatt> tormod added the ppa: handling, I forget its there
<Sarvatt> RAOF: I really am drawing blanks here about this 101_copy-fb.patch. What do you think about just disabling it in the interim until we can get it fixed up? ScottK has confirmed it's screwing up server regeneration on other chipsets as well as it is now. (bug #628077)
<ubot4> Launchpad bug 628077 in xserver-xorg-video-intel (Ubuntu) "[i865] Crash on logout with KDM (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/628077
<ScottK> Sarvatt: I asked mgraesslin to join us to discuss the blacklist.
<ScottK> Hello mgraesslin.
<ScottK> Sarvatt is the one that proposed that blacklist based on our testing and your blog post.
<ScottK> Sarvatt: mgraesslin says he doesnt think it needs to be so extensive.
<Sarvatt> Heyo! I'm really not the right person to discuss it with, the people in#dri-devel would be much more knowledgeable about it :)
<mgraesslin> yeah the blog post is unfortunately incomplete
<mgraesslin> e.g. Intel=20100328 2010Q1:-:7.8.2 will work, too
<Sarvatt> ScottK: I just added every intel string from mesa to the list for future reference, wasn't suggesting using all of that
<ScottK> Sarvatt: OK.
<mgraesslin> and there is only one line per driver - the different versions are comma separated
<mgraesslin> now that I have such a list I can prepare an inclusion upstream
<ScottK> Sarvatt: I'm stuck needing to produce a patch and not knowing enough.  Upstreams sort it out eventually doesn't work on the release timeline.
 * Sarvatt nods
<ScottK> Which is why I invited mgraesslin here so you two can tell me what I need to get done.
<mgraesslin> btw: there are Intel drivers which work, so blacklisting just all, is wrong as well as it gives no possibility to the user to disable it
<Sarvatt> someone would need to go through all the KDE bugs and find out what's broken and pick and choose from there, but there's only 3 or 4 generations out of all of those so if someone is broken on one it's safe to assume the others of that generation are broken too
<ScottK> mgraesslin: Part of the problem I have is that plasma-netbook makes large assumptions that compositing will be available, so if it's not, the user experience is really unfortunate.  So I need to be rather conservative in where the more aggressive options are enabled.
<Sarvatt> aka if 945GME is broken like ScottK says it is all of the opengl 1.4 ones should need blacklisting
<Sarvatt> well maybe not the 8xx series ones but those are broken in everything else anyway :)
<mgraesslin> opengl 1.4 does not need blacklisting as the effects require GLSL - that is 2.0
<mgraesslin> ScottK: at least in 4.5.0 we had a problem that kwin's selfcheck failed on intel hardware
<mgraesslin> it might be resolved in 4.5.1 but I am not sure
<ScottK> OK.  I just updated my netbook to 4.5.1.  I'll check it.
<mgraesslin> so you might want to disable kwin's functionality checks by default
<ScottK> We'll ship with 4.5.1 +patches this cycle so maybe it's OK.
<mgraesslin> problem is, that I have access to one Intel based device and there all issues are not reproducable
<mgraesslin> selfcheck works, kwin does not freeze on settings change and blur is fast
<ScottK> My results seem to be inconsistent.
<ScottK> What does the device you have access to have?
<ScottK> mgraesslin: ^^
<mgraesslin> erm no idea to be honest
<ScottK> OK.
<bjsnider> Sarvatt, any ideas on this: http://pastebin.ca/1931994
<Sarvatt> he booted an old kernel
<bjsnider> no, he proved that's not so
<Sarvatt> oh 256.53? he hasn't rebooted since updating then
<bjsnider> i think this may be a flea power issue, where it's just stuck in memory
<bjsnider> he did reboot
<Sarvatt> don't know what to tell ya, 256.53 isn't installed for the kernel he's on obviously
<Sarvatt> did he update to 2.6.35-20 in the same update?
<bjsnider> no, -19
<Sarvatt> what's his dkms status say?
<bjsnider> it works now after another reboot
<bjsnider> so it was a module staying in the ram even through a reboot or two
<Sarvatt>  - Next week create a 7.9 release branch.
<Sarvatt> \o/
<achiang> does anyone know what happened to xserver-xorg-input-keyboard / kbd in lucid? did the package just go away?
<jcristau> looks that way.
<achiang> what happened to the code it used to contain? :)
<achiang> perhaps now in xserver-xorg-input-evdev?
<jcristau> the code is still in xf86-input-kbd, it's just not useful on linux because evdev replaces it
<achiang> ah, ok, thanks
<vish> how do i identify the chipset of an intel card?
<jcristau> lspci -s 0:2.0
<vish> so from http://launchpadlibrarian.net/54896374/Lspci.txt , it would be 945GME  ?
<kklimonda> how does 10.04 cope with computers with 2 graphic cards?
<vish> yup, [i945gme] seems it , found another bug about AAO with same title.. 
<Sarvatt> thats the same machine i've used primarily for 2 years now :)
<vish> Sarvatt: oh! the one i pasted above?
<Sarvatt> vish: do you have one? the bios is extremely hackable to enable stuff like ahci, nx, more backlight levels, etc
<Sarvatt> yeah
<vish> hmm, havent hacked around the bios yet..
<Sarvatt> it could be a different one, mine's an old AOA150
<vish> Sarvatt: thats the one you've got unity running?
<Sarvatt> i don't use that but it does work with CLUTTER_VBLANK=none
<vish> ah , but unity works normally, only crashes X at times ;) 
<vish> Bug 629814
<ubot4> Launchpad bug 629814 in xserver-xorg-video-intel (Ubuntu) "[i945gme] Moving pointer over Unity's launcher crashes X and causes Unity to reload (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/629814
 * vish tries with vblank..
<Sarvatt> vish: different problem
<vish> k.. :)
<Sarvatt> vish: try this for me? https://launchpad.net/~sarvatt/+archive/sarvatt-graphics
<vish> Sarvatt: for the intel  AAO , or   ATI ? 
<Sarvatt> AAO
<Sarvatt> it's just xserver-xorg-video-intel in there
<vish> sure.. 
<vish> yeah , just now saw the link! :D
<Sarvatt> i think i'm going to hit the liquor store if that works. that patch makes me want some booze.
<Sarvatt> well, it's the backtrace in your gdmlog2 that I'm thinking it'll fix, I didn't read the description :D
<Sarvatt> did you log out when those server crashes happened?
<vish> nope..
<vish> only once, since my network manager crashed..
<Sarvatt> is the xorglogold from a shutdown?
<vish> hmm , might be.. i'm running unity from persistant usb stick on that one..
<vish> oh, ho , somethign is eating my / !  running out of space on my laptop! , so if i crash out. :/
<Sarvatt> vish: how many backlight levels do you have?
<Sarvatt> on the AOA150
<Sarvatt> if its not 9 check this out - http://macles.blogspot.com/2009/03/brightness-table.html
<Sarvatt> (ignore the comments cus I fixed that in udev a long time ago)
<vish> just a sec.. my backup , created its own folder in /media and started filling up my / :(
<Sarvatt> I get an extra hour battery life with that new bios, there are 9 cell batteries you can pick up on ebay that last about 11 hours too :)
<Sarvatt> for $30 or so
<vish> wow! 11hrs of battery life! :)
<vish> hmm , looks like i have 9 steps :s
<Sarvatt> ah, not surprised, only the early AOA150's had the problem that made them not allow the lower levels
<Sarvatt> http://cgi.ebay.com/New-ACER-Aspire-One-9-cell-7900mAh-battery-A110-AOA150-/200489675229?pt=Laptop_Batteries&hash=item2eae1da9dd#ht_1540wt_902
<vish> hmm , well , the ppa works.. but doesnt solve the bug i mentioned above :)
<Sarvatt> those things are about 10-11 hours, they make 12 cells too
<Sarvatt> yeah, sorry about that, your logs exposed another bug that you probably dont notice cus it happens when you reboot :)
<vish> np.. :)
<Sarvatt> grep -r FreeClientResources /var/log/Xorg.* shouldn't return anything new anymore with that though 
<Sarvatt> are you running a unity session or just running unity?
<vish> unity regular! :D
<Sarvatt> from what you said in the bug though X isn't crashing just unity?
<Sarvatt> those X crashes are another bug?
<vish> yeah , i dont get logged out of the session.. but only Unity is reloaded.. so might be two happening at the same time?
<Sarvatt> yeah you'd know it if those X crashes in your log were related to unity reloading, the whole session would go down
<vish> grep -r FreeClientResources /var/log/Xorg.*  gives an output only in the 0.log.old..
<Sarvatt> vish: next reboot it shouldn't be in .old either
<vish> cool!
<Sarvatt> any chance you could confirm that so I can chalk it up as another bug caused by 101_copy-fb.patch in xserver-xorg-video-intel? :)
<vish> yup , rebooting it :)
<Sarvatt> thanks!
<vish> Sarvatt: poof! gone :) , nil output for $ grep -r FreeClientResources /var/log/Xorg.* 
<Sarvatt> thanks vish
<vish> np..
<Sarvatt> yours is identical to ScottK's then, ugh
<Sarvatt> pretty safe to say all intel bugs on maverick with this backtrace are the same
<Sarvatt> Backtrace:
<Sarvatt> 0: /usr/bin/X (xorg_backtrace+0x3b) [0x80e83bb]
<Sarvatt> 1: /usr/bin/X (0x8048000+0x5da8d) [0x80a5a8d]
<Sarvatt> 2: (vdso) (__kernel_rt_sigreturn+0x0) [0xa9640c]
<Sarvatt> 3: /usr/bin/X (FreeClientResources+0xed) [0x808f04d]
<Sarvatt> 4: /usr/bin/X (FreeAllResources+0x60) [0x808f120]
<Sarvatt> 5: /usr/bin/X (0x8048000+0x1a5e6) [0x80625e6]
<Sarvatt> 6: /lib/libc.so.6 (__libc_start_main+0xe7) [0x2a5ce7]
<Sarvatt> 7: /usr/bin/X (0x8048000+0x1a191) [0x8062191]
<Sarvatt> Segmentation fault at address 0x4
<Sarvatt> I really think it would be a good idea to disable 101_copy-fb.patch until it can get worked out
#ubuntu-x 2010-09-04
<shadeslayer> hi id like to know if there's anything planned to fix the nvidia drivers being in compatible with xorg 1.9
<shadeslayer> a proper fix... instead of disabling the ABI
<kklimonda> shadeslayer: it's fixed in nvidia-current already
<shadeslayer> kklimonda: in the archives?
<shadeslayer> which package version please
<kklimonda> 256.53-0ubuntu1
<shadeslayer> ( im asking because ive disabled the ABI atm and wondering if i should enable it back )
<shadeslayer> ok i have that one... then i should probably enable it
<shadeslayer> ok lets see if this works, brb in a bit
<shadeslayer> kklimonda: thanks for the info.. works :D
<shadeslayer> thanks all :)
<zniavre_> good afternoon
<zniavre_> sorry to ask but.... are you working on nvidia 173.14.2x driver to make it usable with the new xserver ?
<gord> zniavre_, its a closed source driver, you would have to ask nvidia
<Sarvatt|gone> zniavre_: I recommend using nouveau and installing libgl1-mesa-dri-experimental in the meantime to get 3D support, but yeah there's nothing we can do because it's all up to nvidia to do it
<zniavre_> gord, Sarvatt  thank you answering
<zniavre_> i hope they will do it as soon as possible
<zniavre_> http://www.nvnews.net/vbulletin/showthread.php?p=2302956    maybe more than soon ...  :o(
<bjsnider> zniavre_, if the 173 is going to be updated it usually happens just before a new ubuntu release
<zniavre_> bjsnider,  ok thank you
<Milos_SD> Hi
<Milos_SD> I enabled xorg-edgers ppa on Maverick. And now with nvidia drivers, compiz bugs a lot. It can not be used at all
<bjsnider> Milos_SD, why would you use xorg-edgers in maverick, when maverick is already bleeding-edge?
<Milos_SD> bjsnider, I wanted to have xserver 1.9
<Milos_SD> but Maverick in my case doesn't have it
<Milos_SD> I upgraded from Lucid
<bjsnider> maverick does have it
<Milos_SD> well, my upgraded install don't have it
<Milos_SD> Maybe there was a problem becouse I upgraded with lucid xorg-edgers packages still installed
<Milos_SD> other 3D works great
<bjsnider> possibly
<Milos_SD> only compiz have some issues
#ubuntu-x 2010-09-05
<scott_ino> I'd like to try and test multi-touch support now, either with existing tools, or new ones. I was looking at Utouch but realize that they're working on new framework
<scott_ino> for next release. So I suppose my question is, how can I test multi-touch currently
<trinikrono_> i would like to join the xswat can someone help me prepare?
<ScottK> Sarvatt: What would be the way to communicate the following to Intel developers in a way that would be constructive and useful (re the ongoing kwin mess):
<ScottK> <ScottK> mgraesslin: While I'm waiting for kdebase-workspace to compile, it would help a lot if I could get a list of the capabilities Intel is misreporting (or some idea how to figure it out).  Canonical does have people that can talk to Intel if I can tell them what needs to be communicated.
<ScottK> <mgraesslin> the list is rather short: we need framebuffer objects and shaders and in inderict rendering mode the unsupported (impossible) extensions should be removed. That's nothing I can provide as that's something only the driver developers can know
<ScottK> Additionally:
<ScottK> <mgraesslin> ScottK: if they need a reference: https://bugs.kde.org/show_bug.cgi?id=173556#c41
<ScottK> <mgraesslin> that's how NVIDIA does it
<ubot4> KDE bug 173556 in compositing "Shader support not detected on various systems" [Normal,Resolved: fixed]
<penguin42> Any mesa guys here? I've got a bug of mine with a link to a particular patch to be cherry picked from the mesa repos that makes radeon useable on maverick and I wondered what the chances of it getting in are - bug 6269943
<ubot4> penguin42: Error: Bug #6269943 not found.
<ScottK> penguin42: You might look at the git snapshot in the sarvatt/mesa PPA.  If that solves your problem, then knowing that helps the chances of the mesa update getting in.
<penguin42> bug 626943
<ubot4> Launchpad bug 626943 in mesa (Ubuntu) "[Maverick] Flickering on Radeon - please cherry pick646d2e9fbc41bf49075013009e9583bec4a51168 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/626943
<penguin42> scottk: OK, will do
<penguin42> ScottK: Is that just a build from the mesa git head?
<ScottK> ~head yes.
<ScottK> I think anyway.  It's take Sarvatt to know for sure.
<penguin42> ScottK: So I'm fairly sure that will have it since my bug is just asking for a patch in the mesa git to be cherry picked
<penguin42> (with a bit of clean up)
<ScottK> right, but if you try that package that is specifically working towards an update in Maverick and can say it fixes the problem, that's more credible than "I think the fix is in there".
<penguin42> ScottK: I know specifically that the git entry that I reference fixes it since I've got a ppa with that change added
<ScottK> Yes, but how about that git commit plus all the other changes?
<ScottK> Up to you, anyway.
<penguin42> Yeh I can give that set a try; but is the intent in Maverick to do a mesa update generically or just to stick with the version in the beta?
<ScottK> The X people intend to update. I don't think they've talked to the release team yet.
<penguin42> ok
<intrader> I am in the process of filing a bug report and I don't know the package, but suspect Xorg or the kernel (I have forum thread http://ubuntuforums.org/showthread.php?p=9782591#post9782591)
<RAOF> Sarvatt: â../../dix/pixmap.c:118: AllocatePixmap: Assertion `pScreen->totalPixmapSize > 0' failed.â means that you've tried to copy create a pixmap before the screen pixmaps have been set up; you can see uxa_init in uxa/uxa.c(I think?) for what they do.
#ubuntu-x 2011-08-29
<Azelphur> the other interesting symptom I get, I have multiple X screens (Not xinerama/twinview) and if I move my mouse to another X screen while the freeze is going, I end up with my mouse rapidly flickering between the edges of both screens, and X stays locked up forever :p
<Sarvatt> Azelphur: yeah thats an nvidia driver problem, it might be worth trying a newer one out (via ppa:ubuntu-x-swat/x-updates)
<Azelphur> cool ty, good to know it's not hardware :D
<Azelphur> I will try the ppa :)
<Sarvatt> that being said i did have an nvidia gpu completely die and it was showing those exact symptoms before it did
<Azelphur> I wish it would just completely die if it was hardware, haha
<Azelphur> I got the EVGA 25 year warranty :D
<Sarvatt> but better to try newer drivers before remotely thinking that :)
<Azelphur> indeed
<Azelphur> although it might be my 8800GT that's dieing, it is getting quite old now.
<Azelphur> (I have a GTX 570 and 8800GT in the same box, lots of monitors \o/)
<bryceh> I agree it's probably driver rather than hardware, but sometimes bad memory, overheating or insufficient/inconsistent power supply can do stuff like that
<bryceh> if it were -intel I'd say it was definitely a driver gpu issue, but -nvidia tends to be better on that count
<bryceh> Azelphur, treat yourself to some new hw, you deserve it ;-)
<Azelphur> can eliminate bad memory (tested it yesterday with memtest86) and overheating (temperature monitoring on the desktop), also insufficient power supply can go (1200W Corsair)
<Azelphur> haha
<bryceh> plus, if it is a driver problem, the likelihood of it getting fixed is low
<Azelphur> GTX 570 is new hardware :(
<bryceh> oh, you have two video cards installed?
<Azelphur> yes
<Rovanion> Azelphur: I'm bying one of those, like tomorrow or the day after
<Azelphur> bryceh: I have a GTX 570 (2 monitors, twinview) and an 8800GT (2 monitors, twinview)
<Azelphur> so 2 X screens both with twinview \o/
<bryceh> if it were me, I'd use two identical video cards, or at least two of relatively recent vintage
<Azelphur> knowing my luck it's probably a bug in the driver exacerbated by my weird setup that'll never get fixed
<bryceh> Azelphur, that's likely so
<Azelphur> hehe :p
<Azelphur> yea I wouldn't mind doing that, but GTX 570 is quite expensive for monitors that are never gonna see any gaming
<Azelphur> I use the 8800GT for boring stuff like IM/Browsing, the GTX 570 gets all the action.
<Rovanion> Azelphur: Are you using the free or propitary drivers?
<bryceh> it seems like a configuration that would tend not to get much testing by NVIDIA
<Azelphur> proprietary
<Azelphur> bryceh: haha, indeed :)
<bryceh> Azelphur, you might file a bug report upstream to the nvidia forums, but like I said it'd probably not get much attention
<Rovanion> But on the off chance that it does. Well it doesn't hurt to report it.
<Azelphur> yea, if it persists after the x-swat update I will
<Sarvatt> i might be remembering wrong but I'm pretty sure I saw a gtx 570 hang fix in the 275.xx changelogs at some point
<Azelphur> If there becomes a way for me to have multiple displays across multiple cards without killing performance (ie xinerama) I could justify getting another GTX 570 :P
<Azelphur> nice, hopefully that'll be me :)
<Azelphur> tri screen gaming in wine would be funny, hehe
<Sarvatt> Azelphur: you could buy a 4-6 output ATI, but those would have to be displayport displays for that to work :P
<Azelphur> yea, and the ATI drivers arn't really up for wine gaming yet
<Azelphur> although from what I've heard things have been getting better since AMD took over
<Sarvatt> nope fglrx is definitely still a nightmare compared to nvidia
<Rovanion> Azelphur: Well that doesn't guarantee that the quality has reached a usable state yet, just that it's better than running the game on a cracker
<Sarvatt> takes 4 months for a fix to make it into a released version of the drivers
<Azelphur> haha
<Azelphur> I'm still not sure what I'm supposed to be watching for re tri screen gaming
<Azelphur> I think I need nvidia to implement randr support
<Sarvatt> any games beside final fantasy XIV even support that?
<Azelphur> sure they do, I actually did it via xinerama for kicks once
<Azelphur> if you just trick the game into thinking it's running on one big monitor, it usually works well
<Azelphur> Sarvatt: you can also do cool things with WoW like move the viewport around and use a second screen for the UI while keeping the first screen totally clear for the viewport :)
<Sarvatt> Azelphur: next step http://www.youtube.com/watch?v=QiYDbdHB548&feature=related :)
<Azelphur> haha :D
<Azelphur> I have 4 x 1920x1200 landscape (7680x1200), I nearly have what he has :D
<bryceh> :-)
<Azelphur> those are only running at 1680x1050 I think, still fun though :)
<Azelphur> I've always said that if nvidia got their stuff sorted out for scaling across GPU's I'd buy another 2 monitors \o/
<Sarvatt> Azelphur: long shot but try Option "UseEvents" "false" in your xorg.conf, that did help me with my dying gpu
<Azelphur> I saw something about that, doesn't it reduce performance?
<Sarvatt> i have no idea to be honest
<Azelphur> Hehe, easiest way to find out is to try I guess :)
<Sarvatt> it worked with that for another 2 months before it really died and wouldn't even work in windows anymore
<Azelphur> haha
<Sarvatt> are you getting NVRM messages when it happens in dmesg too?
<bryceh> Sarvatt, take it you survived the hurricane?
<Sarvatt> bryceh: yeah, barely noticed it here somehow
<Azelphur> Sarvatt: nope, nothing in dmesg :(
<RAOF> Hm.  A surprising number of people are having the mesa upgrade break their systems because they've installed multiarched nvidia drivers from somewhere.
<tjaalton> oh
<ricotz> RAOF, on natty?
<RAOF> ricotz: Yes.
<RAOF> ricotz: Incidentally, are you coming to UDS?
<ricotz> the nvidia driver in edgers for natty is multiarched as the rest of the xorg stack
<ricotz> RAOF, perhaps, i signed for sponsorship
 * RAOF goes to see if he can +1 that anywhere
<ricotz> nice ;)
<RAOF> ricotz: I guess quite a lot of people are installing _just_ nvidia-current from -edgers, or something.
<RAOF> bug #833149 and bug #833841, if you're interested.
<ubot4> Launchpad bug 833149 in mesa (Ubuntu) "package libglu1-mesa 7.10.2-0ubuntu2.1 [modified: usr/lib/libGLU.so.1.3.071000] failed to install/upgrade: problemi con le dipendenze - lasciato non configurato (affects: 1) (heat: 6)" [Undecided,Invalid] https://launchpad.net/bugs/833149
<ubot4> Launchpad bug 833841 in mesa (Ubuntu) "libgl1-mesa-glx alternative link (affects: 4) (dups: 1) (heat: 24)" [Undecided,Incomplete] https://launchpad.net/bugs/833841
<ricotz> RAOF, yeah, i is my quess too, since 285.03 might no be available so widely
<RAOF> Anyway, time for dinner here!
<bjsnider> ricotz, if they installed anything from edgers they shouldn't complain about breakage
<Sarvatt> well the dri1 only drivers being dropped will save 400KB off the livecd at least
<Sarvatt> libgl1-mesa-dri_7.12.0~git20110826.3bcb9a85-0ubuntu0sarvatt_i386.deb (2.9 MiB) libgl1-mesa-dri_7.12.0~git20110829.beca3316-0ubuntu0sarvatt2_i386.deb (2.5 MiB)
<Sarvatt> anyone around using xorg-edgers on amd64 natty?
<Sarvatt> if so, can ya try adding foreign-architecture i386 to /etc/dpkg/dpkg.cfg.d/multiarch, apt-get updating and paste what happens when you try to do a apt-get install libgl1-mesa-dri:i386?
<Sarvatt> should be working now but want to be sure
<bjsnider> would there be an advantage to running 32-but mesa?
<Sarvatt> wine, google-earth, 32 bit flash all require it on amd64
<bjsnider> i c
<Sarvatt> they've been broken since i multiarched natty mesa making ia32-libs mesa stop working
<bjsnider> ricotz, are you seeing any kind of issue in gnome 3 where you can't rename a file using nautilus?
<ricotz> bjsnider, havent seens such problem with nautilus
#ubuntu-x 2011-08-30
<bryce_> http://i.imgur.com/vRTRP.jpg
#ubuntu-x 2011-08-31
<tjaalton> huh, mesa doesn't build from the git tree
<tjaalton> would've tried the swrast_tfp patches
<tjaalton> it doesn't find install-sh et al
<jcristau> yes, it's a pain in the ass
<tjaalton> ah, at least a known pain :)
<jcristau> there are symlinks in upstream git, but the tarball is built with --dereference
<tjaalton> sigh
<jcristau> and dpkg-source doesn't know how to deal with files turning into symlinks
<tjaalton> okay
<tjaalton> oh crap, not enough disk space to build mesa on the i386 laptop, sigh
<tjaalton> ..and 2GB worth of kernel headers purged, should be enough
<tjaalton> meh, the second patch of the tfp series doesn't apply because of the symlink hell
<jcristau> tjaalton: what i'm doing so far is keep the symlinks in git, but replace them with a copy of the actual file before building
<tjaalton> if I comment out the part that deletes the other file, it applies fine on the git tree, but not with pbuilder
<jcristau> to keep dpkg-source happy
<tjaalton> meh, need to have a closer look later ->
<tjaalton> ok, got the tfp patches sorted. the problem is that git doesn't have sw/dri_drawable.c at all, but the tarball does (a dupe of common/dri_drawable.c)
<tjaalton> so the patch doesn't apply to the git tree, but builds fine on pbuilder. tomorrow I'll see if it actually works
<tjaalton> well, the second patch is useful only on master anyway
<tjaalton> ok, it works somewhat, every window is just white, though :)
#ubuntu-x 2011-09-01
<tjaalton> soo, marcheu said that someone else should track the bugs in llvmpipe to make tfp usable on !chromeos :)
<Sarvatt> sounds like you're volunteering :)
<tjaalton> sounds like I wouldn't know where to start :)
<RAOF> piglits!
<tjaalton> RAOF: ok if I push the patches to oneiric? swrastg being shipped in -dri-experimental there is no OOTB regression to be seen, so it's low risk
<RAOF> Yeah, make it so.
<tjaalton> then I could try piglit
<RAOF> Hm, actually - do they touch any other DRI driver?  Parts of llvmpipe are included in r300 and r600, IIRC.
<tjaalton> no, just glx/drisw_glx.c and sw/dri_drawable.c
<tjaalton> doubt the others use those
<tjaalton> gallium/state_trackers/dri/sw/dri_drawable.c is the other file
<RAOF> Could you grep for symbols from there in the r300 and r600 drivers?
<tjaalton> yeah I'll check those before pushing it
<RAOF> tjaalton: Seen airlied's comment in #dri-devel?  Seems like ajax might have already fixed that on a branch.
<tjaalton> RAOF: ah, nice
<tjaalton> I'll check it out
<tjaalton> heh, done over two months ago
<tjaalton> based on the same patches by nobled
<tjaalton> nice, so starting firefox is enough to break the window stacking in unity
<tjaalton> the dash etc appear below everything else after ffox startup
<tjaalton> not a new bug, but confirmed how to reproduce
<RAOF> Works here (mostly âº).
<tjaalton> of course it does :)
<Sarvatt> RAOF: that keyboard is US $199.99 / EU â¬199.99
<RAOF> So like $100 AUD :).  But bah!  So expensive.
<Sarvatt> so probably $899 AUD even though its worth less than USD now
<Sarvatt> yeah just import it from europe :)
<Sarvatt> i wouldn't mind one without the SWTOR branding when they make it
<RAOF> Eh, the branding doesn't look *too* bad.  At least from their advertising materials, which I'm sure are a trustworthy source!
<Sarvatt> http://gamelitist.com/press/wp-content/uploads/2011/08/RazerBlade.jpg look familiar? :)
<Sarvatt> well the panel on the side at least, holy crap what is wrong with those keys on the laptop
<RAOF> They've been huffing too much Apple juice.
<RAOF> Probably adulterated with fermented rice.
#ubuntu-x 2011-09-02
<tjaalton> RAOF: btw, did you commit the git-cleanup on the mesa ubuntu branch on purpose?
<RAOF> Rather than on the debian-branch?  No; I thought I'd done it in debian?
<tjaalton> well, is it more than a matter of taste should we keep git as close to upstream as possible, and only cleanup the symlinks before building but not commit the changes?
<tjaalton> I don't have a strong opinion there, just noticed that I couldn't build a source package from the debian branch
<tjaalton> and noticed the dif
<tjaalton> diff
<RAOF> Hm.  It was meant to be set up so that you *could* build a source package from the branch.
<RAOF> That doesn't work?
<tjaalton> yeah it works from the ubuntu branch :)
<RAOF> Oh, right :)
<tjaalton> but not the binary build, need bin/install-sh for that
<RAOF> Yeah.  That needs to happen in a chroot.
<RAOF> Or, rather, in an unpacked source package.
<tjaalton> yep
<tjaalton> with the mesa swrast patches from ajax compiz runs, unity is still "weird" but overall it works. compiz takes 150% cpu though on a core2 :P
<jcristau> that leaves plenty of cpu free for other tasks
<jcristau> :)
<tjaalton> yeah!
<tjaalton> I need to try it on the sis laptop..
<tjaalton> it'll boil
<RAOF> Use that heat to distil alcohol!
<tjaalton> got plenty already :)
<tjaalton> could fry an egg or two though, since I'm hungryy.. ->
<Sarvatt> ricotz: https://launchpadlibrarian.net/78736960/buildlog_ubuntu-oneiric-i386.mesa_7.12.0~git20110901.49e24d3b-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz
<Sarvatt> wayland packages need updating?
<ricotz> Sarvatt, mhh
<Sarvatt> my thoughts exactly :(
<ricotz> why doesnt mesa have a proper buildsys to check for its dependencies :\
<ricotz> but it looks like that
<Sarvatt> because windows
<ricotz> there were quite some commit for wayland lately
<Sarvatt> its in pkg-xorg now isnt it? might be able to start updating it in my daily build script
<ricotz> yes, but better to use the ubuntu branch
<Prf_Jakob> ricotz: You know, we do actually have a autoconf part which is the part that does the dependancy checking.
<Prf_Jakob> ricotz: so its only the developers that adds the wayland part that fails to add checks.
<ricotz> i see
<ricotz> it is also hard to check for unreleased version of libraries ;)
<Prf_Jakob> that too
<Sarvatt> ricotz: hmm, pretty sure i got wayland working with auto-xorg-git, are version strings like wayland-0.1+git20110902.25fddf65 going to mess anything up?
<ricotz> Sarvatt, should be atleast 0.1.0
<Sarvatt> just pushed it to lp:~xorg-edgers/xorg-server/xorg-pkg-tools, ./auto-xorg-git -d origin/ubuntu -t + -a 0ubuntu0sarvatt -g -p wayland seems to dtrt
<ricotz> like 0.1.0~git...
<Sarvatt> okie easy enough
<ricotz> to actually override the oneiric one
<Sarvatt> oh joy http://paste.ubuntu.com/680825/ :)
<Sarvatt> just need to set PACKAGE_VERSION=0.1.0 in a hook then and use -t '~' instead of -t +
<Sarvatt> wayland (0.1.0~git20110902.25fddf65-0ubuntu0sarvatt) oneiric; urgency=low there we go
<Sarvatt> just need to patch the symbols and i'll push it all to xorg-pkg-tools
<Sarvatt> bryceh: wasnt there a work item to put git wayland in xorg-edgers somewhere?
<Sarvatt> that took all of 15 minutes, sheesh
<bryceh> Sarvatt, yep
<bryceh> Sarvatt, thanks!
<ricotz> Sarvatt, did you remove the hard dep in rules?
<bryceh> Sarvatt, yeah you'd been blocked by something when I asked last time, but I don't remember what the issue was
<Sarvatt> ah yeah it was mesa not having wayland support
<Sarvatt> ricotz: nope, looking into that now
<ricotz> ok
<Sarvatt> bryceh: well hold off marking it done, this symbols stuff might be tricky
<Sarvatt> ricotz: any pointers on what the right way to get around the symbols is? patch debian/libwayland0.symbols.in in a hook? can ya bzr branch lp:~xorg-edgers/xorg-server/xorg-pkg-tools and do a ./auto-xorg-git -H hooks-sarvatt -d origin/ubuntu -t '~' -a 0ubuntu0ricotz -g -p wayland to see if ya spot any problems?
<ricotz> Sarvatt, just remove the symbols check in rules and change c4 to c1
<Sarvatt> ricotz: c0?
<Sarvatt> c1 fails because symbols disappeared
<ricotz> for this purpose c0 is fine too, but then you can drop the whole section "# Generate hard dependencies:"
<ricotz> oh there are?
<Sarvatt> yeah
<ricotz> oh right the symbols file contains 0.1.0~0 instead of 0.1.0
<ricotz> dropping the whole section should be fine then
<ricotz> assuming the git builds are done in sync it should work
<Sarvatt> done in sync with mesa, or wayland-demos too?
<ricotz> oh right, demos would need to be updated too
<Sarvatt> ok think i got it going now, just need to add wayland-demos support to auto-xorg-git then get that updated too
<Sarvatt> really appreciate the help ricotz
<bryceh> awesome
<ricotz> Sarvatt, oh, thought i wasnt much of a help here, i am not really present
<Sarvatt> \o/ the optional cairo-egl patch was upstreamed in wayland-demos
<Sarvatt> so mesa doesnt even build with wayland master ( http://paste.ubuntu.com/680881/ ), and wayland-demos will be broken without a mesa rebuilt against the new one, i'll hold off uploading all this for now
#ubuntu-x 2011-09-03
<lucazade> hi! any hint to which package I should file a bug for this performance degradation?
<lucazade> http://ubuntuforums.org/showthread.php?t=1815146&page=2
<lucazade> glxgears says half fps in oneiric compared to natty
<tjaalton> it's not a benchmark
<lucazade> tjaalton I know it is not a bench
<lucazade> but always give the same good result in old releases and only oneiric gives bad
<lucazade> and the experience using oneiric is slow even not using glxgears
<jcristau> so if something that actually matters becomes slow, say that.  don't say glxgears has less fps.
<lucazade> so suggest me a real bench
<jcristau> whatever you actually want to use
<tjaalton> unity has issues with the nvidia blob, i'm told
<lucazade> i used /usr/lib/xscreensaver glbur as bench but it is no more available in OO
<lucazade> it happens also with intel drivers
<lucazade> and without unity
<tjaalton> blame the driver then
<lucazade> all the drivers? 
<lucazade> :)
<tjaalton> well, intel should sync to the refresh rates, so you get 50fps
<tjaalton> that's not a regression
<tjaalton> same with ati i think
<lucazade> intel gma500 drivers
<tjaalton> poulsbo
<lucazade> yes
<tjaalton> crappiest driver anyone has ever seen, if you even got them working
<lucazade> i'm sure the same happen with ati cards i have
<lucazade> yep, anyway poulsbo is not the matter here
<lucazade> Sarvatt, bryceh any hints? ^^
<bryceh> lucazade, hint for solving performance problem?  It'd be find some sap to take your gma500 away.
#ubuntu-x 2011-09-04
<macer1> Hi
<macer1> can somebody from Xorg team look on my bug report?
<macer1> link: https://bugs.launchpad.net/ubuntu/+source/utouch/+bug/840433
#ubuntu-x 2012-08-27
<ricotz> bryceh, tjaalton, nvidia 304.43 was release and is working with 1.13rc5
<ricotz> bjsnider, ^
<bryceh> ricotz, thanks for the head's up.
<ricotz> uploaded to xedgers already
<bjsnider> ricotz, yeah it's not stable though right?
<ricotz> bjsnider, it is a stable release
<ricotz> http://www.nvidia.com/object/linux-display-amd64-304.43-driver.html
<bryceh> tjaalton, btw I fiddled with http://www.bryceharrington.org/Arsenal/ubuntu-x-swat/Reports/package_status.html.  It had been hitting an error due to an invalid cert for wiki.ubuntu.com.
<bryceh> tjaalton, not certain if that was preventing the page from being updated (looks like basically the same versions on stuff as before more or less), but it is definitely updating now.  I also tacked on a date so we can more easily spot if it gets out of date.
<bjsnider> ricotz, why release another blob so soon?
<bryceh> tjaalton, one downside is that PackageNotes won't be showing up until the cert issue is resolved (or I can figure out a workaround)
<ricotz> bjsnider, why not
<bryceh> the described bugs sound reasonably serious
<ripps> Does the newest Nvidia fix the X crashes with Compiz/Gnome-Shell?
<ricotz> yes
<ripps> awesome, d/ling form edgers now
<bjsnider> ricotz, does nvidia-settings build?
<ricotz> bjsnider, yes, it is in edgers
<bjsnider> ricotz, are your nvidia-settings scripts available somewhere?
<tjaalton> bryceh: nice, thanks
#ubuntu-x 2012-08-28
<bryceh> tjaalton, looks like we got a slew of xserver bug reports about 7 days ago - http://www.bryceharrington.org/Arsenal/ubuntu-x-swat/Reports/totals-quantal-workqueue.svg
<bryceh> tjaalton, probably those SIGABRT bugs I'm guessing, somehow related to the X stack update?
<RAOF> bryceh: Those SIGABRT bugs are likely related to dropping the rethrow-signals patch and lightdm passing -core instead.
<RAOF> bryceh: ie: we'll now be getting more apport crashes than before (because -core is more reliable at dumping core) but they'll be marked as SIGABRT because that's how -core dies. If that turns out to be annoying we can post-process the dumps in the xorg-server apport hook to extract the right signal.
<bryceh> RAOF, makes sense, although isn't it odd there was a sudden jump over the period of 1-2 days then it went back to the previous rate
<RAOF> Yeah, that is a bit odd.
<RAOF> ...actually, not *that* odd.
<RAOF> Because whoopsie's duplicate detection would be kicking in, and wouldn't be letting people file new bugs.
<bryceh> skimming traces, it looks like we're getting good stack traces.  I'm curious why the titles aren't being filled in though.  Would be more helpful if they specified the symbol
<bryceh> hmm, reasonable hypothesis re whoopsie.  I don't think it was noticing X crashes previously though; if it is now then I can cross off a work item!  :-)
<bryceh> interesting; we have a topic page for xorg.  http://status.ubuntu.com/ubuntu-quantal/group/topic-quantal-desktop-xorg.html
<RAOF> So, to extract that, we'd want to post-process the backtrace and extract the signo out of OsSigHandler; that's got the right signal.
<RAOF> Hm. Actually, so does Xorg.0.log; the log should say ?Server crashed with signal 11 (SIGSEGV)?
<RAOF> That might be more reliable.
<bryceh> hrm, errors.ubuntu.com seems not to be loading the problems list
<bryceh> RAOF, yeah agreed those should be improved so the titles are clearer
<RAOF> In my experience errors.ubuntu.com takes *ages* to load.
<RAOF> Probably because it's scraping launchpad.
<bryceh> aw well
<bryceh> here we go
<bryceh> ok one bug against xserver-xorg-core this month, ranked at 28:  https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1033533
<ubottu> Launchpad bug 1033533 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT" [Medium,Confirmed]
<bryceh> RAOF, so I'll take that as confirmation of that hypothesis
<bryceh> src=0x0
<RAOF> Yeah, that's not going to end well :)
<RAOF> Also, hurray! Working backtraces from xserver bugs!
<bryceh> indeed :-)
<bryceh> if I had time I could even totally triage all these
<bryceh> bet that one is an easy fix though
<tjaalton> bryceh: some of them seem to be due to nouveau dri/ddx
<bjsnider> ok, so there's going to be a fourth legacy blob series, the 304
<bjsnider> so there will need to be a special package, perhaps nvidia-304 or something, created for that
<tjaalton> fourth yes, but -71 isn't alive anymore
<seb128> can the xorg-edger nvidia's binary drivers be installed on a quantal stack?
<shadeslayer> hi, the last X upgrade on quantal has rendered my X useless, xorg.log says it can't find any device
<tjaalton> log please
<tjaalton> seb128_: probably
<seb128_> tjaalton, thanks
<shadeslayer> yeah, I will need a couple of minutes :)
<tjaalton> pastebinit /var/log/..
<shadeslayer> http://paste.kde.org/540530
<tjaalton> a hybrid laptop?
<tjaalton> pastebin dmesg too
<shadeslayer> yep
<shadeslayer> sec
<shadeslayer> paste.kde.org/540536
<tjaalton> macbook..
<shadeslayer> uh yeah, it worked just fine till about a hour ago
<tjaalton> and why the heck do you have nomodeset on the kernel cmdline?
<shadeslayer> won't boot without it
<tjaalton> well that dmesg is useless
<shadeslayer> uh ok
<tjaalton> what do you mean "until an hour ago"? mesa is the only update since couple of weeks
<shadeslayer> lemme pastebin last couple of lines from apt logs
<shadeslayer> paste.kde.org/540542
<tjaalton> do you have the previous xserver-xorg-core in /var/cache/apt/archives?
<shadeslayer> nope
<shadeslayer> but I can download stuff since I have my phone tethered
<shadeslayer> also have that package installed already
<tjaalton> it shouldn't matter, there was an update to an arm-specific patch
<tjaalton> mesa got an update to fix an intel bug
<tjaalton> so when was your previous reboot before the upgrade?
<shadeslayer> 4 days ago
<tjaalton> and didn't upgrade anything between?
<shadeslayer> I most likely did
<shadeslayer> checking
<tjaalton> do you get the plymouth splash?
<shadeslayer> mesa upgrade 2 days ago, that's from 8.0.4 to 9.0
<shadeslayer> uh, was out of the room for that part, lemme reboot and check
<tjaalton> without nomodeset
<shadeslayer> I am certain I won't be able to boot without it
<shadeslayer> yep, only a black screen
<tjaalton> so kernel is broken somehow
<shadeslayer> hm ...
<shadeslayer> I have always booted with nomodeset
<tjaalton> ha
<tjaalton> so no regression
<shadeslayer> since without it it never works
<tjaalton> ok, so probably your X got upgraded within the four days, meaning now your ati doesn't support non-kms anymore
<shadeslayer> and with nomodeset I get Plymouth
<shadeslayer> oh 
<tjaalton> dunno why it doesn't fall back on vesa then
<tjaalton> well, tries and fails
<shadeslayer> ok, any suggestions on what I can do ?
<tjaalton> nope..
<shadeslayer> blergh
<shadeslayer> tjaalton: thanks anyway
<tjaalton> try a newer kernel?
<tjaalton> 3.6-rcx
<tjaalton> without nomodeset
<shadeslayer> hm ...
<shadeslayer> looking at the mainline debs 
<shadeslayer> ok, Plymouth came up with 3.6 and not passing nomodeset
<shadeslayer> wat
<shadeslayer> a error occured while mounting boot
<tjaalton> uh, how to install the backport stack on precise? enable the ppa, then what?
<tjaalton> thought there was one package that would pull it all, including the kernel
<ricotz> tseliot, hi
<ricotz> tseliot, please drop the 3.6 buildfix patch which isnt needed anymore and break the build
<ricotz> also please lower xserver-xorg-core (>= 2:1.11.99.901) to (>= 2:1.10.99.901) to make the lts-backport easier
<tseliot> ricotz: I'll do that tomorrow. Thanks
<Prf_Jakob> Sarvatt_, bryceh: Regarding the vmwgfx bug where it didn't start, I think the patches Dave Airlie posted will fix those.
<bryceh> Prf_Jakob, thanks
<shadeslayer> tjaalton: if you're awake, using 3.6 rc3 without nomodeset gives me a orange screen ... not sure how else to describe it
<bryceh> shadeslayer, check dmesg?
<shadeslayer> bryceh: uh ... I kind of hacked my way around stuff and got everything working
<shadeslayer> using nomodeset, and specifying X to use fbdev in /etc/X11/Xorg.conf
<shadeslayer> and I can't post dmesg because I can't switch to a tty when not using nomodeset
<bjsnider> an orange screen
<bjsnider> don't think i've heard of that before
<shadeslayer> :D
<shadeslayer> I've never seen one before :P
<bjsnider> i guess ubuntu now has the orange screen o' death
<shadeslayer> lol
<shadeslayer> lemme reboot without nomodeset and no xorg.conf and try to switch to a tty
<shadeslayer> new color this time
<bjsnider> purple would make sense
<shadeslayer> http://db.tt/b8KiiYRu 
<shadeslayer> not exactly purple :P
<bjsnider> you should be able to get to a tty from that
<shadeslayer> nope
<shadeslayer> no amount of ctrl-alt-f1 gives me a tty
<bjsnider> f1-f6
<shadeslayer> tried all of them
<bjsnider> if you touch the lock keys do the lights on the keyboard light up?
<shadeslayer> sure
<shadeslayer> on a external keyboard 
<bjsnider> the keyboad is working then
<shadeslayer> caps lock lights up on the onboard keyboard, so that works as well
<shadeslayer> bjsnider: why the aversion to nomodeset ? 
<shadeslayer> hm, dmesg.2 is empty
<shadeslayer> that's the boot without nomodeset
<bjsnider> the modern drivers need kms
<shadeslayer> bjsnider: oh ok
<shadeslayer> well, like I said, no dmesg logs from the boot without nomodeset
#ubuntu-x 2012-08-29
<tjaalton> shadeslayer: did you also install the linux-image-extra -package?
<tjaalton> which has the drm drivers..
<shadeslayer> yus
<tjaalton> ok
<tjaalton> time to chat with #intel-gfx then i guess
<shadeslayer> I *think* dmesg saves the logs of previous boots as dmesg.n.gz
<tjaalton> it sholud
<tjaalton> *should
<shadeslayer> so I gunzipped the last couple of logs and they were empty
<tjaalton> could you try a livecd?
<shadeslayer> already did :)
<tjaalton> to rule out a funky install
<tjaalton> k
<shadeslayer> needs nomodeset as well
<shadeslayer> I think I've pretty much tried out everything :D
<tjaalton> well, maybe efi is playing tricks here
<shadeslayer> could be
<shadeslayer> tjaalton: ok so one thing that I don't understand
<tjaalton> is this the latest revision of mbpro?
<shadeslayer> nope
<shadeslayer> 8,2
<tjaalton> i'd expect that to work
<tjaalton> try fedora17! :)
<shadeslayer> CONFIG_DRM_I915=m
<shadeslayer> CONFIG_DRM_I915_KMS=y
<shadeslayer> tjaalton: tried already :P
<shadeslayer> doesn't boot *at all*
<tjaalton> kms built into the drm driver
<shadeslayer> https://twitter.com/rohangarg/status/236890703375003648
<tjaalton> right, mjg59 should know this stuff
<shadeslayer> exactly, he said that it's most likely a bug ( as you can see from the conversation we had )
<tjaalton> since he has worked with macbooks
<shadeslayer> yeah
<shadeslayer> earlier, if I didn't provide a xorg.conf it used to say VBIOS out of memory
<shadeslayer> or was it trying to address out of bounds memory ... can't remember
<tjaalton> try blacklisting efifb
<shadeslayer> for my current issues?
<tjaalton> yes
<shadeslayer> ok
<tjaalton> echo "blacklist efifb" >> /etc/blacklist-local.conf
<tjaalton> or such
<shadeslayer> ofcourse
<tjaalton> then boot without nomodeset
<shadeslayer> should I just put it in /etc/modprobe.d/blacklist.conf
<shadeslayer> or blacklist-local.conf specifically
<tjaalton> -local would be better, blacklist.conf is owned by module-init-tools
<shadeslayer> rebooting
<tjaalton> "the i915 driver requires a patch activating dual LVDS channels, otherwise it will show nothing but a black screen;"
<tjaalton> huh
<tjaalton> http://dentifrice.poivron.org/laptops/macbookpro8,2/
<tjaalton> would assume that's in the kernel by now
<shadeslayer> iirc that was in
<shadeslayer> and efifb doesn't help
<shadeslayer> I get a coloured screen
<shadeslayer> *and disabling efifb doesn't help
<tjaalton> well, check that page for further ideas
<thumper> hello magic X people
<thumper> with the new compiz, I keep hitting this bug: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/966744
<ubottu> Launchpad bug 966744 in compiz (Ubuntu Quantal) "[i965] Resume from suspend leaves me with black screen or a screen of the desktop before it suspended. Compiz hung in intel_update_renderbuffers() from intel_prepare_render() from brw_draw_prims()" [Critical,Triaged]
<thumper> new code paths in compiz rendering seem to be hitting this more and more
<tjaalton> new compiz where?
<thumper> I'm using the unity-team staging ppa
<tjaalton> precise or quantal
<thumper> it is the one we want to release into quantal
<thumper> OpenGL/ES work
<tjaalton> yes, would be nice to get it fixed..
<thumper> anything I can do to help?
<tjaalton> if you're seeing it in quantal, then it's not fixed yet
<thumper> no...
<thumper> no it's not
<tjaalton> there were people seeing it fixed in quantal
<thumper> hmm...
<tjaalton> actually, xorg-edgers but they aren't that different
<thumper> my symptoms are a little different but I'm told the stack trace is the same
<tjaalton> told by who?
<thumper> duflu (compiz dude)
<tjaalton> ok
<thumper> http://pastebin.ubuntu.com/1173379/
<thumper> that is from the hang I got in compiz
<thumper> htop showed 100% cpu usage on one core
<thumper> but no item had any cpu usage
<thumper> perhaps kernel
<tjaalton> yeah
<tjaalton> can you reproduce it at will?
<thumper> pretty much every time I log in
<tjaalton> huh, ok
<thumper> I have to switch to a vt and restart compiz
<tjaalton> then perhaps try a newer mainline kernel from the mainline ppa?
<tjaalton> but that doesn't help?
<tjaalton> restarting
<thumper> actually no, restarting compiz would get it to hang in the same place
<thumper> I had to restart light-dm
<tjaalton> right
<tjaalton> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-rc3-quantal/
<tjaalton> get linux-image and -extra
<tjaalton> which ppa is it, I can give it a go
<thumper> ppa:unity-team/staging
<thumper> you'll be one the bleeding edge with compiz/unity
<thumper> tjaalton: shall I install the linux-image and -extra?
<thumper> I'm downloading them now
<tjaalton> thumper: yeah please
<thumper> ok
<tjaalton> which intel hw gen is it?
<thumper> Mobile IntelÂ® GM45 Express Chipset  
<thumper> does that tell you?
<tjaalton> yes
<tjaalton> i've got gen6 (sandybridge) ready for testing..
<tjaalton> but the original bug is seen on that too, so probably doesn't matter which gen it is
<thumper> my ivybridge laptop lands in the country tomorrow
<thumper> biggest/fastest I could find
<tjaalton> nice
<thumper> system76
<tjaalton> ouch :)
<thumper> maxed out gazelle pro
<thumper> stopped at 480gig ssd
<tjaalton> nah, i'm just a thinkpad junkie, so been spoiled by t420s for a year now
<thumper> as the 600 was sataII not sata III
<thumper> I can't stand the damn red nipples
<thumper> would drive me spare just to know it was there
<tjaalton> the best feature they have :)
 * thumper hates them
<thumper> ok, debs downloaded
<tjaalton> i hate touchpads, then again this is the first laptop for me that has one
 * thumper wonders where chromium put them
<thumper> hmm my destop no longer shows Desktop
<thumper> tjaalton: probably have to reboot right?
<tjaalton> yup
<thumper> see you soon ...
<thumper> tjaalton: nope... still there
<thumper> tjaalton: first login causes it to freeze
<tjaalton> duh
<thumper> tjaalton: restarting was ok briefly
<tjaalton> hmm, seems to work here
<thumper> tjaalton: then compiz crashed...
<thumper> kernel was at 100% cpu again
<thumper> seems to have settled again for a while
<tjaalton> so could be related to the older generation after all
<tjaalton> ok let me upgrade my old laptop which should have the same generation chip on it..
<tjaalton> 965GM but still
<thumper> ok
<tjaalton> thumper: seems to work fine on the other laptop too :/
<thumper> :(
#ubuntu-x 2012-08-30
<Chipaca> hi everybody
<Chipaca> my touchpad's stopped scrolling a couple of days ago
<Chipaca> known issue, or should i report it?
<Chipaca> ah! chrisccoulson refers me to bug #1041594
<Chipaca> thanks
<ubottu> Launchpad bug 1041594 in linux (Ubuntu) "Edge scrolling on touchpad broken since the upgrade to 3.5.0-11" [Medium,Incomplete] https://launchpad.net/bugs/1041594
<shadeslayer> what was the command that allowed me to check what was using up alot of X's memory?
<jcristau> xrestop
<tjaalton> Chipaca: thanks, was wondering about that myself..
 * shadeslayer installs to check what's hogging all his memory again
<shadeslayer> bleh, kwin taking 5220256K
<tjaalton> seb128: you tagged bug 1031784 with regression-proposed, because of the irrelevant comment by bluedream?
<ubottu> Launchpad bug 1031784 in xserver-xorg-video-intel (Ubuntu) "Artifacts on screen with ivy bridge" [High,Fix committed] https://launchpad.net/bugs/1031784
<seb128> tjaalton, I didn't tag it regression-proposed? I just dropped the rls-q-incoming tag because it's dealt with
<tjaalton> ah
<tjaalton> hum, well I closed it for quantal too, it's done :)
<tjaalton> maybe that tag is automatic for updates
<tjaalton> someone has not pushed the ubuntu-precise branch of -synaptics
<tjaalton> and that someone is on vacation :)
<bryce> heh
<tjaalton> I'll add a patch that fixes bug 956071
<ubottu> Launchpad bug 956071 in OEM Priority Project precise "Xorg crashed with SIGSEGV in XIGetDeviceProperty()" [High,Confirmed] https://launchpad.net/bugs/956071
<tjaalton> only s/UNRELEASED/precise-proposed/ missing, so not an issue really
<tjaalton> yeah.. the patch works
<tjaalton> RAOF: unless -synaptics for precise-proposed has passed the queue once you start your day, could you give it a gentle nudge so people can have less crashes :)
#ubuntu-x 2012-08-31
<RAOF> tjaalton: Certainly. Could you add the reproduction steps from the patch to the bug?
<ml|vacation> RAOF: hm, am I mistaken or is 1aud$ still .50$ in terms of what you can buy with it, except the echange rate says otherwise?
<RAOF> ml|vacation: Depends on what you're buying.
<ml|vacation> food
<RAOF> ml|vacation: *Domestic* prices haven't changed much with the higher AUD, obviously.
<RAOF> It's now substantially cheaper to buy things from the US in AUD, though.
<ml|vacation> yeah :s
<ml|vacation> but as an outsider paying 4$ for some honey...
<ml|vacation> used to pay half of that  or less  :)
<RAOF> Yeah. Sucks to be travelling *to* Australia.
<ml|vacation> unfortunately for you if the exchange rate n
<ml|vacation> ormalizes again, they use that as excuse to bump the prices*
<tjaalton> RAOF: alrighty, I'll add that
<tjaalton> actually those steps need a newer xinput than what precise has, but you can simulate it with suspend/resume
<RAOF> Whatever works :)
<tjaalton> ml|vacation: hey, your valgrinding helped fixing the synaptics bug :)
<tjaalton> RAOF: ha, dronus added it already
<tjaalton> but I'll edit the header
<ml|vacation> tjaalton: great :)
<ml|vacation> will it be sru'd to precise too? :)
<tjaalton> uploaded already :)
<tjaalton> and accepted, it seems
<tjaalton> and works, I verified it
<ml|vacation> so all the scary x bbugs are gone now?
<tjaalton> nice that the new version of xinput lets you disable/enable devices
<tjaalton> not exactly
<tjaalton> there's still this weird intel gpu hang causing compiz to spin (black screen, cursor changes). happens on quantal too :/
<ml|vacation> oh, but the xi bugs are gone?
<tjaalton> and thumper said he could reproduce it immediately after login with the proposed unity stack from a ppa
<tjaalton> ah, hope so
<tjaalton> (i tried to reproduce the hang but couldn't)
<thumper> new driver?
<tjaalton> oh hey :)
<ml|vacation> ok well great, back to vacationing, ttyl :)
<tjaalton> ml|vacation: yeah, cya
<tjaalton> thumper: so, I can reproduce it but only on resume, and not that frequently
<tjaalton> thumper: was wondering if your compiz/unity setup was something else than the ~default I have
<thumper> yes, yes it is
<thumper> I'm running pre-quantal branches
<thumper> as in, stuff that should land in quantal soon
<tjaalton> me too, but the configuration of compiz?
<thumper> ppa:unity-team/staging has new compiz and unity
<thumper> nothing special
<tjaalton> k
<thumper> sorry, have to go
<thumper> time to get kids
<thumper> and take the rest of the weekend off
<thumper> kiwi pycon \o/
<tjaalton> mine will wake up in 1-2h
<thumper> ew
<tjaalton> :P
<tjaalton> early
<thumper> that's rough
<RAOF> tjaalton: Is that compiz spinning, or compiz blocked waiting for a vblank?
<thumper> hi RAOF
<RAOF> thumper: Yo!
<tjaalton> thumper: got the strace somewhere?
<thumper> RAOF: it is inside the driver
 * thumper digs
<tjaalton> could get it from irclog..
<tjaalton> actually, my other laptop is hung like that now
<RAOF> Is compiz burning CPU, or is it just not doing anything?
<tjaalton> I could dig one from that too
<tjaalton> not burning cpu here
<tjaalton> unless I try to restart it iirc
<thumper> http://pastebin.ubuntu.com/1173379/
<thumper> RAOF: I do have to run
<thumper> RAOF: no, compiz is idle
<RAOF> Ooooh.
<thumper> 100% cpu on something
<thumper> but none of the htop line items
<thumper> so kernel maybe?
 * thumper really runs
<RAOF> tjaalton: You've got the same thing?
<tjaalton> RAOF: dunno of the trace, but hung yes
<RAOF> Can you attach gdb to compiz?
<tjaalton> probably, should get the symbols first
<RAOF> Yeah.
<RAOF> From thumper's trace, I guess one of two things: (a) compiz has taken out a ServerGrab and either it's on one of its other connection or mesa has its own X connection, or (b) compiz is currently GLX throttled, which would happen if it's got a SwapBuffers pending.
<tjaalton> this is bug 966744 btw
<ubottu> Launchpad bug 966744 in compiz (Ubuntu Quantal) "[i965] Resume from suspend leaves me with black screen or a screen of the desktop before it suspended. Compiz hung in intel_update_renderbuffers() from intel_prepare_render() from brw_draw_prims()" [Critical,Triaged] https://launchpad.net/bugs/966744
<RAOF> Right. So, Chris' UXA fix would be a fix for a pending swap that'll never complete, suggesting (b)
<tjaalton> those are already in quantal
<tjaalton> and on the package for precise I put there, but someone could reproduce it still
<RAOF> Which means we've got another bug; and the same reasoning applies.
<tjaalton> right, entirely possible :)
<RAOF> If you can attach gdb to compiz, I'd guess you're blocking in _XReply, like thumper.
<RAOF> The next thing to do is to attach to the server, and see if you can match up compiz' Client.
<RAOF> Well, actually, the *next* thing to do is to attach to the server and see if someone's got a servergrab, because that's easy.
<tjaalton> http://pastebin.com/raw.php?i=qBtsGKcE
<tjaalton> it's the same
<tjaalton> (got some more symbols)
<RAOF> Right. So, it's most likely either a server grab or the client being GLX throttled.
<RAOF> We can't really tell from the client side.
<tjaalton> ok how do I check the server=
<tjaalton> ?
<RAOF> Attach to the X server; there's a global serverGrab symbol you can print.
<RAOF> Sorry, grabState
<tjaalton> $1 = 0
<RAOF> Ok, so the quick and easy test is failed.
<tjaalton> bummer
<RAOF> Oh. Is the server blocked?
<RAOF> ie: where was the server when you connected gdb to it?
<tjaalton> WaitForSomething
<RAOF> Yeah, that'd be right.
<RAOF> Hm.
<RAOF> You know, you could iterate through the Client list, and see if any are throttled by GLX.
<tjaalton> ok, how do I do that?
<tjaalton> my gdb-foo is limited :/
<RAOF> There's a global clients[] array.
<tjaalton> should I know it's length to print it?
<RAOF> It's of length MAX_CLIENTS
<RAOF> Each client will have an ->ignoreCount; if that's positive, the X server is ignoring it.
<tjaalton> sure it's 'client[]'?
<tjaalton> uh
<tjaalton> too early :)
<tjaalton> ok, got pointers
<tjaalton> I mean, it returns ClientPtr
<tjaalton> 30 clients
<RAOF> Right.
<RAOF> Are any of them ignored?
<RAOF> You can use such constructs as for() and such :)
<tjaalton> still figuring out how to get that info from the pointer :)
<RAOF> It should be the ignoreClient member of the ClientPtr; ?print clients[0]->ignoreClient? should print an integer?
 * RAOF spots a probable bug in IgnoreClient/AttendClient
<tjaalton> There is no member named ignoreClient.
<RAOF> Sorry, ignoreCount
<RAOF> Sorry.
<tjaalton> yeah
<tjaalton> ok let's see..
<tjaalton> ok got one with = 1
<tjaalton> ignoreCount = 1
<RAOF> That's *likely* to be the compiz one.
<RAOF> Particularly if it's the only one with ignoreCount = 1
<tjaalton> yeah just one
<RAOF> To be sure, we'd want to work out whether any of Compiz's drawables have DRI2DrawablePtr->swapsPending > 1.
<RAOF> I can't, off the top of my head, think of a way to verify that, though.
<RAOF> I think its' reasonable at this point to blame this on the intel driver scheduling a swap that never completes.
<tjaalton> yeah, I could show the trace to #intel-gfx once someone is awake
<shadeslayer> tjaalton: \o
<shadeslayer> so here's some fun news, I got some time and messed about with grub a bit
<shadeslayer> I can now disable the ATi discrete graphics
<shadeslayer> still have to boot with nomodeset since the lvds dual channel patches are not there in the ubuntu kernel
<shadeslayer> in dmesg : [   20.258413] i915: `2' invalid for parameter `lvds_channels'
<shadeslayer> unfourtunately, I don't how to compile my own kernel with lvds patches
<tjaalton> shadeslayer: huh, someone clearly failed to send them upstream then
<shadeslayer> dunno, I think I saw them on lkml at one point
<shadeslayer> though I don't follow lkml so I don't know
<shadeslayer> atleast now the thing doesn't heat up like a frying pan
<tjaalton> right
<ml|vacation> tjaalton: yay just applied the fixed version to this laptop, think it was having the same issue on suspend ;)
<tjaalton> yep
<tjaalton> wait, another bug?=
<tjaalton> -=
<ml|vacation> no, just didn't have proposed enabled
<tjaalton> ah
<tjaalton> mesa 9.0 branched
<ml|vacation> great :)
 * apw is seeing some background corruption on quantal, trying to work out if this is X or compiz
<ogra_> apw, might be our new cubistic theme for ubiquity ....
<ogra_> https://launchpadlibrarian.net/113965811/IMG_0170.JPG
<ogra_> :P
<apw> ogra_, luckily not that :)
<tjaalton> apw: there's a known regression on intel < 965
<tjaalton> compared to mesa 8.0.x
<apw> tjaalton, we got any idea of a fix or is beta shipping wit this?
<apw> tjaalton, this is an atom netbook, would i expect that to have the right version
<tjaalton> if it's i945, that's your bug
<apw> tjaalton, how do i tell
<tjaalton> i just learned about the bug today
<tjaalton> lspci
<tjaalton> also, we have a snapshot that's over a week old
<tjaalton> bug 1042211
<ubottu> Launchpad bug 1042211 in mesa (Ubuntu) "[quantal] [regression] [i915] Corrupted display, desktop and menus don't repaint correctly using Mesa 9.0 (8.0.4 works)" [Critical,Triaged] https://launchpad.net/bugs/1042211
<apw> tjaalton, sysfs says this is an is_g33, and the pci_id points to intel_pineview_info ... so i assume its not 945
<apw> the damage i am seeing could easily be compiz as some of it is aligned well with the places it puts things
<apw> tjaalton, that said the description is definatly the same i recon
<tjaalton> apw: yeah sounds like it's no the same bug
<tjaalton> oh :)
<tjaalton> well, try the previous packages
<apw> bacground a solid colour, menus appear and return to menu background
<apw> so the background being mashed is being triggered by nautilus running there
<apw> tjaalton, yeah seem to be this issue as far as i can tell, all the mitigations work as per daniel, though performance is mindbogglingly slow with them
<tjaalton> apw: but does downgrading fix it?
<apw> which packages do nead, there seem to be 40 binary packages here for mesa
<tjaalton> libgl1-mesa-glx, -dri should be enough
<tjaalton> the bug has links
<apw> tjaalton, thanks, here goes nothing
<apw> needs -glapi as well for reference
<apw> tjaalton, ok confirmed, downgrading those mesa packages fixes it here
<tjaalton> ah
<apw> tjaalton, added the information to the bug, looks like basic netbooks are affected
<tjaalton> i believe it has i945 gfx, it should use i915_dri
<tjaalton> but anyway, too late to update the snapshot today, but monday :/
<ml|vacation> hehe :p
<ml|vacation> argh forgot to copy the whole git tree over, linux kernel has no git history now :s
<tjaalton> started looking at the update but didn't get far before eod
<tjaalton> gone again ->
<apw> ml|vacation, sounds like a mistake :)
#ubuntu-x 2012-09-01
<ml|vacation> apw: yeah :p
<ricotz> tjaalton, bryceh, hi, while going with mesa 9.0 -- libglu needs to be packaged since it moved to a separate source http://cgit.freedesktop.org/mesa/glu/
<tjaalton> ricotz: yes
#ubuntu-x 2013-08-28
<tjaalton> http://lists.freedesktop.org/archives/mesa-dev/2013-August/044021.html
<tjaalton> finally able to get rid of the alternatives, soonish :)
<mlankhorst> yay
<mlankhorst> tjaalton: but realistically it will just be another libgl alternative..
 * mlankhorst ducks
#ubuntu-x 2013-08-29
<tjaalton> glamor-egl pushed to saucy
<mlankhorst> lol there ya go
<mlankhorst> glamor-egl 0.5.1 announce
<tjaalton> bah :)
<mlankhorst> urls got truncated in the announce though :P
<mlankhorst> and no cc on xorg-announce, but still!
<tjaalton> it's a start :)
#ubuntu-x 2013-08-30
<agrester> Hello, do you know where I could download this file 'nvidia-319-319.17-0ubuntu1+xedgers~raring1'
<tjaalton> from xorg-edgers ppa
#ubuntu-x 2014-08-26
<mejo1> hi
<mejo1> is there a chance to get the displayport work with the nouveau driver on a GF119M [Quadro NVS 4200M]?
<tjaalton> on which release?
#ubuntu-x 2015-08-26
<jcastro> ricotz: mamarley: are you guys getting these emails from new volunteers? Should I just create a mailing list?
<mamarley> I have gotten a few emails.
<jcastro> ok so I think I'll create a list
<jcastro> https://launchpad.net/~graphics-drivers
#ubuntu-x 2015-08-29
<ricotz> mamarley, pushed a libreoffice rebuild with enabled kde-support
<mamarley> ricotz: Cool, thanks!  I also noticed that you uploaded the new 352.xx release to graphics-drivers. :)
<mamarley> jcastro told me about that last night, but I was without a workable PC at the moment because I was switching out my laptop for my new desktop (the one with the GTX970), but I should be able to handle the next one.
<ricotz> mamarley, don't worry, when I see a new release and have some time I will take care of if you didn't beat me yet ;)
#ubuntu-x 2016-09-01
<tseliot> ricotz, mamarley: I have just uploaded the latest nvidia driver, which now starts/stops nvidia-persistenced properly
<tseliot> you might want to have a look at the changes
 * tseliot is going to SRU that and ubuntu-drivers-common in 16.04
<ricotz> tseliot, nice :), I hope you included the 4.8 patch?
<tseliot> ricotz: I didn't, but I can easily add that
<ricotz> tseliot, alright
<tseliot> ubuntu-drivers-common should fix the bug about gpu-manager not switching off the dGPU in power saving mode
<tseliot> that's what I focused on
<mamarley> I can apply whatever changes you made to the 370 drivers.
<tseliot> yes, that would be great
<ricotz> mamarley, https://paste.debian.net/plain/801058
<mamarley> ricotz: Thanks :)
<ricotz> only xenial and yakkety
<mamarley> Why is that?  Do the others not have nvidia-persistenced?
<ricotz> they don't have systemctl iirc
<ricotz> aka no systemd
<mamarley> Ah, yes, I hadn't looked closely enough at the patch to see that it required systemd yet.
<mamarley> tseliot: I assume you have tested the uninstallation of this driver and it won't blow up like that snapd thing a while back? :)
<tseliot> I didn't add a build-dep on systemd, as the unit is started manually
<mamarley> OK :)
<tseliot> it's pretty simple stuff this time
<ricotz> tseliot, obviously it is a runtime dep ;)
<tseliot> yep
<tseliot> I could have depended on dh-systemd, though, to make sure that the unit is activated by systemd dependencies IIRC
<tseliot> luckily, this is not the case (the nvidia-prime package does it)
<mamarley> ricotz: The updated 370.23 packages are ready in https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages. :)
<ricotz> mamarley, ok
#ubuntu-x 2016-09-02
<mamarley> ricotz: Is it OK to copy those updated 370 packages to the main PPA?
<ricotz> mamarley, oh, did I fail to do so?
<mamarley> Wait, let me check.
<mamarley> ricotz: You did, sorry.  I just didn't notice.
<ricotz> ok, good
#ubuntu-x 2017-08-28
<soee> mamarley: https://blog.martin-graesslin.com/blog/2017/08/warning-nvidia-driver-384-69-seems-to-be-broken-with-qtquick/
<soee> was just informed about it when i was trying to fix kscreenlocker crashes
<mamarley> soee: Yeah, I saw that.  I'm not having any trouble here though.
<soee> on KDE ? :D
<mamarley> Of course.
<soee> what version ?
<mamarley> 5.10.5 5.37 5.9.1 (up-to-date Artful)
<soee> strange than :)
<soee> anyway i have to downgrade
<mamarley> Sorry :(
<soee> not your fault :D
#ubuntu-x 2018-08-27
<mamarley> ricotz: 390.87 is in https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages
<thomasGer> Hi!
<thomasGer> anyone some experience with X running in an lxc container?
#ubuntu-x 2018-08-28
<tseliot> ricotz, mamarley: hi, I am going to upload 390.87 in cosmic, just FYI
<tomreyn> hi, i just learnt that xdriinfo and thgus driconf is apparently generally broken in 18.04(.1). https://bugs.launchpad.net/ubuntu/+source/x11-utils/+bug/1787845
<ubottu> Launchpad bug 1787845 in x11-utils (Ubuntu) "Broken xdriinfo on Ubuntu 18.04 breaks driconf" [Undecided,Confirmed]
<tomreyn> is this something you'd be concerned about?
<tomreyn> (is there a good / better workaround?)
#ubuntu-x 2018-08-30
<RAOF> Hm. Is nvidia-390 broken on my system, is mutter broken, or are both broken?
<RAOF> Hm. Maybe it's mutter that's broken? It's fine on llvmpipe, but segfaults with Nvidia.
<mamarley> RAOF: I haven't had any issues with nvidia-390 on my laptop, but I don't use mutter.
#ubuntu-x 2018-09-01
<mamarley> ricotz: I have 396.54.02 in https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages.
<ricotz> mamarley, thanks
#ubuntu-x 2019-08-29
<mamarley> ricotz: If you look in https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages, you will see nvidia and nvidia-settings 435.21 along with libvdpau 1.3.  I still can't get -settings to build on bionic-amd64 though, and libvdpau now builds with meson, which means that it won't build on anything older than bionic anymore.
<ricotz> mamarley, hey, great!
#ubuntu-x 2019-08-30
<ricotz> mamarley, hi, are you running eoan with 435 yet?
<mamarley> ricotz: Yep, it seems to work fine.
<ricotz> mamarley, I am suspecting gnome-shell has a problem with it, at least I think it is causing my problem here
<mamarley> Yeah, I use KDE, so I wouldn't have run into that.
<ricotz> I am getting stuck in the activity-overview
<ricotz> I see
#ubuntu-x 2020-08-26
<tjaalton> h,ykhuljmjmlb  l
<tjaalton> nÃ¶l
<tjaalton> bah.. :)
