#ubuntu-x 2006-11-20
<Ubugtu> New bug: #72480 in xorg (main) "Ubuntu can't set-up with ATI Radeon 9800 Pro" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72480
<Ubugtu> New bug: #72501 in xserver-xorg-video-i810 (main) "missing depends entries for X video drivers" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72501
<Ubugtu> New bug: #72530 in xterm (main) "meta key (alt key) combinations don't work in xterm" [Undecided,Confirmed]  http://launchpad.net/bugs/72530
<Ubugtu> New bug: #72560 in xmore "xmore crashes" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72560
<Ubugtu> New bug: #72630 in xserver-xorg-video-via "Xorg Via driver DRI OOPS" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72630
#ubuntu-x 2006-11-21
<Ubugtu> New bug: #72655 in libdrm "use icheck to detect ABI breakage" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72655
<Ubugtu> New bug: #72664 in xorg-server "using "chown" in /var/crash" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72664
<Ubugtu> New bug: #72665 in xorg-server "using "chown" in /var/crash" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72665
<Ubugtu> New bug: #72666 in Ubuntu "ssh-agent spawns multiple times via Xsession" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72666
<Ubugtu> New bug: #67466 in gnome-power-manager "Edgy logs out (unwanted) on laptop lid close." [Undecided,Unconfirmed]  http://launchpad.net/bugs/67466
<Ubugtu> New bug: #72697 in linux-restricted-modules-2.6.15 "Soft lockup related to skype, sound, and ipw3945 module" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72697
#ubuntu-x 2006-11-22
<Ubugtu> New bug: #71839 in linux-restricted-modules-2.6.17 (restricted) "In Ubuntu 6.10 Edgy Eft: After install nvidia-glx and setup the system for the new driver, the Hibernate and Suspend don't resume video anymore with a nVidia GeForce 6200 AGP video card." [Undecided,Unconfirmed]  http://launchpad.net/bugs/71839
<Ubugtu> New bug: #72827 in mesa-utils "Please sync from debian/unstable (overwrite ok)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72827
<Ubugtu> New bug: #72157 in libx11 (main) "file-roller crashes while opening .gz file" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72157
<Ubugtu> New bug: #70108 in linux-restricted-modules-2.6.17 (restricted) "After an ifup ath0 the system runs very sluggish." [Undecided,Unconfirmed]  http://launchpad.net/bugs/70108
#ubuntu-x 2006-11-23
<Ubugtu> New bug: #72931 in xorg "dexconf creates a bogus xorg.conf" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72931
<Ubugtu> New bug: #71808 in gnome-power "Keyboard backlight does not work on Macbook Pro / Powerbook" [Unknown,Confirmed]  http://launchpad.net/bugs/71808
<Ubugtu> New bug: #72999 in xserver-xorg-driver-i810 "External monitor with i810 is distorted - 955GMA" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72999
<Ubugtu> New bug: #73004 in xorg "Dell 2005fpw lcd defaults to 1280x1024 instead of its native resolution of 1680x1050" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73004
<Ubugtu> New bug: #72956 in gnome-terminal "gnome-terminal crash unexpected" [Medium,Rejected]  http://launchpad.net/bugs/72956
<Ubugtu> New bug: #73022 in xserver-xorg-video-i810 "Computer locks up when exiting second X server" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73022
<Ubugtu> New bug: #73028 in xorg "Crash in almost every X startup (evdev)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73028
<Ubugtu> New bug: #73034 in xserver-xorg-video-ati "X crashes and restarts when plugging in external monitor" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73034
<Ubugtu> New bug: #73043 in xserver-xorg-input-evdev "Random wireless mouse freezes" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73043
#ubuntu-x 2006-11-24
<Ubugtu> New bug: #73081 in xkeyboard-config "Package description is inaccurate" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73081
<Ubugtu> New bug: #73082 in xorg "Package description is inaccurate" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73082
<Ubugtu> New bug: #73107 in linux-restricted-modules-2.6.17 "9629 hangs X when starting fullscreen games" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73107
<crimsun> there's a slight problem with our current mesa source package in feisty
<crimsun> libgl1-mesa-swx11-dev includes the GLw headers but not the static lib
<crimsun> either we need to ditch the GLw headers there, too, or we need to readd libGLw.a
<crimsun> for instance, this problem manifests itself in http://librarian.launchpad.net/5155466/buildlog_ubuntu-feisty-i386.xmakemol_5.15-1_FAILEDTOBUILD.txt.gz
<Ubugtu> New bug: #73129 in linux-restricted-modules-2.6.17 "Laptop freezes when a skype message comes in" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73129
<Ubugtu> New bug: #73160 in xorg "Wacom support should work out of the box" [Medium,Confirmed]  http://launchpad.net/bugs/73160
<Ubugtu> New bug: #73172 in xorg (main) "upgraded to edgy, lost my ati drivers" [Undecided,Needs info]  http://launchpad.net/bugs/73172
#ubuntu-x 2006-11-25
<Ubugtu> New bug: #73210 in mesa-utils "Launching beryl - crash" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73210
<Ubugtu> New bug: #72959 in xorg (main) "automatically log out" [Undecided,Needs info]  http://launchpad.net/bugs/72959
<Ubugtu> New bug: #73249 in xserver-xorg-video-i810 "X crashes after a restart using dual head setup" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73249
#ubuntu-x 2006-11-26
* Starting logfile irclogs/ubuntu-x.log
* #ubuntu-x  [freenode-info]  channel flooding and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
<Ubugtu> New bug: #73364 in linux-restricted-modules-2.6.17 "Atheros not working on ppc, works on i386/686" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73364
<Ubugtu> New bug: #73382 in mesa "Package is broken (not installable)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73382
#ubuntu-x 2007-11-19
<ubotu> New bug: #163706 in linux-restricted-modules-2.6.22 "nvidia-glx-new missing file" [Undecided,New] https://launchpad.net/bugs/163706
<ubotu> New bug: #147321 in linux-restricted-modules-2.6.22 (restricted) "[fglrx] Mobility Radeon X1300 and Xv doesn't work with totem and jerky with vlc" [Undecided,New] https://launchpad.net/bugs/147321
<ubotu> New bug: #163806 in xorg (main) "X doesn't start on Samsung Q1 Ultra" [Undecided,New] https://launchpad.net/bugs/163806
<ubotu> New bug: #163846 in xorg (main) "input is send to inactive window" [Undecided,New] https://launchpad.net/bugs/163846
<tjaalton> bryce: https://wiki.ubuntu.com/X/GitUsage
<tjaalton> it should be a tad more complete now
<tjaalton> and usable
<tjaalton> choir ->
<bryce> tjaalton: awesome
<ubotu> New bug: #163877 in xorg (main) "Fail to switch bwteen CRT and LCD" [Undecided,New] https://launchpad.net/bugs/163877
<ubotu> New bug: #163432 in xserver-xorg-video-radeonhd (main) "x turns backlight off, freezes keyboard, post 7.04->7.10 upgrade" [Undecided,New] https://launchpad.net/bugs/163432
#ubuntu-x 2007-11-20
<ubotu> New bug: #163965 in linux-restricted-modules-2.6.20 (restricted) "[gutsy] Broken visualization enabling fglrx" [Undecided,New] https://launchpad.net/bugs/163965
<pwnguin> so uh, apparently modprobe wont load the nvidia drivers if xorg.conf doesn't have it listed?
<ubotu> New bug: #163981 in linux-restricted-modules-2.6.20 (restricted) "kernel oops ipw3945" [Undecided,New] https://launchpad.net/bugs/163981
<ubotu> New bug: #163985 in xorg (main) "[Hardy] GUI disappears while working" [Undecided,New] https://launchpad.net/bugs/163985
<tjaalton> whee, alex deucher will be working for AMD soon
<bryce> yup, I saw that on his blog
<bryce> a couple weeks ago I'd tried to get him to join canonical
<tjaalton> oh :)
<tjaalton> I should probably merge the server next
<tjaalton> and I wonder if the hacky patch should be included or not
<bryce> 130?
<tjaalton> bryce: do you remember the bugs where it broke EXA?
<tjaalton> no, the new revision of 120 :)
<bryce> not offhand, but they should be marked high priority
<tjaalton> ok, I'll check
<tjaalton> since it's easy to test at least on intel
<bryce> yeah
<tjaalton> I'll also update the default-DPI patch to use 96, since that's upstream now
<tjaalton> and not 100
<bryce> I upgraded all my test hardware (3 laptops, 2 desktops) to hardy today
<tjaalton> heh
<bryce> including one 945 and two 965's
<tjaalton> btw, did you notice that I filed a bug to remove all the small apps from the archive?
<tjaalton> because they are in x11-* now
<tjaalton> bug 163094
<ubotu> Launchpad bug 163094 in xorg "[Package Removal Request] Please remove these from hardy" [Wishlist,Confirmed] https://launchpad.net/bugs/163094
<bryce> ah, I hadn't seen that - good!
<tjaalton> there are some packages that are not included in those, but they should deserve another request later
<tjaalton> packages that noone uses :)
<bryce> I've been working on my xorg package status script (trying to get it running in a chroot), and I noticed those old packages were still there
<tjaalton> hmm, upgrade doesn't purge them
<tjaalton> so they are in C mode or what's it called
<tjaalton> "configuration installed"
<bryce> hrm, the -intel sru still didn't get through...  I wonder if I need to do something more?
<tjaalton> dunno, what bug?
<bryce> 133118, 108056
<tjaalton> was it turned down or just not yet processed?
<bryce> not processed
<tjaalton> ok
<bryce> (afaik)
<bryce> I'll look at it more after I get these specs written
<bryce> btw, I really appreciate how you're taking care of the merges - it's really freed me up to take care of a lot of scut work that's been hanging around
<tjaalton> heh, np
<bryce> aha, got the chrooted xorg pkg script working :-)  http://people.ubuntu.com/~bryce/Xorg/versions_20071119.html
<bryce> I think once your xapp deletion goes through, we may have the hardy column all green
<tjaalton> indeed, and a bit shorter :)
<tjaalton> now it's official, I just changed my launchpad uid tepsipakki -> tjaalton
<bryce> a few drivers also need resyncd
<bryce> ah wow
<bryce> why the change?  what did tepsipakki mean?
<tjaalton> it was just a silly nickname I got after a very long night at a bar.. ;)
<bryce> hehe
<tjaalton> this is more "official", and a username which I already have everywhere
<tjaalton> since '96
<bryce> well, I think jcristau and tormod will be happy to know my xorg pkg status page will always show the debian versions of everything
<bryce> at AllHands the first night dinner, we played IRC nick bingo
<bryce> and then they had everyone with an unusual nick go up to the mike and explain it ;-)
<tjaalton> hehe
<tjaalton> we used to play "JMT bingo" (JMT= abbreviation of the street) from the balcony of my first flat on the campus, dialing random four digit numbers on the telephone and waiting for lights to turn on on the building next to us :)
<tjaalton> it was a 4x4 matrix, so not that hard :P
<tjaalton> every flat had a phone with a four digit number, and internal calls were free
<bryce> hehe
<tjaalton> hmm, still no comments about the l-r-m changes, not even from kernel-team
<ubotu> New bug: #164049 in xserver-xorg-video-intel (main) "intel xorg driver disables direct rendering for virtual display larger than 2048" [Undecided,New] https://launchpad.net/bugs/164049
<ubotu> New bug: #164052 in xserver-xorg-video-ati (main) "panels smaller than display size" [Low,New] https://launchpad.net/bugs/164052
<ubotu> New bug: #164125 in xrandr (main) "xrandr causes X BadRequest Error " [Undecided,New] https://launchpad.net/bugs/164125
<mvo> bryce: http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=cbf775cde7bb737ddf71fa3aa5b08c859d516084 maybe interessting for gutsy (or gutsy-backports)
<bryce> hi mvo
<bryce> ok, thanks
<mvo> bryce: maybe hardy is enough, I'm not sure aobut the scope, just got it on the compiz irc :)
 * bryce nods
<bryce> if it has xserver 1.4 dependencies, it might be hard to backport
<bryce> since it's an input related thing, there's a risk of it depending on some of the new input code I guess
<mvo> ok, then I misread it
<bryce> do we have a bug in LP that it fixes?
<mvo> its probably just for hardy then
<bryce> hmm, the only part that looks of concern is the inputInfo.keyboard bit - if that's present in xserver 1.3, then this should be safe to backport, however that sort of sounds like an input hotplug bit
<bryce> I can take a look at it next week (busy with specs presently), if you could file a bug in LP about it?
<mvo> bryce: thanks, I just confirmed that it only affect 1.4. iXce` will report a LP bug, when he has, I will forward it
<bryce> ah excellent
 * bryce loves it when bug reports come with the patch to fix it :-)
<pwnguin> what's a good way to reset the gdm configuration to default?
<bryce> pwnguin: hmm there's an /etc/gdm/factory-gdm.conf; I would guess maybe that's the default config?
<pwnguin> well
<pwnguin> i kinda took an alternate route
<pwnguin> apt-get remove --purge gdm
<bryce> ah, brute force ;-)
<pwnguin> a bit too brute
<pwnguin> fortunately startx worked
<pwnguin> otherwise id be netless
<bryce> does reinstalling gdm set the gdm.conf properly?
<pwnguin> apparently
<pwnguin> gdm.conf-custom is strange
<pwnguin> in that its empty
<pwnguin> i guess there's two levels of conf files
<bryce> I suspect that gdm.conf-custom is where you're supposed to place user-specific gdm settings that are not to get overridden by ugprades
<pwnguin> sounds reasonable
<bryce> tjaalton: I'm wokring on the HardyHardwareDetection spec and have some questions about how we're going to use hal for keyboard/mouse autodetection
<bryce> tjaalton: you about?
<pwnguin> on a related hardy note
<pwnguin> nvidia-glx?
<pwnguin>  nvidia-glx-new: Depends: xserver-xorg-core (>= 1:0.99.0-1) but it is not going to be installed
<pwnguin> xserver-xorg-core: Installed: 2:1.4.1~git20071119-1ubuntu1
<pwnguin> am i missing something about versions?
<bryce> hmm odd
<bryce> don't know why that doesn't work
<bryce> tjaalton: ideas on that one?
<tjaalton> bryce: yes, my l-r-m is not uploaded yet :)
<tjaalton> so it's normal
<tjaalton> just got home, btw
<pwnguin> im confused
<tjaalton> the commit that mvo pointed out is in the xorg-server snapshot I uploaded
<pwnguin> i have nvidia loaded
<pwnguin> but glx wont install because of a dependency on xorg
<tjaalton> pwnguin: I don't know how you got into that situation, but take a look at the newer proposed l-r-m at http://people.ubuntuwire.com/~tepsipakki/lrm
<tjaalton> it should fix that
<pwnguin> dist-upgrade ftw ;)
<tjaalton> since the new server conflicts with xserve-xorg-video, which nvidia/fglrx provide
<tjaalton> right, so it removed your non-working version
<pwnguin> since ive got x people attention, im thinking bulletproof x wants read-edid as a dependency
<pwnguin> as i managed to crash both my xorg.conf and the failsafe
<tjaalton> bryce: I noticed gravity mention something about that on #xorg-devel the other night
<tjaalton> bryce: that hal (or xserver-xorg, don't remember) should parse xorg.conf and generate an fdi file out of it
<pwnguin> tjaalton: so then, i shouldnt expect wacom to have the right module versions either, I presume?
<tjaalton> right
<tjaalton> possibly just an oversight
<tjaalton> pwnguin: so you use wacom?
<bryce> tjaalton: ah yeah just read it in backlog
<tjaalton> lool filed a bug about that input-redirect thingie
<ubotu> New bug: #164171 in xorg (main) "key repeat under cursor" [Undecided,New] https://launchpad.net/bugs/164171
<tjaalton> heh, that looks like a dupe :)
<pwnguin> tjaalton: yes
<pwnguin> tjaalton: does that make me evil? ^_^
<tjaalton> pwnguin: ok, I believe I looked at it once, but perhaps just got distracted by the wacom-devel list or something, looking for an update
<pwnguin> i just noticed last night wacom wasnt working, figured it might just not have been updated yet, so i havent filed a bug yet
<tjaalton> right, the version is too old
<tjaalton> xserver-xorg-core conflicts << 0.7.8
<tjaalton> bryce: I noticed that evtouch should provide input-hotplug for touchscreens
<tjaalton> thus replacing elographics AIUI
<tjaalton> but now, last episodes of sopranos :) bbl ->
<bryce> tjaalton: when you get back, I updated https://wiki.ubuntu.com/HardyHardwareDetection with more specifics on the input hotplug side of things - it would be great if you could review that
<tjaalton> whoa, a lot of text :)
<tjaalton> sure, I'll have a look
<bryce> the section I added starts at X.org configuration refactoring
<ScislaC> heya bryce
<bryce> heya ScislaC
<ScislaC> bryce: you want me to "complain"? ;)
<tjaalton> bryce: reading through the spec now
<tjaalton> discover; I believe it's the drivers that have most uptodate information about the pciids
<tjaalton> ..they support
<tjaalton> whatever is in the server is just duplication
<tjaalton> sparc; maybe pci-rework will sort this out, so I'm not sure what to do for hardy..
<tjaalton> xresprobe; yes, let's drop it and manage the fallout :)
<tjaalton> keyboard; maybe it's console-setup that needs reconfiguring when changing the layout
<tjaalton> since if the logic is removed from xserver-xorg
<tjaalton> mouse protocol; I think this is already done
<bryce> ScislaC: yeah
<bryce> tjaalton: cool thanks, I'll update the spec with that, unless you want to directly?
<tjaalton> bryce: please go ahead, I'll go to bed soon, after checking the wacom-discuss archives :)
<bryce> okie
<bryce> done
<tjaalton> hmm, seems that the newest wacom still easily segfaults with 1.4, so no point to update it
#ubuntu-x 2007-11-21
<tjaalton> sweet, openchrome no longer conflicts with via/unichrome
<bryce> nice
<bryce> tjaalton: btw, I've written up a couple more specs:  https://wiki.ubuntu.com/X/MonitorsDatabaseOnline and https://wiki.ubuntu.com/X/AutodetectMonitorFrequency
<bryce> please feel free to update either
<seb128> bryce: is there any radeonhd or fglrx package working on hardy somewhere?
<tjaalton> seb128: see my post on ubuntu-devel
<seb128> tjaalton: which one?
<bryce> not yet, although timo's l-r-m package could be used for fglrx
<tjaalton> seb128: "new l-r-m for testing"
<tjaalton> Nov 13
<seb128> tjaalton: thanks
<tjaalton> seb128: feedback welcome :)
<tjaalton> maybe I should just upload that
<seb128> ok, will try those ;-)
<tjaalton> still no reply from kernel-team
<bryce> don't hold your breath
<tjaalton> seb128: note that it doesn't ship ATI libGL anymore, which makes it installable with -ati :)
<tjaalton> seb128: I've already got one confirmation that it works just as fine, but compiz still fails. Maybe you can get it running :)
<tjaalton> bryce: oh, they are on vacation?-)
<bryce> uh, more like under-manned
<tjaalton> yeah
<bryce> btw, want to become a kernel maintainer for ubuntu?
<tjaalton> hehe
<bryce> :-)
<tjaalton> I'm probably not qualified for the task ;)
<bryce> rats, no hiring bonus for me ;-)
<tjaalton> ah, you have those :)
<bryce> yeah I plan on getting you hired on for something! ;-)
<tjaalton> <blush>
<tjaalton> heh :)
<bryce> want to be a new marketing manager?  Operations Manager? hrm...
<pwnguin> open-gl conman / recruiter ;)
<bryce> do you know taiwaneese?
<tjaalton> aren't you desperate :P
<pwnguin> does taiwan speak taiwaneese?
<bryce> pwnguin, maybe you do?
<pwnguin> im pretty sure they speak chinese, given the history
<bryce> ahhhh
<bryce> need a job?
<pwnguin> i dont speak chinese
<tjaalton> at UDS I noticed to my dismay that even my english had suffered a lot :)
 * pwnguin just noticed a few demoscene packages
<pwnguin> didnt realize sesse was a DD
<pwnguin> bryce: if you're looking for a hiring bonus, this guy might fit the desktop developer role: https://edge.launchpad.net/~sesse
<tjaalton> maintains nfs-utils in debian ;)
<pwnguin> and lots of others
<pwnguin> wrote several openGL apps
<pwnguin> apps that won demoparties
<tjaalton> oh
<tjaalton> that part I didn't know
<pwnguin> apt-get install amoeba
<bryce> hmm, cool.  although there's only 3 open bugs related to him in LP
<pwnguin> http://qa.debian.org/developer.php?login=sesse@debian.org
<pwnguin> there ya go ;)
<bryce> ahh, nice
<bryce> yeah, I've tried to get alex and cworth for the desktop position, but alex went to amd, and cworth isn't replying (guess he's happy at RH).
<pwnguin> these are just names to me
<pwnguin> are many rh engineers DDs?
<seb128_> bryce, tjaalton: is there any known intel bug which means compiz shadows being buggy on hardy?
<bryce> no idea, but cworth is pretty focused on cairo development; I don't think he does much packaging
<tjaalton> seb128: not that I remember
<bryce> seb128, hrm; only one I know of was that one we took care of around the developer sprint last time
<tjaalton> seb128: I have i945 that works just fine
<tjaalton> bryce: is the MonitorDatabase.... meant for custom settings only, and normally rely on autodetection?
<bryce> yup
<bryce> (so I expect it is going to be needed extremely rarely)
<tjaalton> bryce: did I mention that the latest xorg-server has a newer version of patch 120? I tried it with the i945 and it didn't crash or pose any other problems, so I thought it's safer to keep for -ati users for now.. and evaluate dropping it later?
<bryce> yeah you mentioned that.  It sounds like a good idea to keep it
<ubotu> New bug: #164290 in xorg (main) "nvidia driver selects non-existing CRT monitor as default instead of the DFP on the laptop" [Undecided,New] https://launchpad.net/bugs/164290
<bryce> night
<tjaalton> night
<ubotu> New bug: #164295 in xorg (main) "external monitor doesn't "work" on laptop" [Undecided,New] https://launchpad.net/bugs/164295
<tjaalton> seb128: btw, did the fglrx update work?
<seb128> tjaalton: I'll try in a minute
<tjaalton> ah, no hurry
<seb128> tjaalton: works fine
<seb128> I've just installed fglrx
<seb128> it's still unusable slooooooow but that was already the case in gutsy
 * seb128 kicks the radeonhd support on linux
<seb128> should try the radeonhd driver again
<tjaalton> seb128: what card do you have?
<seb128> radeon 2400 something
<seb128> radon 2400 hd I think
<tjaalton> hmm, that's r6xx
<seb128> radeon 2400 hd I think
<seb128> rather
<seb128> yes
<seb128> workspaces or applications switching is alright but scrolling is not, it's really laggy
<tjaalton> atombios support is being merged in -ati, so I'm not sure if radeonhd is another avivo or not :)
<tjaalton> on http://planet.freedesktop.org/ there are a couple of articles explaining the recent changes
<tjaalton> hopefully we'll have proper 2D at least for r5xx when hardy releases
<ubotu> New bug: #163292 in xorg (main) "*buntu runs as root w/ the command "sudo startx"" [Undecided,Invalid] https://launchpad.net/bugs/163292
<ScislaC> just curious, are there plans for xorg-driver-fglrx for the Hardy's xserver in the near future?
<tjaalton> yes
<tjaalton> http://people.ubuntuwire.com/~tepsipakki/lrm
<ScislaC> tjaalton: I am gonna snag those :) thanks
<ScislaC> tjaalton: is the overlay in the bottom right corner to be expected? (regarding your fglrx stuff)
<tjaalton> ScislaC: don't know, since I can't test it :)
<tjaalton> the driver is known to be buggy, but it's the best you can get for now..
<tjaalton> since older versions don't work with the newer xserver
<ScislaC> tjaalton: well... I can test for you ;)  That was part of my motivation of getting a working fglrx, to help bryce with triaging bugs for the newer xserver (the -ati driver isn't too friendly with my video card)
<bryce> tjaalton: ScislaC is one of my long time Inkscape buddies and a kick ass artist
<bryce> he also did a lot of tire kicking on fglrx packages I did during gutsy
<ScislaC> heya bryce :)
<ScislaC> brb
<tjaalton> oh, ok :)
<tjaalton> that's good
<bryce> hi guys - here's the specs I've put in for Hardy:
<bryce> https://blueprints.launchpad.net/ubuntu/+spec/autoconfigure-monitor-frequency
<bryce> https://blueprints.launchpad.net/ubuntu/+spec/monitor-settings-database-online
<bryce> https://blueprints.launchpad.net/ubuntu/+spec/hardy-hardware-detection (this one is actually Pitti's but there's some input hotplug stuff captured there too)
<bryce> A fourth spec I'll work on this afternoon will be dealing with X testing infrastructure
<bryce> comments/corrections on any of the above would be most appreciated
<ubotu> New bug: #164411 in xserver-xorg-video-intel (main) "[Gutsy] X crashes after using xrandr through a game [i915]" [Undecided,New] https://launchpad.net/bugs/164411
#ubuntu-x 2007-11-22
<ubotu> New bug: #40544 in xserver-xorg-video-ati (restricted) "fglrx: Xinerama does not work" [Medium,Invalid] https://launchpad.net/bugs/40544
<DShepherd> http://pastebin.com/m7ecf18a8 -- I get this error when i run sudo /etc/init.d/gdm restart but startx starts X fine. anyone know the solution?
<DShepherd> sudo /etc/init.d/gdm restart|start hangs gdm.
<ubotu> New bug: #21107 in xserver-xorg-video-savage (main) "24bit mode breaks after acpi suspend/resume" [Medium,Fix released] https://launchpad.net/bugs/21107
<ubotu> New bug: #163850 in xf86-input-evtouch (universe) "Uncalibrated and can't calibrate with 0.8.7-2 on Samsung Q1 Ultra" [Undecided,New] https://launchpad.net/bugs/163850
<ubotu> New bug: #164392 in xorg (main) "Freeze on applications for a few seconds" [Undecided,Incomplete] https://launchpad.net/bugs/164392
<DShepherd> psst. anybody around?
<DShepherd> i think i have a problem that is related to X, not sure though...
<tjaalton> DShepherd: just ask
<DShepherd> when i do sudo /etc/init.d/gdm restart|start gdm won't start... but startx starts it fine
<DShepherd> http://pastebin.com/m7ecf18a8 -- i get this error in my syslog. that i think is related to gdm or X. not sure though
<tjaalton> gutsy/hardy/?
<DShepherd> gutsy
<tjaalton> if startx works then it's probably gdm
<DShepherd> correction.. gdm starts up fine.. but hangs on login
<DShepherd> tjaalton, ok
<tjaalton> so X works
<tjaalton> if the login screen comes up
<tjaalton> how come the log timestamps are reversed?
<DShepherd> tac 
<DShepherd> tjaalton, sorry if that confused you. i just like to the most recent log first
<tjaalton> try reinstalling gdm
<DShepherd> tjaalton, I did, that didn't seem to fix the problem
<tjaalton> or file a bug! :)
<DShepherd> *sighs*
<tjaalton> although I think that something in your system is broken
<tjaalton> I've never seen that
<DShepherd> i suspect that too..
<DShepherd> i guess you are throwing in the towel now? =)
<tjaalton> yep
<DShepherd> ok, thanks for attention though
 * DShepherd grumbles about linux, gdm  and .....
<tjaalton> bryce: I'll upload the new l-r-m, think it's due
<tjaalton> uh, AMD has released a newer driver, AMD Catalyst 7.11
<tjaalton> interesting version
<ubotu> New bug: #146613 in xkeyboard-config (main) "The Norwegian apple keyboard is wrong" [Undecided,Incomplete] https://launchpad.net/bugs/146613
<ubotu> New bug: #160171 in xkeyboard-config (main) "Norwegian Mac keyboard layout: No "advanced" characters by default" [Undecided,Incomplete] https://launchpad.net/bugs/160171
<bryce> tjaalton: cool
<Q-FUNK> tjaalton: which chipset?
<tjaalton> Q-FUNK: ?
<Q-FUNK> (21:15:18) tjaalton: uh, AMD has released a newer driver, AMD Catalyst 7.11
<tjaalton> yes, new versioning scheme for fglrx
<ubotu> New bug: #164589 in linux-restricted-modules-2.6.22 (restricted) "Occasional screen-wide "blink" when using compiz" [Undecided,New] https://launchpad.net/bugs/164589
#ubuntu-x 2007-11-23
<DShepherd> can someone explain to me what happens when /etc/init.d/gdm start is executed versus startx?
<tjaalton> DShepherd: startx runs /etc/X11/Xsession, gdm runs /etc/gdm/Xsession
<DShepherd> tjaalton, thanks
<DShepherd> tjaalton: where you the person i was talking to yesterday about my start and gdm problem?
<tjaalton> yes
<DShepherd> were*
<tjaalton> it's not a problem in X
<DShepherd> tjaalton: i think i agree with you
<DShepherd> tjaalton: would you find it interesting if i remove metacity. I can login just fine in gutsy
<DShepherd> if i == that I removed*
<tjaalton> so rm -rf ~/.metacity and try again
<DShepherd> tjaalton: did that already, reinstalled metacity and still no joy
<tjaalton> have you tried asking on #ubuntu?
<DShepherd> tjaalton: yeah, some guy said he had some similar problem and it was related to xgl being installed. removed it and he was fine
<DShepherd> tjaalton: no xgl here so that didnt help much
<tjaalton> well now you have more information to share..
<tjaalton> I don't know whats wrong, and it's offtopic here anyway ;)
<DShepherd> tjaalton: again, i dont think its X problem, so I dont expect you guys to chip in
<DShepherd> tjaalton: aight, thanks again for lending an ear
 * DShepherd wonders if gdm was updated recently
<tjaalton> please
<tjaalton> ..not here :)
<DShepherd> srry
<pwnguin> so do the nvidia drivers work now?
<tjaalton> should work
<pwnguin> ok
<pwnguin> time to test ^_^
<pwnguin> appears to
<tjaalton> good
<pwnguin> i wish nvidia had a public bug tracker. publishing a change log that says "fixed a bug" isnt very descriptive =(
<ubotu> New bug: #140908 in xorg (main) "Nvidia 8800 video card - black screen - system does not complete startup" [Medium,Incomplete] https://launchpad.net/bugs/140908
<ubotu> New bug: #55294 in xkeyboard-config (main) "keyboard doesn't work under xorg" [Undecided,Incomplete] https://launchpad.net/bugs/55294
<ubotu> New bug: #56017 in xorg-server (main) "scanpci do not find all devices" [Undecided,Incomplete] https://launchpad.net/bugs/56017
<ubotu> New bug: #164733 in linux-restricted-modules-2.6.22 (restricted) "[gutsy] CAPI is installed but doesn't work" [Undecided,New] https://launchpad.net/bugs/164733
<ubotu> New bug: #54220 in xserver-xorg-input-synaptics (main) "two-finger scrolling doesn't work with dapper version" [Undecided,Fix released] https://launchpad.net/bugs/54220
#ubuntu-x 2007-11-24
<unggnu> hi all
<unggnu> Can somebody have a look at the back trace on https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/138094. I am not sure if it is usable since X doesn't really crash but maybe it helps or at least someone have an idea how to get better information.
<ubotu> Launchpad bug 138094 in xorg "[Gutsy] desktop and keyboard freezes while mouse is moveable" [Undecided,New] 
<ubotu> New bug: #68150 in xserver-xorg-video-intel (main) "screensaver crashes X on IBM X40 (opengl related?)" [Undecided,New] https://launchpad.net/bugs/68150
<ubotu> New bug: #164892 in xserver-xorg-video-nv (main) "Please sync a new version from Debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/164892
<tormod> without xsfbs, how should one make an orig.tar.gz?
<tjaalton> tormod: what are you packaging?
<tormod> tjaalton: radeonhd, from Debian git
<tjaalton> jcristau mentioned yesterday to make a release later this weekend
<tormod> ok maybe I just wait for that then. I keep posting test packages on XorgOnTheEdge
<tormod> and I had this script doing the whole stuff from http://wiki.debian.org/XTips
<tjaalton> ah, ok
<tormod> tjaalton: reading your https://wiki.ubuntu.com/X/GitUsage now: "put the tarball in the parent directory before running debuild"
<tormod> where does the tarball come from?
<ubotu> New bug: #164902 in xorg (main) "cannot run LiveCD on Inspiron 1100 (intel 845GL)" [Undecided,New] https://launchpad.net/bugs/164902
 * tormod reads http://wiki.debian.org/GitSrc
<tjaalton> from upstream if it's released
<tjaalton> but if it's a random git version, then you just need to build it yourself I guess :)
<tjaalton> sauna ->
#ubuntu-x 2007-11-25
<ubotu> New bug: #144076 in linux-restricted-modules-2.6.22 (restricted) "NVidia Quadro NVS 140M not recognised by nvidia driver" [Undecided,New] https://launchpad.net/bugs/144076
<soren> If you've hosed your xorg.conf and salvage it by using the displayconfig-gtk thing, your keyboard settings are gone... What's the preferred way to get that back? Will "dpkg-reconfigure -pcritical xserver-xorg" give me my xorg.conf as it was generated during install ?
<tjaalton> something like that, or just run dexconf
 * tjaalton runs for the train ->
<soren> tjaalton: Great, thanks!
<ubotu> New bug: #165008 in xserver-xorg-video-intel (main) "Intel driver selects 30 Hz, and refuses to switch to 60 Hz manually" [Undecided,New] https://launchpad.net/bugs/165008
<ubotu> New bug: #91415 in linux-restricted-modules-2.6.22 (restricted) "Firmware file 'dvb-usb-wt220u-fc03.fw' for USB DVB-T receiver missing" [Undecided,New] https://launchpad.net/bugs/91415
<ubotu> New bug: #165034 in xorg (main) "X11 suddenly became very slow" [Undecided,New] https://launchpad.net/bugs/165034
<ubotu> New bug: #165005 in xserver-xorg-video-intel (main) "Gutsy won't shut down on Lifebook E4010" [Medium,Confirmed] https://launchpad.net/bugs/165005
<pwnguin> psh. at the moment displayconf-gtk is not bulletproof ;)
<ubotu> New bug: #57157 in linux-restricted-modules-2.6.15 (restricted) "intel 82801 GBM/GHM (ICH7-M Family) SATA storage controller -27c4" [Undecided,Incomplete] https://launchpad.net/bugs/57157
<tjaalton> tormod: there's only one radeonhd in experimental :)
<ubotu> New bug: #165056 in linux-restricted-modules-2.6.22 (restricted) "gutsy fglrx crashes during startup on ati radeon 9600 SE and Sony 20sfII" [Undecided,New] https://launchpad.net/bugs/165056
<tormod> tjaalton: probably, just following the rules to the letter and beyond :)
<ubotu> New bug: #165060 in xorg-server (main) "/etc/init.d/xprint: 534: Syntax error: Bad substitution" [Undecided,New] https://launchpad.net/bugs/165060
<tjaalton> tormod: ah, well so far it's been enough to just say "sync this package from unstable/experimental"
<tjaalton> whatever is the latest
<tjaalton> gah, xprint refuses to die
<tormod> tjaalton: there's actually an 0.0.1 in experimental too. I guess the rule is there in case different repositories can be out of sync etc, so we make sure the archive admin gets the right one without ambiguity.
<ubotu> New bug: #164974 in dell "[XPS M1330] sleep mode doesn't always work" [Undecided,Confirmed] https://launchpad.net/bugs/164974
<tjaalton> tormod: maybe on your mirror.. actually ftp.debian.org is also left behind
#ubuntu-x 2008-11-17
<james_w> tseliot: hi, do you have an opinion on bug 296809?
<ubottu> Launchpad bug 296809 in nvidia-xconfig "Please remove nvidia-xconfig (universe) from the repositories" [Wishlist,New] https://launchpad.net/bugs/296809
<tseliot> james_w: yes, I talked to him and I suggested that we remove nvidia-xconfig since we already include it in the different nvidia-glx-* packages
<james_w> oh, cool, I'll do a quick check and "sponsor" it
<tseliot> ok, thanks
<superm1> so when running xev, what does it mean when you get an extra line "XKeysymToKeycode returns keycode: ###" where ### is a number?  
<jcristau> superm1: we get a keycode, run XLookupString, which gives us a keysym. that line is printed if XKeysymToKeycode on that keysym doesn't return the original keycode
<superm1> jcristau, but why would that be occurring then?  would that mean that something is wrong with the assignment for keysyms <-> keycodes somewhere?
<jcristau> might just mean that you have two keys with the same keysym assigned
<jcristau> so not necessarily a problem
<superm1> well at least nothing that i've intentionally assigned.  that's occurring for XF86Eject, which is seeming to be indicative of why gnome settings daemon is not reacting to the button press
<jcristau>     state 0x0, keycode 170 (keysym 0x1008ff2c, XF86Eject), same_screen YES,
<jcristau>     XKeysymToKeycode returns keycode: 169
<jcristau> hmm.
<superm1> okay so not just me then...
<jcristau>     key <I169> {         [       XF86Eject ] };
<jcristau>     key <I170> {         [       XF86Eject,       XF86Eject ] };
<jcristau> correspond to the following in the kernel:
<jcristau> #define KEY_EJECTCD             161
<jcristau> #define KEY_EJECTCLOSECD        162
<superm1> what's the difference supposed to be though?  I think hal is only providing granularity for one of them
<superm1> i'd guess cdroms that have an eject and uneject button?
<jcristau> probably
<jcristau> X provides only XF86Eject, but the kernel has both
<jcristau> g-s-d shouldn't care what the keycode is, though..
<superm1> well commenting out /usr/share/X11/xkb/symbols/inet's reference to key <I169> and restarting X makes the eject button work again it appears
<jcristau> sounds like a gnome bug then :)
<superm1> okay i punted it off to gnome bug 561275 then so those guys can get things in order.  thanks for helping find the culprit jcristau :)
<ubottu> Gnome bug 561275 in plugins "eject key doesn't work when disks are mounted" [Normal,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=561275
<jcristau> np
<superm1> ah well the reason that they were caring about the keycodes stands out now; XGrabKey needs to grab a code, can't go off of a sym ( http://tronche.com/gui/x/xlib/input/XGrabKey.html )
<superm1> so the fact that XKeysymToKeycode only returns one code will likely be a troublesome problem to solve then
<jcristau> ah. right..
<jcristau> they should scan the keymap to find all relevant keycodes then
<jcristau> i think
#ubuntu-x 2008-11-18
<wgrant> Yay, LP has package-specific bug reporting guidelines now.
#ubuntu-x 2008-11-19
 * bryce waves
<wgrant> Good afternoon, bryce.
<superm1> wgrant, being that you wrote a bunch of patches to gsd, how responsive is upstream usually about reviewing them?
<superm1> hi bryce 
<wgrant> superm1: I've only taken a couple upstream; I got a response within 24 hours, and normally committed just a few hours after I submitted a good patch.
<wgrant> So they're very good.
<superm1> bryce, i've got an issue you'll probably get pulled into after we get a valid root cause.
<superm1> wgrant, hmk, i submitted something upstream and they immediately said yuck on formatting, resubmit and we'll relook
<superm1> gsd's formatting is really a mess.  i stuck to a standard with all the source files i touched, but it's not standard among all of the files
<wgrant> The standard varies within files.
<superm1> i think i've gotten too used to working with python code
<wgrant> One of the files I worked on has 2 spaces in some functions, 8 spaces in others, tabs in others.
<wgrant> Same.
<superm1> and how nice formatting is consistent everywhere
<wgrant> You do occasionally see tabs in Python.
<superm1> when i do though, if it's in a project that i work on regularly, i start throwing knives at people for that :)
<wgrant> Yep.
<wgrant> The only place I've seen it recently was in PlayOnLinux.
 * wgrant shudders.
<superm1> if you're curious, the patch i wrote is to fix the issue i was discussing with jcristau the other day where XF86Eject doesn't work
<wgrant> If you want evidence that you can make unthinkably horrible code in Python, PlayOnLinux is a good example.
<wgrant> Ah.
<wgrant> How're you planning to fix that?
<wgrant> (I followed the discussion)
<superm1> let me show you the patch, sec
<superm1> http://bugzilla.gnome.org/show_bug.cgi?id=561275
<ubottu> Gnome bug 561275 in plugins "shortcuts don't work if keysym bound to multiple keycodes" [Normal,New]
<superm1> it affected way more of my hardware than i wanted it to, so i got antsy waiting for anyone else to write a patch
<wgrant> Aha.
<bryce> superm1: oh?
<superm1> bryce, yeah bug  297245.  it is seeming like a new vendor was introduced for the 1535
<ubottu> Launchpad bug 297245 in xorg "Dell Studio 15 Doesn't Boot, White Screen of Death" [Undecided,Confirmed] https://launchpad.net/bugs/297245
<superm1> we dont have a root cause of the white screen yet, but i'm thinking it's not reading the EDID correctly
<superm1> unfortunately i've yet to get ahold of any hardware that will reproduce it
<bryce> superm1: oh, it's using -vesa
<superm1> bryce, it only "works" with VESA
<superm1> with -intel the white screen is occurring
<bryce> hmm, comment #7 said that was the log from after reproducing the issue
<superm1> from what i gather, there are at least 3 different LCD vendors available, 2 types of LCD, and 2 sets of resolution
<superm1> people have been manually setting vesa to get to X at least
<bryce> mm, yeah, we'd need to see the edid's, to see if it's just bad edid from the monitor
<bryce> and definitely need an Xorg.0.log[.old] from after booting and seeing the problem, so we can see if the xserver just got confused, or what
<superm1> do you have some useful commands that people can post?  I can provide good EDIDs from the models of LCD that i know work
<bryce> I usually ask for 'get-edid | parse-edid' and 'xrandr --verbose'
<superm1> does get-edid work outside X?
<bryce> I believe so
<bryce> as long as the monitor's connected
<bryce> it's doing a low level bios call, not X calls
<superm1> ah okay yeah that would be a good recommendation then
<bryce> xrandr might work only when booted into -vesa or whatever
<superm1> if it turns out this LCD vendor does have a borked EDID, what are the options though?
<bryce> but the --verbose flag includes a dump of the EDID
<superm1> in terms of fixing it
<bryce> and the xrandr's parsed EDID is very close to what the X server is using
<bryce> quirks :-)
<bryce> unless the edid is completely invalid, in which case shipping a static xorg.conf really is the only option
<superm1> yippee. well at least such things will be possible hopefully
<bryce> although we could upstream the issue and see if the xserver guys can figure out something better
<bryce> if we at least get the LCD vendor name/model from the EDID, the remainder can be quirked
<bryce> if nothing can be gotten from the LCD, then the LCD vendor is very very naughty
<superm1> which wouldn't be a surprise, they may have been a cost reduction option 
<superm1> in which case, this is something i'll have to check if the 1535's successor has this LCD vendor as an option
<bryce> heh, profit reduction option maybe too ;-)
<bryce> but actually, bad edid is only one possibility.  Could be a GPU lockup or some other issue.  Can't say for sure without having the Xorg.0.log
<superm1> do you have a canned reply that you can drop in as a response asking for edid information and what not?
<bryce> superm1: also you may want to test against current xserver git.  They've put in some reworkings of EDID handling based on some bugs I was seeing, which makes it try harder in certain cases.
<bryce> I don't think this is one of those cases, but it's well worth a try
<superm1> well first things first, i need some hardware that reproduces it :)
<bryce> yep
<bryce> nah, I don't have a canned reply for edid.  I probably should make a stock one though
<superm1> okay i'll write up something tomorrow morning then
<bryce> cool.  Oh, btw this week I'm working on a Dell bug for you guys, that's turning into quite a time sync
<superm1> for a belmont related item?
<superm1> or for ideastorm related
<bryce> I may need to ping you for advice on it tomorrow.  we had a call this evening (we're trying to get the bug upstreamed to intel).
<bryce> belmont
<superm1> okay yeah pm me or email me tomorrow if you need some further advice on it.  
<bryce> great
<superm1> there are so many bugs in belmont, i'm not keeping up with them anymore :)
 * bryce paints a picture of superm1 swimming in bugs
<bryce> night everyone
<superm1> night
<tjaalton> seb128: does xvfb still need to Depend on xauth, xfonts-base, isn't Recommends enough now?
<seb128> tjaalton: recommends is likely good enough indeed
<tjaalton> seb128: ok, moving back to Recommends, thanks
<seb128> tjaalton: you're welcome
<tjaalton> oh nice, so jaunty has a broken libxi without properties
<tjaalton> and XInput.h, because it got autosynced :P
<tjaalton> well, I'll add the changes back
<bryce> tjaalton: yes, riddell mentioned that
<tjaalton> bryce: yeah, it was the -2build1 upload :)
<tjaalton> which meant that it would be autosynced when a new version was ready
<bryce> ah
<bryce> superm1: bug 297245 is upstream and assigned to jbarnes, although he's not yet commented on it.  I'll ping him.
<ubottu> Launchpad bug 297245 in xserver-xorg-video-intel "[i965] Dell Studio 15 White Screen on X startup" [High,Confirmed] https://launchpad.net/bugs/297245
<superm1> bryce, ah that's great.  
<superm1> bryce, well the bad news here, if this does end up being attributed to the intel driver's handling of this LCD, the studio 1535's successor does indeed offer this exact same LCD, so the breakage will continue on it
<bryce> superm1: do you have the hardware on hand to reproduce this issue yourself?
<superm1> bryce, i've got several 1535's but not with that LCD manufacturer.  I've been trying to track one down with it, but now that i know the 1535's successor has it too, i might have a little more luck finding one
<bryce> superm1: okay.  I've dinged jesse to hopefully bring his attention to it.  He's not on IRC so I emailed him.  (Possibly he's AFK?)
<bryce> I didn't see anything wrong with the edid we collected, but given that it occurred after the LCD manufacturer was changed, it does sound like EDID is the thing to look at
<superm1> i'll let you know if/when i can finally get ahold of hardware with this
<bryce> superm1: great.  xrandr --verbose would be nice to see.
<superm1> we're trying to nab one of the returned models that was returned for this white screen problem (which proves to be more difficult than you anticipate with this big of a company :))
<superm1> bryce, someone from that bug should hopefully be able to get you xrandr --verbose in the meanwhile I think.  the reporter on it (Chris Menning) seems to be on top of responding to anything asked for
<tseliot> bryce: today I received the tablet :-)
<tseliot> thanks a lot
<bryce> tseliot: ahh excellent!  Finally, I was starting to worry.
<tseliot> BTW I'll write the wiki pages about the projects ASAP
<bryce> tseliot: excellent
<bryce> tjaalton: lool ran into that issue with xorg not starting up due to missing hal - http://pastebin.com/f750ebfb7
<bryce> #
<bryce> (EE) config/hal: couldn't initialise context: (null) ((null))
<jcristau> xorg starts up just fine when hal is missing, just with no input devices
<bryce> okay...  ;-)
<bryce> jcristau: do we need a hal dependency added here somewhere?
 * bryce summons lool
<jcristau> some X package should depend on (or recommend) hal, yeah. and the init scripts for the display managers should depend on hal being started.
<lool> Hi folks
<lool> jcristau: So when one installs gdm it pulls xorg and input-all and everything, but fails to start
<lool> jcristau: I think at some level we need to pull hal
<jcristau> yup
<bryce> lool, <jcristau> some X package should depend on (or recommend) hal, yeah. and the init scripts for the display managers should depend on hal being started.
<lool> jcristau: Currently, in Debian and Ubuntu it will be pulled "externally" by /some/ metapackage
<lool> jcristau: Ok, good points
<jcristau> xserver-xorg should be a good candidate for the hal Depends or Recommends.
<lool> gdm.init looks like crap right now hmm
<lool> I guess only the real server needs hal, not others like Xvfb right?
<bryce> lool, do you want to add to gdm?
<lool> bryce: I'm not sure it's correct
<lool> I don't think gdm has any knowledge of hal
<jcristau> i don't think any server other than Xorg implements NewInputDeviceRequest
<lool> jcristau: Is this NewInputDeviceRequest in an input specific path, like e.g. evdev?
<lool> If that's the case we could add the dep on xserver-xorg-input-evdev instead
<jcristau> lool: NewInputDeviceRequest is the DDX function that's called when hal tells the server about an input device
 * lool doesn't know what ddx is
<jcristau> lool: each subdir of hw/ in the xorg-server tree
<lool> jcristau: I guess my question is rather, is the hal dependency specific to some input module which might not be on the xorg server, or is it really the binary requiring hal?
<bryce> jcristau: xserver-xorg looks like a good place to hang the dependency.  We already have -evdev listed there
<jcristau> it's Xorg requiring hal to tell it what input devices are there
<lool> I guess it's in the xorg-server source tree... then we should probably add the dep on the xorg-server indeed
<jcristau> bryce: 19:13 < jcristau> xserver-xorg should be a good candidate for the hal Depends  or Recommends.
<jcristau> bryce: looks like violent agreement :)
<lool> I don't mind a recommends, if the server can work with other input devices than the hal provided ones
<bryce> jcristau: yes I'm agreeing with you ;-)
<jcristau> lool: it can, but not with the default config
<lool> People, I strongly agree with you too but we need to flame on smth
<bryce> ok, I'll put the change in
<lool> jcristau: Can it with autodetection of the config?
<lool> I mean, without any xorg.conf?
<lool> (My use case was no xorg.conf)
<jcristau> without any xorg.conf, you don't get input devices if you don't have hal, i think
<lool> hmm
<jcristau> i guess whether it should be Depends or Recommends kinda depends whether apt will pull it in on upgrade if it's just Recommended
<lool> It does
<lool> Unless configured not to -- not our problem
<jcristau> ok
<jcristau> then both work. i don't have a strong preference
<lool> jcristau: Ah stop
<lool> jcristau: vorlon tells me that apt doesn't do that
<lool> I'm very confident that aptitude does, but it seems that's an aptitude extension
<lool> So Depends then?
<jcristau> i guess so
<jcristau> and 'Should-Start: hal' in gdm.init, or some such?
<lool> Yeah
<lool> jcristau: Hmm it has it already
<lool> Probably not in Ubuntu though
<jcristau> oh. good.
<jcristau> i only have xdm installed here...
<lool> bryce: http://launchpadlibrarian.net/19793798/buildlog_ubuntu-jaunty-powerpc.libgtk2-perl_1%3A1.190-1ubuntu1_FAILEDTOBUILD.txt.gz
<bryce> powerpc :-o
<lool> chroot needs cleanup
<jcristau> /tmp/.X99-lock left around, i guess?
<lool> Actually was still running from previous build
<lool> And using all CPU
<lool> I think I ran into this once with missing bdeps, but don't recall how to reproduce
<lool> Anyway, buildd admin fixed it for now
<lool> If someone reproduces he should fix xvfb-run to not use 100% CPU but die
<lool> When the package is removed
<lool> jcristau, bryce: I added a depends on hal in Debian's gdm because of the should-start
<lool> (in SVN)
<lool> thanks all
<jcristau> should-start means 'start if available', it's not a dependency..
<bryce> lool, great :-)
<lool> jcristau: I think it should be one, shouldn't it?
<jcristau> is the depends in xserver-xorg not enough?
<bryce> and the xserver-xorg change is committed to git and uploaded to jaunty now.
<jcristau> lool: not if gdm itself doesn't use hal, no
<lool> Hmm
<lool> We are listing hal here because we're leaking into gdm the fact that xorg server needs hal to work
<lool> We need to leak it because we care about representing that in init scripts and xorg server doesn't have an init script
<lool> If we leak that in the init script, we might as well be consistent and leak it in the deps
<jcristau> yeah. but depending how it's configured, gdm might not even start an X server.
<lool> True, so let's make it a recommends
<jcristau> why? xserver-xorg will already have the Depends...
<lool> We should have a gdm-bin thingy like you have a split between meta and binaries
<jcristau> the init script says 'hey, i might start Xorg, and if i do it needs hal started'
<jcristau> but you don't need that leaking in the packaging, since Xorg can have deps of its own :)
<lool> Yeah, so the package deps might want to say "Hey, I might need xorg (recommends) and my init script will attempt to start hal because it's needed in most cases (recommends)"?
<lool> But I've reverted it
<lool> I don't have a strong opinion on it, and I know we have too many deps
<lool> Can't think of something that would break without the dep, so I don't need to care too much
<lool> jcristau: thanks for discussion
<tjaalton> bryce: the displayconfig-gtk change was added to the old changelog entry :)
<tjaalton> not hugely important though
<tjaalton> -gh
<bryce> ok
<tjaalton> bryce: fixed it in git
#ubuntu-x 2008-11-20
<seb128> tseliot: is bug #297706 really a g-c-c bug? or is that a bug in the tool which does set the virtual setting
<ubottu> Launchpad bug 297706 in gnome-control-center "Cannot select optimal resolution in dual screen setup (virtual screen size too small)" [Undecided,New] https://launchpad.net/bugs/297706
<tseliot> seb128: it can't be a bug in the python part since we calculate the virtual resolution in the C part
<seb128> tseliot: ok, I didn't look at the code and it's not clear to me what code does what there
<tseliot> seb128: anyway I'll ask the user to try again
<seb128> tseliot: thanks
<tseliot> you're welcome
<superm1> bryce, ping
<superm1> bryce, regarding that vbios on the 1535, i'm assuming the vbios should remain identical regardless of the LCD used on it, so i can add in a vbios from a "functional" machine?
<bryce> superm1, I'm assuming it needs to be from an afflicted machine
<superm1> okay well i won't bother then
#ubuntu-x 2008-11-21
<james_w> hey, I got a build failure on ia64 on a package that uses XTest.h due to XInput.h not being installed.
<james_w> http://launchpadlibrarian.net/19774512/buildlog_ubuntu-jaunty-ia64.cairo-dock_1.6.3.1-0ubuntu1_FAILEDTOBUILD.txt.gz
<james_w> the package doesn't use symbols from XInput.h from what I can see, so it seems like something might be missing a dependency
<james_w> (I can't work out if it should be libxtst-dev or x11proto-something)
<james_w> or is it something else entirely?
<bryce> james_w: sounds like a dropped patch
<james_w> in cairo-dock, or some X component?
<bryce> one sec
<bryce> x11proto-input provides XInput.h
<bryce> however I don't see any dropped patches there
<james_w> I'm not sure why it's ia64 only either
<james_w> though a few ports architectures haven't built yet
<bryce> that could be why
<bryce> james_w: libxi is involved as well
<bryce> via the 100_add_xinput.h.patch patch
<bryce> however it also looks like it's not dropped any patches that I can see
<james_w> there's a sponsor request open for a package which adds a dependency on libxi-dev due to a build problem a while ago, I'm not sure if that is the same issue
<bryce> quite possible
<james_w> the sponsor request is bug 298496
<ubottu> Launchpad bug 298496 in anyremote "Please merge anyremote 4.6-1 (universe) from Debian unstable (main)" [Wishlist,Triaged] https://launchpad.net/bugs/298496
<james_w> which has In file included from xemulate.c:32:
<james_w> /usr/include/X11/extensions/XTest.h:50:35: error: X11/extensions/XInput.h: No such file or directory
<wgrant> Right, Debian is out of date.
<wgrant> I believe upstream moved it into libxi-dev, and we followed.
<wgrant> Or was it the other way around...
<wgrant> ANywya, we do have it in the other package, although it was gone altogether in Jaunty until a couple of days ago.
<tseliot> mvo: did you have a look at this bug again? https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/292774
<ubottu> Ubuntu bug 292774 in xorg "multiseat xorg.conf setup broken after upgrade to 8.10" [Undecided,Incomplete]
<tseliot> if you give me a link to the script you put in Update Manager I think I can fix the bug
<Ng> <random>anyone have any idea how to extract video timings from windows to make a modeline?</random>
<mvo> tseliot: I have seen it, yes. but haven't done anything about it yet
<mvo> tseliot: do you think the suggestion to check for multiseat is ok? my understanding was that the multiseat setup would be broken after the upgrade anyway unless 'Option "AutoAddDevices" "off" is set
<mvo> tseliot: or do you think we should aim for transitioning that as well?
<Ng> hmm, bah, I don;t think this is a timing issue, it's using exactly what the TV asks for. stupid G45 driver must be doing something wrong then
<tseliot> mvo: I think that counting the number of serverlayout sections should be enough. If there's more than one then don't touch the xorg.conf
<tseliot> mvo: look for "serverlayout" (case-insensitive) in lines which don't start with "#"
<mvo> tseliot: thanks I add that
<tseliot> great
<mvo> tseliot: do you think its common enough to justify a sru?
<tseliot> mvo: not very common but I guess it's still worth a SRU
 * mvo nods
<mvo> tseliot: I commited the "do not touch" bits now
<tseliot> mvo: great, thanks
<superm1> kees, bryce i was thinking this morning when i came to unlock my keyboard, i wonder if ctrl-alt-backspace is available by default even when locked.  to my surprise it was.  isn't that a bit of a security hole?  someone can go and muck with any of your running apps just by pressing that combination
<tseliot> superm1: CTRL+ALT+DEL should work too ;)
<superm1> tseliot, no it doesn't.  that only brings up your session log out options
<superm1> tseliot, however if you switch to a VT and try it, it does
<tseliot> superm1: ok, you can simply press the (physical) "power" button :-P
<tseliot> superm1: did you mean that ctrl-alt-backspace works even when "dontzap" is set in the xorg.conf?
<superm1> tseliot, but at least for behaviors like that you have things such as bios and power on passwords
<superm1> tseliot, no i dont have it in xorg.conf, but i'm saying that it should at least be toggled on the fly in the running session - particularly if you lock your screen
<superm1> i'm not sure if that is available however
<kees> superm1: it's a bit of a DoS, yeah, but I think the benefits have continued to outweight the down sides
<kees> if I could spell
<tseliot> superm1: maybe we should allow users to choose to add that option in some UI
<superm1> kees, benefits in the sense of debugging and availability to restart an X server when things go wrong you mean?
<superm1> tseliot, yeah that would be sensible i think, at least combined with also toggling that behavior automatically when the screen gets locked/unlocked
<superm1> but again it begs whether the X server can allow you to change the feature on the fly
 * tseliot nods
<tseliot> superm1: maybe you could write a blueprint about this so that we can discuss it at the UDS.
<superm1> yeah. i can do that (unless someone hear is sure that there is a piece in the chain that won't allow this)
<superm1> *hear = here
<tseliot> bryce, jcristau: any ideas ^^ ?
<kees> superm1: it's been a long-debated config item.  I have no personal opinion, but would want to have it available since I use it (especially on myth when the frontend hangs...)
<superm1> kees, yeah i think leaving the default behavior as how it is when sessions are active, but provide a UI capplet for changing it - and then always change it if the screen locks
<superm1> it would provide the closest to the same behavior while still helping the problem at hand
<superm1> you still get hangs though in myth? i guess i turn off my frontend every night, so if there was say a memory leak that grows over time i wouldn't have seen it =)
<kees> superm1: yeah, though I isolated (but have no solved) one of them to exiting xine: xine just kind of doesn't fully quit sometimes.
<kees> superm1: and sometimes when trying to start a really giant HD recording it just kind of goes away
 * kees shrugs
<superm1> kees, ah actually i have seen that in xine, but its infrequent enough that i never bothered to look at it.  just pkill at that point
<kees> superm1: yeah, in my .Xsession I've added a little ircat loop that waits for POWER to be pressed on the remote and then kills xine if it's running, and if xine isn't running, kills the frontend.  now I don't have to get up to use ctrl-alt-bkspc.  :)
<jcristau> superm1: zap defaults to off upstream now, fwiw
<jcristau> so ctrl-alt-bs doesn't do anything
<jcristau> not that i think it's a good thing, but hey
<superm1> jcristau, so at the ubuntu level, we are intentionally turning it back on, or this was a recent change in defaults?
<jcristau> that was post-1.5
<superm1> ah okay.  so is there any type of interface exposed for turning it back on that a capplet can stub out?
<jcristau> not without changing xorg.conf or the X command line
<superm1> and it would probably be a significant amount of work to add a runtime option somewhere in the stack?
<jcristau> not really. enable zap, and change its mapping in xkb.
<jcristau> it's not hardcoded to ctrl-alt-backspace, aiui
<superm1> so just map it to some non-present key, and then remap it to ctrl-alt-backspace when you "turn it on"
<jcristau> something like that
<jcristau> should work today, even
<bryce> superm1: daniels disabled it a few weeks ago.  We'd been discussing in ubuntu to change it to requiring holding it down for several seconds, or beeping or some such; one of the users involved in that discussion went upstream, figuring it should be the same way across distros
<bryce> daniels thought it was more sensible to just shut it off by default, and provide it on by default with the -retro option
<bryce> superm1: the xorg.conf option editor spec tseliot has worked on will expose the option in a GUI (although it may be too many options for an ordinary user to wade through to get to it)
<superm1> bryce, I thought the idea was to be moving away from xorg.conf in general though?
<superm1> still for settings like these it makes sense i take it?
<bryce> I was thinking maybe rather than expose just the dontzap option, if we could have a toggle for -retro
<superm1> so there is a second part to this though, what about VT switching? is that also disabled when you set dontzap?
<bryce> superm1: longer term I expect upstream will be making the server and driver options dynamically settable
<bryce> dontzap doesn't affect vt switching
<bryce> or, if it does, that'd be a bug ;-)
<superm1> bryce, okay.  then i think the second part is to just make sure that whatever functionality is allowing you to ctrl-alt-delete from a VT even when X is running gets disabled if X is running
<bryce> you mean -backspace?
<superm1> no i mean ctrl-alt-delete
<superm1> it triggers a restart if you switch to a VT
<bryce> ok, that's not handled by X afaik
<jcristau> that's handled by the kernel
<jcristau> probably only in KD_TEXT though
<bryce> yeah
<jcristau> or, only when the console is not in raw mode, or something
<superm1> i seem to remember that functionality being configurable by something in etc/
<superm1> at least what behavior occurs when ctrl-alt-delete is pressed from a console
<superm1> etc/event.d/control-alt-delete
<superm1> okay i've filed a separate bug about that - bug 300771.  
<ubottu> Launchpad bug 300771 in upstart "control-alt-delete should not restart the machine if gdm,kdm, xdm, or X is running" [Undecided,New] https://launchpad.net/bugs/300771
<tormod> hi I am trying to build latest intel again (succeeded some weeks ago). now libtool looks for libdrm.la and fails. there is "-ldrm" on the libtool command, don't know how that turns into libdrm.la now and not before. any hints?
<bryce> tormod: do you have libdrm 2.4?
<tormod> bryce: yes
<bryce> ok
<tormod> the file list of the libdrm-dev is the same, the libtool command line is the sam
<tormod> hmm I should try debian-unstable, it's newer than debian-experimental ...
#ubuntu-x 2008-11-22
<tormod> bryce, I pushed a clean-up of xorg-pkg-tools.lib  -  I think your editor wrapped and broke things
<tormod> maybe you should check other files that you touched
<bryce> tormod: thanks
<bryce> tormod: I think it must have wrapped when I cut-and-pasted :-/
<tormod> sounds likely :)
 * bryce waves
#ubuntu-x 2008-11-23
<tjaalton> whee, snow
<lopin> Hello.  I was wondering if someone could help me out with a problem that I'm experiencing with Xorg?
<lopin> I'm having problems with my mouse.
<lopin> After a clean install of the xorg, and depended packages after a clean install of a cli, I have no ability to use my mouse, even after restarts.
<lopin> It just started this yesterday.  I was fiddling with the sound card, in order to get it to work, and had a copy of windows 98 on here, and several more installs of Intrepid CLI, and the problem is rather distressing...
<lopin> The keyboard also does not function, but only allows me to switch back to the console.  Does anyone know how I can try to get my mouse and keyboard working again?
<lopin> I'm noticing 3 errors popping up when I start x...
<lopin> (EE) [drm] drmOpen failed.
<lopin> (EE) MACH64(0): [dri] DRIScreenInit Failed
<lopin> (EE) config/hal: couldn't initialise context: (null) ((null))
<tjaalton> install hal
<lopin> Why would that not be installed now?  Would that have not been a dependency now for some reason?  I'm installing it now...
<tjaalton> it's a dependency in jaunty
<lopin> I had this installed two days ago, and it worked fine.  I installed Windows 98 to see if I could get the sound card to work at all, and then it refused to work the next time I installed Intrepid...
<lopin> I'm just kind of confused is all...
<lopin> That frickin worked!  Thank you!  I'd have never even thought to try that!
<tjaalton> Ng: how should i pronounce 'Canan'? is it with a diphtong or not :)
<tjaalton> Ng: rehearsing 'israel in egypt' by hÃ¤ndel, thatÃ¤s why i'm asking..
<tjaalton> uh
<tjaalton> s/Ã¤Ã¤
<tjaalton> fuck
<tjaalton> s/Ã¤s/'s/
<Ng> tjaalton: kay-nann
<Ng> maybe kay-nunn
<tjaalton> Ng: yeah, just as i thought, thanks
#ubuntu-x 2009-11-16
<tjaalton> back home again
<scheich> hi
<scheich> somebody there?
<Duke`> yes?
<scheich> hi Duke`
<scheich> have a small question
<scheich> do u think its clever to use the ubuntu xorg drivers in debian sid?
<scheich> intel
<scheich> just wanted to try gnome-shell, but its not running fluently
<scheich> with ubuntu 9.10 it runs smooth
<Duke`> I don't know
<Duke`> maybe tormod would know better
<scheich> ok
<scheich> he didnt seem to be there
<scheich> hmm
<scheich> think I will risk it :)
<pwnguin> interesting. when did nvidia drop rotation from their mix?
<pwnguin> false alarm; seems an option was dropped on upgrade =/
#ubuntu-x 2009-11-17
<Ng> bryce: I hope you noticed that the rooms here have a VGA cable for the TV :)
<bryce> Ng, indeed!
 * Ng hacking code on LVDS1 while VGA1 plays video \o/
<bryce> nice
<Ng> although it hated doing it at 1080, so I had to go for the next mode down
<bryce> yeah unfortunately I didn't bring any rips
<jcristau> tjaalton: you not at uds?
<bryce_> tjaalton, there aren't really anyone but me here for X, so didn't seem worthwhile to have a bunch of X sessions
<bryce_> anyway --> lunch
<tjaalton> jcristau: nope, just finished a two week trip to south korea & hong kong, so it was a no-op ;)
<jcristau> heh
<tjaalton> hey, what about debian? the freeze was pushed forward to March am I right?
<jcristau> yes
<tjaalton> ok, so 1.8 is theoretically possible?
<tjaalton> hmm, maybe wait until bryce is here.. I'll be back later
<jcristau> yeah.  if somebody works on it.  right now X in debian has nobody with enough time
<tjaalton> bryce: yeah, ok. I'll post my opinion about the 1.8 issue on the list tomorrow, too tired now :)
<bryce> ok
<bryce> tjaalton, will you be staying for the proprietary driver talk (in 10 min)?
<tjaalton> hum
<tjaalton> let me check the spec
<tjaalton> I should be getting to bed right now, but I'll comment some of the points here:
<tjaalton> the patches; still needs an overhaul of the way how the default driver is selected by the server, when coming from a simple xorg.conf, otherwise it'll break (ie. always uses the first option, no fallback)
<tjaalton> alternatives vs. diversions; I think the latter is well tested by now, and I suspect there might be other problems by using the alternatives system (not being consistent all the time, what package get's the top priority etc)
<tjaalton> other than that, I don't have much to comment right now :)
<tjaalton> still jetlagged, so bye for now and "see" you tomorrow ->
<bryce> thanks
<bryce> for anyone interested in the discussion /join #ubuntu-uds-lonestar2
<bryce> tseliot, are you following the discussion ok?
<tseliot> bryce: yes, I can hear most of it
<Riotta> hello
<Riotta> don't know is this a good place to ask but guys from #ubuntu-bugs pointed me here
<Riotta> I'm and some other Ubuntu 9.10 having problem with xserver-xorg-input-evdev package
<Riotta> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/441408 launchpad entry is available here
<ubottu> Launchpad bug 441408 in xserver-xorg-input-evdev "[MASTER] Mouse jumps to bottom corner on click in fullscreen games. New mouses (A4Tech). Related to DGA / DGAMOUSE in SDL." [Low,Confirmed]
<Riotta> we tested this issue alot
<Riotta> and we came to conclusion that the cause of this problem can be in some changed which were made for ubuntu 9.10 from 9.04
<Riotta> in this package, so any fixes/patches applied could broke the package
<Riotta> I can test more and share with the knowledge I have gathered in order to fix this bug with you
<Riotta> anyone can help me?
<tormod> Riotta, if you have narrowed it down to a -evdev version, that's pretty good
<Riotta> I hope so
<tormod> Riotta, if you check the changelog, you'll see 2.2.3 had a fix for a similar issue
<tormod> Riotta, there are no Debian/Ubuntu patches in it, so it is probably an upstream bug.
<tormod> Before filing a bug at bugs.freedesktop.org, you should try the latest upstream version.
<tormod> We have newest xserver and evdev in the xorg-edgers PPA for lucid
<Riotta> ah
<Riotta> so basically you telling me to check same package from xorg-edgers ppa and see if it will be bug-free?
<Riotta> hello again
#ubuntu-x 2009-11-18
<virtuald> is it possible to dist-upgrade to lucid now? update-manager -d didn't work yesterday
<bryce> virtuald, wrong channel
<tjaalton> bryce: ok, mail sent
<Sarvatt> lol tormod we just uploaded mesa at the exact same time :D
<tormod> Sarvatt, d'oh :)
<Sarvatt> 7.8.0~git20091118.eec42828-0ubuntu0sarvatt <= 7.8.0~git20091118.eec42828-0ubuntu0tormod
<Sarvatt> 7 minutes ago, you uploaded 8 minutes ago, thats some timing
<tormod> I always check to see if you're on IRC before uploading, but didn't today
<tormod> I uploaded 7.7 branch to karmic
<tormod> did you upload to karmic?
<tormod> not the first time we are scarily synchronized :)
<Sarvatt> yeah i did but my lucid source package wasnt accepted so karmic and jaunty didnt get accepted
<Sarvatt> so no worries there :)
<Sarvatt> intels still broken :(
<Sarvatt> wonder if its broken on an actual karmic install with the older pixman
<Sarvatt> Duke`: are you on karmic by any chance? i remember you saying you had the same problem a few days ago
<Sarvatt> tormod: can you resend that email? i dont see the script attached
<tormod> Sarvatt, I noticed that after clicking send :)
<Sarvatt> hmm, you're doing nouveau with the script? last time i messed with that debian builds it alot differently than we do and it was better to use the get-orig-source instead
<tormod> anyone here seen bug 459961? a disturbing number of duplicates
<ubottu> Launchpad bug 459961 in mesa "radeon_dma.c:210: radeonRefillCurrentDmaRegion: Assertion `dma_bo->bo->cref == 1' failed." [Medium,Confirmed] https://launchpad.net/bugs/459961
<tormod> Sarvatt, I build it with origin/ubuntu
<Sarvatt> oh nice it was only in bzr back then i think
<Sarvatt> well the mesa 7.6 snapshot should fix that, http://cgit.freedesktop.org/mesa/mesa/commit/?h=mesa_7_6_branch&id=13b5a624b1899c457279907d58046dfb3c95addc
<Duke`> Sarvatt, I'm on karmic yes
<Sarvatt> you had the alpha channel problems or whatever a few days ago right?
<Sarvatt> background on desktop fonts was black, black fonts were light colored
<Duke`> yeah
<tormod> Sarvatt, ubuntu has had that mesa commit for a long time
<Sarvatt> http://img260.imageshack.us/img260/4760/unusable.png
<Sarvatt> still looks like that here with the latest git
<Sarvatt> ahhh gotta run, catch ya guys later
<tormod> hmm that commit/patch brought that assert back
 * bryce waves
#ubuntu-x 2009-11-19
<hyperair> it seems that if you click at around 392 clicks per second, you can cause synaptics to crap up. =p
<hyperair> and get tonnes of EQ overflows
<hyperair> i wonder if that constitutes as a bug, heheheh
<bryce> michaellarabel, please change your article - the way you wrote it it sounds like I am pushing for xserver 1.6 and that is not correct
<michaellarabel> Sure thing, sorry for any confusion bryce.
<jcristau> tormod: i just noticed the i-g-t debian/watch downloads the bz2 tarball instead of the gz one.. might consider changing that.
<jcristau> (for next time)
<tormod> jcristau, oh, yeah next time is fine :)
<tormod> jcristau, is the watch regexp used for anything else than probing for version anyway?
<jcristau> i use uscan to download the tarball
<jcristau> 'uscan --download-current-version' in this case, which got me the bz2
<tormod> I see. I should have done that too :)
<jcristau> hehe
<tormod> jcristau, but there is nothing in the git tree that reveals what was used (for git-import-orig)?
<tormod> jcristau, anyway the point is that debian still needs an orig.tar.gz and not orig.tar.bz, right?
<jcristau> pristine-tar can be used for that
<jcristau> we can have orig.tar.bz2 with source package v3.  but aiui launchpad doesn't support that yet, so probably best to hold off for a little while.
<jcristau> tormod: tagged and uploaded, thanks
<tormod> jcristau, thanks. does your upload script automatically tag it or did you do that manually?
<jcristau> i did it manually
<jcristau> tormod: did you subscribe to the pts (bug reports and stuff) for the package?
<tormod> jcristau, now :)
<jcristau> (looks like it's in incoming now, so all good)
<jcristau> next step is to request removal of the binaries for !x86, since they're useless and won't build this time around
<tormod> the old 1.0.1-1 binaries?
<jcristau> yes
<Sarvatt> hmm so chromeos is based on karmic right now huh..
<bryce> Sarvatt, where are you seeing that mentioned?
<Sarvatt> i'm looking through the source
<Sarvatt> http://src.chromium.org/cgi-bin/gitweb.cgi?p=chromiumos.git;a=blob;f=src/package_repo/repo_list_dev.txt;h=7be40563a58172d5dced5c30db5ca3e439c18448;hb=HEAD#l309
<bryce> oh sneaky
<bryce> michaellarabel, thanks that wording looks much better
<michaellarabel> NP bryce, sorry about any confusion.
<mac_v> bryce: Sarvatt: http://blog.canonical.com/?p=294
<bryce> mac_v, thanks
<mac_v> np .. hehe , i just noticed that blog after you guys mentioned it :)
<Sarvatt> updating tormod?
<tormod> Sarvatt, yes :) holding back intel and ati
<Sarvatt> Press enter to build packages ...
<Sarvatt> lol
<Sarvatt> looking over your scripts, i havent used ppa-update before ever
<tormod> any news about that -intel issue?
<Sarvatt> nothing, if you want to put it back up and just break everyone so it gets more notice feel free :D i'll just build the old one locally with a higher version because i'd like things to work
<Sarvatt> uploading a new xserver with the 2 exa updates now
<tormod> cool!
<tormod> no, if -intel will be broken for everybody I won't upload it :)
<tormod> they include a ChangeLog target in all drivers upstream now, it will conflict with the one we make sometimes
<tormod> auto-xorg-git has some logic for this (or maybe for the opposite situation)
<tormod> probably some work to do there
<tormod> Sarvatt, I see you use origin/ubuntu for xserver. why not debian-experimental, I guess you tried it?
<tormod> anyway I hope lucid will go 1.7 soon
<Sarvatt> they build alot different
<Sarvatt> different options in debian/rules, different packages in control
<Sarvatt> at least last i looked it was that way, i just did server in a hurry after hours of libs and protos
<tormod> ok I see. now I also see the new upstream driver changes causing build havoc. will look at that next week.
<Sarvatt> those commits by Gaetan Nadon on just about every package the past few days?
<tormod> yes
<Sarvatt> missing files trying to be installed in debian/.install i'm guessing?
<tormod> I just saw there was some configure stuff asking for some xorg-macro stuff, autoconf fun I guess
<Sarvatt> on jaunty? dont think i put xutils-dev with xorg-macros 1.3 up for jaunty
<Sarvatt> looks like everything needs it now too..
<Sarvatt> ah looks like we might need to update macros, he did a bunch of commits to that before he started changing everything..
 * tormod -> bed
#ubuntu-x 2009-11-20
<Sarvatt> tormod: yeah its just because you were building all those drivers in drivers-only without macros 1.3 that they all require now
<Sarvatt> oh darn he isnt here
<tjaalton> whoa, wacom 0.10.1 doesn't rely on hal nor libudev, but queries the kernel directly for the capabilities
<tjaalton> is tormod a DD now?
<hyperair> is that a good thing or a bad thing?
<tjaalton> both are good, if true :)
<hyperair> hmm that's cool =p
<hyperair> but wouldn't that require a bit of reimplementation of things?
<tjaalton> it's done in the driver
<tjaalton> hmm, 98 packages to update in debian
<hyperair> by driver you mean kernel module or what?
<tjaalton> no, the X driver
<hyperair> ah
<tjaalton> I've only read the announce, nothing more :)
<tjaalton> +ment
<hyperair> i see
<tjaalton> tseliot: hey, check the wacom 0.10.1 announcement ;)
<tseliot> tjaalton: let me check xorg-announce
<tseliot> tjaalton: now *that* is what I call a cool release. Do we need a new kernel?
<tjaalton> tseliot: no idea, I think not
<tseliot> it's definitely something that I have to try
<Sarvatt> nice, building that new wacom on edgers to try it out
<tjaalton> bryce: there's a fresh wacom that queries the kernel for the device properties, so no hal or udev is needed :)
<Sarvatt> there we go, took a ton of rule changes since the 0.8.4 versions but wacom 0.10.1 is working now in edgers lucid repo under xorg 7.5/xserver 1.8 if anyone wanted to try it
<tjaalton> I don't think there's sense in using the old wacom-tools as a base
<tjaalton> bah, gotta go ->
#ubuntu-x 2009-11-22
<hyperair> does anyone know of a compiz hang with 8086:2772?
<RAOF> Oh, hello!  There are plans for including nouveau's drm in Lucid's kernel?
#ubuntu-x 2010-11-22
<Sarvatt> phew, so many sync requests :)
<Sarvatt> BlackZ: thanks a ton for helping with the universe ones
<BlackZ> Sarvatt: :)
<Sarvatt> BlackZ: I really think we should wait for xterm 267 that fixes all the linking problems btw, it just got released
<BlackZ> Sarvatt: is it in Debian?
<Sarvatt> not yet, it *just* got released
<BlackZ> Sarvatt: ok, then I will wait for the Debian maintainer to update it
<BlackZ> Sarvatt: by the way, can you give a look at bug #677961 ?
<ubot4> Launchpad bug 677961 in ppa-purge (Ubuntu) (and 1 other project) "Fails to deal with compressed indexes (affects: 8) (heat: 38)" [Undecided,New] https://launchpad.net/bugs/677961
<Sarvatt> oh *fun*
<BlackZ> Sarvatt: if you have a fix for it, please let me know
<BlackZ> Sarvatt: otherwhise maybe I can give it a look tomorrow evening
<Sarvatt> double argh, W: Failed to fetch http://extras.ubuntu.com/ubuntu/dists/natty/main/binary-i386/Packages.lzma  404  Not Found
<Sarvatt> lzma too?
<Sarvatt> tjaalton: so who volunteered to maintain this klingon delta in libX11 again so I can ping them? :)
<jcristau> was from lifeless iirc
<tseliot> Sarvatt, RAOF: what's the status of bug 650539 in Maverick?
<ubot4> Launchpad bug 650539 in xorg (Ubuntu Maverick) (and 6 other projects) "SRU: Launching a Qt app crashes X when using Xinerama (affects: 88) (dups: 10) (heat: 518)" [High,Triaged] https://launchpad.net/bugs/650539
<Sarvatt> needs upload desperately
<tseliot> Sarvatt: upload or approval by the SRU team?
<tseliot> or both?
<Sarvatt> not sure if anyone prepared a package there but I know that fix is needed really badly
<tseliot> Sarvatt: ok, I'll deal with it then
<tseliot> Sarvatt: err... we don't have a branch for Maverick, do we?
<tseliot> only one branch, right?
<Sarvatt> nope
<Sarvatt> yeah
<tseliot> I'm asking as it seems that pitti uploaded 1:7.5+6ubuntu3b1 in Natty
<jcristau> that doesn't sound like a server version
<Sarvatt> xorg-server
<tseliot> while we still have 1:7.5+6ubuntu3 UNRELEASED in git (???)
<Sarvatt> thats the meta package
<Sarvatt> patch is for xorg-server
<Sarvatt> http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.9-branch&id=3effb61e207478d92ebbcf5dfc75535cdd2dda12
<Sarvatt> we'll get the fix soon in natty
<tseliot> right, I pulled the wrong code and my eyes are a little tired...
<tseliot> sorry for the noise
<tseliot> hehe I was even surprised that git clone was so fast
<tseliot> thinking that it was xorg-server...
<Sarvatt> tseliot: no need to do it in git really, we've got a newer one in natty already and no maverick branch
<tseliot> Sarvatt: yes, I figured it out after seeing the git log
<tseliot> I'll just change the package
<tseliot> Sarvatt: I assigned the task for Maverick to myself. I hope RAOF doesn't mind
<Sarvatt> i'm sure he doesn't, thanks a ton tseliot!
<tseliot> good :)
<tjaalton> Sarvatt: yeah it was lifeless
<Sarvatt> yay x11-apps compiles again http://sarvatt.com/downloads/patches/0001-x11-apps-Fix-linking-with-no-add-needed.patch
<Sarvatt> bryceh: mind sponsoring http://sarvatt.com/downloads/merges/x11-apps/ if you get a chance?
<Sarvatt> ah wait I should include the debian changelog updates in .changes
<bryceh> Sarvatt, sure, I'll ask a small favor in return
<Sarvatt> there we go http://sarvatt.com/downloads/merges/x11-apps/
<Sarvatt> anything, what's up?
<bryceh> Sarvatt, I was taking a look at 312756 (it generates ample bug mail to me).  I don't know that there's anything we can actually do about it other than wait on upstream.  But would you mind taking a quick look and tell me your opinion?
<bryceh> it's the hybrid graphics hot swap issue
<bryceh> currently the bug is having people submit their DSDT's but is that just busy work or is there actually something that can tangibly be done with it?
 * bryceh goes a-sponsorin'
<Sarvatt> there's nothing we can actually do, but I think having people upload their DSDT's to that bug in a central place is very useful
<bryceh> how would the DSDT's be used?
<Sarvatt> you can tell how the multiple GPU's are implemented on that platform, i've dug into dsdt's from there many times looking up laptops to recommend to people because some are hopelessly crappy but some you can potentially switch via that acpicall module and there's no way to know without looking at the dsdt
<bryceh> )(x11-apps_7.6+2ubuntu1_source.changes uploaded
<Sarvatt> is there any way to make wishlist bugs specifically not spam email maybe? :)
<Sarvatt> thanks man!
<bryceh> procmail ;-)
<bryceh> I think what I'm going to do is set up a procmail rule to put ^Subject: .*MASTER: bugmails into launchpad.masters
<bryceh> and I prepended MASTER: onto this one
<bryceh> Sarvatt, well the only thing we need to think about when asking users "post blah to this bug" is that launchpad will eventually start timing out and throwing oopses when a bug exceeds a certain number of attachments
<bryceh> [ubuntu/natty] x11-apps 7.6+2ubuntu1 (Accepted)
<Sarvatt> darn, launchpad is that broken?
<Sarvatt> I used that bug extensively when shopping for a new laptop for instance :D
<bryceh> yeah we had a similar bug report where people posted data about unsupported joystick buttons, that eventually hit the limit
<bryceh> I encountered it due to my arsenal scripts choking on it when processing through bugs
<bryceh> again it was another situation where there was nothing we could do, it was a kernel / protocol limitation
<bryceh> iirc
<Sarvatt> I still reference that evtouch lshal bug to tell people quirks for their touchpads :D
<bryceh> can you load it?
<Sarvatt> I could last week when I did last, hmm
<bryceh> well possibly launchpad fixed the problem, but it would oops regularly for me when I looked into the oops a few months ago
<bryceh> oh you know what, maybe the did fix it
<bryceh> I was bugging people left and right about that issue when I was on launchpad
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xf86-input-evtouch/+bug/317094?comments=all works fine
<ubot4> Launchpad bug 317094 in xf86-input-evtouch (Ubuntu) "meta bug to collect lshal touchscreen info (affects: 44) (dups: 2) (heat: 316)" [Undecided,Won't fix]
<Sarvatt> maybe they were playing with timeouts?
<bryceh> no one had a clue at the time, but I recall lifeless kept working on it
<Sarvatt> https://edge.launchpad.net/ubuntu/+archive/primary/+copy-packages?field.name_filter=linux&field.status_filter=published&field.series_filter=natty  used to timeout oops 99% of the time for me, but its been ok lately
<Sarvatt> speaking of which, 5th kernel copy in a row that worked fine, amazing!
<Sarvatt> for 6 months it would oops every time but actually do the copy
<Sarvatt> OOPS-1787ED1419
<ubot4> https://lp-oops.canonical.com/oops.py/?oopsid=1787ED1419
<Sarvatt> didn't like searching for linux packages in sid :)
<bryceh> interesting; they're changing the wayland license from MIT to LGPLv2
<ilmari> bryceh: URL?
<Sarvatt> http://lists.freedesktop.org/archives/wayland-devel/2010-November/000249.html
<pcjc2> Hi guys, how are things in Intel-gfx land on Ubuntu?
<pcjc2> I've been testing for a while on maverick + Xorg-edgers + Natty kernel + drm-intel-next DRM backport, and all is really good
<Sarvatt> the usual, many regressions creeping in and getting fixed up shortly after on the kernel side lately :) maverick's 2.12 still has problems with the copy-fb patch, intel GPU's are still slow as dirt, nothing too exciting
<Sarvatt> natty wont get "fun" until around christmas when mesa 7.10 goes in
<Sarvatt> although compiz 0.9.2.1 that's in here is already lots of "fun"
<pcjc2> Using the drivers on a daily basis and tracking kernel changes, I can pretty much pinpoint the regressions, ping Chris Wilson, and he fixes them in about 2 hours or less ;)
<pcjc2> "fun" as in bad?
<Sarvatt> yeah he's awesome like that, I agree :)
<pcjc2> xorg-edges mesa tracks master, right...? That seems pretty good to me
<Sarvatt> yeah
<pcjc2> shader compiler is pretty rubbish, but I can't see that being my bottleneck yet
<Sarvatt> well you probably dont use things like kwin where the fun shows up :)
<pcjc2> I have too many damned pixels on screen to get decent framerate, even with glClear
<pcjc2> I have occasionally turned compiz on, but tend to switch it back off to do performance testing
<pcjc2> What surprises me is that the desktop, compositing, etc.. don't "seem" slow, yet one measly NOOP render running a glClear once per frame can't beat 60fps full-screen (with sync to VBLANK disabled)
<Sarvatt> been focused on sandybridge here and its fun finding out all my hardware has errata making it useless on the graphics side
<pcjc2> Still trying to find the magic bullet to cure that, in my search have just ordered some more 800Mhz ram (had a 667Mhz chip in there)
<Sarvatt> sheesh, mesa is a blast to work with sometimes eh?
<pcjc2> yep
<pcjc2> Canonical has some Sandybridge pre-production machines to play with?
<Sarvatt> yeah, it's surprisingly decent too (just not on linux) :)
<pcjc2> from the sounds of the development work, the architecture has changed a lot
<Sarvatt> pcjc2: what GPU are you using where things are fine on edgers?
<pcjc2> GM45
<pcjc2> But note the drm-intel-next kernel backport
<Sarvatt> interested because I've seen some reports of people having to disable page flip support still and we dropped the disabling patch in natty (it's been disabled in edgers since 2.12)
<pcjc2> woot.. magic switch
<pcjc2> (One I'd found before)
<pcjc2> sudo intel_reg_write 0x21D0 0x1000207
<pcjc2> 59.6 redraws per second -> 82.8 redraws per second
<pcjc2> with one BIT of one ECO register
<pcjc2> oh, no.. wait - it has gone back again.. WHY must things be so variable
<pcjc2> I know that bit has bumped performance for me before.. it disables some clock-gating on the chip's rendercache. It was a documented 965 ECO, but still seems to do "something" in GM45.
<nigelb> bryceh: hi, need your take on a bug
<nigelb> bryceh: bug 325581, the patch needs to go into kernel or into xorg server?
<ubot4> Launchpad bug 325581 in xserver-xorg-input-evdev (Ubuntu) (and 1 other project) "kensington pocket mouse model #72237 USB 0d62:1000 not working under 8.10 (affects: 1) (heat: 17)" [High,Confirmed] https://launchpad.net/bugs/325581
#ubuntu-x 2010-11-23
<bryceh> wazzah, bugbot lives:  https://launchpad.net/~bugbot
<bryceh> heya nigelb
<bryceh> lessee
<bryceh> nigelb, neither; looks like the patch is against xserver-xorg-input-evdev
<bryceh> nigelb, however be careful; I think some input devices prefer the axes oriented the way they are
<bryceh> it may be that a more sophisticated patch is needed to cover this corner case without breaking the general case
<bryceh> but I haven't looked at it too deeply
<bryceh> nigelb, probably would be wise to package the patch in a ppa and get a few people with different kinds of mice to test it before putting it in for sponsorship
<bryceh> nigelb, or alternatively forward the patch upstream to bugs.freedesktop.org for review
<nigelb> bryceh: I'll forwards \o/
<nigelb> Thank you for looking :)
<bryceh> no prob
 * nigelb hugs bryceh :)
 * bryceh hugs nigelb
<nigelb> :)
<bryceh> fwiw, we get axis fiddling patches like that one for the input drivers quite a lot... one set of users send patches to flip the axis one way, another note a regression and send patches to flip them back.  :-D
<nigelb> haha
<bryceh> upstream knows the right way to do things
<bryceh> Sarvatt, RAOF, prepare for an onslaught of bugbot spam :-)
<bryceh> Sarvatt, RAOF, at least now it's more easily procmailable
<nigelb> bugbot? email bugs?
<Sarvatt> bryceh: whats bugbot? I've already got 23k unread in my ubuntu-x-swat folder :D
<bryceh> Sarvatt, prepare for 23k more
<bryceh> bugbot is basically a new launchpad user account I'm going to use for running my arsenal scripts
<bryceh> so all the arsenal spam will be nicely disassociated from me now
<bryceh> my karma shall suffer greatly.  ;-)
<nigelb> lol
<nigelb> bryceh: you worked on lp team for a cycle, shoulda put in a hack to increase your karma :p
<bryceh> hmm, well I don't think I can fiddle my karma score directly, but I certainly can disable the accounts of anyone with more karma than I... 
 * bryceh rubs hands together "bwahahaha"
<nigelb> haha
<Sarvatt> bugbot has only gotten 2 mails through to my inbox so far :)
<RAOF> Why did I put maverick's mesa on the ubuntu-maverick branch??
<apw> RAOF, Sarvatt, yo ... do you remember the discussion on which AGP drivers we needed built-in ... the notes say (only 4) but there are no hints as to which 4
<RAOF> It was intel, amd, nvidia, via, right?
<apw> RAOF, hrm i don't think we really talkaed about it, i am happy with those four though
<RAOF> I only recall saying that we needde them built in, honestly, but I think those are the ones we need.
<apw> RAOF, thats good enough for me :)
<apw> i will start with those and you can tell us if thats not suffiicient :)
<tseliot> RAOF: built-in? I guess this won't cause issues with proprietary drivers since we blacklist those drivers in the initramfs, right?
<RAOF> That's a good question; the binary drivers have their own agp drivers, don't they?
<tjaalton> probably a non-issue, since airlied thought about making them mandatory anyway
<tjaalton> some time ago
<RAOF> I understand that fedora builds in the agp drivers, so yeah.
<tjaalton> right
<apw> well if they are builtin that won't let you blacklist them anymore
<apw> well if fedora does it  i guess we must be ok :)
 * apw warns you that the next upload of the kernel will carry the switch from =m to =y for these AGP drivers
<RAOF> tseliot: fglrx and nvidia are actually working in natty at the moment, right?  We'll be able to spot any problems this might cause?
<tseliot> RAOF: yes, they are
<tseliot> apw: if we cannot blacklist them, then it's not fine
<apw> how does fedora handle this i wonder
<jcristau> why would you blacklist an agp driver?
<RAOF> These are the agp drivers, not the video drivers - are you sure they're a problem?
 * apw cirtainly has no idea
<apw> tseliot, do you have an example of what we blacklist when we enable prop drivers ?
<RAOF> I don't think we currently blacklist any agp drivers in the proprietary driver voodoo; we blacklist nouveau in nvidia and radeon in fglrx, but that's different.
<apw> yeah not proposing anything that high in the stack gets built-in
<tseliot> apw: we simply blacklist nouveau and the other proprietary nvidia flavours when enabling nvidia.
<apw> so i think we are probabally ok then
<apw> but we do need to watch out when the next kernel goes in to be 100% sure
<tseliot> RAOF, apw: ah, sorry, I misread what you wrote. I missed the "agp" part
<jcristau> i certainly haven't heard of any issues since we started having the agp drivers builtin
<tseliot> that's ok
<jcristau> (we = Debian)
<apw> tseliot, i assume you have some h/w you could test on, if I made up some test kernels
<apw> jcristau, thats a good information point
<apw> (thanks)
<tseliot> apw: sure, I can test things here but, as I said, it should be ok to build in agp drivers
<apw> ok ... done ... thansk
<RAOF> apw: thanks.
<Sarvatt> intel_agp.sucks=1 passed to grub, blacklisted :)
<jcristau> way to prevent stuff from working :)
<Sarvatt> ah hah
<Sarvatt> agp=off
<Sarvatt> then nvagp loads
<Sarvatt> with agp :)
<kklimonda> hey
<kklimonda> would it be possible to contact ati/nvidia and ask them to add a command some line argument, to their driver installers, like "--i-am-aware-that-by-installing-those-drivers-i-void-the-ubuntu-warranty" or something similar, and refuse to install on newer Ubuntu systems without it being set?
<kklimonda> no single week passes without me helping some poor soul fix their system after installing those drivers..
<tseliot> kklimonda: in theory there's already a hook for something like that. It only works if the nvidia packages are already installed though (I guess)
<tseliot> this applies only to nvidia
<kklimonda> tseliot: apparently, that's not enough :/
<tseliot> kklimonda: I can't really force more invasive changes into their installers though. I should really work to improve the situation though. The main problem is my lack of time
<tseliot> it's still on my todo list though
<kklimonda> tseliot: can't you just ask? their current installers pro-actively break systems ;)
<kklimonda> and for some reason people blame us :/
<tseliot> kklimonda: I already did. Which is why I said that I "can't" do that
<bjsnider> tseliot, it only works if the nvidia-common package is installed. i think it should be put into jockey.common
<tseliot> bjsnider: see, I don't even remember how I implemented the whole thing...
<bjsnider> hahaha
<bjsnider> i didn't expect that response
<bjsnider> i think the flaw was putting the hook into a package that is not automatically on everyone's system (nvidia-common)
<bjsnider> but it was a good idea
<tseliot> bjsnider: maybe, as you said, jockey is a better place for that
<bjsnider> i think it should be in a package that is part of ubuntu-desktop or the like
<bjsnider> that way the user would have to seriously bork their system to even try the nvidia-installer
<bjsnider> kklimonda, there's a thread on the nvforums website created by the nvidia devs which tells users not to use their installer, but to use the distro installers instead. nobody cares i guess.
<tseliot> bjsnider: that could still be overridden with an option in the installer, something like --override-distro-hooks
<bjsnider> yes but regular users wouldn't know that without a lot of research
<kklimonda> bjsnider: that's why I've suggested actually modifying the installer - it's been proven that users don't read and are generally bunch of.. -ECOCINCOMPATIBLE
<kklimonda> tseliot: if people use such an argument we can just tell them to contact the person who told them to do that.
<tseliot> kklimonda: the installer already supports that argument that I mentioned (even though maybe that's not the exact name). It's just a matter of making sure that the hook is there when Ubuntu is installed
<kklimonda> tseliot: ah, I see - but only nvidia for now, right?
<Sarvatt> what the heck, swapped out the HDD in my 8400M GS laptop and now the nvidia blob works on both linux and windows, I haven't been able to use the blob on that thing since karmic because it had nasty corruption and lockup problems and would blue screen on boot in windows. I thought the GPU was just screwed
<tseliot> kklimonda: yes, only nvidia. fglrx (when it generates deb packages) uses more or less the same sources of the packages in Ubuntu (since I maintain both). The problem is when it acts like the Nvidia installer I guess (i.e. without generating packages)
<tseliot> Sarvatt: err... maybe the blob was indeed screwed, physically speaking
<Sarvatt> put the 200gb 7200RPM drive back in and did a fresh install, still can't use the blob
<tseliot> oh
<tseliot> maybe it's a controller thing?
<Sarvatt> HDD pulling too much power and killing the GPU, thats a new one
<tseliot> that would be weird
<tseliot> I was thinking of some messed up BIOS
 * tseliot likes blaming it on the BIOS
<Sarvatt> me too, it almost always is anyway :)
<tseliot> :)
<Sarvatt> 200gb hitachi 7200rpm drive = cant use blob, 250gb WD 5400rpm drive = blob works fine. on more than one OS.. anyway the wife is happy she can play her minecraft again, nouveau 3D wasn't quite fast enough :)
<bjsnider> does the smart data on the larger drive say it's screwed?
<Sarvatt> dunno, can't check now. will check later though
 * bryceh waves
<Sarvatt> morning bryce
<bjsnider> kklimonda, it ooks l ike the nvidia installer hook is a file -- /usr/lib/nvidia/pre-install. it is a one-line shell script. now, if it were moved from nvidia-common to jockey-common it would be more effective.
<Sarvatt> dang, the JumpyCursorThreshold patch for synaptics is awesome now that I have a huge touchpad that constantly freaks out
<Sarvatt> hmm actually, wonder if its even needed now with http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=a6ca4d2523904b7ce49edc29ba408979bdf0d45e
<Sarvatt> ugh, touchpad acceleration is all kinds of screwed up in current synaptics still, JumpyCursorThreshold isn't needed though \o/
<Sarvatt> guess I still need to revert http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=4e0e53fcba6fd99d458df1905d055d63360155c0 , it's unusably jumpy/slow. move the cursor in a straight line in a smooth motion and it accelerates/decelerates constantly
<Sarvatt> maybe the gnome knobs mentioned in http://who-t.blogspot.com/2010/06/new-synaptics-acceleration-mechanism.html would help but the default is still crap here
 * bryceh updates https://wiki.ubuntu.com/Wayland with more faqqage
<bryceh> Sarvatt, I also added your bits to the X Update section at https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-11-23
<bryceh> https://bugs.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/346289/+activity
<bryceh>  ^ this user is irritating me
<bryceh>  I wrote up a lengthy explanation of the bug, and he keeps reverting the description
<ubot4> Launchpad bug 346289 in flashplugin-nonfree (Ubuntu) "MASTER: Choppy Flash playback in full screen (affects: 26) (dups: 3) (heat: 200)" [Undecided,New]
<Sarvatt> yeesh
<Sarvatt> he'll probably edit the duped bug if you make another one the master too
<bryceh> Sarvatt, speaking of bug 346289, I'd appreciate if you took a quick look at my Discussion and Ideas sections there
<ubot4> Launchpad bug 346289 in flashplugin-nonfree (Ubuntu) "MASTER: Choppy Flash playback in full screen (affects: 26) (dups: 3) (heat: 200)" [Undecided,New] https://launchpad.net/bugs/346289
<bryceh> see if I missed anything.
<bryceh> I'm gathering there is nothing we can do, and the two ideas I've had seem a bit kludgy.  But I'd like to hear your take
<bryceh> (and technically, no I don't think this is an X issue)
<Sarvatt> bryceh: unredirect fullscreen windows option in compiz :)
 * Sarvatt slaps natty for making all URL's open in firefox
<RAOF> Unredirect fullscreen windows isn't going to make flash start GPUing, though.
<bryceh> morning RAOF
<RAOF> Morning bryceh :)
<RAOF> Is mesa ready to review? :)
<Sarvatt> what the heck!
<Sarvatt> [    17.845] (II) VESA(0): Not using built-in mode "1856x1392" (no mode of this name)
<Sarvatt> [    17.845] (II) VESA(0): Not using built-in mode "1792x1344" (no mode of this name)
<bryceh> I'd like that chocolateboy to revert me one more time...
<RAOF> Sarvatt: That'sâ¦ interesting.  Is that a crazywierd VBIOS?
<RAOF> It might be fun to apply that âwhere does this mode come from, anywayâ patch and try  again :)
<Sarvatt> yeah this is crazy, http://sarvatt.com/downloads/Xorg-maverick.txt
<bryceh> RAOF, well I fixed the one mesa bug but found another...
<RAOF> You're building from master, right?
<bryceh> RAOF, I'd love it if you want to take a look at it now, I feel like it's 95% there
<bryceh> yeah
<bryceh> well specifically I'm deriving from one of Sarvatt's xorg-edgers builds
<bryceh> maybe in reviewing it you'll spot whatever I did wrong
<bryceh> RAOF, https://launchpad.net/~xorg-edgers/+archive/wayland/
<RAOF> I'm merging 7.9+repack-1 from debian, and doing the gallium/classic selection stuff now, so more mesa is in my headspace :)
<Sarvatt> RAOF: probably need to merge ubuntu-maverick into ubuntu before merging 7.9+repack-1
<RAOF> Sarvatt: Yup.  I noticed that.  Fortunately, merges are commutative :)
<Sarvatt> 5a3ac74 needs to be reverted for mesa 7.10 to compile too in case ya hadn't seen
<Sarvatt> tormod brought it up on mesa-dev but no one responded
<RAOF> There's got to be a better way of doing patches than quilt.
<bryceh> bzr?  ;-)
<RAOF> Quite possibly.
<RAOF> bzr looms would work.
<RAOF> Man.  That patch compiles first time!
<RAOF> I'm on fire!
<RAOF> Hm.  The option should probably be documented, though.
<bjsnider> what's wrong with quilt?
<RAOF> I always forget to âquilt addâ a file before editing it.
<ilmari> hm, no xorg-edgers/drivers-only ppa for maverick?
<Sarvatt> drivers-only doesn't really work these days in the world where every new driver release needs a new libdrm, etc :)
<Sarvatt> tormod updated that and haven't seen him around lately
#ubuntu-x 2010-11-24
<bryceh> perhaps a note in the PPA would be helpful
<ilmari> ah
 * ilmari ponders doing the live usb stick dance to test newer intel drivers
<ilmari> but can't be arsed tonight
<ilmari> maverick has nasty flickering on my laptop monitor on the diagonal stripy background on http://bbc.co.uk/iplayer/
<ilmari> thinkpad x201s, core i7/arrandale
<Sarvatt> ilmari: ppa-purge works great for reverting anything xorg-edgers installs on your system
<ilmari> ooh, neat
 * ilmari gives it a go
<Sarvatt> at least on maverick and earlier, apt stores indices compressed now in natty so ppa-purge doesn't work at the moment
<ilmari> ah, maverick here
<ilmari> huh, why new ia32-libs?
<Sarvatt> because ia32-libs has mesa in it, you'd be using the distro mesa for wine or google earth otherwise
<Sarvatt> leads to a lot of problems when the distro mesa advertises opengl 1.5 and the PPA one does 2.1 and people are confused and such :D
<ilmari> ah
<ilmari> bah, my internet connection seems to be emulating a piece of wet string: 119kB/s, 7min 52s remaining
<ilmari> I usually get ten times that
<ilmari> if anything, the flicker is worse with xorg-edgers
 * ilmari tries upgrading the kernel too
<bryceh> RAOF, had a chance to look through my mesa rules file?
<RAOF> bryceh: Have you pointed me at it yet?
<bryceh> RAOF, yes
<RAOF> Ah.  I have therefore missed it.
<bryceh> RAOF, direct link...  https://launchpad.net/~xorg-edgers/+archive/wayland/+sourcepub/1372289/+listing-archive-extra
<RAOF> Oh, it's in wayland PPA?
<RAOF> Ta.
<bryceh> yeah https://launchpad.net/~xorg-edgers/+archive/wayland/
<bryceh> $ sudo apt-add-repository ppa:xorg-edgers/wayland
<bryceh> $ sudo apt-get update
<bryceh> $ apt-get source mesa
<ilmari> how the heck do you get flickering on an LVDS-connected internal laptop monitor anyway?
<RAOF> By driving it incorrectly?
<bryceh> here's the wayland output from the broken case:  http://pastebin.ubuntu.com/535723/
<bryceh> here it is working, using bits I built manually:  http://pastebin.ubuntu.com/535724/
<bryceh> mostly that's all with the same versions of everything (more or less), the difference is packaging
<ilmari> RAOF: I guess. it didn't do it on lucid
<ilmari> http://static.bbc.co.uk/iplayer/3.11.0/img/module_cf_background.png # horrible flicker
<bryceh> I see in the working case it's using lib/dri/i965_dri.so, whereas in the broken case it seems to be using lib/egl/egl_gallium.so
<RAOF> Ah, good old 8086:2a42
<RAOF> Yeah.  It shouldn't be using that at all.  Well, not unless you want your GPU to lock up :)
<RAOF> It occurs to could use he daily-builds infrastructure for thisâ¦
<RAOF> After we get it to work once, of course :)
<bryceh> borked grammar be is?
<RAOF> HAH!
<bryceh> but yes indeedy
<bryceh> well, actually what I'd like to do is get the deps into universe (libxkbcommon uploaded today, awaiting review)
<bryceh> and I'd like to see if we could merge the mesa changes into xorg-edgers
<bryceh> if that's all done, then yeah wayland git snapshots could just be one more bit in xorg-edgers ppa
<RAOF> And even the archive mesa, once we flip to 7.10
<bryceh> yep
<bryceh> if I can get wayland into universe for natty I think it'd be awesa mesa
<RAOF> Hm.  We probably want egl-platforms="drm x11", don't we?  For the benefit of running wayland under X?
<bryceh> export EGL_PLATFORM=drm x11   seems to make no difference
<bryceh> here's the configure string I'm using to build it manually:
<bryceh> ./autogen.sh --prefix=$HOME/install  --enable-egl --enable-gles2  --disable-gallium --with-egl-platforms="drm"
<bryceh> make
<RAOF> And you still get a egl_gallium.so in $(HOME)/install/lib/egl?
<bryceh> $ ls /home/bryce/install/lib/egl/
<bryceh> egl_dri2.so*  egl_gallium.so*  egl_glx.so*  pipe_nouveau.so*  pipe_r300.so*  pipe_swrast.so*  st_GL.so*
<bryceh> $ ls /usr/lib/egl/
<bryceh> egl_dri2.so     egl_glx.so       pipe_r300.so  pipe_swrast.so  st_GLESv2.so
<bryceh> egl_gallium.so  pipe_nouveau.so  pipe_r600.so  pipe_vmwgfx.so  st_GL.so
<RAOF> That seems moderately odd, given --disable-gallium
<bryceh> interesting
<bryceh> root@lynmouth:/usr/lib# mv egl egl-orig
<bryceh> root@lynmouth:/usr/lib# cp -r /home/bryce/install/lib/egl .
<bryceh> after that, it worked
<RAOF> Does running âEGL_DRIVER=egl_dri2 wstartâ work?
<bryceh> nope, same output
<RAOF> And if you just plain delete /usr/lib/egl_gallium.so?
<bryceh> ditto, tried it several times in various ways
<bryceh> I deleted all the files not present in the hand-built egl too
<bryceh> if I only copy the egl_gallium.so and egl_dri2.so from the handbuilt stuff, it works
<bryceh> ok it's definitely egl_dri2.so
<bryceh> either of the egl_gallium.so's will work
<bryceh> -rwxr-xr-x 1 root root 79022 2010-11-23 17:14 egl-new/egl_dri2.so*
<bryceh> -rw-r--r-- 1 root root 22444 2010-11-22 19:22 egl-orig/egl_dri2.so
<RAOF> Oooh.
<bryceh> the broken one is much smaller
<RAOF> What if you disable tls?
<bryceh> can that be done via env var?
<RAOF> No, it's a build-time option.
<bryceh> hrm
<bryceh> ok let me try
<RAOF> It seems to be the only interesting #ifdef in egl_dri2
<bryceh> --disable-glx-tls ?
<RAOF> Or --enable-glx-tls on your home build.
<bryceh> what is tls?
<RAOF> thread-local-storage.
<bryceh> oh that might be easier
<bryceh> http://pastebin.ubuntu.com/535736/ - local build configuration
<RAOF> I guess the other possibly interesting #ifdef is libudev; do you have the udev devel libs locally?
<RAOF> Yes is the answer; I can read that from configure :)
<bryceh> hmm, local build still worked with --enable-glx-tl
<bryceh> +s
<RAOF> Aaaah.
<bryceh> was that a scream of frustration or a sign of discovery?
<RAOF> A suggestion of discovery.
<RAOF> libudev isn't available on the buildds, and that's the other interesting #ifdef in egl_dri2
<RAOF> Moving /usr/lib/pkgconfig/libudev.pc somewhere pkg-config can't find it should make your local build not use libudev, which'd be an easier test.
<RAOF> (after you ./configure, of course)
<bryceh> weird, my local debuild of mesa with --disable-glx-tls failed
<bryceh> http://pastebin.ubuntu.com/535738/
<bryceh> nope, still works with libudev.pc moved aside and mesa rebuilt/reinstalled
<bryceh> RAOF, I didn't do a make clean first though... think it matters?
<bryceh> I'll try that just in case
<RAOF> It might.  mesa's build system is moderately stupid, that awy.
<bryceh> oh whoops also found another flaw
<RAOF> Your working local copy is definitely following a codepath that's #ifdef HAVE_LIBUDEV
<bryceh> ok so wasn't a flaw after all
<RAOF> Actually, it looks like egl_dri2 with egl-platform=drm should be dependent on libudev, as it doesn't look like there's any chance of it working otherwise.
<bryceh> RAOF, libxkbcommon pulls libudev-dev as a build dependency
<bryceh> but libxkbcommon-dev doesn't list it as a depends
<bryceh> "udev" isn't in mesa's debian/control
<bryceh> <god I hate mesa>
<RAOF> And the build logs in the PPA show LIBUDEV=/... no
<RAOF> It's probably correct for libxkbcommon-dev to not pull in libudev-dev.  There should just be a bit of a configure patch for mesa to mention that libudev is a requirement for egl_dri2 to work properly :)
<bryceh> so should I pop that into control ?
<bryceh> OOH!
<bryceh> after make clean and make of local mesa, it fails the same way
<bryceh> btw, strace logs:
<bryceh> http://www2.bryceharrington.org:8080/files/broken.log
<bryceh> http://www2.bryceharrington.org:8080/files/working.log
<RAOF> Yeah.  I'll do the same for the archive mesa.  After lunch!
<bryceh> indeed, dinner time here
 * bryceh kicks off mesa build in wayland ppa
<bryceh> crossing fingers, and now fingering croissants...
<micahg> hi, is there anyway we can get the apport-gpu-error-intel script not to fire over 100 times when there's an issue?
<bryceh> micahg, dunno but I'd love it if we could
<bryceh> micahg, maybe talk with pitti about it
<micahg> bryceh: ok, it's an apport issue then?
<bryceh> it's a combination apport and kernel thing
<bryceh> kernel fires, apport reacts
<micahg> and that's triggering the script in the driver package?
<bryceh> yes
<micahg> bryceh: great, thanks
<bryceh> yep
<RAOF> âIt'd be easy to make that fire once per bootâ :)
<micahg> I get it on resume from suspend a lot
<micahg> then pidgin goes bonkers, I thought that was a kernel bug that was fixed in 2.6.35, but apparently it wasn't /end OT rant
<RAOF> Oh, boo.  I forgot my Cedar isn't supported for accel in the natty packages yet.
<RAOF> Time to fire up the r700 and upgrade to natty...
<bryceh> ok... new mesa built... installing...
<RAOF> *blink*
<bryceh> YAY!
<bryceh> waylandage
<RAOF> Why does konsole have a âZModem uploadâ button in the âEditâ menuâ½
<RAOF> bryceh: Yay!
<bryceh> ZModem!
<RAOF> I know!
<RAOF> I used that, like 15 years ago!
<bryceh> boy I loved that... 15 years ago
<bryceh> heh
<bryceh> RAOF, thanks again for your help
<RAOF> I've made that change in the 7.9 merge, too.
<bryceh> kewl
<RAOF> And just as soon as this r700 is updated to natty & I can test it, I'll trawl for sponsorship :)
<bryceh> last thing I need to do is fix up the client apps.  by default they have a hardcoded lib path which doesn't work when they're copied to /usr/bin
<bryceh> RAOF, thought you were core dev now?
<RAOF> Why did you think that?
<bryceh> RAOF, because I saw you on the patch pilots schedule
<bryceh> coming up soon, too iirc
 * RAOF needs to check that schedule again.  He wasn't on there last time he checked!
<RAOF> You don't have to be core-dev to be on the schedule.
<bryceh> is the requirement motu or better?
<RAOF> I think the requirement is actually âCanonical employeeâ
<RAOF> ...on the platform team.
<bryceh> I noticed Jono Bacon wasn't on it
<bryceh> and I pointed this out to him.  ;-)  http://www.jonobacon.org/2010/11/20/new-ubuntu-patch-pilot-scheme/
<bryceh> anyway, yeah I understood it was also 'all platform team employees', but it seems like we're missing people from it
<bryceh> RAOF, oh wow, you're on day after tomorrow for US Thanksgiving
<bryceh> probably will have a nice quiet time
<bryceh> if you get bored you could sneak a few X patches into the sponsor queue - http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/patches.html  ;-)
<RAOF> I actually count that as tomorrow.
<RAOF> I might just do that :)
<bryceh> I've been trying to clear a patch or two a day since I got back.  The list is a lot shorter than it used to be
<bryceh> the remaining xorg-server ones may be a bit tricky
<bryceh> anyway, I'm beat.  night, tty tomorrow
<RAOF> Sleep well!
<RAOF> Hm.  Anyone here have an r300-r500 system?
<RAOF> And are running Natty, and would like to guiniepig a new mesa switching to gallium?
<RAOF> Ok.  10:30 is too late.  Sponsor hunting begins tomorrow.
<tseliot> Sarvatt: in order to use r600g from edgers, all I have to do is move r600_dri.so to /usr/lib/dri, right? (just to double-check)
<Sarvatt> yep thats one way to do it
<Sarvatt> launching your app with LIBGL_DRIVERS_PATH="/usr/lib/dri/gallium" is another way
<ricotz> Sarvatt, hi
<tseliot> Sarvatt: ok. I think I've found my 1st bug in gallium then
<tseliot> r600g, that is
<ricotz> Sarvatt, do you know about this edid bug with 2.6.37?
<Sarvatt> heyo ricotz, still having problems with i915? was meaning to say I think it might have just been the 2.6.37-6 kernel that was busted at the time
<Sarvatt> ricotz: hmm I know of a edid problem with displayport monitors on radeon in -rc3 but not intel
<Sarvatt> err -rc2
<ricotz> yeah, my old nvidia card is broken, i needed to get it to work on this onboard intel, but i had no luck
<ricotz> now i am on a gf104 with nvidia blob
<ricotz> which has some weird edid problems
<ricotz> using dvi connection
<tseliot> what kind of edid problems?
<ricotz> it doesnt get any display information
<tseliot> is this on a sony vaio?
<ricotz> getting kind of the same with nvidia blob and nouveau
<ricotz> tseliot, no it isnt a laptop
<tseliot> ok, it must be a new issue
<tseliot> new to me, at least
<ricotz> seems to be kernel problem
<ricotz> could be a problem of the nvc0 stuff
<tseliot> ricotz: did you file a bug report about it?
<tseliot> if not, please do so and I'll ask Nvidia about it
<Sarvatt> ricotz: gf104 support is even in the kernel now? I didn't know
 * Sarvatt is on a gf106 atm
<ricotz> tseliot, no havent reported anything yet
<Sarvatt> last time I booted without the blob in early .37 nouveau didnt work still
<ricotz> just wanted it working since i need this pc ;-)
<tseliot> I can understand ;)
<ricotz> Sarvatt, nouveau seems to work with nomodeset
<Sarvatt> meaning nouveau doesnt work :)
<Sarvatt> (nouveau doesn't work without KMS)
<ricotz> Sarvatt, on a normal boot nouveau get stuck in some loop with some edid error
<Sarvatt> I dont need nomodeset on this thing though, it just spits out an unsupported chipset warning and stops loading nouveau
<bjsnider>  tseliot, i think i found the nvidia installer hook. see if this sounds familiar: if the file /usr/lib/nvidia/pre-install exists, the nvidia-installer executes it, which is just an exit command?
<Sarvatt> digging now, i've seen quite a few bugs about edid problems on -37 maybe something will pop up
<tseliot> bjsnider: yes, that's how it works
<bjsnider> so then let's put that file in jockey-common instead of nvidia-common
<Sarvatt> https://bugzilla.kernel.org/show_bug.cgi?id=23482 was one of them but just radeon displayport
<ubot4`> Sarvatt: Error: Could not parse XML returned by bugzilla.kernel.org: The read operation timed out (https://bugzilla.kernel.org/xml.cgi?id=23482)
<ricotz> http://lkml.org/lkml/2010/11/17/169
<tseliot> bjsnider: yes, I should talk to pitti about that
<tseliot> Sarvatt: I'd like to add a udev rule and a configuration file (in /usr/share/X11/xorg.conf.d) so as to enable scrolling with the middle button + the trackpoint on thinkpad x201 models. This is the default behaviour in Windows and it helps a lot since the laptop doesn't have a touchpad
<tseliot> Sarvatt: I think I should add this to evdev. I'll file a bug report about it so that we can discuss it
<Sarvatt> yeah sounds good to me, I've seen that bug
<tseliot> Sarvatt: ah, is there one open already?
<Sarvatt> yeah let me dig it p
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/554984
<ubot4`> Launchpad bug 554984 in xserver-xorg-input-evdev (Ubuntu) "[lucid] enable trackpoint scroll emulation by default (affects: 8) (dups: 2) (heat: 42)" [Wishlist,In progress]
<tseliot> Sarvatt: right. I guess we should apply this only to some models, i.e. when a touchpad is not available
 * tseliot doesn't want too many angry thinkpad users to complain in the bug report
<Sarvatt> x201 wouldn't make sense then would it? x201 has a touchpad, x200 doesn't
<tseliot> just a few would be acceptable ;)
<tseliot> my x201 doesn't have a touchpad
<Sarvatt> oh must be able to configure it out, weird
<tseliot> I can make sure that wheel emulation is applied only to the model that I have
<Sarvatt> x200, x200s, x61, x61s would be good to add to that since you couldn't even get a touchpad on those
<Sarvatt> hmm Touchpad Assembly for IBM ThinkPad X61s
<Sarvatt> maybe I have bad info :)
<tseliot> my x201 is pretty new, so maybe things changed a bit
<tseliot> aah, it seems that the touchpad is available only in certain configurations
<Sarvatt> I remember one of the big things in all the reviews when x201 came out a year ago was that it brought back the touchpad, looking at lenovo.com it looks like just trackpoint is the default and trackpoint+touchpad is $20 extra
<tseliot> http://shop.lenovo.com/SEUILibrary/controller/e/web/LenovoPortal/en_US/catalog.workflow:category.details?current-catalog-id=12F0696583E04D86B9B79B0FEC01C087&current-category-id=4F2AFFFF52964FE2BCF0CC608A649A77&action=init
<tseliot> when I bought it, it didn't allow my to select a touchpad
<Sarvatt> dang $899 now, thats tempting
<tseliot> if you get the model with the touchpad you don't get access to the icore 7 cpu
<tseliot> ah, you can choose now
<tseliot> hmm
<bryceh> heya tseliot!
<Sarvatt> wish they would sell x201s again
<tseliot> hey bryceh
<tseliot> what's the difference?
<Sarvatt> 1440x900 screen, lighter
<tseliot> oh
<tseliot> mine is quite light but the 9 cell battery is heavier than the rest of the laptop
<ilmari> more robust as well, I think ("enhanced roll cage")
<ilmari> no 3g though :(
<ilmari> I love my x201s, especially with an intel SSD :)
<Sarvatt> oh it use low voltage cpu's too instead of the normal laptop ones
<Sarvatt> so half speed GPU in linux most of the time :)
<tseliot> yes, intel SSDs are great
<tseliot> I love my 160gb SSD
<Sarvatt> x201s was like twice the price the x201's are now when they sold them though
<tseliot> ilmari, Sarvatt: do you happen to have a thinkpad x201 around?
<tseliot> I'd like to see the output of "dmidecode"
<ilmari> tseliot: I have an x201s
<tseliot> ilmari: that would be fine too
<tseliot> I'd like to see what it says
<Sarvatt> tseliot: nope, I bought a desktop replacement instead at plumbers, was going to get an x201 or a sony Z but decided on this asus G73JW instead since the Z was so flimsy
<tseliot> so that I don't enable wheel emulation by mistake on that model
<Sarvatt> would wheel emulation be bad to enable globally for trackpoints?
<tseliot> good question. I guess not
<tseliot> tjaalton: ^^
 * tseliot knows that tjaalton used to have a thinkpad
<Sarvatt> tseliot: you know you can install gpointing-device-settings to enable it in the gui right?
<tseliot> Sarvatt: is it the tool that used to work with shared memory instead of xinput?
<ilmari> tseliot: http://paste.scsys.co.uk/57082
<ilmari> serial numbers and uuids redacted
<tseliot> ilmari: thanks
<Sarvatt> tseliot: nope it's the newer relacement for gsynaptics
<ilmari> should I be worried that it says Type: <OUT OF SPEC> for the memory modules?
<tseliot> Sarvatt: aah, gsynaptics is the one that's deprecated. I'll have a look at the new tool then
<Sarvatt> gsnaptics was that old SHMConfig one
<tseliot> right
<tseliot> I'm wondering how the new tool saves settings
<Sarvatt> xinput properties and gnome-settings-daemon plugin
<tseliot> nice. Finally someone developed what I never had the time to complete :)
<tseliot> one less item on my endless todo list
<tseliot> ilmari: do you know if wheel emulation is enabled by default in Windows on your laptop
<tseliot> well, I guess Lenovo enables that
<ilmari> what is this windows of which you speak?
<Sarvatt> i'd be a fan of installing that trackpoint xorg.conf.d snippet with evdev personally but I'm partial to things that makes the experience not suck out of the box :)
 * ilmari never booted the pre-loaded windows
<Sarvatt> (for all trackpoints)
<ilmari> the first thing I did when I got it was to replace the drive with an intel ssd and boot the lucid installer from usb
<ilmari> the original drive is still sitting on my desk at work
<Sarvatt> ilmari: oh that's the machine you had flickering problems with on lucid?
<ilmari> Sarvatt: no, I have flickering problems on maverick (and edgers), but not on lucid
<Sarvatt> use the maverick kernel, I would have recommended that from the start if I knew :)
<Sarvatt> ahhh
<tseliot> Sarvatt: +1000 :)
<ilmari> let med find a usb stick to build a lucid live thingy to re-test with
<Sarvatt> ilmari: so thats one of the ones bitten by 2.6.35-rc7..
<Sarvatt> ilmari: thats ok we probably backported just enough eDP stuff so it doesn't suck and not the breakage, it'll probably break again in lucid-updates at some point :(
<Sarvatt> ilmari: 10 bucks says this doesnt flicker on maverick http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.35-rc6-maverick/
<Sarvatt> (fictional internet money of course)
 * ilmari installs
<tjaalton> tseliot: yeah i have an x61
<tjaalton> wheel emulation is great
<Sarvatt> tseliot: btw, JumpyCursorThreshold rocks! and looks like it's not needed with synaptics 2.3.0 anymore from my testing, but 2.3.0 has this really nasty acceleration stuff added that is completely screwed up here on every touchpad I've got
<tseliot> tjaalton: do you remember if it's on in Windows by default on most thinkpads?
<tjaalton> but it wasn't enabled on my friends' win7 t401 when I used it briefly yesterday
<tjaalton> though maybe he turned it off. I'll ask
<tseliot> Sarvatt: it's a hack that I had to write when I was hired. I'm glad to read that 2.3.0 gets things right. I'd like to try it with a with a Dell mini 10v
<tseliot> tjaalton: it would be nice to know. Thanks
<Sarvatt> pretty sure http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=a6ca4d2523904b7ce49edc29ba408979bdf0d45e is what fixed it in 2.3.0 on my asus
 * tseliot felt a bit lost after learning wheel emulation in Win 7 (my 1st time with both the pointer and Win 7) and not finding any in Ubuntu
<tseliot> Sarvatt: aah, maybe your touchpad supports multiple fingers
<tseliot> the one on the mini 10v doesn't :(
<Sarvatt> with MatchProduct	"TPPS/2 IBM TrackPoint|DualPoint Stick|Synaptics Inc. Composite TouchPad / TrackPoint|ThinkPad USB Keyboard with TrackPoint|USB Trackpoint pointing device|Composite TouchPad / TrackPoint" it works great on my dell e64x0 trackpoint too :)
<ilmari> Sarvatt: no luck :(
<ilmari> Sarvatt: with stock maverick xorg
<tseliot> oh, so some dell laptops have trackpoints too
<Sarvatt> ilmari: darn, that one didn't have flickering problems on the HP and sony LM eDP machines
<ilmari> Sarvatt: does that have anything the xorg-edgers kernel doesn't?
<ilmari> I tried taking the full xorg-edgers hit yesterday, didn't help at all
<Sarvatt> ilmari: nope, more specifically it doesn't have what the newer kernels have that regressed it on some machines and fixed it on others :)
<ilmari> ah, it's an _older_ kernel than the maverick one?
<Sarvatt> yeah
<Sarvatt> will let ya know if i find anything, digging around for the x201s flickering bugs now
<ilmari> cheers
<ilmari> it and the disappearance of ctrl-pgdn in aptitude are my only annoyances with maverick so far
<Sarvatt> ilmari: booting with i915.powersave=0 might be worth a try, thats a longshot though
<Sarvatt> i think self refresh is enabled unconditionally now regardless of that setting anyway, pretty sure its a problem there
<Sarvatt> ilmari: http://bugs.freedesktop.org/show_bug.cgi?id=27589 ahh I thought I forwarded a similar bug about that at some point
<ubot4`> Freedesktop bug 27589 in DRM/Intel "[GM45] Occasional flickering unless powersave=0 is used on lenovo laptops." [Normal,Reopened]
<Sarvatt> it got a lot of me-toos including people with arrandale, the gm45 people had it fixed by powersave=0, it was FBC related and it was limited to part of the screen
<Sarvatt> x201s flickering probably isn't related
<Sarvatt> ilmari: hmm, do you have an enable/disable rc6 option in your bios?
<ilmari> this only happens where and when a stripy pattern is displayed
<ilmari> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/680748
<ubot4`> Launchpad bug 680748 in xserver-xorg-video-intel (Ubuntu) "[arrandale] flicker on LVDS laptop display with stripy patterns (affects: 1) (heat: 6)" [Undecided,New]
<Sarvatt> LVDS?!
<ilmari> LVDS1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 261mm x 163mm
<ilmari>    1440x900       50.0*+
<Sarvatt> sorry for wasting your time with the 2.6.35-rc6 kernel then :(
<ilmari> 00:58 < ilmari> how the heck do you get flickering on an LVDS-connected internal laptop monitor anyway?
<ilmari> 00:59 < RAOF> By driving it incorrectly?
<ilmari> (times in GMT)
<ilmari> Sarvatt: no problem. any ideas how I can go about troubleshooting it?
<ilmari> bisect time?
<Sarvatt> ilmari: save the intel_reg_dumper output, find a kernel where it doesn't flicker (can just use the mainline kernels or a lucid livecd) then save that intel_reg_dumper output and attach it to the bug, i'll forward it upstream for ya
<Sarvatt> forwarding it now
<Sarvatt> I'm stumped, hopefully they have ideas. all the intel guys have x201s machines I believe :)
<ilmari> hm, I wonder if it can boot from the sd card?
<ilmari> s/\?$//
<Sarvatt> ilmari: https://bugs.freedesktop.org/show_bug.cgi?id=31901
<ubot4`> Freedesktop bug 31901 in Driver/intel "[arrandale] flicker on x201s LVDS laptop display with stripy patterns" [Normal,New]
<Sarvatt> depends on the laptop, I dont have any that can boot off SD
<Sarvatt> if it's hooked up internally via USB you probably can, like some eee pc's and dells
<Sarvatt> ilmari: can you add your email to the cc list on that bug?
<ilmari> will do
<ilmari> as soon as I get my password reset email
<ilmari> ETOOMANYBUGTRACKERS
<Sarvatt> I can add ya, just wasn't sure which email address you'd prefer
<Sarvatt> ilmari dot org?
<ilmari> yeah
<ilmari> thanks
<tjaalton> tseliot: windows has wheel emulation by default, if the proper driver is installed
<Sarvatt> yay, no more mesa implementation error: bad renderbuffer format spam http://cgit.freedesktop.org/mesa/mesa/commit/?id=78a340fd487c56468ace7347a53f95a0c751c419
<tseliot> tjaalton: ok, thanks
<bryceh> Sarvatt, a few days ago you mentioned:
<bryceh> <Sarvatt_> bryceh: already fix up cairo locally or want me to upload it?
<bryceh> <Sarvatt_> (optional)__gnu_lto_v1@Base 1.10.0
<bryceh> what was that change for?  Should it go into the wayland cairo build?
<bryceh> Sarvatt, oh, that was for the natty build of cairo-gl, gotcha
<Sarvatt> new symbol picked up in natty because of -flto, i already uploaded that to the ppa and its in the archive cairo?
<Sarvatt> wouldn't hurt to have that in the maverick one since its optional
<bryceh> alright, I can add it
<Sarvatt> oh wow, no more edge on launchpad
<bryceh> yep
<Sarvatt> hope that doesn't mean links with edge stop working one day :)
<Sarvatt> dont even want to think about how many wiki's i've put edge on
<bryceh> I'm sure they've got permanent redirects in place
<seb128> bryceh, the lto thing is in natty proper
<seb128> it's a new symbol which get defined when lto support is available in the build chain
<seb128> nothing to do with gl or wayland
<bryceh> ok
<ilmari> Sarvatt: reg dump attached (no flicker on 10.04.1)
<ilmari> (to the fdo bug, not launchpad)
<Sarvatt> gotta love intel docs, the differing bits i've checked so far are all just marked "reserved" :)
<JanC> "reserved" is just code language for "nobody knows anymore"  ;)
<RAOF> At least none of them are marked âChickenâ
<RAOF> :)
<Sarvatt> darn there really is no point to shipping vmwgfx in edgers anymore, I thought the tools would build vmwgfx since that vmware guy requested we stop building it with the kernel but nope
<Sarvatt> RAOF: ya doing crap with mesa? did you reenable nouveau-vieux by any chance? :)
<RAOF> Hm, I did not.
<RAOF> Thanks for pinging me; I was about to search for sponsors.
<bryceh> heh @ http://lwn.net/Articles/416982/
<RAOF> We might as well load it into dri-experimental again :)
<Sarvatt> they were debating calling it stable on the wiki but stopped when it came to the fact people might actually submit bugs :)
<Sarvatt> shoving it in dri has my vote, it's a lot better off than say, savage
<RAOF> Ok.
<Sarvatt> part of that is just me being curious if we actually get any bugs about it and it's early enough to disable though :)
 * Sarvatt digs up an old geforce mx to dog food it
<Sarvatt> wow I somehow have 3 different ones that I didnt know about
<Sarvatt> and a voodoo4
 * Sarvatt wonders if he went to salvation army drunk or something
<RAOF> Oh, while I'm in mesa - do we want to turn on llvm?
<RAOF> Ogre model says: not without a MIR.
<ScottK> Because mesa isn't painful enough already?
<Sarvatt> i'd be interested in benchmarks for an r300-500 IGP with and without llvm enabled
<RAOF> Well, I understand it provides quite a big performance boost for cards without T&L hardware
<Sarvatt> rv515/rv530's are so darn common
<RAOF> Does anyone here *have* a card without T&L?
<Sarvatt> vish
<RAOF> Intel doesn't count, does it?  They're not hooked up to the same infrastructure?
<Sarvatt> ok, enough screwing with vmware because it's killing my net.. was trying to get 3D passthrough in the VM working to test the unity stuff in a VM but we dont have the kernel module
#ubuntu-x 2010-11-25
<bryceh> # Classic DRI and Gallium DRI are mixed up together here
<bryceh> # Remove the whole tree to avoid false-positives in --list-missing, and
<bryceh> # install the right files manually.
<bryceh> rm -r debian/tmp/dri/usr/lib/dri
<bryceh> dh_install -s --list-missing
<bryceh> cp: cannot stat `debian/tmp/dri/usr/lib/egl/st_GLESv1_CM.so': No such file or directory
<bryceh> dh_install: cp -a debian/tmp/dri/usr/lib/egl/st_GLESv1_CM.so debian/libgles1-mesa/usr/lib/egl/ returned exit code 1
<bryceh> make: *** [binary-arch] Error 2
<bryceh> that's after disabling gles overlay and openvg, which krh recommended for mesa to be compatible with wayland
<bryceh> RAOF_, would it be wrong of me to drop GLESv1* from mesa's .install's?
<bryceh> ( http://launchpadlibrarian.net/59576070/buildlog_ubuntu-maverick-i386.mesa_7.10.0%2Bgit20101118.3dcc3153-0ubuntu1~bryce6_FAILEDTOBUILD.txt.gz )
<bryceh> I'm going to comment out  dri/usr/lib/egl/st_GLESv1_CM.so usr/lib/egl  in  libgles1-mesa.install
<bryceh> RAOF_, btw, I found that even though the wayland server started working after our changes last night, the clients now fail to launch
<bryceh>  
<bryceh> errors look like:
<bryceh> Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable
<bryceh> Internal error:   Could not resolve keysym SunProps
<bryceh> Internal error:   Could not resolve keysym SunFront
<bryceh> Internal error:   Could not resolve keysym SunOpen
<bryceh> failed to create cairo drm surface
<bryceh> libEGL debug: Display 0x87f89f8 is destroyed with resources
<bryceh> disconnect from client 0x993db08
<bryceh>  
<bryceh> I'm wondering about the libtxc_dxtn.so bit - that looks odd
<bryceh> however it's the keysym errors that directly precede the termination so I wonder if something's wrong on the input side of things
<bryceh> RAOF_, can you confirm that we definitely do want --enable-glx-tls ?
<bryceh> It looks like we have that on in xorg-server so presumably we want it in mesa too
<RAOF_> I think we do want --enable-glx-tls, yes.
<Sarvatt> ...this is just going in the PPA right? you're building cairo-drm? yeah we want --enable-glx-tls, no disabling gles and openvg isn't an option in the archive
<RAOF_> Because ARM at least wants GL|ES & OpenVG, and we probably don't want to drop those libraries anyway.
<bryceh> Sarvatt, yeah just the PPA for now
<bryceh> I'm not building cairo-drm, that's not needed anymore afaik
<bryceh> instead doing cairo-gl
<bryceh> hm ok
<bryceh> wonder why krh suggested disabling them?
<RAOF> I don't know.  Except that it'll probably take less build time.
<RAOF> I don't see why they would interfere with EGL/GL.
<bryceh> <bryceh> krh, will --enable-openvg cause troubles if it is on?
<bryceh> <krh> bryceh: it wont wroth with --disable-gallium-egl
<bryceh> <krh> s/wroth/work
<bryceh> <bnf> there is --enable-openvg
<bryceh> <Darxus> Hehe.
<bryceh> <krh> yeah, but I'm pretty sure that require gallium egl
<Sarvatt> because he's only made things work on intel with what fedora uses and it gets complicated once you start enabling gallium stuff? :)
<RAOF> Right.  But didn't our little expedition into the wonderful world of libudev fix the egl_dri2 problem anyway?
<bryceh> RAOF, yes-ish
<bryceh> it fixed it for the server, which now launches properly
<bryceh> but the clients don't work
<Sarvatt> we have things build-depping on our mesa gles/vg dev packages, I think most of it is arm/linaro specific though outside of mesa-utils
<bryceh> bryce@lynmouth:~/src/Wayland/wayland$ wsmoke 
<bryceh> libEGL warning: failed to create DRM screen
<bryceh> Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable
<bryceh> Internal error:   Could not resolve keysym SunProps
<bryceh> Internal error:   Could not resolve keysym SunFront
<bryceh> Internal error:   Could not resolve keysym SunOpen
<bryceh> so I'm poking around for what else needs fixed
<Sarvatt> attach gdb and get a backtrace?
<RAOF> Does it work if you run as root?
<Sarvatt> might just be harmless error spam and its stuck doing something else
<RAOF> It could be a simple failure to authenticate the DRM connection.
<bryceh> RAOF, nope
<RAOF> Sarvatt: I wouldn't think so: âlibEGL warning: failed to create DRM screenâ looks likely to be fatal :)
<Sarvatt> yeah somehow parsed that out and meant the keysym errors :)
<bryceh> gdb doesn't help as it's not segfaulting
<RAOF> Strace might?
<bryceh> strace:  http://pastebin.com/f4qA4nKg
<RAOF> And can EGL be a little more verbose? :)
<bryceh> yes
<Sarvatt> if you attach it should stop the execution until you cont, you can just bt full after attaching?
<bryceh> wait no that's all EGL gives
<Sarvatt> yeah theres tons of egl debug env vars
<bryceh> here's the full run log, showing both server output and client:  http://pastebin.ubuntu.com/536116/
<Sarvatt> EGL_LOG_LEVEL=debug
<bryceh> this is with:
<bryceh> export MESA_DEBUG=1
<bryceh> export EGL_LOG_LEVEL=debug eglinfo
<Sarvatt> bryceh: do you have X open?
<Sarvatt> did you sudo service gdm stop first I mean?
<RAOF> Hm.  Looks like it's correctly opening egl_dri2, which is correctly opening i965_dri
<bryceh> Sarvatt, I have X open
<bryceh> I might have stopped gdm and restarted once since last reboot, I don't remember
<Sarvatt> almost positive you can't have X running when you start it?
<bryceh> untrue; I've had that working fine
<bryceh> in fact I've not yet gotten it running outside X
<bryceh> although I've not yet tried very hard
 * bryceh tries
<bryceh> whoa that's weird
<bryceh> screen went tie-died and then wiped to black
<RAOF> I suspect the cairo-drm message is the problem
<bryceh> libEGL debug: the best driver is DRI2 (score 100)
<bryceh> Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable
<bryceh> failed to add socket: Address already in use
<bryceh> libEGL debug: Display 0x88999c8 is destroyed with resources
<bryceh> same thing whether running as user or root
<RAOF> Failed to add socket?
<Sarvatt> are you in the video group?
<bryceh> video:x:44:bryce
<bryceh> RAOF, yeah haven't seen that error before
<Sarvatt> you got that error in a paste earlier
<Sarvatt> http://pastebin.ubuntu.com/536116/
<RAOF> So, I don't particularly think this is a mesa problem; it's loading egl_dri2 properly which is then loading the correct dri driver.
<bryceh> oh wait, socket error just meant I had a stray wayland server process
<RAOF> And it doesn't work, even without a stray wayland? :)
<Sarvatt> tried EGL_PLATFORM=drm EGL_DRIVER=egl_dri2 ./wstart with no X running?
<Sarvatt> well your strace says libEGL warning: failed to create DRM screen is from /usr/lib/egl/pipe_i915.so not existing
<RAOF> Sarvatt: Yeah, but if you read the strace it then goes on to load egl_dri2 and i965_dri.
<bryceh> ok, without a stray wayland it does launch the server, but still no clients
<bryceh> actually fairly cool, I can set a background and get a movable mouse cursor
<bryceh> Sarvatt, yeah those env vars don't seem to make a difference
<bryceh> what generates pipe_i915?
<Sarvatt> are your binaries setuid?
<Sarvatt> i915g
<bryceh> it sounded like from krh that the pipe stuff is used only in certain situations unrelated to this
<bryceh> I haven't fiddled with that at all, should I?
<Sarvatt> yeah just saying you can ignore that warning it looks like
<RAOF> Yeah.  The pipe_* drivers are the gallium hardware drivers; they'd be used if egl_gallium was happening.
<bryceh> RAOF, where did you see the cairo-drm bit?
<bryceh> afaik that shouldn't make an appearance anywhere
<RAOF> write(2, "failed to create cairo drm surfa"..., 35failed to create cairo drm surface
<Sarvatt> <bryceh> failed to create cairo drm surface
<bryceh> oh right
<RAOF> You could play with i915g; I understand that it's not entirely broken, like i965g is :)
<bryceh> that's an error message from the client that it gets after trying to create a surface using cairo
<bryceh> hrm
<bryceh> ok if you guys are out of clue on this too, I'll just shelve it until next week
<bryceh> happy to try more idea though if you got 'em
<RAOF> I think the interesting question is why cairo's failing to create a drm surface.
<Sarvatt> yeah looks like the problems in the way cairo is built to me even though cairo-drm isn't enabled
<bryceh> hm ok
<bryceh> alright, lastly, gonna try newer wayland in case recent git changes fixed something
<bryceh> WHOA
<bryceh> that did it
<bryceh> sweetness
<RAOF> Heh
<bryceh> shoulda tried that earlier!
<Sarvatt> http://cgit.freedesktop.org/wayland/commit/?id=32ff69017ab003911b754982772d0644b1cd23d4
<RAOF> So that sounds like we can use the archive mesa configuration and still have everything work.
<Sarvatt> hah was my  next idea
<Sarvatt> (are you *sure* the udev rules are getting used?)
<bryceh> for the record I still see these warnings when firing up the clients:  http://pastebin.ubuntu.com/536127/
<bryceh> Sarvatt, I express certainty on nothing
<bryceh> oh
<bryceh> on that, I had been forcing install of the udev rules in debian/rules anyway
<bryceh> I can probably clean some of that up now
<RAOF> Yeah; the dxtn library warning is totally harmless.  I guess unless a wayland client wants to upload DXT-compressed textures :)
<bryceh> would be nice to suppress that
<bryceh> I've a pet peeve about harmless-but-technobabbly warnings
<Sarvatt> you could install it :)
<bryceh> actually not sure that I can
<RAOF> You know what would be a good fix?  Show that warning when something tries to fiddle with a DXT texture!
<Sarvatt> yeah you can I just did on a new install a few days ago
<bryceh> bryce@blumonc:~/src/Wayland/wayland/wayland-0.1~git20101124.32ff6901/debian$ apt-cache search dxtn
<bryceh> bryce@blumonc:~/src/Wayland/wayland/wayland-0.1~git20101124.32ff6901/debian$ 
<bryceh> is it a natty package?
<Sarvatt> its patent encumbered, have to do it manually
<bryceh> oh, well I don't count that ;-)
<bryceh> well, I'd say either quell the warning or add the installation directions to it
<bryceh> anyway, task for another day
<bryceh> Sarvatt, where do you get the package?
<Sarvatt> do you have LIBGL_DEBUG=verbose exported maybe?
<Sarvatt> digging around for it now, it was on people.freedesktop.org that got nuked awhile back and had to grab it off bugzilla somewhere
<bryceh> no, but I do have MESA_DEBUG=1 exported
<Sarvatt> oh thats why ya got it i bet
<bryceh> export MESA_DEBUG=1
<bryceh> export EGL_DRIVER=egl_dri2
<bryceh> export EGL_PLATFORM=drm x11
<bryceh> export EGL_LOG_LEVEL=debug eglinfo
<Sarvatt> export EGL_LOG_LEVEL=debug eglinfo ?
<bryceh> hmm commenting out both MESA_DEBUG and EGL_LOG_LEVEL but still prints it
<Sarvatt> http://debian-multimedia.org/pool/main/libt/libtxc-dxtn/libtxc-dxtn.php
<Sarvatt> debs!
<bryceh> ok thanks
 * Sarvatt wonders if he can get away uploading that to xorg-edgers :)
<bryceh> if I get around to it I'll isolate where the warning comes from and add that link, if I don't just quell it outright
<RAOF> Sarvatt: It's free software, right?
<bryceh> is debian-multimedia.org part of Debian?
<Sarvatt> heavily patent encumbered and not suitable for debian :)
<Sarvatt> its debian's medibuntu
<Sarvatt> http://dri.freedesktop.org/wiki/S3TC
<ScottK> Sarvatt: only with lower quality packaging.
<Sarvatt> lower quality?
<ScottK> The debian-multimedia packaging quality is not well thought of in Debian.
 * Sarvatt can't even count how many times he's had broken ffmpeg libs screw up his system from medibuntu
<bryceh> gotcha
<ScottK> AFAIK, most of the people working on medibuntu are actual Ubuntu devs so I think it's similar to Ubuntu package quality wise
<ScottK> It's been quite some time since I actually paid attention to medibuntu though.
<bryceh> okie dokie guys, get your wayland on:  https://launchpad.net/~xorg-edgers/+archive/wayland
<bryceh> IN THEORY, you should be able to just add the ppa, update, install wayland, and then run wayland as described
<bryceh> if not, it's something I should fix
<Sarvatt> ppa-purge no workie in natty, but at least there aren't many packages involved :)
<bryceh> no?  why not?
<bryceh> anyway, this is only tested on maverick so far
<Sarvatt> sources are stored compressed now, haven't had a chance to make ppa-purge work with that
<Sarvatt> /var/lib/apt/lists/ppa.launchpad.net_xorg-edgers_wayland_ubuntu_dists_natty_main_binary-i386_Packages.gz
<bryceh> ah
<bjsnider> the medibuntu ffmpeg is almost exactly the same as the ubuntu ffmpeg. hard to believe it could have broken anything
<tjaalton> bryceh: tried the ppa, but looks like wayland needs to depend on libgles2-mesa
<tjaalton> since it can't find libGLESv2.so.2 without it
<RAOF> And it's looking for GLESv2?  I thought it was strictly a desktop GL affair.
<vish> RAOF: hi, alacarte upstream is unmaintained.. spoke to Amaranth earlier, he said we can just upload the patch in natty.. re: Bug 395692
<tjaalton> ah
<ubot4`> Launchpad bug 395692 in alacarte (Ubuntu) (and 2 other projects) "Drag-and-Drop behavior in the menu editor is inconsistent and confusing (affects: 3) (heat: 28)" [Low,Triaged] https://launchpad.net/bugs/395692
<RAOF> Also, I guess that's a bug in mesa.
<tjaalton> RAOF: yeah I'm trying to run it with the hints from the ppa
<vish> s/natty/ubuntu
<tjaalton> now the compositor runs, but how do I fire up the clients?-)
<RAOF> vish: Yeah, I guessed as much.  I was going to go sponsor hunting this evening.
<vish> RAOF: neat! thx :)
<tjaalton> is there a way to launch wayland without X
<tjaalton> ?
<bryceh> tjaalton, there may be a /usr/bin/wstart script
<tjaalton> bryceh: yeah, it just says "no drm device found"
<bryceh> tjaalton, and there are clients named wayland-* you can run if you have the server up
<tjaalton> so maybe something else is wrong
<bryceh> yeah likely
<tjaalton> bryceh: also, it didn't pull libxkbcommon
<bryceh> ok
 * bryceh makes notes
<tjaalton> the ppa description has old client names, btw (wterminal..)
<bryceh> oh thanks, yeah just redid the naming today
<bryceh> tjaalton, updated
 * bryceh -> bed
<tjaalton> yeah, night
<RAOF> Well, launchpad indicates that mesa doesn't appear to be on fire.  That's nice :)
<bryceh> RAOF, should it?
<RAOF> No, of course not :)
<bryceh> RAOF, oh btw I wanted to ask, you mentioned you'd pulled some of the changes for wayland-enabled mesa into the archive... 
<bryceh> RAOF, which changes exactly did you pull, and was that into the main archive or the xorg-edgers archive?
<RAOF> I pulled the libudev-dev build-dep into the main archive packages.
<RAOF> So egl_dri2 should actually work. :)
<RAOF> The reasons why Mesa might have caught fire are the switch to r300g by default and libdricore shared linking.
<bryceh> ah gotcha
<bryceh> I've been watching all incoming natty bug reports fairly carefully the last couple weeks
<bryceh> the sense I get is that very few people are running natty at the moment, cause there's hardly any bug reports coming in
<bryceh> http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg
<bryceh> there's 1 natty bug against -evdev and one against nvidia-173
<RAOF> Ah.  Mesa hasn't caught fire on people's systems because it's failed to build on the buildds.  Thanks, crappy mesa build system!
#ubuntu-x 2010-11-26
<RAOF> glcpp/glcpp-parse.y:1858:1: fatal error: error writing to /tmp/ccFoKqc4.s: No space left on device
<RAOF> Whoops!
<oier> Hello everybody, could you please look at bug #643895 since it is affecting users of the geforce 310m card?
<ubot4`> Launchpad bug 643895 in nvidia-graphics-drivers (Ubuntu) "nvidia propietary driver fails to load X with geforce 310M (affects: 7) (dups: 1) (heat: 38)" [High,Confirmed] https://launchpad.net/bugs/643895
<oier> I have been told to ask here around if you could provide some info or help with the issue
<oier> BTW, could somebody tell if the bug is triaged or not?
<bjsnider> that certainly seems like an nvidia-specific issue
<oier> is 657634 a duplicate of 643895?
<apw> bryceh, you seen this error: [ 7228.058217] [drm:i915_gem_object_bind_to_gtt] *ERROR* Attempting to bind a purgeable object
<apw> bryceh, think it just triggered an X dump
<bryceh> heya apw
<bryceh> apw, it doesn't ring any bells
<apw> bryceh, something to keep an eye out for, it doesn't look like a new kernel message .. so i suspect its always been in there ... the message implies userspace has lost track of its pinning of memory
<bryceh> apw, ah, the weirdness that is Intel graphics
<apw> bryceh, so very true
<bryceh> apw, does this bug occur a lot?
<apw> bryceh, no so far only once, but i've only been running this specific kernel for a short time, so if it _is_ kernel then i don't know :)
<bryceh> apw, ok I'll keep an eye out on our end too
<bryceh> so far haven't been too many natty bug reports for X
<apw> bryceh, no its overall been quiet on the exploding front
<bryceh> apw, probably no one has it installed :-P
<apw> i actually have a machine fully converted, the first time i've been able to do so soo very early in the cycle
<bryceh> yeah I've got a test box running it too
<bryceh> (without troubles so far)
<apw> most unexpected, i guess all the exploding will be later in the cycle :(
<bryceh> maybe unity scared everyone off?  ;-)
<bryceh> or I should say, maybe unity will scare up some bugs
#ubuntu-x 2010-11-27
<ari-tczew> could someone help with fix FTBFS with gcc 4.5 in xdm merge? bug 682196
<ubot4`> Launchpad bug 682196 in xdm (Ubuntu) "Merge xdm 1:1.1.10-3 (universe) from Debian unstable (main) (affects: 1) (heat: 6)" [Wishlist,Incomplete] https://launchpad.net/bugs/682196
#ubuntu-x 2010-11-28
<apw> bryceh, seems that this error is a once a day kind of thing: [157293.960248] [drm:i915_gem_object_bind_to_gtt] *ERROR* Attempting to bind a purgeable object
<apw> bryceh, as it is a natty kernel with a maverick userspace i suspect we are in untested combinations 
<Milos_SD> Hi
<Milos_SD> is there 3D support for ATI 5000 series graphics cards in open source drivers that are in xorg-edgers ppa?
<virtuald> milos_sd: yes, but it's not as fast as the proprietary drivers
#ubuntu-x 2011-11-21
<Sarvatt> RAOF: do tell, whats needed for making wine work?
<Sarvatt> i havent even considered upgrading to precise because of it
<Sarvatt> figured it's going to be a few months
<RAOF> Equivs up an empty ia32-libs-multiarch package, then install i386 versions of everything that it depends on that's installable.
<RAOF> You miss out on things like Qt and gstreamer, but they're not actually important for the wine use-case.
<Sarvatt> sweet, thats all i care about
<Sarvatt> screw skype :)
<Sarvatt> ivb on 11.10 is proving exceptionally fun, up to 7 kernel cherry-picks that are needed now just from changes in the last week. they broke the world with a bios update, so much for the livecd working when its released :)
<RAOF> Another bios update, or the same one that broke the world previously? :)
<Sarvatt> oh its the same but we keep finding new issues with it
<Sarvatt> mid october update
<Sarvatt> s3/s4 is still completely broken, managed to get i915 to actually load and found that out
<Sarvatt> oh hey ivb works, but you cant close the lid because gnome decided that should suspend by default
<RAOF> In other S3 news, nvidia doesn't seem to suspend on 3.2 on nvd9 :)
<Sarvatt> t420s!
<Sarvatt> lol
<RAOF> On the plus side, 3.2's nouveau actually drives a nvd9
<Sarvatt> sad i can make the codename to the private bug
<RAOF> Heh.
<Sarvatt> oh really? without overriding the firmware?
<Sarvatt> we ship it all as nvidia only, you can pass a kernel command line arguement to make it think you're on windows xp instead of windows vista/7 and it wont even try to enable optimus because that doesnt work on xp
<Sarvatt> acpi_osi=!windows2009 or something like that
<Sarvatt> people were complaiing about broken nvd9 not long ago in #nouveau
<Sarvatt> guess they werent using the latest stuff
<RAOF> Oh, there's no *acceleration* without an mmiotrace'd context program.
<RAOF> But it brings up the card and does XRandR, as long as you don't particularly feel like using the displayport :)
<Sarvatt> oh really? even though the displayport is physically routed to the nvidia gpu?
<RAOF> Yup.
<RAOF> I presume that installing the nvidia driver will cause the DP to get working, but nouveau doesn't realise that anything's plugged in.
<Sarvatt> yay https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/892799
<ubot4> Launchpad bug 892799 in ia32-libs (Ubuntu) "[xorg-edgers] 32bit OpenGL applications fail to load i965_dri.so (affects: 1) (heat: 8)" [Undecided,Fix released]
<Sarvatt> time for a drink
<RAOF> Woot!
<Sarvatt> is that worth fixing in oneiric?
<Sarvatt> the problem is, everything 32 bit on amd64 is using libdrm from ia32-libs instead of the multiarch one
<Sarvatt> (in oneiric)
<Sarvatt> mesa is using the :i386 one, but it'll still use the ia32-libs libdrm
<RAOF> Hm.  Maybe.
<Sarvatt> figure i'll care more if i SRU libdrm to oneiric, since 32 bit apps will be using the non-SRUed libdrm
<Sarvatt> but there hasn't been anything worth SRUing in libdrm for oneiric yet
<Sarvatt> high probabilty if there's a libdrm SRU to oneiric I'll be the one doing it and will poke slangasek/YokoZar, I've been doing craploads of SRUs :P it kinda screws other people doing mesa updates via PPAs though like that oibaf guy
<Sarvatt> there's really no need for mesa/libdrm in ia32-libs at this point that i can see, was made multiarch installable when libpciaccess0 was multiarched at the last minute and added to ia32-libs-multiarch
 * Sarvatt really needs to get upload permissions to upload this crap himself and not ask other people to upload crazy 580mb source package updates for this trivial stuff
<Sarvatt> ricotz: http://www.horizonhobby.com/pdf/BLH3500-Manual_EN.pdf
<Sarvatt> ricotz: go to page 9
<Sarvatt> screwed up with cairo in edgers
<ricotz> Sarvatt, nice ;)
<ricotz> Sarvatt, chris is probably interested in a cairo-trace of this
<Sarvatt> ricotz: yeah pinged chris about it, he added the assert its dying on recently
<ricotz> Sarvatt, alright, so he is probably on it already
<ricotz> Sarvatt, so is it flying? :P
<Sarvatt> dunno he hasn't responded yet, someone in #intel-gfx just pointed out that crash with edgers
<Sarvatt> ricotz: you see all the ia32-libs crap recently?
<ricotz> Sarvatt, ah, ok, i meant the helicopter ;) -- i was thinking you discovered it
<Sarvatt> 32 bit dri on intel wasn't working with edgers
<Sarvatt> oh haha i didn't even look at it, just made it crash
<ricotz> i saw you uploaded ia32-libs, good
<ricotz> shouldnt this go into oneiric-proposed too?
<Sarvatt> ricotz: fixed already :P
<Sarvatt> ricotz: might want to hold off though, he thinks there might be another bug
<Sarvatt> unless its not a PITA to update it again tomorrow
<Sarvatt> cairo packages were a PITA last time i did them :P
<Sarvatt> oh they use dh-autoreconf now dont they \o/
<ricotz> Sarvatt, it isnt much of a problem updating them, unless he commits another fix within the next hours ;)
<Sarvatt> he usually does
<ricotz> nvm, it is on its way
#ubuntu-x 2011-11-22
<Milos_SD> Hello
<Milos_SD> is there any news about fglrx in xorg-edgers ppa? :)
<ricotz> tseliot, ^ ;)
<tseliot> ricotz: I know...
<ricotz> tseliot, sorry for bugging you again
<tseliot> ricotz: I need to deal with broadcom first, as users with 3.2 are left with broken wireless...
<tseliot> but I'll try to do everthing today
<ricotz> tseliot, ok :)
<Milos_SD> I have one more question :)
<Milos_SD> on that laptop with Sandy Bridge graphics and ATI (disabled right now from BIOS), there is some bug that just restarts Xserver (trow me back to log in screen) when using xorg-edgers (and there is no way to get back to ubuntu's default because ppa-purge is not working with multiarch...
<Milos_SD> is there some workaround for this bug?
<Milos_SD> I noticed that almost every laptop with intel graphics, old or new does this with xorg-edgers... and there is no problems with ATI OSS and nvidia binary using xorg-edgers.
<Milos_SD> doesn anyone else has this problem?
<bjsnider> ricotz, http://www.nvnews.net/vbulletin/showthread.php?t=168940
<ricotz> bjsnider, i know ;)
<ricotz> bjsnider, should be available soon in edgers
<bjsnider> yeah, i just wanted to update you because i was putting it into x-updates
<ricotz> bjsnider, alright
<ricotz> bjsnider, please make it so that the edgers version is higher
<bjsnider> ricotz, i think edgers should be higher because they're both tagged ~distro~ppa, and i use ~xup, where you probably use ~edgers, although there's no excude for using both ppas at the same time. that's nuts
<Sarvatt> ricotz: ~zedgers it is? :P
<Sarvatt> Milos_SD: remove the :i386 packages first
<Sarvatt> its a pain in the butt because you'll have to reinstall things but thats the only way at the moment
<Sarvatt> Milos_SD: dpkg -l | grep sarvatt | grep :i386 ; dpkg -l | grep ricotz | grep :i386
<Sarvatt> purge all those, keep track of whats uninstalled (most likely ia32-libs-multiarch and wine), then you can ppa-purge and reinstall those
<ricotz> bjsnider, right, the xorg-server dep should manage this two perhaps
<ricotz> Sarvatt, hmm, purging "| grep ricotz |", hopefully it doesnt use a ppa of mine!
<ricotz> better "dpkg -l | grep 0sarvatt | grep :i386 ; dpkg -l | grep 0ricotz | grep :i386"
<bjsnider> cool, we now have a "cancel build" option for ppas
<bjsnider> first i've noticed it anyway
<bryceh> bjsnider, yep they added it a week or two ago
<ricotz> bjsnider, could you update nvidia-settings in x-updates too? for 290.x there are some needed changes
<bjsnider> yeah, i was going to, but there's such a huge build queue right now that i wasn't worried about it
<bjsnider> good thing there are 20 idle armel builders though
<bjsnider> we've on top of the armel issue for sure
<ricotz> bjsnider, yeah, but they will takes long time too
<dzan> hi, I added the repo ( linux mint 11 ) and did an update, then tried: apt-get install nvidia-graphics-drivers but that came up empty, ideas?
<ricotz> dzan, as i wrote "apt-get install nvidia-current" ;)
<Sarvatt> don't know what ppa you added or what ubuntu release linux mint maps to (hope you added the right one..) but its nvidia-current
<dzan> Sarvatt, thx I got it, ricotz helped me :)
<bryceh> i've run into that bug where you upgrade oneiric -> precise with nvidia installed and then X doesn't start due to nvidia failing
<ricotz> bryceh, a dkms problem?
<bryceh> ricotz, yeah nvidia kernel module missing (apparently didn't build?)
<ricotz> Sarvatt, you probably noticed 1.11.99.1 ;)
<ricotz> bryceh, i read about it, but havent ran into myself
<bryceh> oh wait, I said this was an upgraded machine, actually it was a fresh install
<bryceh> I wasn't expecting nvidia to get installed; I guess it did due to having 'third party sources' checkmarked or some such
<bryceh> aha, bug #876499
<ubot4> Launchpad bug 876499 in ubiquity (Ubuntu) (and 1 other project) "Incorrect Nvidia driver installed by checking 3rd party box (affects: 4) (heat: 18)" [Undecided,Confirmed] https://launchpad.net/bugs/876499
<Sarvatt> bryceh: file bug fast against nvidia-graphics-drivers, move to ubiquity?
<Sarvatt> oh
<bryceh> wait, no not that bug
<Sarvatt> was saying fast because logs might get overwritten, not sure :) ubiquity would probably have good logs from the start
<Sarvatt> you already know the kernel module didnt get built
<Sarvatt> ricotz: you upload it to edgers or something?
<bryceh> good idea; filing bug
<bryceh> ooh, my apport hook prompts are kinda fun from the console
<ricotz> Sarvatt, no, just saying there is finally a first 1.12 pre-release
<Sarvatt> bryceh: /var/lib/dkms/whatever have a build recorded for your current kernel?
<Sarvatt> modinfo nvidia (or is it nvidia-current) say anything?
<ricotz> "modinfo nvidia_current" ;)
<Sarvatt> can tell i haven't used the blob in almost a year :)
<bryceh> sorry had to type the ridiculously long bug filing url into firefox on another computer
<bryceh> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/893760
<ubot4> Launchpad bug 893760 in nvidia-graphics-drivers (Ubuntu) "Could not start graphical session by checking 3rd party box; nvidia kernel driver failed to build (affects: 1) (heat: 6)" [Undecided,New]
<bryceh> *** Unable to determine the target kernel version. ***
<bryceh> hunh
<bryceh> modinfo nvidia_current just says can't find it
<Sarvatt> yeah it never got built
<bryceh> what else would be worth testing?
<Sarvatt> it did install nvidia-173 too
<Sarvatt> 2011-11-21 19:42:40 configure nvidia-173 173.14.30-0ubuntu8 <none>
<bryceh> lsmod is showing no nv*
<bryceh> but you're right, -173 is installed
<bryceh> so, guess it is a dupe of 876499 after all
<Sarvatt> yuck this is a problem in 11.10 too??
<bryceh> hmm, possibly although I don't recall seeing it myself or running across bug reports other than this one
<bryceh> although I was only looking at nvidia bug reports superficially last release
<bryceh> Sarvatt, you thinking it's ubiquity rather than dkms?
<Sarvatt> i'm looking at https://launchpadlibrarian.net/83010560/UbiquitySyslog.txt from the other bug now, all kinds of weird
<Sarvatt> can you get that same log from your system?
<Sarvatt> ubiquity is loading the nvidia driver right after the build for some strange reason, of course that doesnt work
<bryceh> where can I find this UbiquitySyslog?  no 'ubiquity' in syslog, and no *ubiquity* in /var/log either
<bryceh> ah /var/log/installer/syslog maybe?
<Sarvatt> darn, i have absolutely no idea
<Sarvatt> oh that sounds right
<bryceh> wow it's humongous
<Sarvatt> i'd just save all those logs for later and fix it up yourself, purge nvidia-173 see if nvidia-current is offered in jockey (might be a missing pci id from -current?)
<bryceh> well, the entire purpose of setting up this system is to find bugs, so given that it's at 'mission accomplished' at the moment, no need to work around the problem ;-)
<Sarvatt> that was freaking fast :)
<bryceh> I know, I'm pleased in fact
<bryceh> this is one of the three bugs we have open right now against precise - http://www.bryceharrington.org/Arsenal/Reports/ubuntu-x-swat/totals-precise-workqueue.svg
<Sarvatt> wonder if nvidia-current nvidia-current-updates being the same thing is throwing off ubiquity, no nvidia-173-updates
<Sarvatt> then again why isn't this more common..
<Sarvatt> wow
 * Sarvatt has been living off in kernel land, 3 more oneiric SRUs today :(
<Sarvatt> yeah not seeing any other related bugs so far
<bryceh> The bug report says '11-10' in the description but the apport spew says 12.04, so maybe the bug was described incorrectly.  At this point evidence only supports this being a precise-only bug.
#ubuntu-x 2011-11-23
<bryceh> it's a jockey error actually
<om26er> bryceh, Hi! there is a bug with fglrx driver that has been there from last cycle, do you have a thought on this?
<om26er> bug 770283
<ubot4> Launchpad bug 770283 in fglrx-installer (Ubuntu) (and 3 other projects) "[fglrx]title bar does not update on non-maximized windows (affects: 39) (dups: 5) (heat: 208)" [Undecided,Confirmed] https://launchpad.net/bugs/770283
#ubuntu-x 2011-11-24
<Milos_SD> what is the status of fixed fglrx? :D
<tseliot> ricotz, Milos_SD: I'm working to update fglrx to the 11-11 release
<tseliot> in both precise and oneiric
<tseliot> I hope to upload it today
<ricotz> tseliot, ok ;) -- you probably want to look at 290.10 too which is a latest stable release
<Milos_SD> tseliot, great :)
<ginggs> hi all - i hope this is the right place to ask - any chance debian's nvidia-cuda-toolkit could be included in precise?
<ginggs> http://packages.debian.org/source/sid/nvidia-cuda-toolkit
<ginggs> It's going to need some work to make it compatible with nvidia-current
<tseliot> ricotz: if it's a stable release, I certainly will ;)
<ricotz> tseliot, looks like there are more requests for cuda :P
<tseliot> ginggs: yes, I've been just asked about it in #ubuntu-devel and the answer is "I'll have a look at it and see how I can integrate it"
<tseliot> ricotz: right
<ginggs> thanks tseliot
<tseliot> np, thanks for reminding me
<Milos_SD> tseliot, will that 11-11 release package have fixed hybrid graphics support? :)
<tseliot> Milos_SD: yes, I'll backport my fix for hybrid graphics too
<tseliot> so that at least libraries are looked for in the right place
<tseliot> RAOF: do you mind if I steal bug #813809 from you? ;)
<ubot4> Launchpad bug 813809 in fglrx-installer (Ubuntu Precise) (and 2 other projects) "Hybrid Graphics with Intel+fglrx is not supported (affects: 29) (dups: 1) (heat: 131)" [Medium,Triaged] https://launchpad.net/bugs/813809
 * penguin42 has anyone else had problems with mouse pointers disappearing at random times, and any suggestions on debugging it (still does it with soft cursor)
#ubuntu-x 2011-11-25
<tseliot> Milos_SD: unfortunately my fix wasn't enough. I've told upstream about it
<Milos_SD> tseliot, enough for what?
<tseliot> Milos_SD: enough for hybrid graphics to work (i.e. not to segfault)
<Milos_SD> hmm... you tried it?
<tseliot> Milos_SD: yes and it doesn't really work
<Milos_SD> maybe the problem is in xorg :S
<tseliot> well, upstream will let me know
<Milos_SD> it works on sled 11 with older xorg, but new fglrx
<tseliot> it could be
<tseliot> ricotz: I'm uploading fglrx as we speak
<Milos_SD> tseliot, when will that fglrx be available? in xorg-edgers or in ubuntu backports/updates repo?
<Milos_SD> where will*
<ricotz> tseliot, \o/, will push it to edgers asap when i see it
<tseliot> Milos_SD: I'm uploading the packages in precise and in oneiric-proposed. Keep an eye on bug #894802
<ubot4> Launchpad bug 894802 in fglrx-installer-updates (Ubuntu Oneiric) (and 1 other project) "SRU: update fglrx-updates to 8.911 (11.11) (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/894802
<tseliot> ricotz: great
<ricotz> tseliot, you probably want to have a look the lintian warnings
<ricotz> which are pretty easy to fix in this case
<tseliot> ricotz: I know, I'll take care of them next time
<ricotz> alright
#ubuntu-x 2011-11-26
<rrva> major difference btw oneiric and xorg-edgers ppa of today was that touchpad sensitivity works waay different
<rrva> what has changed here? How to change settings? (gnome3 adjustments do not seem to bite)
<LLStarks> hi, is there any simple way to test multitouch before it hits x?
#ubuntu-x 2012-11-19
<mlankhorst> is it ok to do a syncpackage on packages still in the ftp-master queue? I want to update libdrm to 2.4.40 for raring :)
<mlankhorst> http://ftp-master.debian.org/new/libdrm_2.4.40-1.html
<tjaalton> it won't work
<mlankhorst> aw indeed, no .dsc to pick up on
<tjaalton> it's possible to do a manual "sync" though, but then you still have a risk of the debian upload getting rejected (though unlikely in this case)
<mlankhorst> I'll wait for now :)
<tjaalton> yeah
<mlankhorst> tjaalton: any plans for mesa 9.0.1?
<tjaalton> mlankhorst: you want it?-)
<mlankhorst> tjaalton: was updating it for raring
<mlankhorst> and I need something to test some changes on for nouveau in 9.0, so I'll probably test it locally too
<mlankhorst> not part of 9.0.1, but hopefully for 9.0.2 :)
<tjaalton> ah, you've merged it already
<mlankhorst> yeah
<tjaalton> I don't have my sbuild environment running yet, can't test anything bigger
<tjaalton> maybe that's the next on the list..
<tjaalton> +item
<mlankhorst> ugh woops released too early
<mlankhorst> seems they decided it was a good idea to bump libwayland-dev to 0.99 in a minor release..
<tjaalton> note that infinity uploaded mesa during the weekend
<tjaalton> *updated
<tjaalton> https://lists.ubuntu.com/archives/raring-changes/2012-November/001439.html
<mlankhorst> ah
<mlankhorst> I'm only missing the old changelog item and the bump to 0.99.0 then
<tjaalton> so need to update wayland too
<tjaalton> eh
<tjaalton> robert ancell did that already
<mlankhorst> I assumed he only uploaded it after making sure wayland already was in place :p
<tjaalton> what do you mean?
<mlankhorst> it wouldn't make sense to upload mesa before updated wayland
<tjaalton> oh 'he' as in infinity, yes
<mlankhorst> but that means we need to sru wayland to quantal too now? fun..
<tjaalton> or revert those changes
<mlankhorst> I'm going to need it in precise too
<tjaalton> yes
<tjaalton> whatever works
<mlankhorst> especially since I want to do a raring stack soon
<mlankhorst> I'm going to cheat and add 1 upstream patch as well, makes backport stack less hackier if it gets accepted
<mlankhorst> and looks like wayland needs a rename after all, then :(
<mlankhorst> ok hopefully I can rebuild the entire stack one more time with renamed wayland..
 * bryce waves
<mlankhorst> hai
<bryce> tjaalton, push xorg-server git?
<bryce> has anyone run the unity test suite?  Is it pretty straightforward?
<tjaalton> bryce: duh, done
<tjaalton> haven't run any test-suite
<bryce> tjaalton, thanks for taking care of the pointer barrier regression
<bryce> tjaalton, yeah I'm wondering whether that test suite would have caught this particular issue.
<tjaalton> np, nice to start the week with a critical upload :)
<tjaalton> i'm not running raring yet
<mlankhorst> hey well the whole reason we put it in raring in the first place was because we didn't know what it was doing and raof never got around to reviewing the change
<mlankhorst> so I'd say the process worked :P
<tjaalton> perhaps I should upgrade the laptop.. there's still stuff to fix after my ssd died two weeks ago, but at least I can sbuild stuff again..
<tjaalton> but that's the desktop, can break the laptop any time
<bryce> yeah probably time to think about upgrading all my test hardware to raring... ugh
<mlankhorst> yeah I want some nouveau fixes in 9.0.2
<mlankhorst> so I may do an extended gaming session tomorrow
<mlankhorst> :X
<tjaalton> I need to set up cobbler first to make reinstalling painless again.. :)
<mlankhorst> I only have a single raring chroot
<mlankhorst> but I can netboot from it!
<tjaalton> tried maas, but it's built for one thing only (cloud instance clones)
<bryce> yeah I'm experimenting with some scripts to dd image the test systems
<bryce> (with multiple /usr partitions loadable via  grub boot-next commands)
<mlankhorst> bryce: mine is just slightly harder for initial setup, but after that a breeze :)
<RAOF> Bah!
<RAOF> The problem with that patch is exactly the problem I thought it'd have, but the guy said that he'd tested launcher reveal on edges.
<darkxst> RAOF, if you are talking about my pointer barrier patch, sorry I had meant to close the merge request. It was pretty clear after my conversation with jasper (which I pasted into the bug) that it would break
<Dandel> I have a bug i need to report about the xorg edgers repo for piglit that I spotted... it's a few minor changes but increases the total tests available.
#ubuntu-x 2012-11-20
<RAOF> Dandel: A change to the piglit packaging?
<Dandel> yes.
<Dandel> to be exact, it's two main changes ( to fix the EGL, OpenGL+EGL, GLES1, and GLES2 tests): libegl1-mesa-dev libgles1-mesa-dev libgles2-mesa-dev
<Dandel> the last message had the missing build dependencies and then for the build command, it is missing.... -DPIGLIT_BUILD_GLES1_TESTS=ON -DPIGLIT_BUILD_GLES2_TESTS=ON
<Dandel> this would allow one to test the OpenGL ES 2 stuff using ( as long as libegl and libgles2 is not missing upon install): piglit-run.py /usr/share/piglit/tests/all_es2tests results/es2
<Dandel> and most importantly, EGL With desktop OpenGL support can be tested with this change: env PIGLIT_PLATFORM=x11_egl piglit-run.py /usr/share/piglit/tests/quick.tests results/x11_egl_opengl
<Dandel> EGL W/ OpenGL support is somewhat critical to have in the test... especially since things like Wayland and desktops w/o X11 desktops require it.
<Dandel> RAOF: ya get my message?
<RAOF> Yes, thanks.
<Dandel> I was just doing a quick test to see what was there, and what was not.... I also noticed that OpenCL support is missing
<Dandel> it requires the opencl library, and headers, and then to add... -DPIGLIT_BUILD_CL_TESTS=ON to the build flags
<Dandel> I know that OpenCL is currently not implemented to a usable state in mesa yet, so it's not exactly a huge requirement. ( However, it is still worth the a note being added.)
<RAOF> We could certainly include the OpenCL tests; there's not much reason not to.
<Dandel> RAOF: only 1 problem... precise, and up do not have the OpenCL library yet.
<RAOF> ocl-icd-libopencl1 is in Raring.
<Dandel> but it's missing from precise ><;
<RAOF> Then we don't do opencl tests on Precise :)
<Dandel> what about the users of the blob who want to get the vendor to behave nicely?
<RAOF> They use their vendor drivers as normal?
<Dandel> yes, but the executables are missing in the precise package ( bad scenario )
<RAOF> ?
<Dandel> i checked... the opencl tests file is there.
<Dandel> the executables are not
<Dandel> there's no reason not to backport it to precise ( since limited packages depend on it, and it'll let devs start picking it up sooner )
<RAOF> I'm not sure what the problem is - the OpenCL piglit tests won't run on Precise? That doesn't seem like a huge problem to me.
<Dandel> it's complaining about the opencl exectuables not being there.
<RAOF> In piglit, on Precise?
<Dandel> yes
<Dandel> piglit-run.py /usr/share/piglit/tests/all_cl.tests all-cl-test
<Dandel> and all output is skip
<Dandel> Error code: Test executable not found.
<Dandel> it'd be one thing if it had an error due to the OpenCL ICD not being installed, but sadly, I know i have mine installed.
<Dandel> I have an ldd for libOpenCL ( provided by amd driver, but it's still a valid OpenCL provider )
<Dandel> RAOF: about how long do ya think it'll take to see the minor fix to appear in the repo?
<RAOF> About as long as a piece of string; they'll get in shortly after someone takes the time to get them in.
<superm1> so on a fairly fresh mythbuntu install I keep seeing reports of this crop up: " ValueError: invalid literal for int() with base 10: 'experimental-304'"
<superm1> it's 12.04.1
<superm1> with jockey 0.9.7-0ubuntu7.4
<superm1> i see bug https://bugs.launchpad.net/ubuntu/+source/nvidia-common/+bug/1047681 was supposed to add support experimental flavors, but i'm on the latest version and still seeing that (http://paste.ubuntu.com/1371747/) http://paste.ubuntu.com/1371748/
<ubottu> Launchpad bug 1047681 in nvidia-settings-experimental-310 (Ubuntu Raring) "Add package nvidia-experimental for tracking nvidia beta drivers" [Undecided,New]
<superm1> oh but that's actually an old report that kept getting triggered but not uploaded for whatever reason i think, maybe before the new jockey was installed
<superm1> i'll purge reports and keep an eye if it crops up again
<mlankhorst> morning
<tjaalton> same
<tjaalton> updating -intel git
<mlankhorst> sure
<tjaalton> thinking about a ubuntu-next branch for mesa
<tjaalton> or such
<mlankhorst> bit too soon, it will only become easier with all the new autopackaging..
<tjaalton> what is?
<mlankhorst> well more autotools fixes :)
<tjaalton> it would have git master. ah
<tjaalton> hmm xserver has ubuntu+1
<mlankhorst> just split off ubuntu-raring for stable?
<tjaalton> nah
<tjaalton> hmm
<mlankhorst> but we need libdrm 2.4.40 for next branch
<tjaalton> guess that's doable
<mlankhorst> waiting for experimental acceptance..
<mlankhorst> so I can syncpackage it
<tjaalton> oh right
<tjaalton> sure
<mlankhorst> jcristau: do you have the .dsc and diff btw? patience is running out :D
<jcristau> i posted the url on #d-x when i uploaded
<tjaalton> http://ftp-master.debian.org/new/libdrm_2.4.40-1.html
<tjaalton> hmm not that
<tjaalton> mlankhorst: http://people.debian.org/~jcristau/libdrm/
<mlankhorst> ah thanks
 * mlankhorst syncpackage --force
<tjaalton> you could've also just uploaded a -0u1
<tjaalton> just like the current version is
<tjaalton> manual syncs are not encouraged
<mlankhorst> aye but I wanted to test how syncpackage worked :)
<tjaalton> that's not how it's supposed to be used :)
<mlankhorst> aw
<mlankhorst> ok uploaded xorg-server renamed for some version of xorg-server
<tjaalton> it's hard now that debian is frozen
<tjaalton> to make use of syncpackage..
<mlankhorst> guess I should start uploading lts-raring soon when I confirm quantal works
<mlankhorst> yay, installing libcogl-dev or libclutter-1.0-dev wipes the lts stack..
<mlankhorst> should I make the unrenamed mesa-dev packages installable with the renamed stack just in case?
<tjaalton> why?
<mlankhorst> they depend on libgl1-mesa-dev (>= 7.1~rc3-1~)
<tjaalton> shouldn't be needed if the renamed one provides libgl1-mesa-dev
<mlankhorst> and versioned provides is a pita..
<tjaalton> oh right
<mlankhorst> it would be ugly though, but I see no other choice..
<tjaalton> maybe ask on #u-d first
<mlankhorst> tjaalton: to be fair it shouldn't break anything if it ends up compiling :-)
<tjaalton> mlankhorst: lost the context.. :)
<mlankhorst> I mean if I use the unrenamed mesa-dev packages it should still work
<mlankhorst> only way it could fail would be on static linking
<mlankhorst> and that would break anyway :)
 * hyperair pokes Sarvatt 
 * hyperair wonders if anyone has had any luck with Steam, intel and BadMatch
<mlankhorst> verrrrry specific
<hyperair> yeah well, if it works, it works, if it doesn't, it doesn't.
<hyperair> BadMatch, major opcode is 153
<hyperair> appears to be GLX
<hyperair> minor opcode is 26
<hyperair> i don't know what that is
<hyperair> where can i look this up?
<jcristau> in the glx spec
<hyperair> jcristau: www.opengl.org/registry/doc/glx1.4.pdf <-- this?
<jcristau> 26 is GLXMakeContextCurrent
<jcristau> that would probably work too.
<hyperair> hmm i don't see op codes in this thing =\
<hyperair> i do see GLX functions though
<hyperair> thanks
<jcristau> http://cgit.freedesktop.org/xorg/proto/glproto/tree/glxproto.h#n2152
<hyperair> hmm, http://www.opengl.org/sdk/docs/man2/xhtml/glXMakeContextCurrent.xml..
<hyperair> BadMatch is generated if draw and read cannot fit into frame buffer memory simultaneously
<jcristau> the spec (or reading the mesa and xserver code) should tell you when that's allowed to return badmatch.
<hyperair> this sounds potentially the issue.
<hyperair> jcristau: sandy bridges use shared memory, right?
<hyperair> is there some way to increase the amount of memory it can get, or something?
<jcristau> no
<jcristau> other than maybe putting more ram in the box
<hyperair> there's 8G in this box =\
<jcristau> then that's not the issue
<hyperair> hm.
<mlankhorst> ok I think I can push the raring stack now as well, I fixed the command up
<mlankhorst> tjaalton: can you do the uploads for https://bugs.launchpad.net/ubuntu/+source/x11proto-randr/+bug/1081122 ?
<ubottu> Launchpad bug 1081122 in x11proto-randr (Ubuntu) "x11proto-(gl,randr,dri2)-dev need to be updated for backport stack" [High,New]
<mlankhorst> I would imagine you need to add a new changelog entry with a lower version than quantal for the sru, just in case they'd need to roll back.
<tjaalton> sure, when i get back home
 * penguin42 is seeing something he's never seen in >20 years of playing with X and could do with some hints; I've got a Thinkpad w520 - mixed Intel/NVidia machine, running Quantal; now I realise Optimus is odd; but I'm not seeing the external monitor in xrandr, but /proc/fb shows it (via fbset), and nouveau shows it in Xorg.0.log - so if it's shown in both of those how can xrandr not see it?
<mlankhorst> penguin42: because it's driven by nouveau, and it's not a supported config until x1.14 (hopefully!)
<penguin42> mlankhorst: so nouveau has explicitly decided not to tell xrandr about it? Just seems odd sincethe log shows it's probing the output, associated a screen with it etc
<mlankhorst> penguin42: any output on xrandr --listproviders ?
<penguin42> Provider 0: id: 165 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 2 outputs: 2 associated providers: 1 name:Intel
<penguin42> Provider 1: id: 102 cap: 0x5, Source Output, Source Offload crtcs: 2 outputs: 5 associated providers: 1 name:nouveau
<penguin42> hmm
<mlankhorst> DRI_PRIME=1 glxgears, congrats you got nouveau working, still no output support though :P
<penguin42> mlankhorst Sorry, can you just explain that line
<mlankhorst> multiple graphics card never worked before, so the fact it's even working at all is definitely some progress..
<penguin42> true; what surprises me though is since the kernel was actually driving the nouveau display (it had the boot progress screen on previously), and since /proc/fb shows it, why wouldn't it just leave it enabled and let it render to it
<mlankhorst> because x has no support for that yet, if you know C and want to help out however...
<penguin42> mlankhorst: Maybe at the weekend, I could do (although my list of bugs to fix first...); OK, I'd just assumed X would be able to use anything it had a framebuffer for
<penguin42> I guess I should try bumblebee or something 1st
<penguin42> for ref; this is 12.10 with the bios set to optimus mode; in 'discrete' mode it hangs solid ( a cow-orker had 12.04 work successfully in discrete mode)
<mlankhorst> lot of activity in nouveau recently
<penguin42> yeh, good to see - is it worth my trying edgers?
<mlankhorst> could try
<mlankhorst> but no guarantees
<penguin42> sure
<penguin42> ok, thanks for your help; if I find something that works I'll come back and say
<bryce> mlankhorst, 1080808 looks to me like just a kernel regression, what do you think?  Something we should care about or should I bump it over  to the kernel team's queue?
<mlankhorst> bug 1080808
<ubottu> Launchpad bug 1080808 in xserver-xorg-video-nouveau (Ubuntu) "nVidia/nouveau fails when logging in to Ubuntu/Kubuntu with kernel 3.7.0-2" [Undecided,New] https://launchpad.net/bugs/1080808
<mlankhorst> ty
<mlankhorst> fun fun
<mlankhorst> keep against xxv-nouveau
<bryce> ok
<mlankhorst> I don't  think the kernel team does nouveau development
<bryce> mlankhorst, no but they can walk folks through testing mainline kernels and/or doing git bisection
<bryce> however if it's an issue we should care about, we should keep it against X, since things sometimes fall through the cracks if filed against the kernel
<mlankhorst> bryce: yeah 3.7 has the massive rewrite
<mlankhorst> so if they can do update to nouveau git tree first to check
<bryce> mlankhorst, he says it's been happening since quantal beta2, which would predate the 3.7 change
<bryce> maybe he's experiencing two separate bugs
<mlankhorst> also forged alliance works fine with mesa 9.0 fixes
<mlankhorst> but still dead slow :P
<bryce> mlankhorst, ok tomorrow remember to do some triaging at http://www.bryceharrington.org/Arsenal/ubuntu-x-swat/Reports/totals-raring-workqueue.svg.  There's probably only going to be a couple bugs filed so far.
<mlankhorst> bryce: yeah I saw like 3 bugs when I looked at it today
<mlankhorst> so got some work done instead
<mlankhorst> at least last i checked i was on tuesday
 * bryce nods
<bryce> yeah there won't be much this early on, but I've learned if we keep the queue tamped down here early on, it'll help keep the queue better under control down the road in a few months.
<mlankhorst> I'm actually on precise still
<mlankhorst> with wayland from raring renamed installed
<mlankhorst> and mesa 9.0.1
<mlankhorst> + fixes I want to push
<mlankhorst> but ok, qa passed, so fixes pushed to 9.0 branch
<tjaalton> mlankhorst: so what needs uploaded and from where?
<tjaalton> don't see any git branches
<mlankhorst> x11proto-gl, dri2, randr
<mlankhorst> just take quantal version, add a lower version number, upload to precise
<tjaalton> done
<Dandel> RAOF: there's going to be a bit of an issue on the piglit builds... the eglext.h needs updating with the changes that happened in the last 24 hours.
<RAOF> Heh.
<Dandel> i figure it'd be good to know this before the daily autobuild shows the issue.
<Dandel> also, i see a small branch with changes to the piglit builder set... although, I don't see where the code is kept for the waffle library.
 * bryce waves to RAOF 
<RAOF> Good morning!
<RAOF> Slash afternoon :)
<bryce> :-)
<bryce> working on getting verification done for fglrx-experimental-9.  Darn AMD dropped hw support for my card, so had to build a new system.  almost done.
<Dandel> fun.
<Dandel> bryce: i know whay ya mean... i have two cards i can't use for testing with amd driver due to the fact they outright blacklist radeon.
<RAOF> bryce: :(
<RAOF> Intel took back my Haswell desktop SDP, so I now no longer have a box with enough power for my Radeon 7870.
<Dandel> RAOF: i could possibly help with this... I have two different boxes with amd gpus that *are* still supported.
<bryce> RAOF, yeah fortunately I had rebuilt my file server from scratch this year, and had spare parts with enough oomph to drive my 7850
<Dandel> bryce: toy around with any of the a-series systems yet? ( like the a6 apu found in many laptops )
<bryce> Dandel, nope
<Dandel> ah... just was wondering... I'm probably one of the few devs to use one... although i'm disappointed in how the hybrid graphics work ><;
<RAOF> Dandel: I'd quite like to; problem is that I'd need to buy one, which means I'd want a high-end one, and Intel stomp the AMD processors on the high-end.
<Dandel> RAOF: That may be the case, but AMD is more of a budget system, and frankly... I see reasonably good performance even on the a6-3400m i use on my laptop 
<Dandel> anyways, in the lower end, amd is stomping intel across the board ( namely sub-$300 range for cpu/motherboard/ram/video card)
<Dandel> RAOF: do ya run the piglit tests often on the amd gpus by any chance? ( using both mesa and binary driver ) ( I'm wondering since the piglit test suite also appears to be a good measure for stability )
<RAOF> Not often, no. I have in the past, when I was fiddling with mesa and adding piglit tests.
<Dandel> I see... I know someone who's been running piglit on amd cards for a while now.
<mlankhorst> RAOF: want to approve x11proto-* in precise queue? :P
<mlankhorst> after that it should be possible to upload the entire x stack
<RAOF> Urgh. Our previous x11proto-randr had the per-crtc pixmap proto stuff that got dropped in it.
<mlankhorst> ..?
#ubuntu-x 2012-11-21
<RAOF> If you check out the diff between what's in precise and the x11proto-randr in the precise-proposed queue, it drops protocol definitions.
<RAOF> Because we had a snapshot which had the per-crtc pixmap stuff in it that got dropped.
<mlankhorst> that won't affect abi though will it?
<soreau> If I am reading the site correctly, xorg-edgers only packages the core wayland library, no compositors or clients?
<mlankhorst> I mean I doubt there's any x server that used it..
<mlankhorst> and libxrandr builds just fine with new one
<RAOF> mlankhorst: Technically it breaks API; code which compiled on precise will fail to compile with 1.4.0.
<mlankhorst> except that it would already break api in a lot worse way if something used it..
<RAOF> Whether or not there's any code which *uses* that is a different question; the server obviously doesn't.
<mlankhorst> libxrandr doesn't either
<mlankhorst> and those are the only useful cases
<mlankhorst> hm maybe libxcb *checks*
<mlankhorst> nope builds just fine
<RAOF> Oh, yeah.
<RAOF> I don't expect this to be a *practical* problem.
<RAOF> But maybe some crazy loon has written something directly against the xrandr protocol headers in precise, and it'll break :)
<mlankhorst> I will hunt them down, apply an industrial size magnet to their hard disk, then take it with me for physical destruction
<mlankhorst> any code that does depend on it would just get a badrequest anyway
<RAOF> Absolutely.
<RAOF> Actually, no it wouldn't.
<RAOF> ...or maybe it would.
 * mlankhorst did his homework on that one!
<RAOF> It'd certainly error out, though.
<RAOF> The request structs are different sizes :)
<mlankhorst> in any case that would only be a problem when talking to a NEW xserver
<RAOF> Indeed.
<RAOF> But these are the things you learn to think about on the SRU team :)
<mlankhorst> don't try to drag me into the sru team! :P
<mlankhorst> but that should be enough to start uploading most of the quantal stack at least
<bryce> hum.  the fglrx-experimental-9 integration work looks a bit flaky. but the driver itself appears to be working ok.
<mlankhorst> RAOF: oh right, missing llvm-3.1 too, not sure how you want to approach that?
<RAOF> mlankhorst: I'll talk with the rest of the SRU team.
<mlankhorst> thanks
<RAOF> tjaalton: https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/804109 is missing the SRU information; specifically a test case and regression potential.
<ubottu> Launchpad bug 804109 in acpi-support (Ubuntu Precise) "drop synaptics from racy /etc/acpi/asus-touchpad.sh" [Undecided,In progress]
<mlankhorst> RAOF: btw for quantal, mesa 9.0.1 updated to new wayland 0.99 which unsurprisingly wasn't compatible with the old one from quantal..
<RAOF> Then we can't have mesa 9.0.1 in quantal :(
<mlankhorst> fortunately can be reverted
<RAOF> Why were those commits in the stable tree? Gah!
<mlankhorst> hey I did qa for nouveau in mesa9!
<mlankhorst> which seems to be more than it usually receives..
<mlankhorst> well qa = check if game finally ran in wine with renamed stack and wayland from raring..
<soreau> Is there an official channel for xorg-edgers repo or is this unofficially it?
<RAOF> soreau: This is where everyone who can upload to xorg-edgers hangs out, yes.
<soreau> If I am reading the site correctly, xorg-edgers only packages the core wayland library, no compositors or clients?
<mlankhorst> we only use it to satisfy mesa build-depends afaict
<mlankhorst> Sarvatt: ^
<soreau> ah..
<soreau> ok thanks
<Sarvatt> weston is in there too
<soreau> Sarvatt: What branch does it build wayland and weston from, master?
<Sarvatt> yup
<soreau> and still doesn't install weston clients since they're not installed by weston build system
<Sarvatt> i have no clue what its installing these days, ricotz does that
 * soreau now sees weston listed after clicking the next button on the website
<soreau> Sarvatt: thanks
<Sarvatt> list of all the files it installs are at the end of https://launchpadlibrarian.net/121088081/buildlog_ubuntu-raring-amd64.weston_1.0.0%2Bgit20121025.00fbbe6b-0ubuntu0ricotz_BUILDING.txt.gz
<soreau> Is there a page that shows the build status of all the packages?
<Sarvatt> https://launchpad.net/~xorg-edgers/+archive/ppa/+builds?build_text=&build_state=all
<soreau> Sarvatt: cool
<Dandel> Sarvatt: is there a possibility of readding libwaffle to the piglit requirements on quantinal, also, i think there might be a build failure in the works.
<tjaalton> RAOF: oh, indeed it does
<tjaalton> Sarvatt: do you have mesa master in edgers? if yes, any surprises in the packaging?
<mlankhorst> ohai new steam update
<mlankhorst> guess first time steam loaded succesfully here \o/
<mlankhorst> I'll play some more games later, found a nice way to reduce cpu use on nouveau
<tjaalton> bryce: the bug-graphs for released versions don't seem to update?
<mlankhorst> I think that's on purpose
<tjaalton> me too, but I like them :)
<bryce> tjaalton, it's on purpose, but I also would prefer if they kept updating.  Some day when I get time I'll investigate why they don't.
<soreau> Hey guys, is there a webcam program that doesn't suck? Trying cheese here, can't even figure out how to get out of fullscreen :P
<mlankhorst> wrong channel for that
<soreau> hahaha
<soreau> you are right below my luser ubuntu channel
<soreau> wrong click
<soreau> but just for the record, cheese is kinda cheesy
<soreau> mlankhorst: thanks for the reminder ;)
<mlankhorst> np
<tjaalton> bryce: ah, thanks
<Dandel> RAOF: i spotted a minor patch that might be worth pulling in and testing on the piglit packaging... care to take a look?
<tjaalton> bryce: hum, the quantal xserver has the broken barrier commit in it
<tjaalton> that you pushed
<bryce> tjaalton, oh dear did I break the non-functional multihead on nexus7?
<tjaalton> well did you upload it to quantal ?-)
<tjaalton> the branch looks like it
<tjaalton> just a warning..
<bryce> tjaalton, nope, just to the ppa
<tjaalton> which ppa?
<tjaalton> ubuntu-quantal, not ubuntu-quantal-nexus7
<mlankhorst> RAOF: bug bug llvm-3.1 ;P
<RAOF> mlankhorst: Thanks for the ping :)
<mlankhorst> also might do a new xorg upload for precise soon
<mlankhorst> but that could be part of the entire rename x push
<tjaalton> bryce: just verifying; you didn't upload xserver ubuntu-quantal branch to quantal-proposed, but somewhere else?
<bryce> tjaalton, no I did not upload it
<tjaalton> ok good, then it should be marked back UNRELEASED?
<bryce> well let's see
<tjaalton> because it needs the revert from raring
<bryce> yep, you're right.
<mlankhorst> but I think the lts stack is mostly ready for upload now, so when llvm-3.1 is ready I should be able to do a massive upload to precise after doing 1 more verification
<tjaalton> not sure how much mesa/llvmpipe actually 'needs' the latest llvm..
<tjaalton> but less work to have it
<tjaalton> there
<mlankhorst> tjaalton: It's completely untested on the old stack, and later mesa's will probably run into more and more troubles as you try it..
<bryce> tjaalton, ah actually what I pushed to the tree *was* uploaded 5 days ago.  I'm guessing when we caught the original problem we pulled the package from -proposed (at least, it's not there now)
<mlankhorst> s/stack/llvm/
<tjaalton> bryce: oh ok :)
<bryce> tjaalton, I'm guessing you fixed only the raring upload, not the quantal one?
<tjaalton> didn't know that existed
<bryce> yeah, was mentioned on bug 1069031
<ubottu> Launchpad bug 1069031 in X.Org X server "intel gma3600: X unable to start" [Undecided,New] https://launchpad.net/bugs/1069031
<tjaalton> ah, yeah missed that one
<tjaalton> I can fix it tomorrow and push 6.2
<tjaalton> no, 6.1
<tjaalton> can reuse the version since it didn't get through
<bryce> actually...
<bryce> wow, this is interesting
<tjaalton> uploaded -intel 2.20.13 btw
<bryce> looks like you'd attempted a 6.1 upload last month, and it got rejected
<tjaalton> on purpose
<tjaalton> it's a bad number :)
<bryce> so... maybe the reason I'm not seeing my 6.1 upload didn't show up was because that earlier upload already used up 6.1?
<tjaalton> no, it got dropped before it went past the queue
<bryce> bad as in cursed?  ;-)
<tjaalton> something like that..
<bryce> anyway, sure thanks for taking care of it.  :-)
<tjaalton> the reason was that it had some extra cruft on it that I had on the tree (git status ftw)
<tjaalton> and also one of the patches was a bit so-so, but confirmed later on
<tjaalton> so with the revert added it should be good
<bryce> I've a feeling that patch 237 may be an important one to fix up more input rotation hijinks, but couldn't verify it beyond the vm use case mentioned in the bug
<tjaalton> oh there it is
<tjaalton> also, now that the xserver patches have been divided into categories, it's time to drop the nonsense numbers, at least from new patches :)
<tjaalton> altogether when doing 1.14
<tjaalton> hoping that we'd be able to drop most by then
<bryce> hmm, I still find the numbers handy personally but whatever
<mlankhorst> the numbers, what do they mean ;)
<tjaalton> they make it easier to refer to a patch, but then again the numbers are getting reused..
<bryce> true, noticing that a bit with some SRUs.  Of course, this won't fix that
<bryce> well, not right away.
<tjaalton> yeah it'll take some time
<tjaalton> maybe start the no-number scheme with 1.14
<tjaalton> and use whatever for 1.13
<tjaalton> anyway, night all
#ubuntu-x 2012-11-22
<bryce> cya
<mlankhorst> woops, broke switching back
<jcristau> fyi http://bugs.debian.org/693158 may be somewhat relevant to ubuntu as well
<ubottu> Debian bug 693158 in xserver-xorg-input-penmount "Xorg: symbol lookup error: ...penmount_drv.so: undefined symbol: xf86XInputSetScreen" [Grave,Open]
<mlankhorst> proof that nobody uses it? :-)
<tjaalton> bah
<mlankhorst> hm maybe we use a newer version
<mlankhorst> oh we don't
<mlankhorst> tjaalton: hey can we drop penmount from universe? :>
<tjaalton> sounds like a plan
<mlankhorst> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-penmount/+bug/1082015 weee
<ubottu> Launchpad bug 1082015 in xserver-xorg-input-penmount (Ubuntu Raring) "please remove xserver-xorg-input-penmount from universe" [Undecided,New]
<Dandel> Sarvatt and RAOF: I spotted a code merge for piglit that enables EGL, opengl es1 and opengl es2 tests.
<mlankhorst> waffle one?
<Dandel> mlankhorst: yes, waffle is required for opengl es 1/2 tests ( and to use egl w/ opengl on piglit )
<Dandel> and there's a missing environmental variable... PIGLIT_SOURCE_DIR needs to be set ( most likely to /usr/share/piglit/ )
<mlankhorst> tjaalton: hm can I add recommends xserver-xorg-{video,input}-all, libgl1-mesa-glx to xserver-xorg ?
<mlankhorst> should make stack switching slightly more robust
<mlankhorst> I fear that may end up installing xserver-xorg-(input,video)-all again on machines that previously removed them, though..
<tjaalton> yeah i think it'd have some side-effects..
<mlankhorst> I'll try without..
<spindritf> hey, how do I view and change my font path? I want programs to search ~/.fonts first and /usr/share/fonts later
<spindritf> is that up to X? 
<mlankhorst> guessing fontconfig cares
<mlankhorst> tjaalton: can we recommend xserver-xorg-input-all at least?
<tjaalton> mlankhorst: i'm not sure, and not able to check now what issues it might have
<mlankhorst> ok :/
<mlankhorst> well in the worst case switching back will only leave you with evdev then..
<tjaalton> do you have a dl for the stack?
<mlankhorst> it's in my experimental ppa
<mlankhorst> but still testing a little
<mlankhorst> maybe things clear up if I re-add the conflicts/replaces to itself back in *-all
<tjaalton> so no immediate deadline then. i should be able to test it tomorrow
<tjaalton> the up/downgrade
<mlankhorst> it's still broken on -dev packages though
<bjsnider> phoronix headline: AMD's New Catalyst Linux Driver Isn't Too Good
<mlankhorst> I don't think amd has to worry about catalyst drivers being too good
<MCR1> mlankhorst: Stupid fglrx makes it impossible to operate 3 monitors, while open-source gallium has no problem with it...
<MCR1> grmpf
<mlankhorst> tjaalton: forward switching should be ok though, still seem to hit some bug with multiarch
<mlankhorst> apt-get install xserver-xorg-lts-quantal libgl1-mesa-glx-lts-quantal:i386
<mlankhorst> works around it
<Dandel> MCR1: that's not a issue.
<MCR1> Dandel: ?
<Dandel> MCR1: just add "Virtual   4096 4096" to the display subsection
<Dandel> where the other lines are "viewport 0 0" and "depth 24"
<Dandel> MCR1: use xrandr
<MCR1> I need more than 4096x4096
<Dandel> it's so xrandr plays nicely with hotplugging
<Dandel> try higher, but my experience was not good
<MCR1> I need 1920+1280+1920 in x axis
<MCR1> and in that case fglrx fails with not enough vram error or something like that
<MCR1> which is ofc not true
<Dandel> care to give me the system information?
<Dandel> I know how to get the bug report to the right people
<MCR1> ATI HD 5750, Quantal, latest AMD fglrx beta
<Dandel> build id?
<MCR1> one moment
<MCR1> 9.01-121018a-148746E-ATI
<MCR1> Driver Packaging Version ^^
<Dandel> k... care to get the output from? /usr/share/fglrx/atigetsysteminfo.sh
<Dandel> that will need a pastebin tho
<Dandel> it'll output to a text file ~/atisysteminfo-report.txt
<MCR1> grmpf, it is too long for pastebin.com
<Dandel> compress it and file a launchpad report with the file?
<MCR1> Dandel: Got it now (pastebin.ubuntu.com): http://pastebin.ubuntu.com/1377782/
<Dandel> thanks
<MCR1> thanks to you - would be great to have 3 monitors running with fglrx also...
<Dandel> MCR1: i think i see the issue.
<Dandel> you need 3 seperate screens? or just one large one?
<Dandel> MCR1: that configuration is mangled.
<MCR1> 3 separate ones... combined to one big desktop, not mirrored
<Dandel> do you mind fixing it using xrandr?
<bjsnider> MCR1, you have to admit that 3 monitors is really, really, really difficult for them
<Dandel> http://pastebin.ubuntu.com/1377815/ - try th is for a second.
<Dandel> don't expect immediate fix, because you will need to open up xrandr and move the screen around and disable mirror
<Dandel> for now, set the 1920x1200 at point (0,0), the 1280x1024 at point (0,1200), and the 1920x1080 at the point (1920,1080).
<Dandel> or if that's hard... two commands: "xrandr --output DFP2 --right-of DFP4" and "xrandr --output CRT2 --below DFP4"
<Dandel> if that gives you big desktop, but setup a little odd, it's ok... the next test is to change the virtual size once more.
<Dandel> change "Virtual   4096 4096" to "Virtual   6144 6144" then just move the crt and dfp to the positions you desire.
<MCR1> Dandel: Thanks a lot for your suggestions and help - I'll try to do that :) Great !
<MCR1> Do you think it would be possible to make a 3-screen horizontal config also ?
<Dandel> yes.
<Dandel> just apply the change i mentioned about a half hour ago.
<Dandel> and then use xrandr to move displays around
<Dandel> it's mainly the use of the command: xrandr --output "Display to be effected" (--left-of, --right-of, --above, --bellow) "display to anchor by"
<Dandel> although, i also know that the gnome monitor preferences ( or mate monitor preferences ) should do a great job also.
<Dandel> since what this did is fix the built in desktop manager screen configuration utility on the system... what happens is the login screen will most likely get mirrored, but once you login, the setting will reapply.
<Dandel> ricotz: would it be possible to update libwaffle from 1.1.0 to 1.2.0?
<MCR1> Dandel: I am sorry for my slow responses, but I was attending a meeting on #ubuntu-desktop - Once again, thanks a lot 4 your help - It is highly appreciated. I will try and report success or failure to you in the next days...
<MCR1> bjsnider: Fact is that AMD/ATI advertise their cards for 3-monitor usage and it works with gallium... But maybe I get it to work with fglrx also, thanks to the help of Dandel... I hope so at least as I wanna watch movies on my TV ;)
<Dandel> bjsnider and MCR1, amd actually advertises support for up to 6 monitors on a single card, but many cards can only can handle up to 3
<mlankhorst> You don' t get what 'up to' means then
<ricotz> Dandel, i guess i can do
<ricotz> 1.2.1 that is?
<Dandel> 1.2.1 works... it's mainly to get the latest fixes ( including the opengl es 3 support )
<MCR1> \o/ OpenGL ES 3
<ricotz> Dandel, pushed it to the ppa, but precise will probably fail
<Dandel> it should work just fine due to the fact that the last piglit worked fine.
<ricotz> (due missing cmake multiarch support in precise debhelper)
<Dandel> cmake in precise needs a blanket upgrade anyways
<ricotz> Dandel, is there any care for the oneiric/lucid builds in there?
<Dandel> the debian build using cmake is broken
<Dandel> it generates packages that can't be installed
<ricotz> i see
 * ricotz meants to delete the oneiric/lucid packages there
<Dandel> oneiric and lucid, i don't care about... i have one machine using precise, the other using ocelot ( or w/e 12.10 is called )
<ricotz> quantal ;)
<Dandel> actually, i just had to reinstall on the other machine because grub upgrade balked ><;
<Dandel> 10.04.1 ( lts) to 12.04.1 (lts) broke grub and i had to rework the install from scratch.
<MCR1> urgh
<Dandel> nothing like a grub 2 install without any modules :/
<Dandel> MCR1: if fglrx crashes with the 8192x8192, it's because of driver bug ( it fails on the hd6520G i have )
<Dandel> that's part of why i suggested 4096x4096 initially since that did not crash the test machine i use.
<MCR1> Dandel: I do not have the energy today anymore to try and fix if it fails, so I'll try tomorrow... but IIRC it crashed last time I tried 8192x8192 with some not enough videomem error
<Dandel> MCR1: your config was weird
<MCR1> yeah, something went wrong during last update I guess, but I did not look at it in detail before, because my 2-screen config was working perfectly - so I did not even know that it was bortched
<MCR1> but I could not change config by disabling one monitor and enabling the TV instead via AMDCCC anymore, I guess the weird config was causing this
<MCR1> so I still see a chance in your suggestions and will try to apply them ;)
<MCR1> Does Virtual always need the same x and y to work ?
<MCR1> Or is something like "8192 2048" also valid ?
<Dandel> should work
<Dandel> but it'd limit the screen orientation changes
<MCR1> I do not need to change orientation never, so I would not care
<Dandel> then it should be fine.
<MCR1> thx again - I'll promise to report the outcome ;)
<MCR1> afk
<bjsnider> ricotz, pkg-config tool not found
<bjsnider> on that waffle build
<bjsnider> MCR1, why not use radeon instead of fglrx?
<ricotz> bjsnider, i know
<MCR1> bjsnider: Used gallium, was very satisfied and it was very stable, had no problems with 3 monitor-config, had a much smoother 2d-scrolling in chromium, no gfx-error with docky, but 3d performance was not comparable and unfortunately weak... I have a quite fast card with lots of fast DDR-5 VRAM and I expect it to max out Compiz framerate on 3 screens, which it wasn't capable of...
<bjsnider> it's an exapnsion card?
<MCR1> bjsnider: ?
<bjsnider> is the gpu built into the board or is it plugged into the mainboard
<MCR1> ATI HD 5750 PCI-E
<MCR1> plugged-in
<bjsnider> i don't understand why you bought an amd card in the first place
<MCR1> 3 screens ?
<bjsnider> why not nvidia?
<MCR1> not possible with nvidia 1 card
<bjsnider> sure it isn't
<MCR1> and at the time this card offered a good value for the price and was 40 nm GPU tech
<MCR1> and DDR5, while Nvidia was still using DDR3
<MCR1> other computer uses GTX-570-448 cores...
<Dandel> ricotz: there's a pull request for piglit packing that has had 1 approval, and just needs some review... mind looking at it?
<ricotz> Dandel, seems fine
<Dandel> the only other thing i can see is the missing opencl libs being an issue the stock repo for precise. ( i know there's a backport request for it
#ubuntu-x 2012-11-23
<tjaalton> whee, xserver 1.13.0.901
<mlankhorst> \o/
<tjaalton> merging
<tjaalton> mlankhorst: did you have some pet-patches from fedora to include? I see they disable building acpi support
<tjaalton> "no good can come of this." :)
<tjaalton> http://pkgs.fedoraproject.org/cgit/xorg-x11-server.git/tree/?h=f18
<tjaalton> some are included in .901
<tjaalton> pushed the branches
<tjaalton> didn't see anything of interest on the fedora tree
<mlankhorst> tjaalton: well sounds ok, would have to check with intel though if they still use it in their driver or not
<mlankhorst> tjaalton: well just disable it for raring should be ok
<tjaalton> ffs, we have an ancient plymouth
<mlankhorst> yeah
<tjaalton> maintained in bzr -> pass
<mlankhorst> the only thing I can do in bzr is bzr pull push and diff :P
<mlankhorst> maybe I should check out bzr-git
<tjaalton> maybe they'll merge it after moving a bunch of bugs against it
<tjaalton> where booting sometimes fails
<mlankhorst> we'll see :-)
<mlankhorst> brb
<Dandel> ricotz: i saw the build failure for piglit daily... it's a minor fix... just update eglext.h since it's a build change but not runtime.
<mlankhorst> tseliot: I can confirm I can't see any package on experimental stack right now at least ;P
<mlankhorst> just nouveau, which it claims is not enabled
<mlankhorst> hm might be right about that, too!
<tseliot> mlankhorst: you will see some drivers when they are approved in -proposed ;)
<mlankhorst> tseliot: how does it recognise nouveau?
<mlankhorst> bryce: what happened to turning off spam to ubuntu-x-swat? :P
<bryce> mlankhorst, now you can just unsub from the mailing list if you don't want it.
<mlankhorst> ah k
<mlankhorst> btw vdec kernel changes are heading upstream, still working on the ttm changes :P
<tseliot> mlankhorst: I don't think it should
<mlankhorst> oh kmod:nouveau
<Dandel> mlankhorst: what steps would it take to request the update of two files in 12.04 lts and then 12.10? ( namely /usr/lib/GL/glext.h and /usr/lib/EGL/eglext.h )
<mlankhorst> usr/lib ?
<Dandel> */usr/include
<mlankhorst> see stablereleaseupdates
<Dandel> i see... i haven't seen any problems with running programs by simply dropping in the latest eglext.h and glext.h... however, i *do* see problems with compiling programs at times if these get out of date
<mlankhorst> Dandel: we can't generally update those though..
<Dandel> i see.
<mlankhorst> but it Å standardized so having a duplicate in your program shouldn't be hard or conflict
#ubuntu-x 2012-11-24
<FernandoMiguel> hi
<FernandoMiguel> [   41.648651] gnome-settings-[1756]: segfault at 101 ip 00007f2485fe4046 sp 00007ffff3369710 error 4 in libmedia-keys.so[7f2485fd7000+25000]
<FernandoMiguel> [ 8114.663134] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
<FernandoMiguel> [ 8114.663140] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state
<FernandoMiguel> I'm seeing my system with 13.04 freezing a lot today
<FernandoMiguel> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1082544
<ubottu> Launchpad bug 1082544 in unity (Ubuntu) "*ERROR* Hangcheck timer elapsed... GPU hung" [Undecided,New]
<soreau> when creating source deb packages, is bzr a required tool?
<bjsnider> soreno
<bjsnider> soreau, no
<bjsnider> bzr-builddeb is sometimes used
<soreau> bjsnider: I was reading this here http://developer.ubuntu.com/packaging/html/packaging-new-software.html but the method seems to heavily rely on bzr commands
<soreau> do you need some form of revision control tool? Could you use git for example?
<bjsnider> it's just nice to be able to publish the packaging code on lp and you use bzr for that
<soreau> I'm somewhat confused by bzr involved in the building process
<bjsnider> dh-make will give you the basics
<bjsnider> how far have you gotten?
<bjsnider> soreau, how far have you gotten?
<soreau> bjsnider: just trying to read about how to build a ppa.. wondering about how mesa has several packages from the one upstream repo, can you just package a single package and have it conflict with all the typical ones or what?
<bjsnider> you can have a package conflict with anything you want
<bjsnider> normally we would put some thought into the matter
#ubuntu-x 2012-11-25
<soreau> can you have your package conflict with all packages in another ppa?
<penguin42> is it ever legal for a client to add a resource of type 0?
<penguin42> (which I realise might be a question of an x-spec lawyer)
<bjsnider> penguin42, yes, there are several hundred people behind bars in turkey for such offenses
<bjsnider> soreau, i don't see how
<soreau> bjsnider: ok thanks
 * penguin42 looks at bjsnider curiously
<penguin42> bjsnider: I'm looking at bug 1060059, I've got a 'fix' for it, but I was trying to understand whether the fix was the correct one
<ubottu> Launchpad bug 1060059 in xorg-server (Ubuntu Quantal) "Xorg crashed with SIGABRT in ResFindAllRes()" [High,Triaged] https://launchpad.net/bugs/1060059
<bjsnider> musta been the way you axed the question
<penguin42> bjsnider: The bug is being triggered because there is a resource of type 0, and the XRes code doesn't handle the case; trivial to stop the xres code falling over, but it's not clear to me if that should ever happen
<penguin42> bjsnider: I've added debug and I can see that AddResource is being called with a type of 0, and I just wanted to know whether that should ever happen
<penguin42> it certainly seems odd
<stigarn> hi sorry for the newbie question but how do I install the latest amd drivers after adding the ppa?
<Dandel> tormod: i saw your comments on the piglit packing update... along with a few other updates.
<tormod> hi Dandel
<Dandel> it appears the rapid development of piglit is what caused the issue ( since the build failure is directly linked to a commit made on the 20th )
<tormod> yeah, so does it require latest of everything to build now?
<Dandel> yes
<Dandel> the last 3 commits depend on this change.
<Dandel> http://cgit.freedesktop.org/piglit/log/tests/egl/spec/egl_khr_create_context
<Dandel> so any revision before that would have worked just fine
<tormod> btw are you Ken?
<tormod> do you think it would be possible to fix piglit upstream so that it builds against whatever is available?
<tormod> i.e. #ifdef EGL_OPENGL_ES3_BIT_KHR sprinkled around?
<Dandel> look at latest message on the bug report.
<Dandel> it actually points to a simple fix
<Dandel> http://bazaar.launchpad.net/~kphillisjr/piglit/trunk/revision/3391
<tormod> aha, that's possibly where I had that idea from :) Is the first hunk meant to be there?
<Dandel> dunno.
<Dandel> bzr is alien to me... i prefer git.
#ubuntu-x 2013-11-19
<Prf_Jakob> Have the xorg-pkg-tools repos been updated for a recent mesa master?
<Prf_Jakob> Hmm is git://git.debian.org down?
<jcristau> yes
<jcristau> https://lists.debian.org/debian-infrastructure-announce/2013/11/msg00001.html
<jcristau> it will hopefully be back later today, they're working on restoring stuff
<Prf_Jakob> ok thanks
<Prf_Jakob> And to go back to the first question, you guys haven't updated the xorg-pkg-tools for mesa-git recently?
<tjaalton> that's some edgers thing?
#ubuntu-x 2013-11-20
<mlankhorst> Prf_Jakob: well doesn't seem like it has been updated
<Prf_Jakob> mlankhorst: okay thanks
#ubuntu-x 2013-11-21
<tjaalton> [   729.814] (EE) Server terminated successfully (0). Closing log file.
<tjaalton> that seems to trigger apport..
<mlankhorst> erm it shouldn't?
<tjaalton> hmm maybe not that
<tjaalton> probably
<tjaalton> i see it locally too :)
<tjaalton> anyway, closed bug 1250017..
<ubottu> bug 1250017 in xorg (Ubuntu) "........" [Undecided,Invalid] https://launchpad.net/bugs/1250017
<tjaalton> meh, alioth ssh keys changed?
<tjaalton> yep
<tjaalton> updated -intel, didn't push yet
<tjaalton> to trusty
#ubuntu-x 2013-11-22
<ricotz> mlankhorst, hi :), are there (precise) packages for wine 1.6.1 yet?
<mlankhorst> ricotz: erm scott ritchie does those
<ricotz> mlankhorst, ok, thanks, since you are involved too, i was hoping you had uploaded it somewhere already -- haven't found it on launchpad though
<ali1234> i've got a question about RetainPermanent and the various atoms used to signal the existence of such on the root window pixmap
<ali1234> first: there's a bunch of different ones: XSETROOT, XROOTPMAP, ESETROOT_PIXMAP_ID, _XROOTPMAP_ID... any more?
<ali1234> second: how do these pixmaps get freed? if i set and change the background image using one of these tools, it's going to keep allocating new RetainPermanent pixmaps. how are they supposed to get deallocated?
<ali1234> RAOF: in my searching on this topic i saw you discussing RetainPermanent in relation to unity-greeter. can you tell me anything about this stuff? i'm hacking on lightdm-gtk-greeter for xubuntu
<ali1234> it looks like unity-greeter defines RetainPermanent but doesn't use it. so how does the wallpaper handoff happen between unity-greeter -> compiz?
<mlankhorst> ali1234: no idea, magic? :>
<ali1234> well all this RetainPermanent stuff sure feels like magic
<mlankhorst> I guess until compiz starts compositing the old image will exist
<mlankhorst> because nothing new has been drawn to it yet
<ali1234> the problem we have is xfwm starts compositing with a empty grey buffer, and there's a delay before the app that draws the wallpaper starts up
<ali1234> xfwm can read the RetainPermanent background at startup to avoid this, but the whole thing seems incredibly bad with magic atoms and unmanaged buffers...
<mlankhorst> I think you can just read out the uncomposited buffer before starting to composite
<mlankhorst> or at least delay drawing until you have a background
<mlankhorst> but I haven't put much thought since I mstly worry about driver issues ;)
<ali1234> speaking of driver issues, why does nouveau corrupt the hell out of the display when using RetainPermanent pixmaps?
<ali1234> "oh, you wanted your wallpaper? here's some windows that were on your screen earlier today"
<ali1234> i think "read out the uncomposited buffer" is what compiz does, that's probably going to be our best option
<mlankhorst> I guess it uses random vram memory with nothing drawn to it yet
<mlankhorst> which happens to match window contents in some cases
#ubuntu-x 2013-11-24
<lfaraone> So I'm trying to debug launchpad bug 1246384 , which I encountered on doing an upgrade from 12.04 with HWE to trusty. The issue is that it appears that /usr/lib/xorg/protocol.txt was updated by another package after it was diverted, and when the diverting package is removed it attempts to undivert. 
<ubottu> Launchpad bug 1246384 in xorg-server-lts-raring (Ubuntu) "xserver-common-lts-raring does not always get correctly removed." [High,Confirmed] https://launchpad.net/bugs/1246384
<lfaraone> Is that perhaps because a newer xorg package was Replaces: xorg-server-lts-raring and overwrote the file without checking if it was diverted?
<tomreyn> flash player tells me this - should i care, and is this file packaged in a PPA?
<tomreyn> Failed to open VDPAU backend libvdpau_r300.so: cannot open shared object file: No such file or directory
<tomreyn> the filename search on packages.ubuntu.com doesn't know about it
#ubuntu-x 2014-11-19
<jderose> ricotz: where is the debian/ branch for the 364.16 xorg-edgers package? 
<jderose> also, wanted to draw more attention to this - https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-331/+bug/1394348
<ubottu> Launchpad bug 1394348 in nvidia-graphics-drivers-331 (Ubuntu) "nvidia-331.postrm calls `stop nvidia-persistenced`, but upstart job has been removed" [Undecided,New]
<jderose> i know there were tons of apport crash reports about that, but not being able to remove a package is "very bad (TM)", and the fix is seemingly easy :)
#ubuntu-x 2014-11-20
<Sarvatt> ricotz: hmm so libegl1-mesa-drivers and libopenvg1-mesa are gone in that newest mesa update? its trying to remove the world here because of it
<ricotz> Sarvatt, yes, some funny upstream changes which even are in 10.4 -- http://cgit.freedesktop.org/mesa/mesa/commit/?h=10.4&id=c46c551c56f78c6bf9e63524c89478695fc4f525
<ricotz> so libopenvg1-* should reappear if it possible again
<ricotz> i mean OpenVG support
<Sarvatt> libcogl15 depends on libegl1-mesa-drivers directly :(
<ricotz> hmm, so trusty :\
<ricotz> so better add an empty package and hoping the best
<Sarvatt> or uploading libcogl to the ppa with the dependency dropped, looking like thats the only thing so far
<ricotz> i would prefer an empty transitioning package
<ricotz> will take a look later
<mlankhorst> Sarvatt: yeah it's removed
<mlankhorst>  openvg no longer exists in 10.4 iirc
<ricotz> mlankhorst, are you going to pick up 10.4rc1 for vivid?
<tjaalton> and then 10.5 hopefully
<ricotz> ;)
<mlankhorst> hm is it out yet?
<tjaalton> since tuesday it seems
#ubuntu-x 2014-11-22
<codygarver> hi, does anyone know if/when xorg intel driver 2.99.914 will get backported to trusty? my distro, elementary OS, needs the fix from https://bugzilla.redhat.com/show_bug.cgi?id=1133142
<ubottu> bugzilla.redhat.com bug 1133142 in xorg-x11-drv-intel "Wrong shadows on CSD windows when SNA is enabled" [Unspecified,Closed: errata]
#ubuntu-x 2015-11-17
<tseliot> ricotz, mamarley: hey guys, just a heads up. I'm going to upload new nvidia drivers in xenial this morning (in an hour or so), so you might want to reuse my tarballs instead of uploading your own
<mamarley> tseliot: Sure, will do.
<tseliot> it should all be in xenial-proposed now
<mamarley> tseliot: Which versions are they?   I get "no current release" for https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-358 and https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-355.
<tseliot> mamarley: 352, 340, 304
<tseliot> only LTS releases in Ubuntu, that's my policy ;)
<mamarley> Ah, OK.  We have those versions in the PPA too, but the ones you uploaded have a higher version number, so ours won't get installed.  Did you want us to re-upload them now based of what you did, or just the next time there is a release?
<mamarley> Also, is there anything we need to do for 355 or 358?
<mamarley> (Sorry for all the questions; I just want to make sure that I don't screw up and do something wrong like I have repeatedly in the past.)
<tseliot> mamarley: I think nvidia-352 and nvidia-358 are different packages, so they can all be installed, unless you use transitional packages to migrate users from one to the other
<tseliot> mamarley: sorry, I misread
<tseliot> mamarley: my original point was, if you need to make changes to the latest 352, etc. you can use my new packages as a base. No need to upload a new tarball
<mamarley> OK, sure.  Thanks!
<tseliot> mamarley: as for 358, I haven't looked into that yet but, if that one needs device nodes to be created with specific permissions, I posted an update on what I plan to do here: https://bugs.launchpad.net/ubuntu/+source/nvidia-modprobe/+bug/1421209
<ubottu> Launchpad bug 1421209 in nvidia-modprobe (Ubuntu) "[MIR] nvidia-modprobe" [Undecided,Won't fix]
<mamarley> tseliot: It just needs to have the nvidia-modeset module loaded automatically before X starts, nothing more.
<tseliot> mamarley: ok, that's easy to do
<ricotz> tseliot, will take a look in the evening
 * ricotz notes there is a "working" 358 in the ppa
<mamarley> ricotz: How did you have it load nvidia-modeset?
<ricotz> with a hacky udev rules
<mamarley> Ah, OK.
<mamarley> Looks like 352.63 and 340.96 have been released.  I will begin working on those right away and should have something ready before lunch (it is early morning here right now).
<ricotz> mamarley, this is what tseliot was talking about!
<ricotz> and to reuse the uploaded tarballs of him
<ricotz> tseliot, btw due to the internal module dependency it should just work while loading nvidia_modeset as default/main module (instead of nvidia)
<ricotz> g2g
<mamarley> *facepalm*  I completely misunderstood the initial message, sorry.
<mamarley> tseliot: Sorry, I thought you meant you had made packaging changes and to re-use those, but you actually meant to re-use the tarball.
 * mamarley beats himself with the clue-by-four.
<tseliot> :)
<tseliot> ricotz: right, I need to see if that breaks anything though
 * tseliot -> lunch
<mamarley> ricotz and/or tseliot (when you get back): I noticed that the packages were uploaded to Xenial as nvidia-graphics-drivers-yyy-updates, should I keep using the same name as before from the PPA or add "-updates"?
<ricotz> mamarley, there are nvidia-graphics-drivers-yyy uploads too (I am going to take a look in the evening)
<ricotz> currently busy with other things
<mamarley> Ah, OK.  Missed that, sorry.
<tseliot> yes, you don't need the -updates flavours
<mamarley> ricotz: OK, I have everything uploaded to https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages
<ricotz> mamarley, nice :), it still have to wait some time -- btw what is up with 304?
<mamarley> ricotz: Why does it have to wait?  I didn't realize anything was up with 304.
<ricotz> mamarley, because I want to take look at it first
<mamarley> Oh, OK, sorry.  What's up with 304?
<ricotz> there is a 304 relase too as mentioned earlier
<mamarley> Oh, I didn't even realize.  I will get on it.
<mamarley> Hmm, tseliot's amd64 build of 304.131 failed because execstack segfaulted.  That's odd...
<tseliot> mamarley: in the ppa or in proposed?
<mamarley> tseliot: proposed: https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-304/304.131-0ubuntu1/+build/8308471
<tseliot> mamarley: I'll try to rebuild it in my xenial chroot when it's done building some other stuff
<mamarley> ricotz: Done. :)
<tseliot> mamarley: it should be fixed in -0ubuntu2
<ricotz> mamarley, looks ok apart from some minor issues, will copy them over
#ubuntu-x 2015-11-18
<mamarley> Argh, 358.13 is out but I can't package it for the PPA because only the non-stripped x64 build is available, no 32 or ARM.
#ubuntu-x 2015-11-21
<mamarley> ricotz: 358.16 is ready in the usual location. :)
<ricotz> mamarley, great!
<mamarley> ricotz: Enjoying that GTX 970?
#ubuntu-x 2015-11-22
<mamarley> ricotz: Regarding the email from the guy about EGL in 355 and 358, I almost have that fixed and will have packages ready later today. :)
<mamarley> ricotz: The EGL-fixed 355 and 358 builds are up now.  It also looks like 340, 346, and 352 should have been setting the EGL alternative to /usr/lib/nvidia-xyz, since hardware-accelerated EGL/GLES doesn't work on those either.
#ubuntu-x 2016-11-21
<tjaalton> RAOF: hi, my unity8 session still just shows a blank screen, so can't test my mir egl patch refresh on new mesa.. any ideas how to get it work?
<tjaalton> jcastro: yeah, it doesn't need much actually. with some packaging changes it can use older llvm and libclc, but backporting those too isn't hard
<tjaalton> jcastro: and then there's libdrm of course
<tjaalton> jcastro: 16.10 has all that's needed though, backports needed only for 1604
<tseliot> mamarley: hi. Today I am going to fix up the nvidia drivers in zesty so that they build with the new kernel.
<mamarley> tseliot: Cool, thanks!  I already have 367 and 370 patched in the graphics-drivers PPA if you want to use those, and 375 doesn't need a patch.
<tseliot> mamarley: great, I'll have a look at those patches :)
<tseliot> and focus on 340
<mamarley> They are both exactly the same :)
<tseliot> good
<tseliot> mamarley: can you point me to the error you faced with 304, please? It might save some time
<mamarley> One secâ¦
<mamarley> tseliot: It is the same issue experienced by "ejmarkow" in https://devtalk.nvidia.com/default/topic/973807/linux/nvidia-linux-x86_64-340-98-driver-not-building-with-kernel-4-9-0-rc2-/ .
<tseliot> mamarley: ok, thanks
<ricotz> 304 or 340
<mamarley> ricotz: 340, though I haven't tested 304 so it may have the same problem too.
<mamarley> It looked like it might be trying to initialize the driver twice so I checked to see why that might be happening, but I don't know enough about kernel module programming so I couldn't figure anything out.
<mamarley> I have found that the Mesa 13.0.1 from the xorg-edgers PPA fixes the resource leaks and subsequent lagging caused by animated tray icons in KDE Plasma 5 while using the modesetting driver and Glamor.  This is nice, now I don't have to restart Plasma a bunch anymore!
#ubuntu-x 2016-11-23
<tseliot> mamarley: I patched 367 for linux 4.9, but it seems to break hybrid graphics. X starts but attaching the output fails, so I am left with a black screen. It could be an intel issue too. I'll have to debug this
<mamarley> :(
<mamarley> Any luck with 340?
<tseliot> not yet
<tseliot> as I haven't tried it yet
#ubuntu-x 2016-11-25
<tjaalton> tseliot: when nvidia releases drivers that can do driver abi for 1.19, feel free to add the Provides to zesty, debian is transitioning now, hope we could do that before xmas or shortly after
<tseliot> tjaalton: there seems to be one (375.20). It says "Added support for X.Org xserver ABI 23 (xorg-server 1.19)"
<tjaalton> yeah, are 304 and 340 the other two branches still alive?
<tseliot> alive, yes, updated for the new X, not yet
<tseliot> also I'll be off starting from December 8
<tseliot> (till January)
<tjaalton> ah
<tjaalton> ok, well xmir isn't ported yet either, so let's have another look next year :)
<tjaalton> I should take paternity leave at some point..
<tseliot> oh, ok
<mamarley> 375.20 is also afflicted with a rather severe bug the breaks many games and also breaks the KDE lockscreen (again, but in a different manner than 375.10 broke it).
<mamarley> https://devtalk.nvidia.com/default/topic/977518/linux/problems-with-multiple-opengl-applications-running-simultaneously-with-375-20-on-a-gtx970
<ricotz> tseliot, better keep it to 367 as newest series
<tseliot> ricotz, mamarley: oh, I had no idea. Hopefully things will be fixed next year
<mamarley> I hope it doesn't take them that long to fix itâ¦
<tseliot> also, I fixed up 367 for linux 4.9, but 340 is kind of hard to debug, as I can't get to the console, and I can't get the errors in the logs
<mamarley> Yeah, same problem I had.
#ubuntu-x 2017-11-24
<mamarley> ricotz: I noticed 387.34 was released.  I am handling it.  I am again "rebasing" on the 384 driver from the official archive because several relevant fixes have been made since the last 387 we uploaded.
<mamarley> (Don't worry, I am also getting rid of the transitional packages.)
<mamarley> OK the drivers are up in https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages as usual.  The source code for nvidia-settings hasn't been posted yet; I will package it when it is available.
<soee_> just wanted to mention this version is avi :D
<ricotz> mamarley, thank you!
<soee_> mamarley: could take a look: https://pastebin.com/3nD8MZFy ?
<soee_> lines 12-17
<soee_> hmm, maybe i forgot to reboot after kernel upgrade today
<soee_> anyway brb
<mamarley> soee: Yeah, that message is because you uninstalled 4.14.0 but were still running it.
<soee> soee: yup :)
<soee> mamarley: ^
#ubuntu-x 2017-11-25
<ricotz> mamarley, all your 387 packages still have transitionals expect bionic one
<mamarley> Oops, sorry, fixed.
<ricotz> mamarley, alright
#ubuntu-x 2018-11-21
<soee_> hiho
<soee_> https://i.imgur.com/7K18UWn.png as always thans for update :)
<mamarley> ricotz: That reminds me, I have new releases of 410 and 415 ready in https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages.
<mamarley> I also have a Linux 4.20 patch for 415 that should be easily adaptable to the older releases, but these packages do not contain it because I haven't run-tested it yet.  I will do that when 4.20-rc4 is released this Sunday.
<ricotz> mamarley, great, did you rebased the packaging to 410 in disco?
<ricotz> mamarley, ah still in new https://launchpad.net/ubuntu/disco/+queue
<mamarley> Sorry, I didn't see it in there.
<mamarley> ricotz: Should I rebase Disco, Cosmic, and Bionic or just Disco on the 410 from Disco.
<mamarley> s/./?
<ricotz> mamarley, depends on the changes which were made compare to the current ppa packaging
<mamarley> OK, I will check.
<ricotz> thanks
<mamarley> ricotz: It doesn't look like there are any Ubuntu-release-specific functional changes between what we have (which is the same for Bionic, Cosmic, and Disco) and the newly-uploaded 410 for Disco, so if you don't object I will just rebase all three.
<mamarley> (Also, no change was required to go from 410 to 415 besides renaming the packages.)
<ricotz> mamarley, good, please use the tarball in the queue
<mamarley> I will.
<mamarley> ricotz: OK, I rebased everything. :)
