#ubuntu-x 2006-12-04
<Ubugtu> New bug: #74327 in xorg "X crashes leaving fullscreen totem [feisty] " [Undecided,Unconfirmed]  http://launchpad.net/bugs/74327
<Ubugtu> New bug: #74341 in linux-restricted-modules-2.6.17 "fireglcontrolpanel crashed(core dump)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/74341
<Ubugtu> New bug: #70740 in emacs21 "emacs looses font when upgrading from 6.06 to 6.10" [Undecided,Unconfirmed]  http://launchpad.net/bugs/70740
<Ubugtu> New bug: #73602 in gv "gv crashes when run from `a2ps -Pdisplay ...`" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73602
<Ubugtu> New bug: #74023 in Fedora "Xorg does not start in dom0 with i810 driver" [Unknown,Confirmed]  http://launchpad.net/bugs/74023
<Ubugtu> New bug: #74399 in xserver-xorg-video-amd "gfx artifacts and low res on redcloud chipset" [Undecided,Unconfirmed]  http://launchpad.net/bugs/74399
<Ubugtu> New bug: #74292 in xserver-xorg-video-imstt "Error installing Firefox" [Undecided,Unconfirmed]  http://launchpad.net/bugs/74292
#ubuntu-x 2006-12-05
<Ubug2> New bug: #74453 in mesa-utils "glxinfo crash with beryl and update" [Undecided,Unconfirmed]  http://launchpad.net/bugs/74453
<Ubug2> New bug: #74479 in xserver-xorg-video-mga "[edgy regression]  random X server crashes" [Undecided,Unconfirmed]  http://launchpad.net/bugs/74479
* Starting logfile irclogs/ubuntu-x.log
* Starting logfile irclogs/ubuntu-x.log
* Starting logfile irclogs/ubuntu-x.log
<Ubugtu> New bug: #74487 in xorg-server (main) "keyboard no recognised at all after install edgy" [Undecided,Unconfirmed]  http://launchpad.net/bugs/74487
<Ubugtu> New bug: #74537 in Ubuntu "keyboard layout view not shown" [Undecided,Unconfirmed]  http://launchpad.net/bugs/74537
#ubuntu-x 2006-12-06
<Ubugtu> New bug: #74596 in Ubuntu "Duplicate files in /etc/X11/Xsession.d" [Undecided,Unconfirmed]  http://launchpad.net/bugs/74596
* Starting logfile irclogs/ubuntu-x.log
<Ubugtu> New bug: #69945 in linux-source-2.6.17 "should auto detect serial mice" [Undecided,Unconfirmed]  http://launchpad.net/bugs/69945
<Ubugtu> New bug: #74297 in xkeyboard-config (main) "Genius SlimStar 310 (GK-050010/C) keyboard layout missing" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/74297
#ubuntu-x 2006-12-07
<Ubugtu> New bug: #74751 in xserver-xorg-video-i810 "Multiple new issues with 855GM, Dapper -> Edgy" [Undecided,Unconfirmed]  http://launchpad.net/bugs/74751
<Ubugtu> New bug: #74771 in xorg "Feisty Fawn Herd 1 desktop iso boots to 1024x768, not 1280x800 on Acer Aspire 5601AWLMi" [Undecided,Unconfirmed]  http://launchpad.net/bugs/74771
#ubuntu-x 2006-12-08
<Ubugtu> New bug: #74948 in xserver-xorg-video-ati "Please include xv scaling patch from upstream GIT" [Undecided,Unconfirmed]  http://launchpad.net/bugs/74948
#ubuntu-x 2006-12-09
<Ubugtu> New bug: #75102 in xserver-xorg-video-nv "display flickering problem" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75102
<Ubugtu> New bug: #75121 in xserver-xorg-video-nv "vesa selected as default instead of nv on Feisty" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75121
<Ubugtu> New bug: #75146 in xorg "Upgrade to 1:7.1.1ubuntu6.2 breaks AGP / xinerama " [Undecided,Unconfirmed]  http://launchpad.net/bugs/75146
<Ubugtu> New bug: #75149 in xorg "Palm TX connecting on USB does not have consistent device name" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75149
#ubuntu-x 2006-12-10
<Ubugtu> New bug: #75257 in xserver-xorg-video-i810 "System hangs on X restart/logout on i945+amd64" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75257
#ubuntu-x 2007-12-03
<ubotu> New bug: #173458 in linux-restricted-modules-2.6.22 (restricted) "[Gutsy] video bug sometimes" [Undecided,New] https://launchpad.net/bugs/173458
<ubotu> New bug: #173350 in xorg (main) "Caps lock LED changes state even when caps lock is mapped to ctrl" [Undecided,Confirmed] https://launchpad.net/bugs/173350
<ubotu> New bug: #165025 in ubuntu "can't switch to a terminal in hardy (dup-of: 131751)" [Undecided,New] https://launchpad.net/bugs/165025
<ubotu> New bug: #173638 in linux-restricted-modules-2.6.22 (restricted) "[hardy alpha1]X with no window borders, no shortcuts, etc. after install of fglrx drivers" [Undecided,New] https://launchpad.net/bugs/173638
<ubotu> New bug: #173653 in xorg (main) "[hardy] xserver freezes regularly" [Undecided,New] https://launchpad.net/bugs/173653
<ubotu> New bug: #173663 in linux-restricted-modules-2.6.22 (restricted) "compiz will not launch with fglrx driver - falls back to metacity" [Undecided,New] https://launchpad.net/bugs/173663
<tjaalton> bryce: I'm back
<tjaalton> bryce: so far no ideas what to call the tools, but something neutral would probably be fine
<mvo> tjaalton: could we get libxf86misc-dev to the build-deps of x11-xserver-utils please? "xset q" does no longer give us the config path
<mvo> tjaalton: its important for compiz, I can do a ubuntu1 upload with that change if you want me to 
<mvo> tjaalton: what is the prefered workflow for fixes like this? I can't (obviously) commit to the debian git for the upload, so should I ignore the VCS here? or branch and give you a locaiton to merge my changes?
<tjaalton> mvo: I've committed that to git already, but you can upload a new version if it's needed quickly
<tjaalton> mvo: we are still learning how the workflow goes, but small changes like this can be done skipping the VCS, imho :)
<mvo> tjaalton: thanks! when is the next sync/upload planed? 
<tjaalton> mvo: no idea, I haven't asked
<mvo> ok, I think in this case I do a upload, thanks
<tjaalton> yeah, thanks
<tjaalton> btw, I added x11proto-xf86misc-dev to the build-deps, that should work right?
<mvo> tjaalton: I'm not really a X11 expert myself, but shouldn't that be libxxf86misc-dev? my understanding is that the x11proto-*-dev packages provide only the headers for the wirelevel protocol and not e.g. the libxf86misc shared lib  that libxxf86misc1 has
<tjaalton> mvo: hmm, could be.. upload whatever works and I'll check git later :)
<tjaalton> gone now ->
<mvo> tjaalton: ok, I will let you know what worked for me :)
<ubotu> New bug: #145887 in xorg "Gutsy Beta: Tablet Notebook's Stylus Not Working" [Low,Confirmed] https://launchpad.net/bugs/145887
<ubotu> New bug: #173685 in xorg (main) "xf86-video-ati Modeline and xvidtune problems" [Undecided,New] https://launchpad.net/bugs/173685
<bryce> heya tjaalton
<bryce> tjaalton: I went with xorg-pkg-tools.  I guess we can just rename later if there's any problems
<jcristau> tjaalton: x11-xserver-utils uploaded with the libxxf86misc fix
<jcristau> and accepted now
<ubotu> New bug: #117631 in xorg "Dell Optiplex GX50, Cannot Install From CD" [Undecided,New] https://launchpad.net/bugs/117631
<tjaalton> jcristau: wow thanks
<tjaalton> bryce: yeah that sounds good
<ubotu> New bug: #173776 in xorg (main) "Horizontal gray bars in display after last security update" [Undecided,Incomplete] https://launchpad.net/bugs/173776
#ubuntu-x 2007-12-04
<keescook> .... odd, nothing updates x or x drivers.  :P
<bryce> yeah I'm pondering what got updated
<tjaalton> probably just badly timed hardware failure ;)
<ubotu> New bug: #173814 in xorg (main) "no xorg.conf created on install of hardy alpha" [Undecided,Incomplete] https://launchpad.net/bugs/173814
<ubotu> New bug: #173833 in xserver-xorg-input-evdev (main) "evdev mouse fails on hardy: cannot open input pEvdev" [Undecided,New] https://launchpad.net/bugs/173833
<ubotu> New bug: #173012 in x11-xserver-utils (main) "Hardy alpha 1 wants to use compiz in vmware" [Undecided,Fix released] https://launchpad.net/bugs/173012
<ubotu> New bug: #173920 in xorg (main) "xorg 7.3 no font" [Undecided,New] https://launchpad.net/bugs/173920
<bryce> morning
<ubotu> New bug: #173959 in xorg (main) "X server ignoring FontPath directive" [Undecided,New] https://launchpad.net/bugs/173959
<jcristau> someone should tell 173959's reporter to use Option "UseDefaultFontPath" "false"
<bryce> will do
<ubotu> New bug: #163930 in xserver-xorg-video-via (main) "Video playback has messed up colour scheme (green lines appearing over the video) for multiple video players using .avi files" [Undecided,New] https://launchpad.net/bugs/163930
<ubotu> New bug: #96048 in xorg (main) "LiveCD boots in low res (SiS graphics card)" [Undecided,Fix released] https://launchpad.net/bugs/96048
<ubotu> New bug: #163482 in libxinerama (main) "Xinerama cursor problem in second monitor" [Undecided,New] https://launchpad.net/bugs/163482
<ubotu> New bug: #161106 in xorg (main) "Compiz runs slowly in a multiple user system" [Undecided,New] https://launchpad.net/bugs/161106
#ubuntu-x 2007-12-05
<ubotu> New bug: #102633 in xorg (main) "gnome / xserver doesn't start from live cd" [Undecided,Fix released] https://launchpad.net/bugs/102633
<ubotu> New bug: #105758 in xorg (main) "nVidia chipset install must use alternate disk" [Undecided,Fix released] https://launchpad.net/bugs/105758
<ubotu> New bug: #174042 in xorg (main) "Xorg does not properly detect and configure second monitor in Hardy Alpha 1 (Nvidia)" [Undecided,New] https://launchpad.net/bugs/174042
<tjaalton> wow, the post by david on debian-x is good stuff
<tjaalton> xresprobe going away \o/
<ubotu> New bug: #174120 in xserver-xorg-driver-nv (main) "No screen display with hardy/gutsy displays from gdm onwards" [Undecided,New] https://launchpad.net/bugs/174120
<ubotu> New bug: #165240 in linux-restricted-modules-2.6.22 (restricted) "mouse clicks fail after monitor powered off and back on" [Undecided,New] https://launchpad.net/bugs/165240
<ubotu> New bug: #164506 in compiz (main) "Memory usage = 100% with Visual Effects in Gutsy (dup-of: 151168)" [Undecided,New] https://launchpad.net/bugs/164506
<mvo> tjaalton, bryce: do you mind if I upload http://paste.ubuntu.com/2484/ ? it should fix the transition -driver-all to -video-all for dapper->hardy upgrades (currently people end up without -video-all)
<ubotu> New bug: #174171 in xserver-xorg-video-intel (main) "[hardy] xorg crash with "gdm_slave_xioerror_handler: Fatal X error - Restarting :0"" [Medium,New] https://launchpad.net/bugs/174171
<ubotu> New bug: #160658 in linux-restricted-modules-2.6.22 (restricted) "Using fglrx my computer is brought to a full stop if I log into an account, switch to an other and log out" [Undecided,New] https://launchpad.net/bugs/160658
<tjaalton> mvo: could it depend on -video-all?
<tjaalton> maybe not, since -video-all replaces -driver-all
<tjaalton> mvo: do you have a bug #?
<tjaalton> it's strange that people would be left without -video-all, if they have xserver-xorg installed
<ubotu> New bug: #160871 in xorg (main) "Screen resolution issues in Gutsy" [Undecided,Incomplete] https://launchpad.net/bugs/160871
<ubotu> New bug: #163222 in xorg (main) "windows have lines to the right" [Undecided,New] https://launchpad.net/bugs/163222
<tjaalton> bryce: currently the hardy live-session does not create an xorg.conf, because livecd-rootfs cleans the stub which is created on postinst
<tjaalton> sorry, preinst
<tjaalton> so when postinst is run it refuses to create xorg.conf
<bryce> hrm
<tjaalton> I haven't looked further how to fix that
 * tjaalton continues looking at xkeyboard-config bugs
<tjaalton> too bad that xkb-data is not in git.fd.o
<mvo> tjaalton: sorry, I don't have a bugnumber yet, but I can create a bugreport for you if you wantone
<tjaalton> mvo: ok, so it's your upgrade tests that had this issue?
<tjaalton> maybe a bug is not needed
<mvo> tjaalton: yes, but I'm pretty sure that its universal
<mvo> (i.e. not specific to my test environment)
<tjaalton> but wouldn't -video-all replace the old -driver-all?
<tjaalton> you did have -d-a installed in dapper?
<ubotu> New bug: #5740 in xkeyboard-config (main) "Problems with Apple keyboard" [Medium,Incomplete] https://launchpad.net/bugs/5740
<mvo> tjaalton: the resolver does not cope properly, the system ends up with a single xserver-xorg-video-amd instead of -video-all. I did have driver-all installed on dapper
<mvo> its a stock install without any changes basicly
<tjaalton> that's odd
<ubotu> New bug: #174214 in xorg (main) "[Hardy] xserver-xorg can't generate configuration file" [Undecided,New] https://launchpad.net/bugs/174214
<tjaalton> maybe something else triggers that
<tjaalton> if we added that metapackage, wouldn't we have the same problem with hardy+1?
<tjaalton> hmm, GlÃ¼hwein, bbl ->
<mvo> I don't have the resolver logs at hand currently, but what happens is that -video-all gets selected first for install, but because of all the conflicts it generates with the -driver-$foo it gets removed again
<mvo> haha - glÃ¼hwein :)
<mvo> xserver-xorg does not depend on -video-all, but on -video-1.0 | -video-all and so the user ends up with a single video driver that is enough to satisfy the depends
<mvo> tjaalton: I think for hardy->hardy+1 we are fine, because all the -driver-$foo conflicts with -video-$foo conflicts go away and its just a single transional package that is left
<mvo> I could hint this in the update-manager code and special case it, but I would prefer to solve it with dependencies so that people who are crazy^Wbrave enough to perform a apt-get dist-upgrade get the expected result too
<bryce> my crazy cat
<bryce> http://bryceharrington.org/Photos/Cats/i_cans_clean_gutters.jpg
<bryce> that's the neighbor's roof that I see out my office window.  They were having their gutters cleaned
<mvo> heh :)
 * mvo likes cats
<bryce> I regret teaching her how to climb ladders
<bryce> it'd be ok, but it's harder for cats to go down ladders than to go up
<ubotu> New bug: #89497 in xorg (main) "Language is faulty in the console" [Undecided,Incomplete] https://launchpad.net/bugs/89497
<ubotu> New bug: #107399 in xserver-xorg-video-intel (main) "Laptop screen turns on with lid closed when mouse is moved in feisty" [Low,Confirmed] https://launchpad.net/bugs/107399
<mvo> bryce: do you have a opinion on my proposed change? http://paste.ubuntu.com/2484/
<bryce> mvo, as long as it gets adequate testing, it looks good to me
<tormod> hi, ati 6.7.196-2 is in experimental. do we have to file a sync request to get it into Hardy then?
<bryce> I don't think experimental gets sync'd from automatically, so yeah
<tormod> ok filed bug #174235, please confirm (subscribe archive managers)
<ubotu> Launchpad bug 174235 in xserver-xorg-video-ati "please sync xserver-xorg-video-ati 1:6.7.196-2 from Debian experimental" [Undecided,New] https://launchpad.net/bugs/174235
<ubotu> New bug: #174235 in xserver-xorg-video-ati (main) "please sync xserver-xorg-video-ati 1:6.7.196-2 from Debian experimental" [Undecided,New] https://launchpad.net/bugs/174235
<tjaalton> mvo: ok, I see the point
<tjaalton> mvo: committed to my tree
<mvo> tjaalton: thanks! when do you plan the next upload?
<tjaalton> mvo: dunno.. maybe we'll get to drop xresprobe later this week, so perhaps then?
<tjaalton> but it's not that hard to do a release in the meantime
<mvo> tjaalton: thanks! it would be cool to have a upload before the weekend, but I'm happy to help you if you want me to
<tjaalton> mvo: ok, I'll see what I can do (tomorrow is a day off anyway, so I should have time)
<tjaalton> there's the "no xorg.conf" bug that should be fixed too
<mvo> thanks!
<mvo> I'm off to bed now too :)
<tjaalton> np:)
 * mvo waves
<tjaalton> bryce: do you know if we are supposed to get janitor mails for bugs that were autoclosed?
<bryce> yes we should
<bryce> in fact afaik the autoclosed ones were re-opened subsequently
<tjaalton> ok
<bryce> otoh, while I saw the decrease in the stats from the autocloses, I never saw a corresponding jump from reopens
<tjaalton> btw, I can't find the link to those stats from the wiki
<tjaalton> X wiki that is
<tjaalton> I have 15112 mails on my lp-x mailbox (since May 2nd), and that's without the restricted crap :)
<tjaalton> need to clean it up
<bryce> heh
<bryce> the links can be found via the Bug team's page, but I'll add the appropriate links to the X page
<tjaalton> great, thanks
<tjaalton> 6111 of those mails matched sourcepackage=xorg
<bryce> btw, I set up PPA for ubuntu-x-swat yesterday
<tjaalton> oh, cool
<bryce> links are posted https://wiki.ubuntu.com/X
<tjaalton> yep, just as I thought, there were some xorg bugs autoclosed yesterday
<tjaalton> nice
<bryce> huh
<tjaalton> or someone was quick :)
<tormod> hmm is it possible to join x-swat without getting all that bug mail? :)
<bryce> I've added some additional links from brian to the X page - reports on bugs with max comments, max subscribers, etc.
<bryce> tormod: unfortunately no
<tjaalton> tormod: I'm afraid not :/ Can't you filter them in any way?
<bryce> tormod: best approach is to filter them to /dev/null
<bryce> brian did these reports after I mentioned that it seemed like the easiest bugs to fix were ones that had lots of eyeballs on them already, as they'd often already figured out a solution, it just needed cleaned up and packaged
<tormod> seems like nobody really wants these mails? or can cope with the amount?
<tjaalton> I do, but I also read just those that I find useful :)
<tormod> well I'll think about opening a new mail account only for bug mail, and filter etc.
<tjaalton> gmail can handle the load ;)
<tormod> tjaalton: so you gonna find those useful ones among the 15112?
<tjaalton> don't know about how it filters them
<tjaalton> tormod: I'll just delete the oldest ones at some point
<tormod> you might as well just work through launchpad :)
<tjaalton> like, older than three monts
<tjaalton> +h
<tjaalton> that's what I do, I never reply to these by mail :)
<bryce> tjaalton: there's a page pitti did on wiki with some bug filtering tips
<bryce> he segregates based on if he is a direct subscriber, team member, etc.
<tormod> I meant, go through all reports on LP one by one, instead of the mails.
<tjaalton> I have a folder which only gets the bugs that I've reported, but should do the same for those that I'm assigned to
<bryce> actually I've found the mails to be quite useful
<bryce> I've configured mutt's colors to highlight certain state changes and people, so while looking in threaded view I can quickly see replies to bugs I've asked questions on 
<tormod> nice, I guess I can make gmail to do something useful with its "labels"
<tjaalton> headers have all the information you could need
<tjaalton> X-Launchpad-Bug: ...
<tjaalton> etc
<bryce> yup
<bryce> while I'm looking through my chart links, here's another interesting one, although not X-related:  http://daniel.holba.ch/p300/
<tjaalton> damn, thunderbird doesn't know how to sort by the Subject _and_ show them in a thread
<tormod> I just need to open another mail account first. Since for now, I sync my personal gmail with POP from time to time, and then I don't want to d/l all the bug mail.
<bryce> ah true
<tormod> I noticed xorg has 200 New bugs...
<tjaalton> tormod: it supports IMAP now
<tormod> yes I saw that. But if I just want to have a local copy of all mail, pop is almost as good.
<tjaalton> we should probably decide a set of tags to use for xorg etc
<tormod> tjaalton: good idea
<tjaalton> since xorg tends to be the package that gets all the bugs that seem to be X related
<tormod> I guess we should try to push more bugs over to xorg-server, I for one haven't been good at that. And leave xorg for untriaged/unknown package?
<tjaalton> well, it has all the stuff that xserver-xorg configuration fails to do right
<tjaalton> of course many of the >400 bugs are in fact xorg-server or driver bugs, so those need to be cleaned out from there
<tormod> only? should it maybe also have the stuff that goes wrong in the server (which is not driver-specific)?
<tormod> xserver-xorg I mean by "it"
<tjaalton> it should have all the stuff that doesn't have a better home :)
<tjaalton> stuff=bugs
<tormod> yes :)
<tjaalton> so for instance, crashers should be elsewhere
<tormod> did anyone feel like blessing the ati sync?
<tjaalton> a sec
<tjaalton> done
<tormod> thanks
<tormod> apropos http://daniel.holba.ch/p300/ I guess it counts bugs that are open in a non-Ubuntu task.
<tormod> there are not so many open in Ubuntu
<tormod> but that queue is slow! I always have to wait ages to get something sponsored.
<tormod> and that's usually after bugging people on IRC
 * tormod should ask daniel holbach about that
<ubotu> New bug: #164996 in xorg (main) "gnome desktop icons does not respond to mouse clicks " [Undecided,New] https://launchpad.net/bugs/164996
#ubuntu-x 2007-12-06
<bryce> tjaalton: yeah we definitely need to put some time into xorg.  I've been (trying) to focus on -intel mostly since uds and haven't been looking much at xorg
<ubotu> New bug: #161007 in xorg (main) "black screen when X should start (live CD)" [Undecided,Incomplete] https://launchpad.net/bugs/161007
<ubotu> New bug: #161029 in xorg (main) "screen corrupt" [Medium,Confirmed] https://launchpad.net/bugs/161029
<ubotu> New bug: #174267 in xorg (main) "[8.04 alpha 1] regression - touchpad loses right, middle and scroll functionality on macbook" [Undecided,New] https://launchpad.net/bugs/174267
<tjaalton> a slight drop in the xorg bugs (416 -> 389).. lot's of low-hanging fruit there, mostly reassigned to other packages though
<tjaalton> like, l-r-m
<tjaalton> always a good place to dump bugs about nvidia/fglrx blobs :)
<tjaalton> dump and forget
<tjaalton> I'll continue later, now it's 3:32AM so bedtime for me :P
<bryce> heh, I was looking into a screensaver bug someone reported with -intel on my -ati box, 
<tjaalton> night ->
<bryce> but stepped away for a minute and my system crashed too!
<bryce> sounds good; I've been banging on -intel bugs
<tjaalton> bug 68150?
<ubotu> Launchpad bug 68150 in xserver-xorg-video-intel "screensaver crashes X on IBM X40 (opengl related?)" [Undecided,Incomplete] https://launchpad.net/bugs/68150
<bryce> heh, yeah that was what I was looking at
<bryce> however this is an -ati (R350) box with dual-head
<tjaalton> yep, there are some screensavers that tend to have issues with some drivers
 * bryce nods
<ubotu> New bug: #131431 in xserver-xorg-video-mga (main) "GLX not loaded in Xubuntu with Matrox G400" [Undecided,New] https://launchpad.net/bugs/131431
<bryce> I'll dig around and see if I can find the matching one for this
<tjaalton> our intels have had problems with "lattice"
<tjaalton> but latest mesa should have fixes for that, also backported to feisty
<bryce> hrm, I'm also now having a firefox rendering issue
<bryce> bugz bugz bugz
<tjaalton> you never get enough of them
<bryce> anyway, g'night, hope you don't have to get up too early tomorrow :-)
<tjaalton> nope, it's the independence day (90th, btw), so it should be nice :)
<bryce> cool
<bryce> well I'm glad I spent a chunk of time yesterday fixing up my .xprofile and so on
<bryce> nice having all my windows auto-arranged and be back in business quick
<tjaalton> gnome-session-save works sometimes, but it's quite fragile
<bryce> I find it unreliable
<bryce> plus I like having all my terminals arranged just-so
<tjaalton> me too
<tjaalton> habits..
<bryce> I figured out how to code it all up so I get multiple tabs loaded with my various mutt mailboxes, todo lists loaded into emacs, etc. etc. 
<tjaalton> heh, I rarely use g-t tabs
<tjaalton> but I have this screen session running on a server..
<bryce> I used to use multi-gnome-terminal way back when, then switched over to konsole (even with gnome), and only yesterday finally switched back
<tjaalton> I should revisit all this session stuff some time
<tjaalton> things have been too stable to make a difference ;)
<tjaalton> ah well, now I'm gone for real ->
 * bryce waves
<ubotu> New bug: #174287 in xserver-xorg-input-synaptics (main) "touchpad + nubmouse combo fails to combine" [Undecided,New] https://launchpad.net/bugs/174287
<ubotu> New bug: #174291 in xorg (main) "Comment text in xorg.conf missing" [Undecided,New] https://launchpad.net/bugs/174291
<ubotu> New bug: #174309 in xserver-xorg-video-radeonhd (universe) "radeonhd -- package doesn't install driver" [Undecided,New] https://launchpad.net/bugs/174309
<ubotu> New bug: #174311 in xserver-xorg-video-radeonhd (universe) "radeonhd not shown when configuring xorg" [Undecided,New] https://launchpad.net/bugs/174311
<ubotu> New bug: #162109 in linux-restricted-modules-2.6.22 (restricted) "Nvidia restricted drivers segfault in _nv001174X+0x36" [Undecided,New] https://launchpad.net/bugs/162109
<ubotu> New bug: #162013 in xorg (main) "Resolution fell to 320*240 when clicking"Don't save" on a change." [Undecided,Invalid] https://launchpad.net/bugs/162013
<ubotu> New bug: #162014 in ubuntu "Text size abnormal (dup-of: 162013)" [Undecided,New] https://launchpad.net/bugs/162014
<ubotu> New bug: #174367 in xserver-xorg-video-intel (main) "Driver can't drive G33 with 2.6.24" [Undecided,New] https://launchpad.net/bugs/174367
<ubotu> New bug: #174425 in xserver-xorg-video-ati (main) "compiz dead locks for dual monitor setup using ati driver 6.7.195" [Undecided,New] https://launchpad.net/bugs/174425
<ubotu> New bug: #174426 in xserver-xorg-input-keyboard (main) "Genius Comfy 21e Scroll Keyboard misconfigured" [Undecided,New] https://launchpad.net/bugs/174426
<ubotu> New bug: #174427 in xserver-xorg-video-ati (main) "Tremulous causes X server crash (signal 11) on Radeon 9250" [Undecided,New] https://launchpad.net/bugs/174427
<ubotu> New bug: #35211 in gnome-screensaver (main) "gnome-screensaver started delayed in session" [Medium,Confirmed] https://launchpad.net/bugs/35211
<jcristau> bryce: http://people.ubuntu.com/~bryce/Xorg/versions_current.html doesn't seem to be updated?
<bryce> hmm, ok I'll take a look at it
<ubotu> New bug: #174479 in xserver-xorg-video-ati (main) "radeon dri and blender in gutsy" [Undecided,New] https://launchpad.net/bugs/174479
<ubotu> New bug: #57229 in xorg (main) "Kubuntu drops me unpredictably to tty1, tty2 etc" [Undecided,Fix released] https://launchpad.net/bugs/57229
<tjaalton> bryce: I'm thinking of adding tags for xorg bugs, especially for those that are fixed by dropping xresprobe, and for those that need input-hotplug
<tjaalton> so, should we have tags that start like "x-foo" or similar, to stand out from the noise
<bryce> sure that sounds great
<bryce> btw, I just had a really good meeting with the Envy guy, and BenC, mvo, and dholbach.  I'm writing up the meeting notes and will post them shortly
<bryce> I put the IRC minutes here:  https://wiki.ubuntu.com/EnvyNG
<tjaalton> ok, reading
<ubotu> New bug: #174323 in totem (main) "Totem dies with ogg file (dup-of: 111257)" [Low,Invalid] https://launchpad.net/bugs/174323
<tjaalton> right, so AIUI the dropped hw-support from fglrx is temporary (the pro stuff)
<tjaalton> so I'm not so sure about the need of fglrx-new
<tjaalton> but the rest of it sounds good
<tjaalton> updating l-r-m is heavy, though :)
<bryce> yup
<bryce> actually I think this will not require updating l-r-m.  as I understand it, envy builds the kernel module and stuff locally on the user's system
<bryce> so lrm and envy just need to be aware of each other, not tie in directly
<tjaalton> yes that's true
<tjaalton> back to tagging; I'll add x-input-hotplug and x-resprobe tags, maybe also x-discover?
<bryce> I think that's probably fine
<tjaalton> keeping them short would be nice, but x-i-h doesn't really tell anything ;)
<bryce> there was some discussion on the devel list though, that ubuntu has too many tags, so be conservative in creating new ones
<bryce> heya tedg
<tedg> Hey, so basically it seems that the XSM Protocol sucks.
<tedg> It's underspecified, so every implementation of it is different.
<tedg> So, now the GNOME folks want to abandon it.
<tedg> I guess the real question is: is someone willing to fix it?
<tedg> (and perhaps make some implementations of it invalid)
<bryce> eh, gotta love open source... flee problems rather than dive in and fix them ;-)
<bryce> tedg: can you provide some references for XSM?  I'm not super familiar with it
<tedg> Yeah, that's part of the problem.  The other problem is that all the implementations seem to be different.
<tjaalton> session-management? eww..
<tedg> http://gould.cx/ted/blog/Who_cares_when_we_quit_
<tedg> The spec itself is linked in that entry.
<tedg> But, I think the diagrams are perhaps more useful than the spec is :)
 * bryce reads
<bryce> nice diagrams
<bryce> (and inkscape plugs *grin*)
<tedg> I'd never plug it if it wasn't useful ;)
<bryce> have you seen wmctrl?
<tedg> No, I don't seem to have it on my system.
<bryce> I discovered it myself the other day; I've only used it a little but it seems to have some cool wm-independent capabilities
<bryce> I don't know if it has anything relating to shutdown, but since it's wm-agnostic, it might be a point where this sort of stuff could be plugged in
<bryce> it's based on implementing some wm standards; I don't know if you've already looked at them, but might be worth a little research if not
<tedg> Yeah, but XSM is really unrelated to the window manager.  It's a separate protocol.
<bryce> well in your blog post you propose modifying the wm to handle the notifications
<tedg> That is pretty cool.
<tedg> Oh, yes.  I'm more thinking adding a WM hint.  Kinda like Toolbar or something like that.
<bryce> I'm just thinking wmctrl might be an alternative there
<tedg> Add a "unsaved data" hint.
<tedg> I don't think that exists in the protocol today.
 * bryce nods
<tedg> So we'd have to add it, and add it to wmctrl also :)
<bryce> yup
<bryce> what about preserving state even for saved docs
<tedg> That's going to have to be an application thing.
<bryce> the idea being to enable when you start up, things get loaded back up as you'd had them
<tedg> Exactly, that would be wonderful.
<tedg> But, it seems because the XSM spec is poorly defined, and implemented differently everywhere, people are avoiding implementing it.
<bryce> you said GNOME is going to abandon it - to what are they planning to move?
<tedg> They don't know, they're just really upset about XSM.
<tedg> They'll probably keep it for the notifications, but do all the restarting stuff using .desktop files in the autostart spec.
<bryce> have they had difficulties getting changes done to XSM?  Who controls it?
<tedg> So basically an app would write .desktop files.
<tedg> Well, I've asked that, and no one seems to know -- that's why I'm here :)
<tedg> Is there anyone in the X hierarchy that cares?
<tedg> I don't think anyone has asked for changes specifically.
<tedg> And I'm guessing they're all figuring that the X guys won't change anything.
<bryce> I don't know - tjaalton, jcristau?
<tedg> But, if there were X folks willing to talk, I think we could have a productive discussion.
<tedg> Though, I think part of that discussion may need to including orphaning some implementations.
<bryce> tedg, do you know Bart Massey?  He seems to have his fingers in several protocol-level things, and knows lots of those sorts of people.  He might be the guy to ask.  Want me to give you his email address?
<tedg> No, I don't know that many X folks, that why I'm asking you guys ;)
<bryce> he's also on the X.org board, so could be a good point person if some pushing needs done from within the community
 * tedg enjoys giving bryce a hard time
<tedg> I'd be willing to start there.
<tedg> We'd really like to get something working for Hardy+1, but at this point I'm worried it's going to be Hardy + 100
<bryce> heh
<bryce> yeah that's how I felt about bulletproof-x
<bryce> ted@canonical.com?
<tjaalton> that would be ubuntu 58.04 then ;)
<tedg> bryce: Sure, that address works.
<tedg> tjaalton: I'm SOOO excited about Ubuntu 58.04.  I think I'm going to take the release day off.
<tedg> Let me e-mail my boss! ;)
<tjaalton> haha :)
<bryce> tedg: ok mailed and cc'd
<tedg> bryce: Cool, thanks.
<bryce> ok, I've written up a summary + tasks - https://wiki.ubuntu.com/EnvyNG
<bryce> tjaalton: if you know of any other tasks or ideas, please add them to that page
 * bryce waves to tormod
<bryce> tormod: btw we had a meeting earlier today about Envy, and making it play better with l-r-m for nvidia and fglrx:  https://wiki.ubuntu.com/EnvyNG
<tormod> hi bryce!
<tedg> So, how are the X11 specs handled now?
<tedg> There's no XOpen group, right?
<tedg> Are Sun and SGI still maintaining their own X server?
<tormod> tedg, I thought I had read that Sun was going towards Xorg, but you might get more answer on #xorg or #xorg-devel
<tormod> bryce, I made a patch for xorg-server.postinst, but is that soon obsolete anyway?
<tedg> tormod: Interesting, that'd probably be easier for everyone.
<tedg> I'm trying to get an idea on how surmountable the spec changing process might be :)
<bryce> sun is maintaining its own X server, but some groups within it are pushing to move to xorg
<bryce> so we'll see
<bryce> I don't know of any active X standards body, but bart would know for sure
<bryce> tormod: we'll always retain xorg-server.postinst, it'll just be much shorter
<tormod> will it still make the list of drivers to choose from?
<tedg> bryce: Are there Sun folks on the X.org lists?
<bryce> I don't know when we'll be pulling in gravity's trimmed down changes
<bryce> tedg, yep
<bryce> tormod: I think that'll still be there
<bryce> tormod: gravity could say for sure
<bryce> tormod: I'd suggest being sure to send him any changes you apply to the ubuntu postinst, so if it's still needed in the future, he can be sure to put it in upstream, so we can remain in sync
<tormod> and gravity is the 133t nick for whom?
<bryce> tedg: they post from their @sun.com addresses, if you want to look at the past month's list archives for them
<bryce> gravity = david nusinow
<tormod> ok I'll make a patch for Debian then.
<tedg> bryce: I wasn't looking for someone specific as much as trying to understand everything.
<tjaalton> tormod: did you not see my reply to that bug? I have it ready for the next upload
<tormod> I haven't gotten any bugmail lately. Maybe I complained too much last night :)
<tormod> tjaalton: thanks that was quick! Should I still file a Debian bug, or do you have some magic for that ?
<tjaalton> tormod: well, maybe I or jcristau could commit that to debian-unstable too
<tjaalton> it's pretty simple
<tormod> sounds good
<tjaalton> jcristau: so, the postinst filters ati-drivers and that means radeonhd is not on the driver list even though if it's installed
<tjaalton> jcristau: and the fix is modifying the egrep line
<tjaalton> hmm, I could push ubuntu branch now so it's easy to pick from there
<tormod> tjaalton: is your tree on alioth.d.o? is there a cgit or gitweb?
<tjaalton> yes
<tjaalton> git.debian.org
<tjaalton> http://git.debian.org/?p=pkg-xorg/debian/xorg.git;a=shortlog;h=ubuntu
<tjaalton> there are guides how to use it on the X wiki
<tjaalton> same goes to xorg-server
<tjaalton> hmm, there was a chick on the telly with the same necklace that princess Leia had on episode IV :) (it's finnish design)
<tormod> tjaalton: thanks I saw the wiki guide, but there was no link
<tjaalton> tormod: hum ok, I'll fix that
<ubotu> New bug: #174537 in xorg (main) "[Hardy] No Xorg in live cd" [Undecided,New] https://launchpad.net/bugs/174537
<ubotu> New bug: #174538 in libx11 (main) "[Hardy] keyboard stops working" [Undecided,New] https://launchpad.net/bugs/174538
<tjaalton> tormod: check the page now, I've even added something under the "git archive policy" headline
<bryce> jcristau: http://people.ubuntu.com/~bryce/Xorg/versions_current.html is updated; still investigating why it works when running manually but not when cronned...
<bryce> dah, stupid PATH tricks
<bryce> ok I think that should take care of it
#ubuntu-x 2007-12-07
<ubotu> New bug: #174442 in ubuntu "unable to switch virtual console (dup-of: 131751)" [Undecided,New] https://launchpad.net/bugs/174442
<tjaalton> ok, we are now down to 311 xorg bugs
<tjaalton> over 100 less than yesterday
<tjaalton> now to bed ->
<bryce> yay!
<ubotu> New bug: #174571 in xorg-server (main) "Xorg crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/174571
<ubotu> New bug: #120105 in xorg (main) "Driver card video is not saved" [Undecided,Incomplete] https://launchpad.net/bugs/120105
<ubotu> New bug: #174632 in linux-restricted-modules-2.6.22 (restricted) "[gutsy] Geforce 7600 GS driver does not work" [Undecided,New] https://launchpad.net/bugs/174632
<ubotu> New bug: #174650 in xserver-xorg-video-intel (main) "xorg very slow when rotated on external monitor" [Undecided,New] https://launchpad.net/bugs/174650
<jcristau> tjaalton: you can use things like git-commit --author 'Michael Vogt <mvo@ubuntu.com>' btw
<tjaalton> jcristau: cool, haven't got that far learning git :)
<jcristau> anyway, i've cherry-picked tormod's fix to debian-unstable
<tjaalton> cool, thanks
<tjaalton> btw, I'll test the input-hotplug autoconfiguration this evening (when the kids are asleep..), it's pretty simple if it works :)
<tedg> On the Intel drivers page it says that the 945G won't work with the current released drivers of Debian (no date).
<tedg> How does that relate to Ubuntu Gutsy?
<tedg> Oh, but in the stable version of Gentoo.
<tedg> I like how there's no version numbers.
<tjaalton> 945 works fine :)
<tedg> Errr, mine isn't. :(
<tjaalton> really?
<tedg> Well, it seems to be falling back to vesa.
<tjaalton> you have intel and not i810 in use?
<tedg> Yeah.  It seems to be running, but won't work with my screen.
<tedg> It drops back to 1600x1200 instead of 1920x1200.
<tedg> How can I hard code the VRAM amount?
<tedg> If it's shared, do I need a kernel setting?
<tjaalton> no
<tjaalton> the log should reveal how much it's using
<tjaalton> besides, are you sure that 945 is able to drive WUXGA screens?-)
<tedg> It does in OSX.
<tedg> Ah, it says that it has 16MB when it should be 64MB.
<tjaalton> change that from bios
<tedg> Eww, at it's going to 16bpp.
<tedg> Do you by chance know how to do that in EFI?
<tedg> It seems like if it was a BIOS setting it wouldn't work in OSX either.
<tjaalton> ah, mac goodness...
<tjaalton> Option "AperTexSize" "integer"
<tjaalton> hmm, no
<tjaalton> since default is 32MB
<tjaalton> put the log somewhere so I can have a look
<tedg> Sure, let me get out of EFI, just a sec.
<tedg> hmph, worked on reboot.
<tedg> Apparently I just hadn't rebooted enough :)
<tedg> tjaalton: Thanks for your help.
<tjaalton> hah :)
<ubotu> New bug: #174745 in xserver-xorg-video-intel (main) "xorg lockup when screen is rotated" [Undecided,New] https://launchpad.net/bugs/174745
<ubotu> New bug: #174434 in xserver-xorg-driver-vesa (main) "ATI drivers" [Undecided,Incomplete] https://launchpad.net/bugs/174434
<tjaalton> right, hal runtime-hotplugging would work, if I knew how to delay the operations until hal is actually ready :)
<tormod> bryce, there's "bug report" in https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2007-December/002571.html
<bryce> yup, we know about that
<tormod> good
#ubuntu-x 2007-12-08
<tjaalton> damnit, I've been banging my head against the wall with hal
<tjaalton> it's just strange
<ubotu> New bug: #39822 in xserver-xorg-input-synaptics (main) "Trackpad didn't work with new user first time of use." [Medium,New] https://launchpad.net/bugs/39822
<ubotu> New bug: #174840 in xserver-xorg-input-synaptics (main) "Switching users disables synaptic touchpad scroll" [Undecided,New] https://launchpad.net/bugs/174840
<ubotu> New bug: #174810 in linux-restricted-modules-2.6.22 (restricted) "ati driver, right side of LCD screen artifacts, hangs off" [Undecided,New] https://launchpad.net/bugs/174810
<ubotu> New bug: #174899 in xorg-server (main) "Xorg crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/174899
<ubotu> New bug: #122348 in ubuntu "New nVidia drivers 100.14 fix problems with ACPI / Suspend (dup-of: 120943)" [Undecided,New] https://launchpad.net/bugs/122348
<ubotu> New bug: #160289 in fast-user-switch-applet (main) "User Switcher gives white screen (dup-of: 160264)" [Low,New] https://launchpad.net/bugs/160289
<tjaalton> oh yeah, singing karaoke (Singstar game for PS2/3) at Lasipalatsi ("Glasspalace", in downtown Helsinki) for seven hours now... an attempt to break the world record :P
<tjaalton> glad that we only have 24h to deal with our group, the whole ordeal will take ten days
<bryce> whoa
<bryce> tjaalton: good luck!
#ubuntu-x 2007-12-09
<tjaalton> bryce: thanks, although we are just one group out of ten that are in this
<tjaalton> the record is some 214 hours, and we are trying to do 240 (ie. ten days)
<tjaalton> and we had to do 24h, still 13.5h left but I just got home and left other to finish it off
<tjaalton> I took some pictures to prove it, but we'll see how long it takes to actually get them published (same hold to the photos I took at UDS :)
<bryce> awesome
<bryce> tjaalton: my girlfriend is big into karaoke (karaoketerri@yahoo.com)
<ubotu> New bug: #39530 in wacom-tools (main) "xorg.conf "TPCButton" option does not work" [Medium,New] https://launchpad.net/bugs/39530
<tjaalton> bryce: heh, so you should get singstar, it's great fun :)
<bryce> heh maybe
<tjaalton> there is some freeware game for windows available, maybe for linux too
<tjaalton> like the frets on fire is a version of guitar hero
<tjaalton> ultrastar-ng, hmm
<tjaalton> ..and it's apt-get'able ;)
<bryce> heh
<bryce> yeah we don't have any windows in my house anymore
<bryce> well, except for the ones you see through
<tjaalton> I've got two installations, one on the laptop for a car diagnostics program, and one on the desktop that I can't even boot :)
<tjaalton> but I'd really like to play something again, so PS3 is on the list
<bryce> you know, for the style of games I like (turn based strategy like civilization, HOMM, etc.) the don't really make those anymore, even for Windows
<bryce> I do have a windows hard drive in a drawer with a bunch of older strategy games installed
<bryce> but linux actually has a sufficient number now, and I found a Linux ported version of HOMM by Loki on an auction site earlier, so I'm fairly well set.  Plus a lot of them run under wine now.
<bryce> but I don't know, I don't really play games as much as I used to
<tjaalton> same here, ENOTIME :)
<tjaalton> but the kids are getting bigger (3 and 1y atm), so there's an excuse to get a console
<tjaalton> yeah wine is getting better and better
<bryce> nice
<tjaalton> I should get a new display card because the radeon 8500 can't drive 1920x1200 (getting a new monitor as well), so I can't decide should I get a nvidia 7xxx which can do 3D right now (blob), or a modern radeon which will take a while until it can do the same
<bryce> I'd ordered a pair of new widescreen monitors, but the order got canceled (insufficient stock on hand)
<tjaalton> I missed a great deal of a Benq 24" monitor this week, it has the same problems
<tjaalton> some pics, maybe a bit too small: http://users.tkk.fi/~tjaalton/singstar/
<tjaalton> powered by ubuntu (my ancient T23) :)
<tjaalton> oh, there's a bigger version of every pic if you click on it.. this is the first webfolder I've created with the bibble :)
<bryce> awesome, I can show these to terri :-)
<tjaalton> of course :)
<tjaalton> the first picture is a duet of "Smoke on the Water" (Deep Purple)
<bryce> cool
<ubotu> New bug: #175062 in linux-restricted-modules-2.6.22 (restricted) "fglrx driver reports unsupported hardware" [Undecided,New] https://launchpad.net/bugs/175062
<ubotu> New bug: #33717 in linux-restricted-modules-2.6.22 (restricted) "Screensaver stops working with fglrx drivers" [Medium,Incomplete] https://launchpad.net/bugs/33717
<ubotu> New bug: #175114 in xkeyboard-config (main) "backslash symbol is not defined in /etc/X11/xkb/symbols/us (in the "basic" set)" [Undecided,New] https://launchpad.net/bugs/175114
#ubuntu-x 2008-12-01
<tjaalton> sigh @ bug 303849
<ubottu> Launchpad bug 303849 in xorg-server "Xorg --version doesn't work while Xorg -version does" [Undecided,New] https://launchpad.net/bugs/303849
<bryce> heya tjaalton
<tjaalton> hi bryce 
<bryce> actually I sort of do agree with the bug reporter on bug #303849
<ubottu> Launchpad bug 303849 in xorg-server "Xorg --version doesn't work while Xorg -version does" [Undecided,Invalid] https://launchpad.net/bugs/303849
<bryce> --version should equate to -version in this case
<tjaalton> I don't think it's going to fly upstream
<bryce> probably not
<bryce> well, maybe not
<tseliot> tjaalton: are you busy today?
<tjaalton> tseliot: always :) why?
<tseliot> :-)
<tseliot> I would like to upload some drivers to jaunty
<tseliot> but if you're busy I can ask superm1 later
<tjaalton> if it's just uploading them, it's fine
<tseliot> yes
<tseliot> I'll have to contact pitti for the uploads to Intrepid
<tseliot> tjaalton: can you upload these drivers too? http://albertomilone.com/ubuntu/newlrm/pitti/jaunty/destination_jaunty.txt
<tseliot> superm1: driver 177 includes the fix you needed ^^
<tseliot> tjaalton: (they are for jaunty)
<tjaalton> tseliot: ok
<tseliot> great
<superm1> tseliot, are you also going to have a NEW driver for the -180 series?
<tseliot> superm1: yep
<tseliot> tjaalton: uploaded nvidia-glx-180
<tseliot> heck, I meant
<tseliot> superm1: tjaalton uploaded nvidia-glx-180
<superm1> tseliot, oh okay. i just didnt see it in that above text file
<tseliot> that's because we did things separately
<superm1> ah
<bryce> morning
<tseliot> good morning bryce
<jcristau> Ng: fwiw, the only dependency for xf86-video-intel is libdrm. you can keep your kernel and mesa. (re fdo bug 17805)
<ubottu> Launchpad bug 17805 in gnome-panel "Cannot check 'periodically synchronize' checkbox on clock applet (dup-of: 11560)" [Medium,Invalid] https://launchpad.net/bugs/17805
<ubottu> Launchpad bug 11560 in gnome-system-tools "[time-admin] must be restarted in order to use ntp, but it doesn't say so." [Low,Fix released] https://launchpad.net/bugs/11560
<bryce> superm1: I did the monday triage on -fglrx.  There were 4 bugs left this time that I was unclear what to do with them; could you take a look?  303726, 304045, 266911, 302126
<Ng> jcristau: ah interesting
<Ng> jcristau: I don't really have time to test the patches today or tomorrow though, and then I'm off to FOSSCamp/UDS, so it's going to be a couple of weeks :(
#ubuntu-x 2008-12-02
<jcristau> hmm. why does your -intel changelog still mention 128_stolen_memory_counting_g4x.patch for 2.5.1? that patch was in 2.4.98.0 already.
<tjaalton> checking..
<tjaalton> right, it's commented out from series
<tjaalton> as is 111
<jcristau> ok, so just confusing changelog. thanks for checking :)
<tjaalton> np
<tseliot> tjaalton or superm1: can you upload the nvidia 177, 173 and 96 to intrepid-proposed (from Jaunty) and put 180 in intrepid-backports? 
<tjaalton> tseliot: I've gotta run soon :/
<tseliot> tjaalton: thanks anyway
<seb128> tseliot: hi, how busy are you? ;-) could you update your 100_load_desired_settings.patch gnome-desktop patch to the current version?
<seb128> tseliot: is there any bugzilla bug about that change btw and any discussion about getting that upstream too?
<tseliot> seb128: why, what happened? Does the patch fail to build?
<tseliot> seb128: I wish upstream could reply to my email :-(
<seb128> tseliot: upstream did changes to the logic in this source and I don't fancy trying to understand the logic and the change to update the patch, that's blocking half of the GNOME 2.25 updates
<tseliot> seb128: ouch. Ok, where shall I get the source from? Svn or bazaar?
<seb128> tseliot: http://ftp.acc.umu.se/pub/GNOME/sources/gnome-desktop/2.25/gnome-desktop-2.25.2.tar.gz
<seb128> tseliot: http://svn.gnome.org/viewvc/gnome-desktop/trunk/libgnome-desktop/gnome-rr-config.c?r1=5229&r2=5253 is the upstream change
 * tseliot has a look at the diff
<seb128> it's probably not too much work but I've a pile of updates and I would like to get most of those done before travelling for uds
<seb128> so if I can avoid spending an hour updating a distro patch i've no clue about that would be nice ;-)
<seb128> thanks!
<seb128> brb
<seb128> restarting my session using the new glib
<tseliot> seb128: it looks like the removed gnome_rr_config_find() and changed the file a bit. I'll work on it but I don't think I can do it today. Is it a problem?
<tseliot> s/the removed/they removed/
<seb128> tseliot: I'll look at what other updates I can do, it blocks the nautilus update for example
<seb128> tseliot: no real hurry but I wanted to do the 2.25 updates before uds, anyway whenever you can, tomorrow would be nice
<tseliot> seb128: otherwise you can (temporarily) remove my 2 patches
<tseliot> I'm fine with either choice
<seb128> I would prefer getting the patch updated ;-) but I'll consider that tomorrow if I run out of updates I can do
<tseliot> ok, good
<seb128> and you should open a bug on bugzilla about the patch if upstream doesn't reply to emails
<tseliot> seb128: I already did that. Actually I used a bug report which you opened
<seb128> hum, ok
<tseliot> seb128: http://bugzilla.gnome.org/show_bug.cgi?id=545118
<ubottu> Gnome bug 545118 in Screen resolution "should give a clue about why the settings can't be applied sometimes" [Normal,New]
<tseliot> superm1: shall I consider it a no? ;)
<superm1> huh tseliot ?
<tseliot> superm1: can you upload the nvidia 177, 173 and 96 to intrepid-proposed (from Jaunty) and put 180 in intrepid-backports? 
<tseliot> superm1: pitti gave me his ACK
<tseliot> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-173/+bug/297543
<ubottu> Ubuntu bug 297543 in nvidia-graphics-drivers-180 "Update Package: nVidia 180.06" [Undecided,In progress]
<superm1> tseliot, not at the moment no sorry.  wouldn't 180 make more sense in -updates since it's NEW anyway?
<tseliot> superm1: it's still an alpha
<tseliot> and it's no longer in NEW
<superm1> tseliot, yeah but it's NEW in intrepid still
<superm1> it either get's NEWed into backports or into updates either way
<superm1> i suppose backports makes more sense though if you're going to be updating it as more releases come out
<tseliot> superm1: if we put an experiment release in -updates without blacklisting it in jockey it will get installed by default instead of the stable release
<superm1> well that'd be if you installed the modaliases package
<superm1> which it wouldn't be
<tseliot> superm1: good point
<superm1> anyhow though, you might want to put this into the main sponsors queue for now.  i should have some time tomorrow if no one nabs it
<tseliot> superm1: there's no hurry, not for me at least ;)
<bryce> morning
<superm1> bryce, i was talking to nvidia yesterday; on laptops that have nvidia graphics, they do have a command line interface for nvidia-settings changing displays.  perhaps it would make sense to have the fallback for fn-f8 if RR 1.2 isn't detected to look for that binary and if it finds it try calls there
<superm1> at least in the cases that ACPI events aren't generated from fn-f8.  a lot of the new laptops don't do ACPI events, but instead NVIF and a keycode press
<bryce> superm1: yeah, what implements fn+f8 currently?
<superm1> bryce, well gnome settings daemon is binding it, so i'm guessing it's probably just xrandr --auto
<bryce> mm could be
<superm1> perhaps a small python app that does this fall back makes more sense
<bryce> iirc the ScreenResolution upstream work was going to implement a better binding for that.  dunno if it got implemented
<superm1> well nonetheless, whatever binding it ends up going to - at least until NV has the RR1.2, it should fall back
<superm1> AMD I think it's less of an issue since they provide atieventsd 
<superm1> gah, i'm working on an SRU to re-enable XF86Battery, and it's going to need to touch xkeyboard-config, libx11, gnome-power-manager, and x11proto-core.  just for one hotkey, i wonder if this is worth it..
<bryce> superm1: since that's against g-s-d could you talk with seb128 about this?  I suspect he'd like to push that change upstream if possible
<seb128> what change?
<superm1> sure, seb128 i just mentioned this: 
<superm1> i was talking to nvidia yesterday; on laptops that have nvidia graphics, they do have a command line interface for nvidia-settings changing displays.  perhaps it would make sense to have the fallback for fn-f8 if RR 1.2 isn't detected to look for that binary and if it finds it try calls there at least in the cases that ACPI events aren't generated from fn-f8.  a lot of the new laptops don't do ACPI events, but instead NVIF and a keycode press
<seb128> right, would be nice to suggest that upstream in any case
<superm1> what's the work going on upstream for the fn-f8 binding?
<seb128> not having a ton of distro patches makes the job easier for everybody ;-)
<seb128> not that I know about
<superm1> bryce, what was "<bryce> iirc the ScreenResolution upstream work was going to implement a better binding for that.  dunno if it got implemented" in reference to then?
<bryce> superm1: I read in the todo list early on that there was a plan to add support for toggling between different configs in your monitors.xml with the CRT/LCD button (fn+f8 for me)
<bryce> superm1: later I saw some cvs entries alluding to the above work being implemented
<bryce> I have not seen it in action or know whether the function is complete or usable
<seb128> they added fn-f7 code recently
<seb128> but I've not seen any change about f8 yet
<bryce> seb128: what is fn+f7?
<superm1> okay i'm referring to XF86Display being fn-f8, is that what you mean for fn-f7  too?
<bryce> yeah
<seb128> equivalent of calling xrandr --auto
<seb128> I think
<bryce> anyway, just worth keeping in mind if talking to upstream - they'll probably expect new ideas to integrate nicely with whatever they're already working on
<superm1> okay so lets refer to it as XF86Display from now on, i suppose variations of laptops change where that keycode comes from. 
<jcristau> bryce: hrm, isn't your 111_textured_video_option.patch superseded by 24c34f02 in -intel?
<tjaalton> jcristau: it's commented out from series like 128
<jcristau> tjaalton: https://lists.ubuntu.com/archives/jaunty-changes/2008-December/001476.html
<bryce> jcristau: let me look
<tjaalton> jcristau: oh..
<bryce> hrm, is there a faster way to look up commit id's besides cgit?
<tjaalton> git log :)
<tjaalton> or diff
<tjaalton> right, git diff foo
<bryce> git log doesn't show 24c34f02.  git diff 24c34f02 returns a 32,000 line diff ;-)
<tjaalton> true, without more options it just shows the diff between your current head and the commit
<bryce> jcristau: thanks, uploaded
<jcristau> what you want is 'git show', fwiw
<bryce> aha, good to know
<tjaalton> heh, didn't know about that one
<bryce> oh tjaalton, btw meant to tell you...  I finished that sync request script and did all the obvious syncs on the ubuntu-x package page
<bryce> tjaalton: however I wanted to ask - there's a bunch that are just rebuilds
<bryce> I assumed there wasn't much point to doing them, but is there?  It's easy enough to do.
<tjaalton> syncs from experimental?
 * bryce nods
<tjaalton> ok, so they are harmless to sync anyway
<bryce> I was figuring we'd just wait until unstable has a new version and then they'll just autosync
<tjaalton> either way is fine
<tjaalton> but.. we might need to rebuild them for 1.6
<bryce> yeah I figured we may as well wait until the server is updated
<wgrant> Do I blame -intel if I can no longer VT switch safely while running Compiz in Jaunty?
<wgrant> (if I suspend and resume, I can unlock the screen, but then I just get a cursor and not even magic-sysrq.
<superm1> wgrant, i've got a gpm sru that i've put together.  it may help with your earlier issues related to gpm
<superm1> wgrant, (and if you're in jaunty, it's coming there too)
<bryce> wgrant: likely -intel
<bryce> wgrant: I saw similar symptoms in launchpad; might be good to browse and see if you're seeing an issue we already had reported
<wgrant> superm1: I'm currently running a custom gpm that prefers xrandr over hal. Other people are running it from my PPA for the same fix.
<wgrant> Er, prefers hal over xrandr.
<superm1> wgrant, well the fix i put in falls back to hal when xrandr starts failing
<wgrant> How do you mean?
<wgrant> In my case xrandr doesn't fail.
<superm1> well there's two types of failures i saw - one of them was when xrandr claimed it could change the brightness when there was a range of Min: 0 Max: 0.  the other was when one of the calls somewhere would return False
<superm1> and this should cover both of those
<superm1> so what was it about xrandr that was causing your problem?
<wgrant> It claims to work, but it doesn't.
<wgrant> It has an obscenely high maximum, and doesn't actually change the brightness.
<wgrant> This isn't too bad, because the brightness buttons also work in hardware, but it means brightness applets and automatic dimming fail, and gpm hangs a lot.
<superm1> ah that's a worse (and more annoying) problem then too
<superm1> what series is your laptop?
<wgrant> 630m
<wgrant> Quite a few Dells seem to be affected.
<superm1> well the series is important though because different ODMs do different series'
<superm1> and don't necessarily adhere to Dell's libsmbios spec as closely
<superm1> the problems i referred to above affect the studio line and some inspirons
<wgrant> AFAICT the problem is unrelated to libsmbios - the problem is -intel is saying that it can do things when it can't.
<wgrant> If I make it use libsmbios via hal, it's fine.
<superm1> ah okay
<superm1> how does -intel determine what it's able to do?
<superm1> have you poked around the driver?
<wgrant> Sorry, was on the phone.
<wgrant> I poked around a bit.
<wgrant> But I couldn't do an awful lot, as it was during exams.
 * wgrant looks now.
<superm1> tbh i've yet to see a useful execution of the backlight support in -intel :)
 * wgrant is trying to read that line, but is thwarted by a hung brightness indicator... it'll be a few seconds.
<wgrant> I don't see why xrandr should be preferred over hal.
<superm1> have you talked to upstream about the possibility of switching it?
<jcristau> doesn't the X driver just use sysfs for backlight stuff?
<superm1> not necessarily.  it's got this combination support where it will use sysfs or native
<wgrant> It'd be really nice if manufacturers just didn't reinvent backlight control.
<superm1> well that's why hal is there
#ubuntu-x 2008-12-03
<wgrant> superm1: gsd is screaming at me a lot now.
<wgrant> Warning:          No symbols defined for <AB11> (keycode 97)
<wgrant> And a few dozen related.
<bryce> refreshed Ubuntu-X wiki a bit - https://wiki.ubuntu.com/X/
<tjaalton> morning
<tjaalton> ooh, pictures
<tjaalton> sigh, can't find a reason why -intel doesn't pick the libdrm-intel1 dependency
<tjaalton> unless it's the difference in compat between libdrm and drm-snapshot
<tjaalton> other than that the diff is irrelevant
<crevette> hello
<tjaalton> hi
<tjaalton> need to decide if we want to move XInput.h back in inputproto or not
<tjaalton> 1.5 didn't move it, master did
<crevette> I have a question about the consoles on tty1-6, it is displayed with a low resolution which is blurry on my laptop screen, it is possible to have it displayed in the native resolution?
<crevette> this is not I use it everyday, but it would be better
<tjaalton> which graphics hw?
<crevette> Intel on thinkpad T61
<crevette> which is funny it is worked one time when my xorg was broken :)
<tjaalton> well, it might support kernel modesetting when 9.04 is out
<crevette> and without mosetting is it possible to have it working or not ?
<tjaalton> I don't know what blurry means in this case
<tjaalton> it's low-res by default
<tjaalton> and using vesafb-tricks bring other problems
<crevette> okay
<crevette> salut seb128 
<seb128> lut crevette
<crevette> tjaalton, I'll wait for a sane method to come up and I'll see
<crevette> tjaalton, this is a TTM that make the Fedora 10 performance better on intel than ubuntu? I've seem some people stating the performance on F10 was back to a good framerate 
<tjaalton> crevette: GEM
<crevette> ah GEM sorry
<tjaalton> it's just a requisite for KMS
<tjaalton> and other things
<tjaalton> well, helps performance too
<seb128> hey tseliot
<seb128> tseliot: no hurry for the gnome-desktop changes, the new version has a soname change too and that requires a transition, since I'm travelling tomorrow I'll probably not start on that today
<crevette> seb128, you're moving to an ubuntu meeting ?
<tseliot> seb128: ok, thanks
<seb128> crevette: uds
<tseliot> seb128: we'll meet at the uds then ;)
<seb128> tseliot: right ;-)
 * tseliot logs out to try driver 180.11
<tseliot> tjaalton: are you (too) busy today?
<tjaalton> tseliot: depends :)
<tjaalton> I'll have lunch in a minute
<tseliot> tjaalton: there's a new version of 180 for Jaunty: http://albertomilone.com/ubuntu/newlrm/pitti/jaunty/destination_jaunty1.txt
<tseliot> which fixes a rather annoying problem
<tjaalton> ok, I'll have a look after lunch
<tseliot> thanks
<crevette> bryce, around ?
<tjaalton> rather late for him
<crevette> tx tjaalton, I didn't if he was US or UK based
<tjaalton> UTC-8 :)
<tseliot1> tjaalton: I have updated my http://albertomilone.com/ubuntu/newlrm/pitti/jaunty/destination_jaunty1.txt so as to include a patch for Jaunty's kernel for driver 177
<tjaalton> tseliot1: right, I forgot about that.. downloading now
<tseliot1> tjaalton: thanks
<tjaalton> tseliot1: done
<tseliot1> tjaalton: great, thanks a lot :-)
<tjaalton> np
<tjaalton> now lets see if mesa master builds
<tseliot1> tjaalton: ah, I almost forgot, can you copy 177, 173, 96 to intrepid-proposed? I guess I'll have to modify the changelog for 180 to put it in intrepid-proposed too, right?
<tjaalton> well it's the same for all of them
<tjaalton> I can't copy packages from a pocket to another
<tseliot1> tjaalton: ok, I'll change them all
<tseliot1> tjaalton: shall I do a "debuild -S -sa" for 180?
<tseliot1> or would a -S be enough?
<tjaalton> I don't know..
<tseliot1> tjaalton: the orig.tar.gz is already in the archive since you used it for Jaunty
<tjaalton> ok then
<tseliot1> tjaalton: -S then?
<tjaalton> I guess
<tseliot1> ok, let's try with -S
<tseliot1> tjaalton: here you go: http://albertomilone.com/ubuntu/newlrm/pitti/destination.txt
<tseliot1> tjaalton: as discussed with superm1 I think 180 can get into -proposed without using the backports since it won't be installed by default without the modaliases package
<tjaalton> tseliot1: I'm not the release-manager.. they can drop it if it's not suitable there
<tseliot1> tjaalton: right
<tseliot1> let me know when you're done
<tjaalton> um, you used the same version numbers?
<tjaalton> I believe this should be dealt with a RM..
<tseliot1> tjaalton: aah, does dput refuse to upload the source?
<tjaalton> tseliot1: no, but -updates should not have same versions as the devel version, I think
<tjaalton> besides, you should have a permission to upload stuff to -proposed first
<tseliot1> tjaalton: actually I think this happens from time to time. pitti copied the packages from -proposed to jaunty with the same version
<tseliot1> (in the past)
<tjaalton> that's different
<tseliot1> tjaalton: hmm
<tjaalton> I'm sure he bumped the version too
<tjaalton> it doesn't work the other way around
<tjaalton> and he's an archive admin too
<tseliot1> ok, I think I can ask slangasek about this
<seb128> intrepid updates are copied to jaunty when the intrepid and jaunty version are identic
<seb128> you can't upload the same version twice to intrepid and jaunty though
<tseliot1> seb128: and would it be possible to copy from jaunty to intrepid?
<seb128> either you have to use different versions or get the source copied on soyuz
<seb128> no
<seb128> because binaries are built on jaunty this way
<seb128> and depends could change a lot
<seb128> the copy is a source and binary one
<seb128> copying the intrepid binaries to jaunty is no issue
<seb128> but it wouldn't work the other way around due to shlibs changes, etc
<tseliot1> ah, ok this makes sense
<tseliot1> tjaalton: I guess I'll just bump the version then
<solarion> anyone know why the MS optical mouse I got would middle-click when I right click and right click when I middle click?
<solarion> seems rather bizarre and very highly annoying
<solarion> nobody?
<jcristau> solarion: try evtest on it, see what it reports
<solarion> I don't see an evtest
<solarion> yeah, pushing the button and listing state gives button[2,3]=down
<solarion> nm, I just got a less crappy mouse.  :)
<solarion> side scrolling even just worked right ootb
#ubuntu-x 2008-12-04
<TomJaeger> When are we going to see an xserver 1.6.0 beta in jaunty, and is there a way I can help speed this up?
<bryce_> tjaalton: I've written a page on how to do git-bisect for X in ubuntu.  Would you mind reviewing it?  https://wiki.ubuntu.com/X/Bisecting
<bryce_> (my git-fu is not strong; there might be better ways to explain the process)
<superm1> bryce_, you still here?
<bryce_> yep, in and out
<superm1> just a quick q about BART
<superm1> http://bart.gov/schedules/bylineresults.aspx?route=11&date=12%2F4%2F2008 . those times listed, so say the last one for bay fair is 1:02, does that mean that one runs all the way to milbrae still, you board at bay fair at 1:02?
<superm1> just wanted to make sure i've planned ahead to understand when to be back to the BART stop at for uds
<superm1> (er for the days before uds)
<superm1> bryce_, that howto on git biset looks useful. i've not known how to use git bisect myself, but that looks to explain it well
<bryce_> yeah I don't know much about the end times for the bart.  I tended to use it only for getting to/from work and didn't push the late times
<bryce_> superm1: yeah, I know upstream often asks to do git bisecting, but ubuntu users find it a bit technically perplexing, so having it documented like we do for backtracing could only help
<bryce_> this is particularly aimed at our OEM team, since they're very often wishing to backport fixes for earlier releases (esp. hardy)
<superm1> ah right
<tjaalton> bryce: looks good, I've bisected mesa once
<wgrant> tjaalton: You seem to have a duplicate account on LP (~tepsipakki; some packages are showing up with that as the uploader)
<bryce> http://www2.bryceharrington.org:8080/Photos/Woodworking/Desk/ <-- some photos of recent work on my desk :-)
<wgrant> bryce: Oh, it's done?
<bryce> wgrant: yep!
<bryce> I'm sitting at it right now :-)
<wgrant> bryce: Not bad. It's nice and shiny.
<bryce> yep, went kind of mad with the varnishing ;-)
<bryce> more importantly, it's extremely solid.  I'm happy with it.  Nice to be back on a normal desktop with a couple big dual heads :-)
<bryce> been stuck on only a laptop for the last month
<wgrant> It also looks remarkably straight for a piece of home-built furniture.
<bryce> yeah, the angle the wall makes is not exactly 90 degrees, so getting it all to fit in, be level, and be straight, was quite challenging
<wgrant> Oh, ouch.
<tjaalton> wgrant: yes, I changed that a year ago, now I've removed  tepsipakki@ email and waiting for tjaalton@u.c
<tseliot> tjaalton: what or who is/was tepsipakki? Or what does it mean?
<tjaalton> tseliot: my nickname in certain circles :)
<tjaalton> tepsi = TPS (the hockey team I cheer), pakki=defenseman
<bryce> nite
<tjaalton> night bryce, the desk looks nice :)
<wgrant> Night bryce 
<tseliot> very nice :-)
<wgrant> tjaalton: But you should probably merge the account...
<tseliot> night bryce
<tjaalton> wgrant: how?
<wgrant> tjaalton: https://launchpad.net/~tepsipakki, there's a link there.
<tjaalton> oh
<tjaalton> well, msg'd jpds about it
<tjaalton> since tepsipakki@ doesn't seem to work anymore
<tjaalton> so I can't merge the accounts :)
<tjaalton> oh, it does work
<tjaalton> done now
<tjaalton> so it's not wise to remove the address from my list of addresses
<tjaalton> bryce: ping? should I blueprint'ify xserver-1.6 etc? can't figure out what talk to host otherwise (unless you have suggestions) :)
<bryce> tjaalton: yep that sounds good
<tjaalton> bryce: ok, good. maybe xorg-jaunty is better
<bryce> are there any other major changes we intend for X this go around?
<bryce> so far mostly the blueprints are for toolsmithing type stuff
<bryce> oh also I had a question for you, non-X related
<bryce> I'm merging nfs-utils and there is a patch 100-gssd-use-kernel-supported-enctypes.diff
<bryce> I've refreshed it to apply to the new release, but I'm wondering if it's still necessary?
<bryce> tjaalton: I emailed kevin coffman and here is his reply:
<bryce> Hi Bryce!
<bryce> This patch isn't needed.  There is still no code in the kernel to
<bryce> return the enctype information and, as it turns out, the way we're
<bryce> going to get this information from the kernel has changed.  (Which is
<bryce> why this has never gone upstream.)
<bryce> Bruce and Olga are working on a new upcall interface for gssd which
<bryce> will include the ability to send up the supported encryption types.
<bryce> The code to add new encryption support in the kernel (besides des) is
<bryce> waiting on that new upcall interface to be completed...
<bryce> HTH,
<bryce> K.C.
<bryce> sounds like we should drop the patch, but I wanted to doublecheck with you first
<tjaalton> dunno really, I didn't add it originally
<tjaalton> ..but the original changelog entry is not preserved thanks to me.. maybe launchpad helps
<bryce> okie.  Guess if anyone needs it, they can bring it back in
<tjaalton> yeah
<tjaalton> I'll notice when we start testing/using nfsv4+krb5 again :)
<tjaalton> phoronix claims that nvidia blob will support randr-1.2 soon
<bryce> about time ;-)
<bryce> did they indicate if it'd be full support?
<bryce> iirc -fglrx said they added randr 1.2 support but left out a few functions
<tjaalton> it didn't say
<bryce> oh speaking of fglrx, I told amd we'd have a beta version of xserver 1.6 in alpha2 (which is immediately after uds).
<tjaalton> I bet they are cheering
<bryce> heh
<bryce> well, they're going to wait on updating fglrx until that's in
<tjaalton> probably tseliot is too :)
<bryce> tseliot: oh btw there was a question on whether you'd be providing the newer -nvidia packages in envy for Hardy?
<tjaalton> I got mesa master to build just fine, so we just need to update randrproto and dri2proto before it and xserver 1.6beta
<tseliot> bryce: the problem is that I don't know how to provide it. 170 and 180 don't support geforce 5xxx series
<tseliot> bryce: providing an upload which drops the support for certain devices can be a bit risky
<tseliot> I need a plan
<bryce> yeah
<bryce> maybe something we all can chat about next week
<tseliot> yes, right
#ubuntu-x 2008-12-05
<crevette> hey tseliot 
<tseliot> crevette: hi
<crevette> tseliot, I've been said to contact you by seb128 about bluetooth upload, that's true ?
<tseliot> crevette: bluetooth?
<crevette> yes
<tseliot> maybe you should talk to superm1 about it
<crevette> excpet if I've been mistaken
<crevette> okay
<tjaalton> https://blueprints.edge.launchpad.net/ubuntu/+spec/xorg-jaunty
<crevette> tjaalton, you're at UDS? 
<crevette> tjaalton, does usplash is compatible with KMS or there is nothing related?
<tjaalton> crevette: plymouth will replace usplash
<crevette> Okay, so plymouth would be a dependency for this spec
<tjaalton> probably
<bryce> tjaalton: any ideas on bug 303177?  I've been able to reproduce the issue on one of my dev boxes
<ubottu> Launchpad bug 303177 in libdrm "Intel driver 2.5.1 has unmarked dependency on libdrm-intel1" [Critical,Confirmed] https://launchpad.net/bugs/303177
<tjaalton> bryce: well, the version in experimental built against drm-snapshot does get that dependency, but I couldn't find anything special about drm-snapshot which would explain it
<bryce> is it strictly an issue of the dependency not getting picked up?  can we force it in the -intel Depends?
<tjaalton> we sure can
<bryce> I'll give that a try then
<bryce> huh that worked
<tjaalton> surprise?
<bryce> wasn't expecting for it to be quite so easy
<bryce> guess I overestimated the bug reporters' troubleshooting capabilties ;-)
<bryce> feels like we're missing something though.  Wouldn't debian have needed the depends as well?
<tjaalton> no, the libdrm-dev/intel1 shlibs/symbols should ccover this
<tjaalton> -c
<bryce> alright, Depends uploaded.
<bryce> we can revert that once the libdrm symbols are fixed up
<tjaalton> yep
<bryce> heh, I'd allocated most of the day to work on that ;-)
<bryce> tjaalton: oh hey, last night I started working on a new launchpadlib tool, to retarget bugs filed against xorg
<bryce> so like, if they mention intel in the title --> xserver-xorg-video-intel
<bryce> or if they mention "crash|freeze" --> xorg-server
<bryce> problem is that launchpad doesn't have an api routine for actually re-targeting a bug
<bryce> I could add a new bug-task, and then invalidate the xorg one, but that seems sloppy
<tjaalton> yeah, and might break email filtering
<tjaalton> for me it would :)
<bryce> anyway, I filed a bug against launchpadlib for the feature.  we'll see if that comes
<bryce> in my dry runs, it was targeting around 200 bugs to be moved
<tjaalton> cool
<bryce> one unsolved issue is that most bug reporters don't seem to know to distinguish between -nvidia/-nv and -ati/-fglrx, so in those cases it's sort of ambigious where to move them to
<bryce> but I figure even putting them into the wrong queue would be better than leaving them ignored in xorg ;-)
<tjaalton> heh, right
<bryce> which nvidia package maps to NVIDIA GLX Module  169.12 ?  Is that -177?
<tjaalton> 168.12 :) (nvidia-glx-new in hardy)
<tjaalton> make that 169
<bryce> ahh
<bryce> ok, I misfiled some bugs against -177 then.  but hopefully someone can catch those
<bryce> (just 2-3)
<tjaalton> what the.. banshee lost the ability to sync my ipod
<tjaalton> duh
<tjaalton> no new music for the trip then
<bryce> wow that sucks
<bryce> what airline are you flying?
<bryce> NWA international flights have nifty linux-based seat-back movie player thingees
<tjaalton> Finnair & British Airways
 * bryce finishes retargeting xorg crash bugs
<tjaalton> I've got a book about polymer tech. and some handouts to read :)
<bryce> knocked xorg down by a few dozen.  mostly moved to xorg-server, some to drivers
<crevette> tjaalton: you can use rhythmbox
<bryce> sad how many crash bugs don't have full backtraces.  I really need to get that signal handling support hooked up.
<bryce> I wish X's automatic traces provided full info
<crevette> good night
<tjaalton> rb does not support syncing
<tjaalton> bryce: 1.6 should do that already AIUI
<bryce> oh??  8-)
<bryce> let's get 1.6 in then!  :-)
<tjaalton> yeah, next week :)
<tjaalton> right, thanks rb, I really want to get 4568 duplicates on my ipod
<tjaalton> and no way to stop that from happening
<tjaalton> oh well, 4h before I have to wake up and get to the airport..
<tjaalton> see you at the hotel then :)
<bryce> have a good flight tjaalton, see you there :-)
#ubuntu-x 2008-12-06
<lool> jcristau: So there's this -psb poulsbo xorg driver which is not in freedesktop upstream and we're maintaining in ubuntu in a ppa
<lool> jcristau: I'd like to host it in a vcs
<lool> And because xorg stuff is usually git on alioth, I was wondering whether to put it there?
<lool> bryce: Do you think that would make sense?
<JSeann> hello, i would like to know , where is the settings of the screen by gnome under Ibex?
<lool> JSeann: Which setting?
<lool> JSeann: /desktop/gnome/screen/default/0 probably?
<JSeann> up to hardy was the settings for the screen in /etc/X11/xorg.conf
<JSeann> sorry, my english isn't good
<JSeann> lool, i have not /desktop
<lool> JSeann: GNOME will default to that, but it applies your GNOME settings when the Xorg server starts
<lool> JSeann: These are GConf settings; you may browse them with gconf-editor
<JSeann> the situation is, my dad has the screen resolutions set too big , and now, he has no screen , 
<JSeann> is that right, i look in mein home-directory  in ./.gconf ?
<JSeann> @ lool 
<JSeann> ?
<lool> JSeann: Sorry, can't help you much more than that; I'm at a conference and am moving to the next discussion room
<JSeann> ok, thanks lool 
<JSeann> come someone from germany ?
<JSeann> juhu thosch66 :-)
<thosch66> JSeann: Hi.
#ubuntu-x 2008-12-07
<tjaalton> yawn
<tjaalton> ooh, gallium-0.2 will be merged to mesa master and that'll become mesa 7.3 before newyear
<tjaalton> lool: could debian ship it?
<tjaalton> lool: I mean license-wise, or is it completely free?
<JSeann> moin
<lool> tjaalton: License wise it's free
<lool> tjaalton: The kernel driver (the free part) can do KMS, it used ot rely on bleeding edge drm though 
<tjaalton> lool: ok, sounds fine. i guess that if you would maintain it for debian as well, having it on alioth is not a problem (just like the openchrome driver is maintained)
#ubuntu-x 2009-11-30
<tseliot> tjaalton: do you know what version of libdrm Lucid will use?
<tjaalton> tseliot: no, there's 2.4.15 but who knows what will be released within the next few months
<tjaalton> depends on what ati/intel(/nouveau?) require
<tseliot> right, we'll see then
<tjaalton> bryce: the versions_current.html doesn't show lucid versions yet? also, libxss is libXScrnSaver upstream, so the upstream version isn't shown
<bryce> tjaalton, hmm, ok will get that working
<bryce> tjaalton, should be fixed now - http://www2.bryceharrington.org:8080/X/PkgList/versions_current.html
<WeatherGod> Hello, I have a quick X question to rule out some possible causes for a bug
<WeatherGod> does X at all control the brightness of a display?
<WeatherGod> I am sure it doesn't, but I just want to double-check
<jcristau> for laptops, it can
<WeatherGod> oh?
<WeatherGod> so, if a user is experiencing changes in the brightness level on their display, could that be an X issue?
<WeatherGod> note, it isn't a power-saving setting
<jcristau> brightness can be changed through X yes.  X doesn't change it on its own, it has to be requested by a client
<jcristau> mostly it exports the interface from /sys/class/backlight/
<WeatherGod> ok, that helps
<WeatherGod> hmmm, ok, I will have to investigate this further
<WeatherGod> thanks!
<spO> hi
<spO> https://bugs.launchpad.net/ubuntu/karmic/+source/fglrx-installer/+bug/440233    <---   this bug is not assigned.... do you think it would ever be fixed within a few months or shoudl i be looking at a new motherboard+ integrated video card?
<ubottu> Launchpad bug 440233 in fglrx-installer "fglrx fails at startup because of missing amdpcsdb.default + removal leaves bad settings in Xorg.conf" [High,Confirmed]
<bryce> added Debian Testing as well - http://www2.bryceharrington.org:8080/X/PkgList/versions_current.html
<tormod> bryce, radeon KMS: I see the kernel guys have made some blueprints and stuff. I hope you are in the loop?
<tormod> is it right that they have settled on 2.6.32 only but want to use radeon KMS by default?
<bryce> yep and yep
<bryce> we had a chance to sync up plans at UDS
<jcristau> aiui the debian and ubuntu kernel teams met at plumbers and decided to both settle on .32
<tormod> so they have massive drm-backporting in their plans also then?
<mac_v> bryce: hi... has the slow radeon KMS performance been improved?
<mac_v> with .32?
<tormod> mac_v, it has improved yes
<mac_v> cool...
<tormod> but not quite at UMS level
<mac_v> sadly , X crashes in .31 while viewing image files... not sure how to debug it even.. :(  
<tormod> then suspend/resume is quite important and needs lot of testing and probably patches
<bryce> mac_v, tips on debugging X issues are available from http://wiki.ubuntu.com/X/
<tormod> mac_v, why are you using .31 ? :)
<bryce> mac_v, if those docs don't answer your questions, please add Q's at the bottom of the respective page and I'll try to fill in / clarify
<mac_v> karmic ;)  .... need to get to lucid ;)
<bryce> I hope the performance issue on radeon can be worked out by release, but at this point having KMS in place is a higher priority
<tormod> mac_v, even if you use karmic you should use the lucid kernel if you want to try KMS
<mac_v> bryce: is there a bug already reported > where X crashes when there user is viewing a lot of image files?
<bryce> mac_v, heck if I know
<bryce> we get so many bug reports now it's impossible for me to keep track
<mac_v> lol.. yeah... 
<mac_v> bryce: saw your graph ;)
<bryce> sadly I am having to give up the notion that I'll ever be able to handle all the bug reports
<bryce> I am going to just have to pick some suitable subset to focus on
<bryce> maybe bug reports from people with the highest karma ;-)
<tormod> bryce, I can defend KMS by upstream focusing totally on it, but I would not trade performance for "flicker-free" booting
 * mac_v has a healthy karma ;)
<bryce> tormod, I think this is one of those situations where due to it being LTS, we want to put the tech in place that we're going to be able to maintain for several years
<bryce> which accentuates the importance of upstream's total focus on it vs. UMS
<tormod> bryce, that's sound sane
<bryce> as well, the Dx team is doing a lot of stuff now which presupposes KMS is there, so if we're not on KMS we make them grumpy
<tormod> I was a bit worried this could be a top-down management decision because esthetics and buzzwords are important, but that's certainly not true, right?
<bryce> same rationale exists for why we're pushing for -nouveau
<mac_v> tormod: any word on this bug > Bug #436546 
<ubottu> Launchpad bug 436546 in xserver-xorg-video-ati "X crashes when using compiz cube and cairo-dock" [Undecided,Confirmed] https://launchpad.net/bugs/436546
<tormod> but then we definitely should hurry up and get radeon KMS by default in Lucid
<bryce> yep
<tormod> and prepare for the bug flood
<bryce> there is definitely top down encouragement for doing this
<bryce> however, I had both -nouveau and -radeon KMS in the plans for karmic myself, already so it's just encouragement for what had already been planned :-)
<bryce> (I was actually pleasantly surprised to see top down support for this strategy, since I had expected it was going to redouble focus on proprietary driver support)
<mac_v> bryce: is it possible to run gdb from one user and wait for the X crash to be produce in another session?
<mac_v> another user*
<jcristau> use another machine
<bryce> mac_v, if that other user is root, then yeah
<jcristau> otherwise when X crashes you'll be stuck..
<bryce> mac_v, jcristau is right though; usually better to ssh in
<tormod> I am sad to see how much time you Canonical guys have to use on proprietary drivers
<mac_v> jcristau: i dont have a second linux box :( , the other one is windows :/
<tormod> great blob support is  of course a major advantage for some users
<jcristau> mac_v: windows has ssh clients
<bryce> tormod, yeah
<jcristau> (X will be stopped in gdb, and you can't vt switch with X stopped)
<mac_v> oh
<tormod> but what if the resources had been used on open source for the benefit of the future
<bryce> tormod, to be honest, the amount of effort I spend on proprietary drivers myself is quite small compared with what I spend on foss stuff
<tormod> mac_v, look for putty
<tormod> good to hear that
<bryce> tormod, tseliot and superm1 do most of the hard work on them
<mac_v> yeah , i should do that... havent tried putty , its about time i debugged this crash ;)
<bryce> tormod, I'm hopeful that if we can get 3D+KMS on r6xx/r7xx for -radeon, we may drastically reduce the number of -fglrx users
<tormod> bryce, yes according to phoronix posters, radeon is already better than fglrx in many cases
<bryce> with -nouveau I have similar hopes but at a much smaller scale
<tormod> bryce, we won't get 3D with nouveau on lucid?
<superm1> i hope that the specs that were released will be able to get XvBA like support in radeon at some point using va-api or vdpau
<bryce> tormod, nope
<bryce> tormod, even upstream recommends we not do 3D yet.  (Forwarded mail to ubuntu-x@ last week)
<bryce> tormod, maybe we could do a ppa or something if we have time/ambition
<tormod> yes I think I remember that, so nouveau will not really be better than nvidia then
<tormod> but better than nv :)
<bryce> my suspicion is that it will be better than -nv in that it has kms, but I think we may have stability problems and regressions on a lot of hardware
<bryce> but I see that as the price to pay in order to move forward
<bryce> -nv is just a dead end it seems
<tormod> bryce, are you running KMS on your radeons?
<bryce> tormod, on my test machines, yeah
<bryce> although lately I've had nvidia hw slapped into them, for all those -nvidia bugs we had post-release
<bryce> oh btw regarding the bug situation
<tormod> did you see my gdm.conf on https://wiki.ubuntu.com/X/RadeonKMS ? you probably had module loading race issues as well
<bryce> I've given a lot of thought to how I should spend my bug time
<bryce> and esp. in light of how many bug reports we got, and the need to narrow my focus,
<tormod> you should just work the automated tools IMO :)
<bryce> I am thinking instead of working on bugs directly, that my time would be better spent writing tutorials on how to fix certain kinds of X bugs
<bryce> I've started writing up one on "how to fix X crashes", am about 50% done with it
<tormod> make those tutorials into ubuntu-bug wizards :)
<bryce> and I'll do one on fixing resolution detection problems, that's another common category
<mac_v> any known serious bugs in kernel .32 ? 
<bryce> yeah, and then redouble efforts around automated tools
<tormod> mac_v, not in -rc8 AFAIK
<mac_v> great
<bryce> also I want to work on expanding our ubuntu-x community.  I am hoping the tutorials make a nice path for people to follow to get involved
<tormod> oh I feel good, I wrote half a tutorial on git-bisect today :)
<tormod> bryce, back to KMS, interesting that airlied said a few days ago, he would never push radeon KMS into a non-experimental distribution now :)
<tormod> I hope that will change, like soon
<bryce> wow
<bryce> tormod, did he elaborate why?  just stability issues in general or any particular troubles we should be wary of?
<tormod> well I guess he was just defending fedora 12 which got quite some sh*t for regressions due to KMS
<bryce> ahh
<bryce> yeah I've heard fedora has had even more complaints than us regarding gfx problems
<tormod> trying to look up the quote before I put words in his mouth though...
<RAOF> What should I be doing wrt nouveau in Lucid?  The X/Nouveau blueprint doesn't seem to have actionable stuff for me.
<bryce> RAOF, probably the next important thing to do with -nouveau is identify the kernel patches that steve needs to pull
<bryce> so if you know what we need in the kernel, a list to him could help move things forward to the next step
<RAOF> Would he want a list of git commits?
<bryce> yep
<RAOF> That's going to be a really, really big list.
<bryce> on the X side of things, identifying if we need to pull mesa and/or libdrm support from git would be good to know
<RAOF> Don't need mesa, less sure about libdrm.
<bryce> a debdiff for updating -nouveau to a new version that I could sponsor would be handy
<tjaalton> "commits up to id .." should be easier
<RAOF> tjaalton: How would I get that?
<bryce> RAOF, also testing on all of your available hardware + filing good bugs on issues would be a solid step
<bryce> RAOF, also you probably know -nouveau better than any of the rest of us, so if you could jot down any bits of wisdom/advice/tips-and-tricks/etc. it would help a lot as we try to draft up the bits of documentation we'll need (release notes, troubleshooting guides, and so forth)
<tjaalton> RAOF: well, how is it done now? you depend on a dkms'ified snapshot of drm-modules, so telling what id and of what tree is needed for the ddx
<RAOF> tjaalton: Ok, that's easy; master of nouveau's linux-2.6 tree.  That, however, would pull in more than we need, 'cause it'll also pull in drm-next.
<jcristau> how many changes in drm core does nouveau depend on?
<RAOF> That's a question I haven't answered yet.
<RAOF> I'm pulling the Lucid kernel tree; I'll run some comparisons.
<RAOF> They tend to depend on the very most latest stuff, though.
<jcristau> a diff against drm-next would give an idea i guess
<RAOF> bryce: We'll be having xserver 1.7 in lucid, yes?  That eliminates the most commonly hit limitation of nouveau, which is you don't get EXA or Xv on nv5x cards without a composite manager in < 1.7
<bryce> yep, hopefully 1.7 by alpha-1 (Dec 10th)
<jcristau> looks quite small
<jcristau> assuming i got the diff right, it's  drivers/gpu/drm/ttm/ttm_bo.c                |    4 
<jcristau> and that's it
<RAOF> That wouldn't surprise me.
<jcristau> which is pretty good news :)
<RAOF> But there'll be a much bigger diff against lucid's kernel, right?  And we'll need to be careful when pulling in updates.
<jcristau> yeah
<tormod> for radeon KMS we would probably need most of drm-next as well
<RAOF> Hm.  525 commits in nouveau that aren't in lucid.
<jcristau> i'll get intel video overlay pulled into squeeze's kernel probably
<jcristau> so that's part of intel's drm-next :)
<RAOF> git masters: how do I get a list of commits that touched a set of files?
<jcristau> git log --format=oneline -- <paths> seems to work
<tormod> mac_v, that bug you asked about, it is related to bug 446578 I think. fixing one breaks the other.
<RAOF> Here's a list of git commits for nouveau http://pastebin.com/f5c80954e
<tormod> that looks like the source code for pacman
<RAOF> :)
<RAOF> Bah.  Trying to cherry pick those commits in an automated manner seems hard.
<jcristau> that would be the wrong thing to do anyway
<RAOF> What would the right thing to do be?
 * tormod as a kid would type stuff like this from computer magazines into the "home computer" and hope nothing break before I could save it on the tape recorder
<jcristau> RAOF: either merge from some tree, or combine the stuff into one big 'add nouveau' patch, imo
<jcristau> trying to rebase will just lead to madness
<RAOF> We could merge, as long as we don't mind pulling drm-next in.
<jcristau> i suspec tthat you do
<bryce> I'm open minded about drm-next, but really it'd be a kernel team decision
<bryce> I pinged sconklin
<sconklin> heya
<RAOF> Howdie.
<bryce> sconklin, we were just discussing kernel stuff needed for -nouveau/kms (and radeon kms)
<bryce> in particular, it appears to need drm-next
<bryce> sconklin, <RAOF> Here's a list of git commits for nouveau http://pastebin.com/f5c80954e
<jcristau> RAOF: shouldn't be too hard to extract just what nouveau needs from -next
<RAOF> So, getting nouveau in the kernel by merging from their kernel tree implies merging in drm-next, because they frequently merge drm-next into their tree.
<jcristau> wel, hopefully :)
<jcristau> +l
<RAOF> If we want to add nouveau by means of a mega-patch we'll need to carefully merge in the drm changes nouveau requires, and check that they don't break our other drm drivers.
<sconklin> Someone told me that the drm-next commits required for nouveau were not stable with intel harwdare, anyone know about that? It was a hallway conversation at UDS
<RAOF> I don't know about that, no.
<bryce> jbarnes, ^^ ?
<tormod> radeon KMS will probably need some drm-next stuff also
<sconklin> here's my general thinking about all of this - please say something if I'm on crack . . .
<RAOF> If we want to test drm-next I can trivially extend nouveau-kernel-source to build the other drm drivers, too.
<sconklin> I'm beginning to understand the risks to nouveau, and there are a lot of them, and it also impacts our normal code flow.
<sconklin> The best thing would be to get it into the first alpha and see if it falls over.
<sconklin> I still don't have  a solid understanding of what our benefits are as a distro to using nouveau
<sconklin> I do understand the benefits to nouveau.
<sconklin> I also see that Fedora appears to be dealing with a pile of graphics stability issues rigth now
<bryce> sconklin, one of the main benefits we gain is a more active upstream (compared with -nv)
<bryce> (and I admit "active upstream" can be a con as well as a pro depending on the situation...)
<sconklin> bryce: understood, but that upstream pretty much admits that they aren't ready for relases or a distro.
<sconklin> But . . . this could really get them some huge benefits also
<RAOF> Which is a pity, because they're a much better nvidia driver than nv.
<jcristau> didn't stop fedora.  but then rh hired one of the nouveau developers.
<bryce> sconklin, I still expect that most nvidia owners will still just use -nouveau as a bridge to installing -nvidia.
<sconklin> yeah, and trust me I know that "because Fedora does/doesn't do something" isn't a good reason to go either way on a decision.
<jcristau> fair enough :)
<RAOF> bryce: I agree.  Nouveau is a much better 2d driver, but most people are going to want 3d.
<sconklin> bryce, and are all the drm bits either compatible or selectable between -nouveau and -nvidia?
<tormod> what RHEL will do is maybe more relevant
<RAOF> nvidia doesn't have any drm bits.
<jcristau> sconklin: nvidia doesn't use drm at all
<sconklin> tormod: not necessarily - RHEL and Ubuntu have very different user bases.
<bryce> sconklin, nvidia does its own thing
<RAOF> A problem nouveau _may_ introduce is binding to the hardware in the initramfs and preventing nvidia's kernel module from loading.  I haven't tested that.
<jbarnes> bryce, sconklin: I haven't heard anything about that either
<sconklin> bryce: sorry, I meant "any of the things in drm-next"
<jbarnes> nouveau and intel should be mostly independent in the kernel
<bryce> sconklin, ahh
<sconklin> ok I think I drifted off topic a little.
<RAOF> jbarnes: But nouveau requires a different drm.ko to the one we ship, and that's shared.
<sconklin> bryce: the ptches that you pastebin'd - is that the entire drm-next diff from our tree?
<jbarnes> RAOF: yeah but it's mainly TTM functionality there afaik
<bryce> RAOF, sconklin, so really what -nouveau buys us is an out-of-the-box kms 2D experience on first boot (ooh nice boot), followed by installation of -nvidia and the usual teeth grinding on binary blobs ;-)
<jbarnes> unless they've also made some core mode setting changes or something
<bryce> sconklin, no I think RAOF selected the specific ones needed.  RAOF?
<RAOF> sconklin: It's the full diff of everything nouveau touches against our tree.
<sconklin> bryce, RAOF - plus we support open development, and provide some solid testing base and bug reporting for upstream.
<RAOF> sconklin: Upstream will unlikely to be terribly interested in our bugs, unless we track git closely.
<tormod> don't tell Bryce there will be more bug reports :P
<bryce> sconklin, right, and while in the near term you're right that this is to upstream's benefit mostly, since it's an LTS it hopefully means in the long term we'll be more able to deploy more fixes than if we stuck with -nv
<sconklin> RAOF: I intend to offer them the option of linking with lp through the upstream plugin, they probably won't want to.
<bryce> although that's kind of hand-wavy...  -nouveau is developing fast enough that I suspect backporting fixes to the LTS would only be realistic for some months before the codebases are too divergent.  
<RAOF> bryce: I support that assessment, although the bottleneck would be the kernel, rather than libdrm (because that's much more nicely isolated)
<sconklin> bryce: right. and I can forsee a degenerate situation where we end up sort of stuck with the LTS, but the testing we did there lets us turn our a really good M release
<sconklin> Yes, what I was describing was the kernel. But also remember this - that starting with Lucid we'll probably also have the ability to run later kernels on Lucid userspace
<RAOF> We could track git closely in xorg-edgers and require bug reporters to retry with that; upstream would likely be interested in _those_ bugs.
<sconklin> which gives people a choice
<sconklin> so I'd like to propose a plan (for the kernel at least)
<sconklin> That we (very soon) pull nouveau and the required drm-next into Lucid.
<sconklin> That we invest in heavy testing at alpha 1 and alpha 2, and give ourselves the chance to make an assessment after A1 whether to continue.
<sconklin> and whether to rebase to a more recent nouveau or to freeze and take selected patches.
<sconklin> If we freeze, then there's a good chance that by the time Lucid releases, linus's tree will have caught up with the drm-next that was used for nouveau.
<bryce> sconklin, +1 sounds good to me
<RAOF> +1 from me, too.
<sconklin> and we'll just be supporting nouveau + selected patches, without any drm sync problems.
<sconklin> ok, I'll write this up and send it around to the kernel group (and who else) - and which mailing lists am I not on that I need to be? - X related?
<tormod> linus's tree catch up with drm-next, isn't that 2.6.33 by definition?
<jcristau> tormod: rc1 :)
<tormod> and lucid has settled for 2.6.32 right
<sconklin> yeah, I think that's right.
<sconklin> so we won't get it.
<bryce> sconklin, ubuntu-x@lists.ubuntu.com
<sconklin> I would say here that pulling in drm-next is subject to veto by the kernel ack process
<sconklin> s/would/should/
<sconklin> I can't make those decisions unilaterally
<RAOF> I wouldn't expect as much.
<sconklin> No, just trying to be clear
<tormod> I wonder about alpha-1 that's like next week, right. shouldn't this be dogfood for at least a week? sounds like sorting out the right drm-next commits is not trivial
<sconklin> so I'll join the ubuntu-x list and then send this to both that and the kernel list, and shout if I get anything wrong, please
<sconklin> tormod: I know, and I'm getting beat up about some other unrelated things at the moment, so let me discuss the priorities with some people and see if I can get some help
<tormod> you'll get broad coverage but maybe more than you'd like
#ubuntu-x 2009-12-01
<bryce> tormod, alpha-1 is dec 10th
<sconklin> I've seen a number of opinions that graphics got worse from Jaunty->Karmic, I don't want to set up any sort of trend. And also, there are people irate over Fedora because 3d support is not good, but no one really tested 3d until after the release, and I think we'll see the same thing happen.
<tormod> bryce, which means freeze on 8th
<bryce> tormod, right
<bryce> sconklin, fwiw, every single release we have heard "graphics is worse!"
<sconklin> And if people think it's broken, none of the arguments we've made for going to nouveau will make any sense to them if it 'worked' before.
<sconklin> bryce: ok, I feel better :) maybe
<bryce> sconklin, what I think happens is we hear from people when things get worse, but not when they get better
<tormod> most of the things that got worse in Karmic were introduced around/after FF
<sconklin> bryce: agreed. It's the same with most kernel drivers. No news is really good news.
<jcristau> tormod: what was that, btw?
<tormod> key here is to get things in early and get everybody to test lucid continuously not wait for (late) alphas
<sconklin> yes.
<jcristau> tormod: (stuff that "got worse" in karmic)
<sconklin> some intel drivers got worse, although I think that's mostly resolved now - we froze in the middle of a bunch of changes that came from upstream.
<tormod> jcristau, there were a few radeon mesa regressions, well I don't know if there was much, u pstart issues got sorted out mostly
<jcristau> ok
<bryce> jcristau, gdm rewrite + upstart post-FF caused failsafe to break horribly; boot speed improvements exposed design flaws in dkms that can result in nvidia.ko not getting built 
<jcristau> so other than the mesa stuff that's not really X stuff
<sconklin> also, there were things like EDID quirke that didn't get migrated from X to the kernel KMS code, which caused apparent regressions (Bryce explained this to me)
<bryce> sconklin, the intel issues - were those the ones just for ironlake / new hardware?
<bryce> sconklin, oh right... still need to get that fixed up
<bryce> jcristau, right X just got caught in the crossfire for the most part
<sconklin> bryce: no, I think there were some suspend/resume issues that came up with old hardware. That patch is already out for an SRU.
<tormod> anyway, I think graphics in general got a lot better from Jaunty to Karmic, my "opinion"
<bryce> sconklin, ok
<bryce> oh also there have been some regressions on older ATI hardware where it falls back to XAA instead of EXA (as a workaround to still other problems)
<bryce> we should switch to Wayland
<bryce> it has *so* fewer bugs
<jcristau> it has *so* fewer users :)
<bryce> jcristau, perfect!
<bryce> bbiab (babysitting time)
<sconklin> fun times
<sconklin> RAOF: did you see that I had put up the Fedora kernel patch set for people to browse? There are some additional nouveau patches in there, which may very well now be in the upstream nouveau - I haven't had time to look
<RAOF> sconklin: I don't think I did see that; is it on ubuntu-x@?
<sconklin> no, I sent it to the kernel list, hang on for a link.
<RAOF> Oh, whoops.  Yeah, found it.
<sconklin> http://www.ai4qr.com/fedora12kernel/rpmbuild/
<sconklin> yeah
<sconklin> are you familiar with rpm's layout?
<sconklin> not that you have to go browse patches - I just thought you may be interested
<RAOF> No, but it's easy enough to find the patches.
<sconklin> in SOURCES :)
<RAOF> So, they've taken the route of dumping a huge "nouveau" patch on the kernel rather than pulling from the nouveau tree.
<sconklin> but there are patches in there that aren't actually used, so be wary
<sconklin> ha, yeah
<sconklin> and a 2.9M drm-next patch
<sconklin> it gives me the willies
<RAOF> Owch, yeah.
<pwnguin> RAOF: I'm guessing the "nouveau" patch is generated from git for packaging purposes
<RAOF> pwnguin: as in: git diff nouveau/master?  I'd guess, yes.
<pwnguin> so the individual patches might still be around
<sconklin> yeah. If we pull it in, it'll be probably done as a pull to a branch and a rebase, but that's andy's call - he's the git wizard. I know we won't do huge patches like that.
<sconklin> it's unmaintainable
<RAOF> As I say, if we pull from nouveau's kernel tree we pull in (a recent snapshot of) drm-next, too, due to frequent merges.  I don't know how you'd (the kernel team) want to deal with that.
<sconklin> I already handed that to Andy to think about.
<sconklin> but for the moment and for the purposes of the plan, I'm assuming that there's a magic step for making that happen in a sustainable way. It would be a first - we have
<RAOF> Heh.
<sconklin> always taken Linus's tree plus minimal patches
<sconklin> we do drop in drivers, but there's never been a situation like there is with drm
<RAOF> Interrelated drivers, what fun!
<RAOF> So, I guess my next action here would be a nouveau DDX package update, so we've got a shiny new snapshot for when the kernel does whatever it's going to do.
<Sarvatt> hmm, where are these patches at?
<Sarvatt> * Apply Julien Cristau's udev patches. from https://edge.launchpad.net/~pitti/+archive/halsectomy/+packages
<Sarvatt> grabbed the source for the xorg-server package there but i dont see any new patches in the series, guessing he applied them by hand? i was going to add them to the server in edgers
<tjaalton> Sarvatt: check the version in experimental
<tjaalton> it's there too
<Sarvatt> thanks tjaalton, found it there
<bryce> tjaalton, how goes 1.7?  need help merging stuff in?
<tjaalton> bryce: pretty well I think. xserver 1.7.2 broke the ABI, so we need to wait for 1.7.3 (which should happen RSN). we could start by syncing the protos from unstable/experimental
<tjaalton> and libs too
<bryce> ok
<tjaalton> some of them haven't been uploaded yet, though, but most are
<bryce> can't most of those just be sync'd?  do we need sync requests?
<bryce> oh duh, we're syncing from testing, that's why they're not already sync'd
<tjaalton> I've updated all the driver repo's, so those are just waiting for the 1.7.3, which should be uploaded to unstable once it's released AIUI
<tjaalton> right
<tjaalton> so they need manual syncs from unstable/experimental
<tjaalton> very few of them need merging
<bryce> ok, I'll work on those today
<tjaalton> but the most important one is probably xutil-dev which is a pre-req for many of the new versions :)
<tjaalton> the new version of xutil-dev, that is
<tjaalton> the only change we have on it probably makes sense for debian too, but since there's a rush to get all of this in a merge is probably worth it for now
<tjaalton> hmm looks like libxxf86{dga,vm} need some fixing until they can be uploaded (moved headers)
<tjaalton> I'll fix them shortly, but first something to eat.. ->
<Sarvatt> well thats no good, 2.6.32 still doesnt suspend/resume right but now I cant use a web browser on the 2.6.31-14 kernel without crashing x and getting this - [drm:i915_gem_object_bind_to_gtt] *ERROR* Invalid object alignment requested 4096
<marqy> hello. i've just upgraded to karmic and i've had a few issues with my graphics driver for my ati radeon 2400.
<marqy> i waas using fglrx but i couldn't boot the kernal except in safe mode, so i switched to the ati drivers. i still couldn't boot except in safe mode
<marqy> i turned off the splash screen to get some error messages and the kernal then booted and x has started fine
<marqy> although i don't have 3D rendering in my current state
<marqy> all in all a bit confused
<tormod> marqy, did you remove all the fglrx trash?
<marqy> i think so, it took a couple of attempts; 
<marqy> but it'd be nice to know how to be sure
<tormod> there is a wiki page https://wiki.ubuntu.com/X/Troubleshooting/FglrxInteferesWithRadeonDriver
<marqy> tormod: cheers, i had a look.  i took the manual steps to purge: removed xorg-driver-fglrx and reinstalled libgl1-*
<marqy> $ dpkg -l fglrx
<marqy> No packages found matching fglrx
<marqy> but locate fglrx returns a load of stuff in /usr/src/fglrx-8.561, usr/share/ati, lib/modules, /var/lib/dkms/fglrx and /var/lib/dpkg/info
<Sarvatt> uploading a new libdrm now incase you were in the middle of packaging one tormod lol
<Sarvatt> was just building it to check on new symbols
<tormod> Sarvatt, cool I am taking a break right now :)
<tormod> many intel's yesterday, many mesa's today
<tormod> Sarvatt, are you gonna add the udev patch to xserver?
<tormod> I forgot to reinstall pitti's after doing a dist-upgrade, and I got pretty screwed :)
<Sarvatt> more like 10 patches and a bunch of rules changes, haven't had a chance to look it over yet
 * bryce is syncreq'ing
<Sarvatt> i dont see the patches in his xserver though
<Sarvatt> think he applied them by hand
<tormod> not even the power button would react :)
<tormod> you can debdiff against yours
<Sarvatt> they're in the debian-experimental git
<tormod> but not all the rules are there yet
<Sarvatt> oh? darn gotta dig out the 20091111 server build then
<tormod> I had to add one for my SynPS protocol touchpad, pitti said jcristau would add it to git
<jcristau> yeah will be there soonish
<tormod> it only adds udev support and does not take hal support away, right?
<jcristau> tormod: you can still choose hal at build time
<tormod> jcristau, but you have to choose one of them?
<jcristau> yes
<jcristau> otherwise i don't see how you avoid duplicated events
<tormod> yeah
<bryce> tjaalton, all protos have sync req's filed
<jcristau> (also there probably wouldn't be much point.  all linux will use udev, !linux can stay with hal)
<bryce> tjaalton, I also syncreq's x11proto-input which had the XInput.h change - I assume we don't need that change any more, sounds like it got taken into debian at 1.9.99.902-1; let me know if otherwise
<tormod> jcristau, sure. I just wondered about this transition period with one version in xorg-edgers and another in lucid
<Sarvatt> isn't Xinput.h in libxi-dev now?
<bryce> Sarvatt, that's what 1.9.99.902-1 says, however I'm not sure we have the right version of libxi in ubuntu yet...
 * bryce moves on to syncing lib's
<tormod> Sarvatt, I remember that transition upstream in hardy time, a PITA for xorg-edgers...
<Sarvatt> think we should keep the old versions in edgers or delete them to clean it up tormod?
<tormod> Sarvatt, which old versions?
<Sarvatt> i dont really like the idea of telling people to use lucid sources on karmic like we were doing for jaunty-karmic because it was a nightmare explaining things to people who wanted to build packages
<Sarvatt> the protos and stuff that are already in lucid
<Sarvatt> can wittle it down to just the server eventually
<tormod> oh yes if it obsoleted by main it should be deleted
<tormod> like we were doing for jaunty-karmic? I don't understand or remember exactly?
<tormod> oh yeah cross-release mixing, yeah that can be a mess
<tjaalton> bryce: true about x11proto-input, can be synced now
<Sarvatt> we had libdrm-radeon1 on karmic but not on jaunty and people were mixing and matching packages
<bryce> tjaalton, ok 
<bryce>  * x11proto-input: sync req# 491051
<tormod> Sarvatt, your intel issues are on your netbook?
<bryce> tjaalton, all libs without ubuntu versions sync'd
<tjaalton> bryce: libdmx and libxext can be synced too
<bryce> tjaalton, rationale?
<tjaalton> libdmx runs autoreconf now
<tjaalton> on build
<tjaalton> libxext was pulled for moblin, and runs autoreconf now like the rest
<tjaalton> libxi should be syncable as well
<tjaalton> libxrender too
<tjaalton> (yet-another autoreconf)
<bryce> ok, I'm working through these, just need to specify the rationale ("all changes upstream", "was just a fakesync", "was rebuild with no source change", etc.)
<tjaalton> yeah, most of them are simple
 * bryce nods
<bryce> thank god I have a script for this now
<tjaalton> libxvmc syncable
<tjaalton> epoch is bumped in debian, the rest aren't that important I guess ;)
<tjaalton> +of the changes
<jcristau> what's your diff in libxfont?
<tjaalton> checking 
<tjaalton> debian/rules: unset LDFLAGS to not be hit by -Bsymbolic-functions, as libxfont contains weak symbols which are meant to be overriden (cf. LP #226156).
<ubottu> Launchpad bug 226156 in libxfont "After update in intrepid branch Xorg " [High,Fix released] https://launchpad.net/bugs/226156
<bryce>  * libxvmc: sync req# 491086
<jcristau> tjaalton: hmm i've seen one of those in a debian/rules a few days ago
<bryce> libxfontcache?
<jcristau> libxt has it
<jcristau> bryce: i've gotten libxfontcache removed from debian
<bryce>  * libxrender: sync req# 491088
<bryce>  * libxext: sync req# 491085
<jcristau> i got, even
<jcristau> tjaalton: if the diff is the same as in libxt, care to put it in libxfont debian-unstable before i prepare an upload?
<bryce> tjaalton, "libxi should be syncable as well" - mind doublechecking, seems quite a few changes, just want to be absolutely sure it's syncable
<bryce> https://edge.launchpad.net/ubuntu/+source/libxi/2:1.2.1-2ubuntu1
<tjaalton> bryce: it's the same as with inputproto
<bryce> jcristau, ok
<tjaalton> I'll check the status of patch 101
<tjaalton> jcristau: yes, I'll check the diff
<bryce>  * libxi: sync req# 491094
<jcristau> tjaalton: thanks.  i pushed an update of libxfont to 1.4.1 to git a few minutes ago, so i'll wait
 * bryce ignores libxfontcache for now
<bryce> (but noting that it's dropped in debian)
<jcristau> i think libxfontcache had no reverse deps in lenny
<tjaalton> jcristau: it's done by just appending LDFLAGS="" for configure
<jcristau> tjaalton: ah, ok
<bryce> libxkbfile has one patch - https://edge.launchpad.net/ubuntu/+source/libxkbfile/1:1.0.5-1ubuntu2
<jcristau> libxt specifically filters out -Bsymbolic-functions
<jcristau> bryce: pretty sure that's upstream
<bryce> ok, we'll do a merge on that to be sure
<bryce> tjaalton, libdrm ?
<bryce> changelog entry is a bit terse ;-)
<bryce> https://edge.launchpad.net/ubuntu/+source/libdrm/2.4.14-1ubuntu1
<jcristau> your libdrm builds -radeon iirc?
<tjaalton> yes, it's not syncable
<bryce> ah right
<tjaalton> at least not yet ;)
<bryce> libx11 probably needs merger attention too
<tjaalton> the full log is in git of course :)
<jcristau> bryce: http://git.debian.org/?p=pkg-xorg/lib/libxkbfile.git;a=commit;h=e695be2ab7eb1361b204f98c3da872eff58ad6b5
<bryce> alrighty, so except for libxfont I think all the libs and protos that can be sync'd are sync'd
<bryce> jcristau, aha awesome thanks
<tjaalton> or just check an older entry, if it's the same I usually don't bother
<bryce> oh wait, there is also kees' fortify-crash.diff patch in libxkbfile
<jcristau> upstream as well
<jcristau> http://git.debian.org/?p=pkg-xorg/lib/libxkbfile.git;a=commit;h=dd9514fe714d81b881a1bd6bd88d4287adc5fc7e
<bryce> aha excellent
<bryce>  * libxkbfile: sync req# 491103
<tjaalton> the libxi patch 101 was pulled from upstream, so it should be safe to sync
<tjaalton> but you already filed that, so it's good
<bryce> yep
<tjaalton> jcristau: libxinerama should be good?
<bryce> long sync list this cycle...  https://wiki.ubuntu.com/X/PackageNotes
<bryce> (and haven't even gotten to the good stuff yet)
<bryce> updated notes @ http://www2.bryceharrington.org:8080/X/PkgList/versions_current.html
<tjaalton> jcristau: also libxxf86dga and libxxf86vm have the Replaces, so whenever you have time.. :)
<tjaalton> checking libx11
<tjaalton> bah, not upstream
<tjaalton> bad robert
<tjaalton> "Fix 'locale not supported by XLib' errors for la locales" that is
<jcristau> what's that locale?
<tjaalton> la_AU.UTF-8
<jcristau> that isn't even in libc afaict..
<tjaalton> hehe
<tjaalton> apparently he created it
<tjaalton> and was turned down by upstream
<tjaalton> http://sourceware.org/bugzilla/show_bug.cgi?id=6583
<ubottu> sourceware.org bug 6583 in localedata "Please add a locale for Latin" [Enhancement,Resolved: wontfix]
<jcristau> yeah so i'm not going to carry that as a debian-specific patch
<jcristau> 003_recognize_glibc_2.3.2_locale_names.diff is enough of a nightmare as it is
<tjaalton> wow
<joumetal> http://alec.mooo.com/mpx.php looks intresting.
#ubuntu-x 2009-12-02
<apw> anyone know whether there is a how-to on getting different settings (such as keyboard layout) per input device in X ?
<tseliot> apw: yes, you can rely on the name and/or the id of the input device (which you can get from the "xinput list" command).
<tseliot> as regards keyboard layout you can use the device id
<tseliot> for example setxkbmap -device 2 -print
<tseliot> or something like that
<apw> tseliot, and is there somewhere you add that to get it to persist, as it gets lost on suspend
 * tseliot hasn't played much with setxkbmap
<tseliot> apw: in Gnome I *guess* the gnome-settings-daemon would take care of it
<tseliot> jcristau: ^^
<apw> tseliot, does xmodmap work per device too?
<apw> that is a poor question ... i want to change the layout, xsetxkbmap is good for that.  i also want to swap two keys on the new keyboard, can i do that on a per device basis
<tjaalton> I don't think there's gui support for it yet
<apw> happy to use command line for this for now
<tjaalton> I meant for g-s-d
<apw> ahh
<tjaalton> the tools are lacking
<tseliot> apw: I don't think xmodmap allows you to have per device settings
<bryce> tseliot, if you're around, there is a conf call with AMD today in about an hour
<tseliot> bryce: thanks but I don't think I'll be around in an hour. Maybe you can forward the report to me?
<tseliot> I mean the report on the call
<bryce> actually I don't really have anything to discuss with them, so was hoping the call would be of more usefulness to you
<tseliot> bryce: oh, nothing comes to my mind at the moment but maybe I can ask them next time (I'm quite busy with the new house)
<lyhana8> hi, I try to use ppa-purge, but IÂ´m running a Linux Mint 8 aka Helena and got plenty of error messages
<bryce> lyhana8, sorry I don't think it is supported on linux mint
<lyhana8> here is my log : http://pastebin.com/d53d34889
<lyhana8> LM is ubuntu-based, I think it's only the distro name that trigger the problem
<Sarvatt> yeah
<Sarvatt> is it based on a ubuntu release?
<lyhana8> yep
<lyhana8> http://www.linuxmint.com/about.php
<Sarvatt> you can try DIST="whatever" ppa-purge xorg-edgers
<Sarvatt> whatever the one you're using is based on
<lyhana8> http://en.wikipedia.org/wiki/Linux_Mint
<lyhana8> ok
<Sarvatt> i meant are those packages from the ubuntu archives instead of linux mint archives, no idea how they handle the dist thing
<lyhana8> I added the xorg-edgers repo manually
<lyhana8> well doesnÂ´t work : Warning:  Could not find package list for PPA: xorg-edgers ppa
<lyhana8> how can I do it manually ?
<Sarvatt> thats cus it removed it last time it failed
<Sarvatt> try uncommenting it from your sources then apt-get update then try again
<Sarvatt> you want to sudo apt-get install package/karmic package2/karmic to downgrade manually
<Sarvatt> or uncomment the edgers ppa in your apt sources and apt-get update to refresh it and try again with DIST="karmic" ppa-purge xorg-edgers
<tjaalton> bryce: I'll merge the xserver so it's (more) ready for upload once the prereqs are in
<lyhana8> Sarvatt: isnÂ´t removing the ppa and reinstalling the xorg-server package enough ?
<Sarvatt> nope
<lyhana8> same error, he look for an helena archive for each package
<lyhana8> did the package use lsb_release or something la that to know the context ?
<bryce> tjaalton, excellent
<Sarvatt> yeah it did
<Sarvatt> DIST=$(lsb_release -c -s)
<lyhana8> Sarvatt: so it override my DIST ?
<tjaalton> kees: is libaudit-dev finally in main (lucid) ?-)
<Sarvatt> did you use sudo somewhere in there or did you pass DIST="karmic" as root?
<lyhana8> I use the sudo commadn
<lyhana8> I try to remove the ppa version cause I think it make my firefox buggy
<Sarvatt> just run this command and bypass ppa-purge, http://pastebin.com/d6f09bb34 :D
<lyhana8> XD
<lyhana8> any idea if your driver can cause issue to firefox (flash) ?
<Sarvatt> yeah it sure could
<lyhana8> or this ppa : launchpad-weyland/xserver-nobackfill/ubuntu
<lyhana8> oh~
<lyhana8> Sarvatt: downgrade ok, i'll logout later. Thanks
<mac_v> hmm , even with kernel .32-6 ATI KMS performance is slow :(  ...
<mac_v> anyone know how to effectively measure the fps/speed reduction with KMS ?
 * mac_v was told glxgears isnt a good indicator
<tjaalton> try openarena or similar
<mac_v> hehe , i have to learn to play a new game :)
<mac_v> has been "on the wagon" for nearly 2yrs... ;)
<tjaalton> or run phoronix-test-suite
<mac_v> ah , great , ok
<mac_v> tjaalton: basically i wanted to help in testing , will those results help , or rather are they needed/essential?
 * mac_v realizes he asked the questions first :)
<tjaalton> we know it's slower
<tjaalton> phoronix has an article about it
<bryce> what is launchpad-weyland ?  Did someone package wayland?
<tjaalton> nah, the author is mathias weyland :)
<bryce> mac_v, what's needed is to locate patches upstream that haven't filtered down to us that sound like they would improve performance, patch your driver, and test *that*
<bryce> mac_v, and then if you find something which looks really good, flag it for our attention so we can look into incorporating it
 * mac_v is unfortuantely not good/technical enough to help bryce with patching and testing   :(
 * mac_v is more a noob , who can test ppa and whine when things are broken ;p
<bryce> heh, we have an oversupply of that at the moment ;-)
<mac_v> lol ;)
<bryce> one other thing we could use is regular performance testing
<bryce> do an upgrade each day to latest lucid, run the test suite, plot the data point on a graph
<bryce> and then make the graph available to us
<bryce> this would enable us to spot performance regressions (or improvements) faster
<Sarvatt> i'm surprised how good gallium is right now on i915 at least, simple things like qgears2 and glxgears are 2x faster and openarena is within 10% of the normal driver. the old build i did of it in july is 4-6x slower in the same things (or didnt even run them at all for the most part)
<mac_v> bryce: that i can do :)  ...  right now , what i have done is I'm running the Karmic with lucid kernels , in a few days once alpha 1 is released I'll fuly install Lucid on another partition and start doing that...
<Sarvatt> wish I knew of a way to make phoronix-test-suite not run some tests 3x so I wouldnt have to babysit it and manually exit the 2nd and 3rd runs, takes out my machine for 3 hours running openarena and smoking guns tests when i just want a rough idea of the speed
<bryce> Sarvatt, maybe yank out just that one test and package it to run in isolation?
<tjaalton> bryce: looks like the "remaining changes" -part of the xserver changelog was a mess, partly because of me :)
<tjaalton> it had obsolete information and nothing new, because I haven't been updating it when merging
<tjaalton> the diff, apart from patches, is pretty small
<virtuald> I thought the random dpms offs were fixed
<bryce> virtuald, should be yeah
<bryce> tjaalton, ok
<bryce> tjaalton, yeah this would be a good opportunity to do some housecleaning on xserver
<bryce> btw, I revamped the Xorg.0.log timing patch
<bryce> been testing it on my laptop, I can check it in, although I don't think there's much need to enable it
<tjaalton> ok, nice
<virtuald> bryce: i'm on edgers now, and a while after resume from ram my monitors turned off. i have an rv570.
<bryce> virtuald, let me know if you find a patch that fixes it
<bryce> although I'm more focused at the moment on what's in lucid than what's in edgers, but I'm open to looking at patches either way
<tjaalton> anyone else have issues loading http://cvs.fedoraproject.org on karmic (firefox), with intel gfx or other?
<tjaalton> it makes ffox take 100% cpu and takes several minutes..
<tjaalton> umm, http://cvs.fedoraproject.org/viewvc/devel
<virtuald> i don't know where or how to find such a patch, and i'll try to remember to try to reproduce on lucid
<tjaalton> bryce: should we still autoload poulsbo?
<bryce> tjaalton, do we?  thought that was defaulted to vesa in our xserver
<tjaalton> bryce: so it seems. anyway, the patch fails now
<tjaalton> hmm, done differently upstream
<tjaalton>             } else if (dev->device_id == 0x8108) {
<tjaalton>                 break; /* "hooray" for poulsbo */
<tjaalton> that should fall back to vesa then
<bryce> so that causes it to fall back to vesa?
<tjaalton> yes
<jcristau> yes
<bryce> should be fine
<tjaalton> echo :)
<bryce> I'd defer to alberto, he's more clued in on what the OEM team wants
<bryce> but they can patch it themselves for the psb hardware they ship
<tjaalton> they can change it later if needed
<tjaalton> that's the fourth patch I've tried to apply, and fourth to delete :)
<bryce> I don't think we have a -psb at present that'll work on lucid with xserver 1.7 anyway.  probably needs to go to vesa.
<tjaalton> two of the patches were from fedora, and dropped there. I doubt we should be shipping stuff the "upstream" doesn't
<bryce> tjaalton, just please give a mention of the patches being dropped and why.  Sometimes in troubleshooting a regression I have to figure out why a given patch was dropped so it would be helpful info.
<tjaalton> bryce: sure
<jcristau> i haven't looked at what f12 has on top of 1.7.x recently.
<jcristau> just cvs upped, though :)
<jcristau> ah there's the glx 1.4 thing
<jcristau> should probably steal that
<bryce> sconklin, btw do you know if the kms pageflip patch is on the radar for the 2.6.32 kernel?  http://www.phoronix.com/scan.php?page=news_item&px=NzY5OA
<sconklin> bryce: I wasn't familar with it, I can see
<bryce> if not, would be nice to have it in a ppa for testing purposes
<sconklin> bryce: according to the page you linked, it didn't make .32 - I'll try dropping it on top of our karmic and see what happens.
<jcristau> right it's queued for .33 upstream
<sconklin> bryce: I'm just now uploading a karmic kernel + the moblin speedup test patches to a PPA for Alberto to have a look at.
<bryce> sweet
<bryce> sconklin, I tested apw's karmic kernel with those patches, but on an SSD didn't spot changes to X's boot time (didn't look at kernel boot time)
<bryce> I'll test your kernel too
<sconklin> and andy is doing research with the sme patches for Lucid. Did you see Andy's email to kernel-list about accounting for the differences in moblin kernel speed?
<sconklin> He's accounted for all of the differences without the patches we're looking at
<apw> bryce, thats odd as tseliot claimed 2s with some x patches included
<sconklin> bryce: apw's kernel doesn't have all the patches that mine will, but they still may not make much difference
<bryce> sconklin, ok no I'm not on the kernel list
<bryce> apw, he thought it might be due to me running on SSD and him not on SSD
<apw> bryce, may be so indeed
<Sarvatt> do you use compiz jcristau? i just wrote down the time of every flicker for the past 30 minutes and when i turned on compiz halfway it went from having 80 seconds exactly between flickers alot of the times to 20 seconds
<bryce> apw, my X boots in <2 sec on SSD already, so a 2 sec savings would be pretty astounding ;-)
<apw> bryce, yeah it would
<bryce> I've a i945 laptop with a much longer X boot, I could try on that
<bryce> but since the target hardware is SSD, I'm sort of more interested in that case
<apw> yep.  testing here on the same
<jcristau> Sarvatt: no
<sconklin> bryce: basically, turning off initramfs and ISA-PNP results in a kernel init time of about 0.8S
<bryce> mm
<jcristau> Sarvatt: so that seems to match what you see
<Sarvatt> metacity compositing maybe? i didnt test that
<jcristau> no compositing for me.  plain old fluxbox.
<jcristau> oh i misread what you said
<jcristau> sorry
<apw> bryce, you done any testing on lucid yet..
<jcristau> thought you said it went 80 -> 20s by turning compiz *off*
 * apw thinks he just had a hang on there on the 10v
<apw> bryce, oh i forgot ... did you note ATI KMS is now on by default
<Sarvatt> its weird, if i stared at gnome terminal with nothing else open it'd have chunks of time where it'd go off 80 seconds exactly, if i opened a new program it'd almost always trigger it not long after
<bryce> apw, yeah I've got both my laptops on lucid now.
<apw> brave :)
<jcristau> Sarvatt: jesse suspected the fifo watermarks settings.  i haven't had time to play with that yet.
<bryce> I ran into an issue where upstart isn't starting gdm, unless I remove some line about kernel tty7 from grub.cfg
<apw> bryce, i think i saw a flicker on my 10v too, like a jump left an inch for a frame
<bryce> filed a bug
<apw> bryce, ouch
<bryce> apw, not so brave... I still keep my desktop on karmic for now ;-)
<jcristau> apw: what chip is the 10v?
<bryce> but I'm not traveling for the next couple months so if laptop breaks it's not a problem
<bryce> jcristau, i965 iirc
<apw> 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03)
<bryce> ah 945
<jcristau> could be the same bug Sarvatt and i are seeing
<Sarvatt> thats what I have, i get the flickering after a suspend/resume cycle every time on 2.6.32
<apw> bah ... and we are close to final on the kernel
 * jcristau gets it after boot, no suspend needed
<Sarvatt> also i cant suspend with a SD card mounted on 2.6.32
<Sarvatt> and its not a ubuntu patch problem, happens when i compile a vanilla kernel
<apw> Sarvatt, we had a patch for that in karmic and i think its still in lucid
<apw> may not work of course
<Sarvatt> hmm wonder if i suspend without a dpms off from pm-utils if it'll still flicker
<Sarvatt> or lock up on the solid color
<apw> Sarvatt, on the SD card thing, it hangs hard on suspend yes?
<Sarvatt> yeah, the screen wont turn off but the system freezes
<apw> as you can reproduce it, perhaps you could boot with 'no_console_suspend' on the kernel commad line, and try a suspend from VT1 using sudo pm-suspend
<apw> and see if you get a panic
<Sarvatt> i'll do that right now
<Sarvatt> same issue, /var/log/pm-suspend.log shows a success but it was frozen with the screen still on and unresponsive
<Sarvatt> http://paste.ubuntu.com/333422/
<sconklin> is it worth sending announcements of test kernels like the moblin patches on Karmic to the ubuntu-x list?
<tjaalton> bryce: preliminary merge done, there are a bunch of patches that need a review and/or a refresh
<tjaalton> we should probably replace patch 140 by disabling acpi altogether
<tjaalton> since it's not used by anything
<tjaalton> http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-server/xserver-1.6.0-less-acpi-brokenness.patch?revision=1.1&view=markup
<tjaalton> one way to do it :)
<Sarvatt> hmm, looking like a good excuse to go splurge on an SSD and just shutdown instead of suspending :D
<jcristau> tjaalton: patch 140 is obsolete anyway
<jcristau> (commit 7a05c8b1e70680ddd3b3e09ad448788f8d70a428)
<Sarvatt> 140 174 178 179 180 fix-dga-removal 181 182 183 185 187 Add-libgcrypt-as-an-option-for-sha1 were all upstream last i looked, but i was looking at master not 1.7 branch
<jcristau> Sarvatt: the libgcrypt one is only on master
#ubuntu-x 2009-12-03
<tjaalton> jcristau: oh, nice.. didn't spot that one
<bryce> heya
<tjaalton> howdy
<tjaalton> no archive-admin action yet, it seems :)
<bryce> yeah :-/
<bryce> I did mention the sync req's to rick
<bryce> if they don't get done in the next day I can ping some people
<tjaalton> most of the protos should be autosynced anyway, since they entered testing yesterday
<tjaalton> but I need to merge xutils-dev so they build
<tjaalton> maybe I should upgrade my laptop as well..
<tjaalton> before the madness
<tjaalton> mvo: hey, could the "failed to install" bugs attach the output of df to the bug. I suspect most of them are due to full root partition..
<tjaalton> 'df -l' would do
<mvo> hey tjaalton
<mvo> tjaalton: sure
<mvo> tjaalton: good idea
<mvo> hm, update-manager should check (well, approximate) that now, however apt itself does not
<tjaalton> mvo: great, thanks
<tjaalton> mvo: is it generally ok to drop Breaks/Depends/.. on packages from a past devel version (so that the version was not in the final release)?
<tjaalton> since I don't think we support upgrades from a past alpha
<mvo> yeah, that should be fine
<tjaalton> good
<mvo> tjaalton: df -l commited to my bzr branch, thanks
<tjaalton> mvo: excellent :)
<Unggnu> hi all
<Unggnu> I have read that the big X/Kernel changes are scheduled before Alpha 1. So it doesn't make sense/is dangerous before that to upgrade a Lucid Testing environment?
<Unggnu> Btw. which gain do we have through noveaou. I mean it has no 3D support yet afaik and KMS is good but most people would switch to the proprietary driver anyway.
<Unggnu> I mean nv is quite stable and has an alternative or are there many bugs for nv?
<tjaalton> bah, I upgraded an hour ago
<Unggnu> tjaalton, So the big changes hasn't happened yet or already? :)
<tjaalton> nv is pretty much dead
<tjaalton> Unggnu: not yet
<Unggnu> tjaalton, But they still make it work for new cards, 2d and xv or not anymore?
<tjaalton> waiting on syncs from debian, and xorg & xorg-server merges to be uploaded
<tjaalton> Unggnu: it has modesetting bugs that wont be fixed
<Unggnu> Ok, noveau would be great for old Nvidia cards that has no proprietary driver anymore but I doubt that it is already fast or so stable
<tjaalton> it's fast for 2D
<Unggnu> ok, I just thought it is a tough decision for LTS
<tjaalton> and some people can't get nv up at all
<Unggnu> I mean radeon driver is in development since a long time and still has no Powerplay
<Unggnu> which makes the computer pretty loud and uses much energy
<Unggnu> I don't know if the nv has the pendant.
<jcristau> it doesn't
<Unggnu> But with the edgers package KMS already works and textured video (still with tearing though).
<Unggnu> Ok, we will see how it works out. I haven't any Vvidia card anymore, at least not in use.
<Unggnu> Through ChromeOS and developments like this Nvidia will probably change their decison, at least I hope so
<Unggnu> The pressure through Dell has already worked in some areas afaik
<Ng> chromeos would be more likely to be used on a tegra type platform I would have thought?
<Unggnu> Ng, on Netbooks and in future it should be combine with Android afaik. Anyway Nvidia also produces chips for this devices afaik.
<Unggnu> If they only use open source drivers they have to change
<Ng> sure, the tegra, but I'm assuming wildly that it's very different to their desktop offerings
<Unggnu> synergy ;)
<Unggnu> KMS seems to work with nouveau even for nvidia TNT, that's cool.
<Unggnu> So Debian plans to use Nouveau in SID too?
<tjaalton> probably not as default. that would mean kernel changes
<tjaalton> which is the painful part
<Unggnu> yes, I have heard
<Unggnu> Radeon is also pretty fast without KMS
<Unggnu> but I think this was fixed lately
<Unggnu> Got to go, thanks for the information, bye.
<diverse_izzue> hi all, using kernel 2.6.32 from the mainline kernel ppa and the xorg-edgers ppa on karmic, i get no dri. xorg.log says:(EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch. [dri] radeon kernel module version is 2.0.0 but version 1.17.0 or newer is needed. [dri] Disabling DRI.
<diverse_izzue> any ideas?
<diverse_izzue> i should say that i also enable kms
<tjaalton> does .31 work?
<diverse_izzue> tjaalton, i'll check that, just a minute
<diverse_izzue> tjaalton, same thing with 2.6.31-15 from karmic repos
<tjaalton> don't use kms, it seems
<diverse_izzue> it does use KMS i believe
<tjaalton> but if you use modeset=1, DRI works
<tjaalton> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/394263
<ubottu> Ubuntu bug 394263 in linux "2.6.31 kernel breaks 3d for radeon x1600" [Undecided,Confirmed]
<tjaalton> erm, =0
<diverse_izzue> i'm quite sure it's someting in the updated  X stack, because i get dri with the X stack from karmic + KMS
<tjaalton> mesa then
<tjaalton> google for the error, there are tons of hits
<jcristau> diverse_izzue: your issue is either your ddx driver doesn't support kms, or there's a race when loading the radeon kernel module which makes this fail.
<diverse_izzue> jcristau, my ddx driver is the most recent one from the xorg-edgers ppa
<diverse_izzue> so probably number 2
<diverse_izzue> what to do about that?
<jcristau> modeset=0, or load radeon earlier
<diverse_izzue> how to load radeon earlier?
<diverse_izzue> have to go to the lab, back in a little while...
<tormod> bryce, can you join our radeon kms discussion on #ubuntu-kernel please?
<tjaalton> doubt he's awake yet
<diverse_izzue> the xorg wiki talks about the error: http://www.x.org/wiki/radeonBuildHowTo.
<tormod> hmm doesn't his son keep him awake all the time?
<tjaalton> hehe
<jcristau> tjaalton: i'd forgotten xft.. damn lib not starting with lib.  fixed now, on its way to sid.
<tjaalton> jcristau: hehe, time to rename it? :)
<tjaalton> it's libXft upstream
<tjaalton> so it would be even consistent :)
<tormod> diverse_izzue, it's not what they say on the x wiki
<diverse_izzue> tormod, but what...?
<tormod> diverse_izzue, the reason for that error message can be what the x wiki says, and it can be what my page says
<tormod> on Ubuntu, the x wiki explanation is not applicable since we build with the kms api
<apw> bryce, yo ... we are discussing the change to enable radeon kms on #u-k
<tormod> apw, I tried to wake him too :)
<apw> heheh
<tjaalton> so how does intel initialize early enough, but not radeon?
<tjaalton> is the module in initramfs?
<tjaalton> AIUI it isn't
<tormod> tjaalton, is the i915 force loaded somewhere, not by the X server?
<tjaalton> tormod: maybe, I don't know
<tormod> I just remember there was this i915 and fbcon(?) issues in karmic before release
<tormod> wasn't there some kind of race that got sorted out?
<tjaalton> apw: ^
<tjaalton> or should Keybuk know?
<tjaalton> things progress too fast for me :)
<tormod> I asked Keybuk about all this some days ago
<tormod> he did not know
<tjaalton> heh ok
<tormod> I thought I had more time to sort it out anyway :)
<apw> its odd, we load the drivers which do that very early, in responce to udev events for them
<apw> we then boot ... slowly for several seconds, then start X
<apw> how it could not be ready in time i do not know
<tormod> radeon does not load by itself
<tormod> I tried, see my gdm.conf on the wiki page
<apw> the radeon driver does not have module aliases ?
<tormod> if I remove "modprobe radeon" X does not start
<tjaalton> tormod: but kms worked?
<tormod> if I then manually modprobe radeon, boom X starts
<tjaalton> I mean, how can it work without radeon?
<tormod> no kms does not activate before
<apw> it can't work without radeon, but radeon should load automatically by itself
<tjaalton> right
<apw> if its done right
<tjaalton> it takes 2.5s for i915 to load here
<apw> but that is sychonous
<apw> so its done by the time X starts
<tormod> historically only the X server would make radeon load
<tormod> and only if the X server uses "radeon" DDX I guess
<tormod> and not if it uses fglrx
<tormod> so it's a chicken and hen element to this
<tormod> *egg
<apw> #if defined(CONFIG_DRM_RADEON_KMS)
<apw> MODULE_DEVICE_TABLE(pci, pciidlist);
<apw> #endif
<apw> if KMS is turned on in the build (which it is) then we should load the driver if the id's are listed
<tjaalton> ha
<tjaalton> maybe that would do it?
<apw> that is the current settings
<tormod> that is the current settings since a long time right?
<apw> so if you disabe the gdm upstart job, we'd expect to see it loaded by udev
<tjaalton> tormod: has anyone tried with a kernel where it's enabled?-)
<apw> all of karmic yes
<apw> thats enabled, with or without modesetting selected
<tormod> tjaalton, CONFIG_DRM_RADEON_KMS means support for KMS
<tormod> not that it is on by default
<tjaalton> ah right
<apw> yep we have the code ON but disabled by option
<tormod> well, it does not load by itself here
<apw> then the module aliases are wrong i would guess
<tormod> what can I check?
<tormod> wait I know
<apw> if you don't load it by default
<apw> then you can see what udev sees in its logs /var/log/udev
<tormod> my card is 1002:5653 and I see pci:v00001002d00005653sv*sd*bc*sc*i* in modinfo
<apw> tormod, there are a lot of id's listed
<apw> nope not listed
<tormod> is /var/log/udev kept logged to?
<apw> its a live file i believe
<apw>    This file is auto-generated from the drm_pciids.txt in the DRM CVS
<apw>    Please contact dri-devel@lists.sf.net to add new cards to this list
<apw> ok the list of supported id's has that comment in it
<tormod> apw, not listed where? I see it in modinfo
<apw> yeah ... hrm
<apw> it is in there
<apw> tormod, i see the ids in the source but not in the modules.alias file
<tormod> anyway, it can still be racy since kms init takes ~0.6s and X starts earlier and earlier
<apw> tormod, wa
<apw> tormod, what is the solution to that ... 
<tormod> apw, you saw my gdm.conf hack?
<tormod> there must be a real solution though
<tormod> drmCheckModesettingSupported in libdrm should not return before init is finished maybe
<tormod> if there's a way from userspace to see if drm init has finished regardless of kms support
<apw> we have an issue that we want X to start earlier to get things working qucker, but that makes people do init async, and we have no way to work out if its meant to be coming
<apw> the issue is that there is no way to know if the device will find an output and modeset it or not
<tormod> we could make drm emit an event and let gdm wait for it, but then if you boot something where there is no drm hw...
<apw> you need to know its done whether it did anything or not
<tormod> I am tending towards fixing radeon DDX, it knows it has a drm device, just have to wait for it to finish init before probing it
<tormod> I wonder if /dev/dri/card0 shows up before it is fully initialised?
<tormod> in other words, if /dev/dri/card0 shows up before /sys/class/.../drm/controlD* which is the KMS marker it probes for
<tormod> I mean /sys/bus/pci/devices/.../drm/controlD*
<tormod> yes it does, that is obvious from Xorg.0.log
<tormod> (more loud thinking in #radeon)
 * tormod notices libdrm 2.4.16 is out!
<apw> bryce, yo!
<apw> i reenabled ati kms, tormod seems to think that userspace is not ready, what do you want the Alpha-1 kernel to have  as the default, on or off?
<tormod> apw, I have some ideas to avoid potential races if the module already has been loaded and is under initialisation, but what about the fact that radeon is not loaded by itself?
<apw> its sounding like you guys just need to do more before this is ready
<apw> so i'll just turn it off again
<tormod> apw, yes I agree. we could add some quick workarounds now, but we need to find a better solution
<apw> we 
<bryce> heya apw
<apw> i'll put together an email tomorrow saying that we're turning it off
<tormod> would be good if more of you devs would run lucid and latest bits and KMS though
<apw> and you guys can argue about how to fx it for alpha2
<apw> we all sensibly have intel
<tormod> if I am the only one who have tested KMS, I would not enable it for everybody ATM
<apw> then we'll never enable it, which seems like no progress
<apw> bryce, talking about radeon
<tormod> yes that's bad that you all use the same hardware
<apw> i enabled it in the -6 kernel and its seeeming its not working
<apw> userspace issues, so i wanted to confirm whether i should switch it off for a1 or not
<bryce> if it is completely broken, there's not much time remaining pre-a1 for us to fix it
<apw> bryce, i thought from our disucssions at uds it was ok, but tormod says userspace isn't ready
<apw> perhaps you could disucss with him and let me know what you wnat the default to be for a1
<apw> i'll be uploading tommorrow am my time for the release
<apw> i have to run now, so drop me an email.... 
<bryce> leave it off
<apw> ack
<bryce> I tend to prefer switching things on right after a release, to give maximal time to test
<bryce> if we already know radeon kms doesn't work reliably, I'd rather not have the deluge of bug reports ;-)
<apw> ok so lpan of off for a1 and on in the first upload after thant
<bryce> yep
<bryce> I'll work out the plan with tormod for what we have to do on the userspace side and hopefully get that squared away in the mean time
<tormod> bryce, to summarize: radeon is not loaded before X loads it, but when X probes for KMS the module has not finished initializing so it thinks KMS is off
<tormod> and you get UMS and KMS at the same time!
<bryce> tormod, ah
<tormod> bryce, please read the backlog here, #ubuntu-kernel and #radeon
<bryce> tormod, could we just force it to expect KMS and sleep if it is missing?
<jcristau> tormod: afaict with CONFIG_DRM_RADEON_KMS=y, the radeon module exports a device table that should get it loaded automatically by whatever at boot
<bryce> hmm, I'm not on #radeon
<tormod> jcristau, I was discussing this with apw above, but it seems it is not loading
<bryce> hmm and looks like I caught only the tail end of the #ubuntu-kernel discussion...  mind re-summarizing the main bits for me?
<jcristau> hmm the MODULE_DEVICE_TABLE isn't enough?
<tormod> so maybe it is a kernel issue although apw blames userspace :)
<jcristau> well there's still another bug if 'modprobe radeon; drmCheckModesettingSupported()' fails
<tormod> bryce, I have a patch for what you suggested there :)
<tormod> jcristau, yes it is still racy
<jcristau> tormod: but that should only matter in the case where radeon doesn't get loaded by udev earlier
<tormod> jcristau, or everything starts up really quick :)
<jcristau> which is aiui the whole point of the device table
<tormod> note also that radeon will need firmware available, currently missing from initrd
<jcristau> it doesn't need to be in initrd
<tormod> depends on when you load radeon...
<jcristau> udev should load it after / is available, i think
<tormod> bryce, this is patch http://ubuntu.pastebin.com/d3b3afb7c
<bryce> tormod, firmware?
<tormod> bryce: platform radeon_cp.0: firmware: requesting radeon/R420_cp.bin
<bryce> tormod, yeah that's what I was thinking
<tormod> on my own laptop, I have a kms-ready.conf that waits for "filesystem" to load radeon
<tormod> then I let gdm.conf wait for kms-ready (which is NOP without KMS)
<jcristau> tormod: that patch seems wrong.  drmCheckModesettingSupported returns 0 if modesetting *is* supported
<tormod> jcristau, quite possibly, not tested yet :)
<bryce> tormod, oh right the command processor
<jcristau> also a 2s penalty for ums users seems a lot...
<tormod> not if KMS is default
<bryce> right ideally we don't care about UMS
<bryce> like with -intel people need UMS only to work around bugs
<bryce> (in theory, ideally)
<tormod> ideally drmCheckModesettingSupported should be fixed to wait if stuff is initialising
<jcristau> yes
<tormod> jcristau, this is not a upstream patch :) just a Ubuntu hack
<tormod> drmCheckModesettingSupported is kind of mickeymouse also IMO
<tormod> how difficult would it be to fix the radeon module to create a /sys file that tells if KMS is enabled or disabled (and not just one of them)
<bryce> jcristau, do you envision in debian testing wanting to support both UMS and KMS on radeon?
<jcristau> i don't think we'll turn radeon kms on by default if that was the question
<bryce> jcristau, since I know with -intel the plan is to eliminate UMS entirely, I'm sort of figuring supporting both to be just a transitional thing
<bryce> jcristau, ok gotcha
<jcristau> (if we do, we'd have to track whatever's in f12, since apparently dave didn't get all fixes in .32 final, and considering the manpower issues we have i don't think that's feasible
<jcristau> )
<tormod> since many users does kernel-hopping it would be good if user-space can deal with both active-by-default and not
<bryce> email from alex deucher:
<bryce> Any chance you can pull radeon drm bits from 2.6.33 during
<bryce> development?  We are planning to move radeon kms out of staging during
<bryce> 2.6.33 and there are a number of important patches already queued for
<bryce> 2.6.33: a number of bug fixes, tmds support on pre-avivo igp chips,
<bryce> interrupt support on r6xx/r7xx, and displayport support to name a few.
<bryce>  
<bryce> Displayport is supported now in xf86-video-ati master for UMS, and for
<bryce> KMS the patches are in drm-radeon-testing.  I hope to have the
<bryce> interrupt bits for KMS DP/HPD merged soon too.  This will give us
<bryce> interrupt driven monitor detection which will trigger a uevent (e.g.,
<bryce> box pops up saying: "You've attached/disconnected a monitor", etc.).
<bryce>  
<bryce> monitor uevents... sweetness
<tormod> anyone here on radeon UMS ATM?
<bryce> yes
<tormod> can you pastebin your "find /sys/devices/pci-blahblahvideocard" ?
<bryce> http://pastebin.ubuntu.com/334037/
<tormod> thanks
<tormod> my KMS one: http://ubuntu.pastebin.com/d43af9bdf drmCheckModesettingSupported looks for drm/controlD* in there
<bryce> tjaalton, how are we looking for the 1.7 merge?  would it help if I work on some of the misc. outstanding merges?
<tjaalton> bryce: 44 packages are waiting to be synced
<tjaalton> xorg & xorg-server are merged, but the latter has some patches that need a review & refresh
<bryce> tjaalton, right, beyond the syncs anything else needed that I should work on?
<tjaalton> well, maybe have a look at the patches and see if they are needed?
<tjaalton> I've updated the versions page with some new syncs and comments
<bryce> ok
<bryce> I've pinged pitti to do the syncs
<tjaalton> great
<bryce> are the patches to review flagged somehow in git?
<bryce> ah yes they are
<bryce> ok on it
<tjaalton> uncommented from series, and marked in the changelog
<tormod> are you gonna use udev in the xserver for A1?
<tjaalton> yes
<tormod> cool
<bryce> hrmph, everyone complains "canonical doesn't contribute to X.org upstream", yet here are all these patches I made and sent upstream and they never got taken (or got a reply as to why not)
<bryce> and I continue to wait for my fdo git account  :-P  https://bugs.freedesktop.org/show_bug.cgi?id=20373
<ubottu> Freedesktop bug 20373 in Account Modification Requests "Please add gpg key to this account" [Major,New]
<tjaalton> maybe ping someone on #xorg-devel?
<tjaalton> and the workflow has changed, so direct commits to master are a no-go, so posting patches for a review doesn't require the login (not that it would harm either..)
<tjaalton> but maybe it's just the xserver that follows this, dunno
<bryce> oh interesting
<bryce> yeah mainly I wanted access to do work on -ati
<tjaalton> it's been discussed on the list several times the past few months :)
<bryce> yeah read those, and also discussed at XDC which I attended.
<bryce> you'd think I'd remember these things
<tjaalton> oh right
<tjaalton> hehe
<jcristau> it's mostly for the server, where keith is the one to push to master
<bryce> yeah I guess I can try pushing the patches in again
<bryce> iirc some of them whot said were just papering over issues and he'd prefer to crash in those situations
<jcristau> i need to resend the udev stuff
<bryce> I tend to prefer issuing a warning in Xorg.0.log and not crash... seems more friendly to the user
<Sarvatt> patch 169 obsoleted by http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.7-branch&id=3d30789a05a730a03faa6058c73a5eda36ef3779 ?
<bryce> Sarvatt, unfortunately that's not the only place where MIPOINTER() is dereferenced without checking for NULL
<tormod> tjaalton, I don't see the touchpad rule in git yet
<bryce> Sarvatt, grepping launchpad, patch 169's error string does show up in a couple bug reports (for proprietary drivers).
<bryce> maybe those are outdated, I didn't check
<jcristau> tormod: i think i pushed it to -synaptics...
<tormod> jcristau, oh that would make sense 
<bryce> tjaalton, looks like the syncs are coming in
<bryce> libs at least so far
<tjaalton> bryce: yep :)
<bryce> looks like lp is about to go down so rest are going to wait for tomorrow
<tjaalton> it's only 90min or so
<bryce> I think pitti wants to go to bed
<tjaalton> ah, right :)
<Sarvatt> at least most of that wont build without the missing protos so things wont be broken until then :D
<tjaalton> yep
<bryce> ok, down to two patches
<bryce> but oy, saved the hardest for last
<Sarvatt> nothing can be worse than libx11's 03 patch lol
<Sarvatt> which one is left?
<bryce> 003_recognize_glibc_2.3.2_locale_names.diff ?
<bryce>     - 135_rethrow_signals.patch - TODO: Refresh
<bryce>     - 190_cache-xkbcomp_output_for_fast_start_up.patch
<bryce> <pitti> bryce: ok, it's still alive, synced all bug bug 491051
<ubottu> Launchpad bug 491051 in x11proto-input "[Sync Request] Please sync x11proto-input (1.5.0-2) from Debian [unstable] (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/491051
<Sarvatt> ugh yeah thats the nightmare one I spent 8 hours refreshing
<bryce> oop he did that one too
<tjaalton> bryce: 003? where's that from?
<bryce> tjaalton, ok all in
<bryce> tjaalton libx11
<tjaalton> hehe
<Sarvatt> libx11, sorry was talking about nightmare patches
<tjaalton> the infamous la_AU patch
<bryce> Sarvatt, 006 looks bad too (at least, it's huge)
<Sarvatt> wait, you need x11proto-input 2.0 from experimental not the one from unstable dont you?
<tjaalton> indeed
<bryce> $ diffstat 006_tailor_pt_BR.UTF-8_Compose.diff 
<bryce>  Compose.pre | 5619 ------------------------------------------------------------
<bryce>  1 file changed, 1 insertion(+), 5618 deletions(-)
<bryce> ok maybe not so bad, just deletes a lot of stuff :-)
<tjaalton> huh
<bryce> Sarvatt, yes, the bug was just misfiled, my bad
<jcristau> Sarvatt: want to help getting it upstream?
<jcristau> :)
<tjaalton> bryce: only patch 16 is ours
<tjaalton> 016 I mean
<tjaalton> so it's a simple merge
<bryce> hey, speaking of XI2, does this finally get rid of the 256 limitation on key codes?
<bryce> or is that a more fundamental X11 protocol issue?
<jcristau> the core protocol still only has 8bit for keycodes
<jcristau> but i think apps can listen to xi2 events and get 32bit keycodes
<jcristau> so we probably still need xkb2 and then fix clients
<bryce> jcristau, so will only apply for xi2 compliant apps?
<bryce> do apps need changed to use this or is it something that can be taken care of by the toolkits?
<jcristau> bryce: may be enough to migrate toolkits
<jcristau> that's probably all that's needed
 * bryce nods
<jcristau> but then it's possible even fewer people understand gtk's input code than X's
<jcristau> ;)
<bryce> lol
<Sarvatt> refreshing the udev patch for master and i'll upload it in a bit tormod
<Sarvatt> oh darn he just left, nevermind
<bryce> ok patch 135 done, one patch left
<bryce> done
<bryce> and refreshed/re-enabled the timing patch 160 for good measure
<Sarvatt> that one fails nastily on master :D
<bryce> Sarvatt, the timing patch?
<Sarvatt> 190_cache-xkbcomp_output_for_fast_start_up.patch
<bryce> oh
<bryce> it required only minor tweaking to get it to apply (just one chunk was off)
<tjaalton> bryce: so 156 is no longer needed?
<tjaalton> the commits were a bit messy ;)
<bryce> tjaalton, where might I best snag xorg-server_1.7.2.orig.tar.gz ?  I'll do a build test
<tjaalton> packages.debian.org?
<jcristau> ftp.debian.org works
<tjaalton> that too
<bryce> tjaalton, my commits were messy?  sorry about that, tried to keep one commit per patch
<tjaalton> well, some changelog edits etc. and patch 156 is still in git and enabled, also referenced in the changelog :)
<Sarvatt> sweet, changelog is down to 4 hooks for xorg-server master now from about 40 :D
<bryce> oh whoops
 * bryce fixifies
<bryce> pushed
<tjaalton> thanks
<Sarvatt> 02_Add-libgcrypt-as-an-option-for-sha1.diff is upstream 164_trap-aspect-ratios.patch fails 190_cache-xkbcomp_output_for_fast_start_up.patch fails and 12-Add-libudev-input-hotplug-backend.diff just needed 2 words changed. ah yeah and --disable-werror needed to be changed to --disable-strict-compilation in rules on master
<bryce> what's the error on 190?
<bryce> ftp.debian.org is slooow
<Sarvatt> wait, you're patching the patch in the patch?
<Sarvatt> in 190
<Sarvatt> --- a/debian/patches/190_cache-xkbcomp_output_for_fast_start_up.patch
<Sarvatt> +++ b/debian/patches/190_cache-xkbcomp_output_for_fast_start_up.patch
<bryce> oh hell
<bryce> hang on
<tjaalton> :)
<bryce> wow I made a mess
<bryce> er, wait maybe not
<Sarvatt> all of configure.ac and 2 hunks out of ddxLoad.c failed on master though before the patch patched itself and tried to delete all the other hunks :D
<Sarvatt> that patch just speeds up startup times after the first one?
<bryce> ok I think I see what happened
<Sarvatt> lucid's got a pretty nasty bug right now, all the standard preferences and administration items are gone from the menus
<RAOF> I guess now's not the time to restart, then.
<Sarvatt> not till ya get a gnome-menus update for sure
<bryce> fixed (I think) 190 pushed
<bryce> my pbuilder env is not getting the new protos for some reason
<bryce> and                                 Depends: libxi-dev (>= 2:1.2.99.1) but 2:1.2.1-2ubuntu1 is to be installed.
<Sarvatt> thats a good sign --
<Sarvatt> robert@ubuntu-9{/opt/source/xorg-pkg-tools}:aptitude show x11proto-xext-dev
<Sarvatt> Segmentation fault
<Sarvatt> :D
<bryce> maybe not everything got sync'd after all?
<Sarvatt> think it's even moved past the libs that were synced before the protos that wont build yet?
#ubuntu-x 2009-12-04
<Sarvatt> i *just* got libxfont
<Sarvatt> shoot cant use apt-get either
<bryce> grumble grumble
<bryce> well, at least I did verify this time that 190 applies
<Sarvatt> somethings majorly screwed up, i better reboot and hope for the best
<johanbr> hmm... nouveau + all the other bits from xorg-edgers fails for me, "error opening the drm"
<johanbr> http://pastebin.com/f2c14c96b
<bryce> Sarvatt, luck?
<Sarvatt> yeah just something screwy. latest intel git doesnt boot x though which was fun to find out :D
<Sarvatt> Version: 7.0.16~git20091111.3ec82cd7-0ubuntu0sarvatt  Version: 7.0.15-1 for x11proto-core-dev, looks like the protos arent even built yet
<Sarvatt> oh hey
<Sarvatt> 190 actually applies to master now with your change
<bryce> good
<RAOF> Argh!  Why do I _still_ need to look up 'git help checkout' to switch to an upstream branch?
<Sarvatt> shoot, auto-xorg-git changes coming back to bite me now that it was updated, i used ~ instead of + in alot of the protos and libs so >=1.2.0 build deps fail for 1.2.0~whatever
<RAOF> Should I upload a new nouveau-kernel-source package to Lucid, or wait for whatever falls out of the kernel team discussions?
<RAOF> Interesting context: nouveau is currently untestable on Lucid, because the current nouveau-kernel-source fails to build against 2.6.32 kernels.
<bryce> RAOF, I'd doublecheck with the kernel team first
<Sarvatt> oops, looks like 177_animated_cursor_change_master.patch needs to go too
<Sarvatt> ../../render/animcur.c: In function âAnimCurDisplayCursorâ:
<Sarvatt> ../../render/animcur.c:222: error: âstruct _DeviceIntRecâ has no member named âisMasterâ
<Sarvatt> thats on master but will be the same on 1.7 branch -- http://cgit.freedesktop.org/xorg/xserver/commit/?id=b12d302df8283186ce87882c29b2b0294adb2770
<Sarvatt> darn http://paste.ubuntu.com/334210/
<Sarvatt> yep 177 fails on 1.7.2 too
<Sarvatt> checking if 190_cache-xkbcomp_output_for_fast_start_up.patch makes 1.7.2 fail to build now too like it does master
<Sarvatt> pushing this little atom cpu hard tonight :)
<bryce> hehe
<bryce> hrm, wonder if there exists an updated version of 190
<bryce> bugger my pbuilder environment still isn't updated
<bryce> well, we can leave 190 disabled for alpha-1, that won't be the end of the world
<bryce> ditto 177
<Sarvatt> yeah i'm using edgers just to see if things work, had to change x11proto-xf86bigfont-dev (>= 1.2.0), to x11proto-xf86bigfont-dev (>= 1.1.99), to make it build because of 1.2.0~ behind lower than 1.2.0
<Sarvatt> hmm 
<Sarvatt> checking for DMXMODULES... yes
<Sarvatt> ../configure: line 20715: XDMXCONFIG_DEP_CFLAGS: command not found
<Sarvatt> ../configure: line 20716: C: command not found
<Sarvatt> ../configure: line 20717: XDMXCONFIG_DEP_LIBS: command not found
<Sarvatt> ../configure: line 20718: linker: command not found
<Sarvatt> (sorry for so many lines at once)
<Sarvatt> 1.7.2 failed the same as master with 190 applied :(
<jcristau> Sarvatt: that's fixed in 1.7.3
<jcristau> that doesn't fail the build here tho
<Sarvatt> yeah doesnt fail, just saw the error while that one was building
<Sarvatt> same failure on 1.7.2 with 190 though http://paste.ubuntu.com/334216/
 * bryce comments out in git
<bryce> it's my fault, I said "190 was easy" earlier and jinxed us
<Sarvatt> now its failing in hw/xfree86/common/xf86Events.c :(
<Sarvatt> patch 135
<Sarvatt> trying 1.7.2 to see if it fails there too
<Sarvatt> gotta love ccache
<Sarvatt> http://paste.ubuntu.com/334223/
<RAOF> Ok.  So, nouveau would also like libdrm 2.4.16 for Lucid.
<Sarvatt> intel requires 2.4.16 to build now too
<RAOF> And it looks like it's practically finished in pkg-xorg git.
<Sarvatt> darn, ccache doesnt work when you build 2 seperate versions of the same package :D
<Sarvatt> and i'm an idiot.. disabled 135 when i built 1.7.2 to see if 135 made it fail that time :D
<Sarvatt> yeah 135 fails on 1.7.2 in origin/ubuntu too :( http://paste.ubuntu.com/334228/
<Sarvatt> builds fine without it
<Amaranth> oh yeah, can we drop the XAA hack now? I don't think any driver that supports compiz uses XAA by default anymore
<Amaranth> I can't drop the compiz half of it until the Xorg half is gone
<bryce> which XAA hack is this?
 * Amaranth looks for it
<bryce> the radeon XAA hack for low mem cards?
<Amaranth> it was a way to dynamically enable XaaNoOffscreenPixmaps
<Amaranth> from way back in feisty or something
<Amaranth> looks like maybe it's gone already
<Amaranth> I know it wasn't some time during karmic development though
<bryce> if you spot it, let me know
<bryce> we mostly don't care about XAA anymore
<Amaranth> well nothing in debian/patches mentions _COMPIZ_GL_INCLUDE_INFERIORS anymore so I guess it is gone
<bryce> Amaranth, there actually is a situation where XAA is used on -ati
<bryce> upstream found that on some antique cards they can't do EXA very well so they do XAA by default on them
<Sarvatt> they'd have to be crazy to be using compiz in that situation where they have 32mb or under video ram though lol
<Amaranth> those are the same ones that report invalid GL_MAX_TEXTURE_SIZE, aren't they?
<bryce> however from what I've seen and heard this causes as much trouble as it solves, and I'm tempted to just force it all EXA anyway, and deal with the EXA bugs
<bryce> Sarvatt, what our users crazy?
<Amaranth> that need KMS to do it properly because they create a buffer large enough to fit the screen when rotated so they run out of memory
<Sarvatt> doesn't fglrx use XAA still? I dont use it but thought it did for some reason
<Amaranth> Pretty sure they have almost useful XRender acceleration so I don't think so
<Sarvatt> thats the most positive comment about fglrx 2d acceleration i've ever heard
<Sarvatt> wow 1.7.2 has a _huge_ load of dmx compile warnings, no wonder they rushed out 1.7.3
<Amaranth> Well, fglrx is almost faster than software :)
<Sarvatt> how many times is this darn xserver compile going to run the tests
<Sarvatt> ...answer is 2
 * Amaranth stabs xmodmap
<Sarvatt> yep fully compiles fine without 135_rethrow_signals.patch. not the full build log because my scrollback didnt go back far enough: http://sarvatt.com/downloads/xserver_1.7.2_buildlog.txt
<Sarvatt> not the same build environment that is going to be in lucid as soon as the stuff builds though of course
<Amaranth> bryce: Should I turn on the compiz reflection plugin to test your GPU wedge hook? :)
<Sarvatt> patches.ubuntu.com doesnt have the extracted patch folders anymore? :(
<Sarvatt> hmm, guess it isnt that big a deal not having the apport hooks in the edgers packages but i need to add a hook for the intel-gpu-tools recommends update
<Sarvatt> intel hasnt been stable upstream in almost a month now, i'm still having to use ones checked out on 11-11
<Sarvatt> oh wait its 11/06, forgot i reverted back and dated it higher so it'd override the broken ones even then
<Sarvatt> 2.9.99.901 release is ok except I cant use it on a 2.6.31 kernel without it killing x randomly, and cant suspend without the flickering problems under 2.6.32 on any 2.9.x release
<Sarvatt> hmmm so what all do I need for this new udev driven xserver? i see synaptics in experimental has a udev rule installed with it, need to do anything special with evdev?
<Sarvatt> oh theres a ubuntu branch for evdev now? sweet
<Sarvatt> ubuntu did it different than debian before where hal installed the evdev fdi so i wasnt sure if udev installed an evdev rule or something like that
<Sarvatt> lets see how this udev xserver works now. when I dont come back things blew up horribly :)
<Sarvatt> i'm always disappointed when things just work :D
<Sarvatt> was I supposed to purge hal first?
<tjaalton> bryce: yeah I don't think the protos/libs are all built and published yet
<tjaalton> Sarvatt: good catch on that merge goof, I forgot to add the VCS bits back
<Sarvatt> the publisher is screwed up or something, even ppa builds arent getting published even though they say they have been and the protos built 6 hours ago https://edge.launchpad.net/ubuntu/lucid/i386/+builds?build_text=&build_state=all
<tjaalton> yes, well LP has been down for hours
<tjaalton> and been up maybe an hour or so
<tjaalton> ah, those have been built fine, so it's the publisher alright
<Sarvatt> x11proto-xf86bigfont built about 45 minutes ago on edgers and it still isnt getting used building server
<Sarvatt> watched it turn into a gear then finish getting published but still not up for download either
<Sarvatt> hmm looks like xfonts-utils is missing in the server build deps
<Sarvatt> failed on the PPA configure.ac:41: error: must install fontutil 1.1 or later before running autoconf/autogen but its got font-util 1.1.1 in the PPA
<Sarvatt> might be a xserver master only problem though
<tjaalton> 1.7 doesn't check fontutil at all
<Sarvatt> well its starting to update, x11proto-xinerama is breaking gtk app builds ;D
<Sarvatt> hmm libx11 didnt get synced
<Sarvatt> someone just hit rebuild on all the dep wait libs at the same time, of course it's going to fail :D
<tjaalton> well, there are errors too
<tjaalton> since the headers were moved...
<tjaalton> although it shouldn't have mattered
<tjaalton> if the deps were right, the packages would have been waiting in the depwait queue
<tjaalton> stupid g-t can't open urls with epochs :)
<tjaalton> Sarvatt: ok, maybe the build-deps should have been versioned, seems like four packages failed to build because the old version was available
<tjaalton> Sarvatt: and libx11 can't be synced
<tjaalton> if we are going to keep the la_AU stuff
<tjaalton> so there are a couple of libs that need to bump the build-dep on libxext-dev
<tjaalton> we are fine though, since the builds can be retried later
<hyperair> Sarvatt: it seems that X segfaults when changing resolution on i965..
<hyperair> using xorg-edger
<hyperair> 3: /usr/lib/xorg/modules/drivers//intel_drv.so(i830_set_pixmap_bo+0x4b) [0x7fda715b2d6b]
<hyperair> 4: /usr/lib/xorg/modules/drivers//intel_drv.so [0x7fda715c0f7d]
<hyperair> weird that it's calling an i830 function
<hyperair> hmm there's a new x-x-v-intel around so i'll just upgrade and see
<tjaalton> bryce: so, some libs failed to build because our libxext was newer than what the xextproto was set to Breaks. Once the synced libxext is everywhere, I'll order a round of rebuilds for the missing libs (four of them)
<hyperair> ...this has to be the first time i've ever seen X screw up so bad i can't even use a terminal
<paran> is this the right place to report problems with packages from xorg-edgers ppa?
<tjaalton> if the guilty are here
<paran> tjaalton: fair enough
<tjaalton> tormod and Sarvatt are the ones you want
<tjaalton> tormod is missing atm
<paran> Sarvatt should be the guilty one in my case... Or, probably intel upstream
<paran> I tried the latest intel packages (2.9.99.901+git20091202.a938673e-0ubuntu0sarvatt~karmic), too much glitches to even run a terminal windows
<paran> characters only show up as black boxes, until I switch desktop back and forth
<paran> gnome-terminal in a pretty much default karmic gnome installation
<paran> the previous version 2:2.9.1~git-0ubuntu0tormod caused some corrupted fonts after suspend (not the same corruption), but was otherwise ok.
<paran> also thanks a lot for the ppa-purge script, very useful :)
<freeflyi1g> hi dudes, how to use thinkpad's trackpoint on karmic? 
<freeflyi1g> I already configure it with gpointing-device-settings
<freeflyi1g> X.0.log and lsinput output are here
<freeflyi1g> http://paste.ubuntu.com/334564
<freeflyi1g> http://paste.ubuntu.com/334565
<freeflyi1g> tseliot: any clues?
<tseliot> freeflyi1g: it should work just like a mouse, in relative mode, I guess
<freeflyi1g> tseliot: I didn't get that lucky :)
<tseliot> freeflyi1g: what's the problem?
<freeflyi1g> tseliot: like scrolling can't be used
<tseliot> tjaalton: ^^
 * tseliot doesn't own a trackpoint
<tjaalton> tseliot: can't check the urls now. xinput should work though
<tseliot> does scrolling work with trackpoints?
<tseliot> is it supposed to?
<tjaalton> it's disabled by default
<tjaalton> you need to hold a button down and then scroll
<tjaalton> middlemouse by default
<freeflyi1g> tjaalton: is there anything need to be done in kernel?
<tjaalton> freeflyi1g: no
<freeflyi1g> tjaalton: then trackpoint can't be detected here, I'm using lucid
<tjaalton> xinput list, xinput list-props $id, xinput set-int-prop...
<tjaalton> it doesn't work at all?
<freeflyi1g> tjaalton: just the scrolling
<tjaalton> so use xinput
<tjaalton> to enble the property
<tjaalton> +a
<Sarvatt> darn libxinerama needs to publish already, cant build anything right now
<bryce> tjaalton, aha.  did xextproto get fixed up?  anything I can do to help with this?
<tjaalton> bryce: everything should be ready, but apparently libxinerama needs a retry?
<Sarvatt> xinerama built fine
<Sarvatt> https://edge.launchpad.net/ubuntu/+source/libxinerama/2:1.1-1/+build/1378080
<Sarvatt> installing x11proto-xinerama-dev wanted to remove all of gnome dev packages too
<Sarvatt> proto breaks the old libxinerama-dev version is all
<tjaalton> I don't follow..
<Sarvatt> hyperair: you and me both! intel git is so messed up right now
<Sarvatt> libgtk2.0-dev tries to pull in libxinerama-dev
<tjaalton> ok, so it's just a matter of time then
<tormod> Sarvatt, I got libxinerama-dev 1.1 a few hours ago
<tjaalton> bryce: the drivers might make it in debian this weekend (depends if there are people to upload them), which would allow us to sync them on monday
<Sarvatt> ok both of the mirrors i use are screwy then, one didnt have the protos at all
<tjaalton> gotta go again ->
<bryce> tjaalton, ok
<bryce> regarding xorg-edgers breakages... especially this cycle we probably should encourage people to look to upstream when they run into issues
<hyperair> Sarvatt: ..again, huh.
<tormod> bryce, that's usually what we do when they use xorg-edgers
<bryce> tormod, ok
<hyperair> Sarvatt: well hopefully it'll get stable before the next release
<Sarvatt> hyperair: yeah its like a year ago only worse this past month in intel git :D i'm still using a checkout from 11/06 since it was the last time things just worked
<hyperair> Sarvatt: heh, i've gone back to using the one in karmic =D
<Sarvatt> oh not using lucid then?
<tormod> bryce, it's also the main reason for xorg-edgers :) when upstream says "so you have a bug - try latest git"
<tormod> what's cool now is that with lucid A1 + xorg-edgers, you have pretty much everything latest git, kernel, mesa, xserver, drivers
<Sarvatt> phew! the libxinerama problem was just a mirror problem, both of the ones I tried weren't updated
<hyperair> Sarvatt: no, not using lucid. i think i'll wait until somewhere around alpha 2 or so before upgrading
<tormod> Sarvatt, you might noticed libxinerama worked fine in xorg-edgers also :)
<bryce> tormod, right, I was just concerned with the number of people coming here for help with xorg-edgers issues
<bryce> concerned in the sense that I don't want Sarvatt wearing himself out!  :-)
<tormod> bryce, well that's fine, so we know what's up and can tell them/upstream. as long as it does not get too busy in this channel :)
<tormod> yes we don't want that!
 * Sarvatt disappears for months again
<Sarvatt> woohoo, took 6 reboots but I made it into X with the latest intel :D
<tormod> Sarvatt, your 12-Add-libudev... does not apply against master?
<Sarvatt> i have a hook to wget a refreshed one that does
<tormod> yes, the wget'ed one does not apply, unless I am doing something stupid
<tormod> yes I did ^
<Sarvatt> phew
<Sarvatt> was going to say, it was working 30 minutes ago when i uploaded a new xserver
<tormod> I had the old version laying around, did you just change it?
<Sarvatt> change what? the patch? nope havent touched it since last night
<Sarvatt> ahh i've gotta run, 2 hours late to a job :D
<Sarvatt> jcristau: the flashing on 2.6.32 is fixed in drm-intel-next for me. of course what fixed it i have no clue
<Sarvatt> down to 7.4w idle power usage now from around 8.1 too. i just tried this out since drm-intel-next doesnt merge into 2.6.32 cleanly right now http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/current/
<jcristau> Sarvatt: ah.  would be nice to figure out what fixed it to get it into 2.6.32.x.. :)
<Sarvatt> 31 possibilities there
<jcristau> maybe i can try tomorrow.  need to work though, and right now i should get home..
<tormod> drm-next in kernel-ppa, that's awesome! how come I missed that
<tjaalton> tormod: are you a DD now?-)
<tormod> tjaalton, no why?
<tjaalton> tormod: ah ok, saw the intel-gpu-tools upload, but that was sponsored?
<tormod> at my current rate of Debian development I can be a DD in like ten years I guess :)
<tormod> yes, I am a co-maintainer ("uploader" which is kind of wrong name) of some packages
<tormod> I am discussing with the radeontool maintainer also
<tjaalton> heh ok. I guess we need a DD to upload the current stack to unstable, and the drivers once they are ready in git
<tormod> starts with j and ends with cristau :)
<tjaalton> too busy I hear :)
<tjaalton> any DD, willing to do the job this weekend after everything is go, would do
<tormod> did you ask bgoglin?
<tjaalton> jcristau did, no reply so far. let's see how it goes :)
<jcristau> i'm asking -release if that'd be ok with them, too..
<tjaalton> great
<bryce> tjaalton, anything I can help with on xserver 1.7 right now?
<bryce> ideally it would be nice to get xserver 1.7 uploaded today, but if that's not looking possible I have some bug tool work for the desktop team I should get to
<tjaalton> bryce: it wouldn't help much anyway, since all the drivers need a rebuild, and it's wise to do that as syncs from unstable
<tjaalton> or less work anyway
<tjaalton> I believe the uploads to unstable will happen this weekend
<tjaalton> so we could sync on monday
<bryce> mm
<tjaalton> some drivers will remain broken though, like wacom an evtouch (which doesn't build against 1.7)
<tjaalton> but that shouldn't matter much for a1
<bryce> fair enough, although I'm off all next week (and wife has stated she's banishing me from the computer) so won't be able to assist
<tjaalton> oh :)
<pwnguin> as long as you mention it in the release notes
<tjaalton> bryce: well, there shouldn't be much drama
<pwnguin> (wacom, not vacation)
<bryce> tjaalton, tseliot might be able to help on the wacom and evtouch issues, could you touch base with him about it?  At least, like pwnguin says, it should be mentioned in release notes
<tjaalton> I thought evtouch is dead, evdev supports runtime calibration now..
<tjaalton> wacom needs xf86-input-wacom, but ron hasn't packaged it yet
<bryce> maybe it is; from the touchpad session at UDS I got the impression it still had its uses
<bryce> however evdev was clearly the way forward, it just needs more hardware support
<tjaalton> runtime calibration support was added recently, so maybe it was just features missing from evdev that kept evtouch around
<bryce> mm
<tormod> I remember recently some evdev bugs, and some people using evtouch instead, was it the eeetop maybe?
<tormod> no that was 441408 which was fixed in evdev. I guess only older howto
<tormod> howto's talk about evtouch
<tjaalton> ron packaged wacom after all http://people.debian.org/~ron/wacom/
<pwnguin> fast!
<tormod> xf86-input-evtouch (0.8.8-0ubuntu7) came recently, with fixes for eeetop
<tjaalton> well, I mailed him about the progress yesterday or so
<tjaalton> tormod: that's just calibration quirks
<tjaalton> same thing can be done for evdev, it's just a matter of deciding where
<tjaalton> aiui quirks belong to the kernel
<tormod> the fix yes, but why are these people using evtouch?
<tjaalton> I believe ogra babbled about calibration once
<tjaalton> don't know where we stand now
<bryce> we talked about it at length in a session on UDS
<bryce> ogra seemed extraordinarily depressed about the whole situation, but gave a ton of good info
<bryce> we scoped out a plan for an updated calibration tool, although the blocker is finding someone to do the work (what's new)
<tjaalton> bryce: yeah maybe it was about the fact that evtouch had a tool for that. it should be a lot easier to make one for evdev now
<bryce> yeah that rings a bell
<bryce> (in my swiss cheese memory)
<tjaalton> hehe
<tormod> RAOF, is it linux-nouveau-modules instead of nouveau-kernel-source now?
#ubuntu-x 2009-12-05
<spO> https://bugs.launchpad.net/ubuntu/karmic/+source/fglrx-installer/+bug/440233   <-- this is why ati sucks, I haven't been able to play 1080p movies since karmic fresh install
<ubottu> Ubuntu bug 440233 in fglrx-installer "fglrx fails at startup because of missing amdpcsdb.default + removal leaves bad settings in Xorg.conf" [High,Confirmed]
<superm1> spO, do you have a reliable way to reproduce that bug from a fresh install?
<spO> yes
<spO> use 3000-3999 ati series card
<spO> install karmic
<superm1> i've seen it reported a few times, but people tend to be messing with their systems
<spO> enable fglrx
<spO> done
<spO> it is a bug for only 3000-3999 series cards
<superm1> i would tend to believe that's not all there is to reproducing it otherwise everyoen would reproduce it
<superm1> a missing conf file only on certain hardware?
<superm1> that's ridiculous
<spO> nope
<superm1> being incompatible with hardware, that's a different bug
<spO> everyone can reproduce it , they mostly do not enable fglrx like i do
<superm1> well how are you enabling it?
<superm1> that's exactly what i'm getting at, we don't have an EXACT scenario to reproduce it
<spO> i gave you the exact one okay
<spO> i can enable it via xwindows or through the driver via download amd site
<spO> i will try something again
<spO> but i doubt it will work
<spO> okay
<spO> if it makes you happy
<spO> superm1, look at this
<spO> https://launchpad.net/ubuntu/+source/fglrx-installer/+bugs
<spO> that suggests that everyone else does have it
<spO> not just a few
<spO> understand?
<spO> thanks for driving through
<superm1> i'm glad to help debug this problem, I just need a set of reproducible steps that I can run through to evaluate what causes it
<superm1> and that list of bugs just suggests that there are a lot of people with bugs
<superm1> not a lot of people who are missing amdpcsdb.default
<spO> fine
<spO> i will in a few days
<spO> my system is doing something right now and i rather not reboot
<spO> http://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg1843314.html
<superm1> which still doesn't give a scenario to reproduce it
<spO> superm1, maybe i hate you maybe i don't
<spO> what should it be?
<superm1> 1) install karmic.  2) touch file X, Y, Z. 3) install package A,B 4) install fglrx using hardware drivers tool
<superm1> or maybe:
<superm1> 1) install karmic.  2) touch file X, Y, Z. 3) install package A,B 4) install fglrx version D.E.F from AMD website
<spO> i guessi can install karmic on a flash drive?
<spO> i dont' really want to do a fresh install like this url suggests
<spO> what do you think?
<superm1> you are able to, just make sure that you pick the right device to install the boot loader to in the advanced dialog at the end
<spO> how big does it have to be at least ?
<spO> 2gb?
<superm1> it will default to your first BIOS drive usually, which can cause some weird stuff for you
<superm1> not sure these days what the minimum is
<superm1> worst comes to worst, it will fill up and not work
<Cur5ed> Hello all, I am running Intrepid amd64 in low graphics mode, I get an error at startup saying "intel(0): No valid modes". Is this a problem in xorg.conf or a bug in intel driver or what?
<Cur5e> When I get an error in Xorg saying "intel(0): No valid modes" does this mean a problem in xorg.conf or a problem in intel driver itself??
<mac_v> hmm , anyone know how to disable KMS in kernel .32 ?
<mac_v> for ATI
<bryce> https://wiki.ubuntu.com/X/KernelModeSetting
<Sarvatt> what package is xcb proto in? dont see an x11proto-* for it
<Sarvatt> oh wow I'm slow, xcb-proto it is :D
<bryce> xcb-proto yeag
<bryce> weird, wonder why that's named differently
<Sarvatt> need xcb-proto 1.6 and libxcb 1.5 from unstable to build xvmc support for intel now :(
<Sarvatt> source format 3, go figure
<Sarvatt> cant sync it
<jcristau> bryce: it's named differently because it's unrelated
<bryce> jcristau, unrelated?
<jcristau> it's not the C protocol headers for a specific extension
<jcristau> it's xml descriptions for the protocol
<bryce> ah
<jcristau> sort of related since it's all X11, but still
<Sarvatt> got a patch to make evtouch compile fine against xserver 1.7/1.8, http://sarvatt.com/downloads/patches/901_xserver_1_7_fix.patch
<Sarvatt> no clue if things work though, nothing to test it on. uploaded it to edgers though
<Sarvatt> would something like this work for an xserver-xorg-input-joystick udev rule? http://sarvatt.com/downloads/joystick_rules.txt
<Sarvatt> i have no clue how they work, just saw there was a ID_INPUT_JOYSTICK in 60-persistent-input.rules and copied the stuff out of the old fdi using the synaptics udev rule as a template
#ubuntu-x 2009-12-06
<Sarvatt> RAOF: got a nouveau-kernel-source that works on 2.6.32 on a PPA by any chance?
<Sarvatt> or does the one in edgers work?
<Sarvatt> something tells me this 185.36 nvidia blob isn't new enough to support xserver 1.7+..
<Sarvatt> yep we're gonna need to upgrade the nvidia blob to 190.xx at least for xserver 1.7
<unggnu> hi all
<unggnu> Does anyone know if someone is working on a KMS vesa driver?
<tjaalton> ask ajax on #xorg-devel
<unggnu> This would make KMS available for everybody, at least without acceleration :)
<unggnu> thx
<tjaalton> but don't hold your breath
<unggnu> Isn't it supposed to be the easiest integeration since it has no acceleration?
<unggnu> Does current fglrx not work with 2.6.32 or is it a problem with the Ubuntu kernel?
<tjaalton> it never is a kernel problem :)
<unggnu> Because I have read somwhere else that 2.6.32 is supported through fglrx
<unggnu> I just was interested how fglrx deals with radeon KMS in lucid
<unggnu> *were
<jcristau> i guess badly, but then it's fglrx so that was an easy guess
<tjaalton> I don't think the blobs will/can ever support kms
<unggnu> Yes, I know, I just wanted to know if there is a problem when using radeon and switching to FGLRX
<unggnu> I am only using FGLRX because of Powerplay
<unggnu> 2D acceleration is very poor and XV still tears
<unggnu> I have to use OpenGL video output, this driver is a mess
<unggnu> but OpenGL doesn't tear only if vsync is forced and no composite is used
<unggnu> ciao
<tormod> unggnu had some good points here though, about fglrx
<tormod> proper radeon KMS support needs early loading of radeon, and fglrx does not like radeon I guess
<tormod> so it has to decide in early boot whether to for radeon or fglrx
<tjaalton> same thing with nvidia
<tjaalton> don't know how to deal with that..
<jcristau> the closed drivers already deal with moving libGL.so.1 and libglx.so away
<jcristau> they can add radeon.ko and nouveau.ko
<tjaalton> hmm, right
<tormod> does fglrx install its own libGL?
<tjaalton> of course
<tjaalton> and diverts the mesa one
<tormod> so they should just install a do-not-load-radeon modprobe blacklist then, or move the module but that's difficult since it's at a new place for every kernel
<tormod> and blacklist probably don't stop modalias loading
<jcristau> it does
<tormod> wasn't there some talk about a fglrx.ko which could coexist with radeon.ko?
<jcristau> that's its whole point actually
<jcristau> also, modinfo radeon|awk '/^filename:/ { print $2 }'
<tormod> the point of blacklists?
<tormod> jcristau, your command lists the current location of the radeon.ko. but if you upgrade the kernel, fglrx will have to move the new one.
<jcristau> yes, the point of blacklists is to prevent automatic loading
<jcristau> true re: the modinfo thingy
<tormod> I thought the blacklist was dealt with by modinfo
<jcristau> modprobe
<tormod> yes :)
<jcristau> udev uses modprobe -b
<tormod> oh does it
<jcristau> which doesn't do anything if the module is blacklisted
<tormod> so that's why it is so slow :)
<tormod> where does udev do the autoloading?
<tormod> /lib/udev/rules.d/80-drivers.rules
<tormod> so why does this not load the radeon module?
<jcristau> do you have CONFIG_DRM_RADEON_KMS=y?
<tormod> yes
<jcristau> dunno then
<tormod> sudo modprobe -b pci:v00001002d00005653sv00001025sd00000070bc03sc00i00
<tormod> FATAL: Module pci:v00001002d00005653sv00001025sd00000070bc03sc00i00 not found.
<jcristau> modinfo radeon should list some modaliases..
<tormod> it does list my card
<jcristau> maybe check how /lib/modules/`uname -r`/modules.alias is generated
<tormod> funny enough my card is in there too
<jcristau> weird.
<tormod> I think the kernel does tell udev about it
<tormod> does not
<jcristau> tormod: udevadm info --export-db shows the modalias?
<tormod> yes
<tormod> but that is now, after radeon has been loaded "manually"
<jcristau> oh, it's not there before?
<tormod> I don't know :)
<jcristau> i'll try and see what happens when 2.6.32 hits sid
<tormod> week old kernel release, in Debian? :)
<tormod> maybe I should try this before loading radeon
<jcristau> well, we're at -rc8, and 18:18 < CIA-3> waldi * r14741 /dists/trunk/linux-2.6/debian/changelog:  debian/changelog: Prepare to release (2.6.32-1).
<tormod> brb
<tormod> must be something with modprobe's alias resolving
<tormod> for instance, modprobe --resolve-alias  pci:v00001389d00000002sv*sd*bc*sc*i* -> applicom
<tormod> modprobe --resolve-alias  pci:v00001002d00005653sv*sd*bc*sc*i* -> (nothing)
<tormod> omg plz forget everything I said while I go hiding, I just discovered an old modprobe file I had put there for debugging some stuff months ago...
<jcristau> hah.
<Sarvatt> so many problems with intel now :( this happened 3 times today freezing x - http://paste.ubuntu.com/336069/
<tormod> ok, I have been spreading a fair amount of disinformation about radeon KMS, but the initialisation race can still be a problem. Here, kms can take up to 1.7s to initialise and nothing stops X from starting before it is ready.
<tormod> I wish upstart could log events with timestamps
<Sarvatt> there isnt a wait after loading it in the initramfs
<Sarvatt> ?
<tormod> Sarvatt, not for radeon, it is loaded later
<jcristau> i don't think it should be loaded in the initramfs
<Sarvatt> hooks/framebuffer packs in all gpu and agp modules and it waits for fb0, dri/card0 and fbcon to load as well before moving on from what I see, I'm probably misunderstanding though
<Sarvatt> looking at initramfs-tools-0.92bubuntu55 which is waaay different than debians
<tormod> this is only in use if you boot with video= right?
<tormod> uh no
<Sarvatt> http://paste.ubuntu.com/336085
<yofel> hi, would bug 491483 be SRUable?
<ubottu> Launchpad bug 491483 in xorg "Since failsave-x was enabled in karmic it starts if gdm is disabled and kdm is used" [Undecided,Confirmed] https://launchpad.net/bugs/491483
<Sarvatt> yeaaah I give up on attempting to package i915 gallium tonight :D
<johanbr> hmm... xserver-xorg-video-nouveau: Depends: linux-nouveau-modules which is a virtual package
<johanbr> did I manage to hit the PPA just while it's being updated?
<johanbr> (the PPA being xorg-edgers)
<Sarvatt> nope, sounds like it was synced with debian instead of ubuntu
<johanbr> oh
<johanbr> so the dependency should be on nouveau-kernel-source?
<Sarvatt> just checked and the one waiting to build uses linux-nouveau-modules too, i uploaded that 10 hours ago.. 
<Sarvatt> yeah its linux-nouveau-modules in debian
<Sarvatt> i'll upload a new one but it'll be a looong time until it builds at the rate ppa builds are going
<johanbr> alright
<johanbr> but I just downloaded the source package, which does have Depends: nouveau-kernel-source in debian/control
<johanbr> weird
<Sarvatt> oh? what version is it?
<Sarvatt> are you on karmic or something?
<johanbr> oh, never mind, wrong version
<johanbr> I didn't put in the deb-src line for the ppa
<johanbr> I'll see if I can fix it locally in the meantime... thank you for the help
<Sarvatt> no worries, updated source should be up in about 5 minutes if not, just finished uploading it
<Sarvatt> hmm, is a xbox 360 controller supposed to use -joystick? shows up as a mouse here
<johanbr> hmm... the package compiled, but didn't work too well: "drmOpen failed"
<johanbr> http://pastebin.com/f595ad9b5
<Sarvatt> theres no dri for it
<Sarvatt> trying to remember what options i used with it, page i wrote it on has changed :(
<jcristau> well nouveau needs the drm
<jcristau> but he didn't paste dmesg, so..
<Sarvatt> ahh maybe he didnt force KMS on with the module option, i remember having that same problem now
<Sarvatt> found my old dmesg from it working http://sarvatt.com/downloads/nouveau-kms.txt
<Sarvatt> i couldnt start x without KMS but that was like 6 months ago
<Sarvatt> same exact gpu though
<johanbr> well... got a little further... the nouveau kernel module loads fine, but then the system locks hard when gdm starts
<Sarvatt> try booting with nouveau.modeset=1 added to grub johanbr
<johanbr> alright, I'll give that a try, thanks again
<Sarvatt> i had the same problem on the same card 6 months ago when I was messing with it, had to use KMS to get it all working
<Sarvatt> should probably ship a modprobe.d rule for nouveau with the package
<tormod> Sarvatt, johanbr, if the new nouveau dep is wrong, just use my old package
<tormod> that dep is most of the change anyway
<johanbr> I just replaced it with nouveau-kernel-source and rebuilt
<Sarvatt> heres what my logs looked like with KMS, when i tried without KMS it got stuck trying to restart gdm constantly http://sarvatt.com/downloads/nouveau-kms.txt
<Sarvatt> nvidia didnt have a blob that worked on xserver 1.7 back then after the video abi changed, at least 190.xx and up works now
<Sarvatt> i'll try it out right now, purging 195.22 i manually installed
<johanbr> about to do the same
<Sarvatt> i cant even build the kernel module
<Sarvatt> /usr/src/linux-headers-2.6.32-6-generic/arch/x86/Makefile:81: stack protector enabled but no compiler support
<Sarvatt> think ccache is screwed up on this machine
<Sarvatt> nouveau sets a initramfs rebuild trigger before it makes the module?
<Sarvatt> then it does it again after the module is built, ah
<Sarvatt> yep it aint working right now: http://sarvatt.com/downloads/gallium.txt
#ubuntu-x 2010-12-06
<Sarvatt_> awesome! http://bazaar.launchpad.net/~pcjc2/notify-osd/fix_dropshadow/revision/428
<Sarvatt_> notify-osd being screwed up with pixman since july in xorg-edgers fixed by that
<Sarvatt_> oh boy, don't tell me notify-osd needs copyright assignment... :)
 * Sarvatt_ is confused as to how it can require copyright assignment to Canonical when it has source from OpenHanded in it (egg/)
<RAOF> New contributions get CA'd, I presume.
 * ajmitch is surprised that such small patches can require copyright assignment
<hyperair> Sarvatt: hmm did something break in mesa? i'm suddenly seeing a lot of damage bugs
<hyperair> Sarvatt: okay, it seems that the latest mesa (on i965) doesn't like compiz++'s mipmaps.
<hyperair> er okay, maybe not mesa.
<hyperair> xxvi?
<hyperair> =\
<mdeslaur> Could someone from the X team please give their blessing to LP: #607071, and I'll prepare a lucid SRU?
<mdeslaur> bug 607071
<ubot4`> Launchpad bug 607071 in xorg-server (Ubuntu) (and 1 other project) "X server segfaults when using XTest (xvfb) (affects: 3) (heat: 45)" [Undecided,Confirmed] https://launchpad.net/bugs/607071
<mdeslaur> ROAF, bryceh, etc. ^
<Sarvatt> mdeslaur: big fat ack from me :)
<jcristau> Sarvatt: would it make sense to upgrade to server-1.7-branch head as lucid sru?
<Sarvatt> bryceh, RAOF: on that note, what do you think about upgrading xserver completely in lucid at some point? we could revert the xsfbs change
<jcristau> or is that never going to be accepted?
<Sarvatt> ^^
<mdeslaur> Sarvatt: great! Could you please add a "+1" to the bug?
<Sarvatt> jcristau: yeah that's been bugging me, so many fixes we're missing. it's just the xsfbs abi changes making every driver need an update holding it back
<Sarvatt> mdeslaur: done, thanks for that!
<mdeslaur> Sarvatt: cool, thanks
<jcristau> Sarvatt: merging the upstream fixes and leaving the packaging alone should be possible though?
 * Sarvatt nods
<jcristau> ok, great :)
<Sarvatt> hyperair: can't say I'm surprised, looks like there have been a lot of risky 965 composite speedup commits lately http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/log/
<hyperair> Sarvatt: it seems that using mipmaps causes a whole bunch of textures to become black
<Sarvatt> hyperair: btw did notification popups get fixed for you yesterday with the notify-osd upload?
<hyperair> or maybe mipmaps broke
<hyperair> Sarvatt: eh? i lowered my libpixmap or something version
<hyperair> libpixman
<Sarvatt> oh ya can upgrade it again now
<hyperair> okay
<Sarvatt> uploaded a fixed notify-osd to the PPA
<hyperair> ah i see
<hyperair> that's nice
<hyperair> did you upload it to natty as well? natty's also got that libpixman version right?
<Sarvatt> nope pixman doesn't build in natty
<Sarvatt> doesn't pass the test suite at -O2 but does at -O1 :(
<hyperair> =\ weird
<hyperair> Sarvatt: what goes wrong in the test suite?
<Sarvatt> guess I could force it to gcc-4.4
<hyperair> ah
<hyperair> it's fixed.
<Sarvatt> two of the tests fail, but it doesn't on debian's gcc-4.5 weirdly
<hyperair> hm how weird
<Sarvatt> ok now its uploaded for natty
<greg-g> Sarvatt: so, I installed the PPA, restarted, and hooked up an external monitor. Didn't quite work: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/682864
<ubot4`> Launchpad bug 682864 in xserver-xorg-video-intel (Ubuntu) "[GMA 4500MHD] Display freeze after VGA cable disconnected (affects: 1) (heat: 6)" [Undecided,New]
<greg-g> Sarvatt: put simply: I had an output problem with the package in the PPA
<Sarvatt> greg-g: did you upgrade to everything in that PPA or did you just force intel to upgrade? the libdrm packages were required too, just want to be sure
<Sarvatt> greg-g: hmm, so the freeze went away but you got a new problem?
<greg-g> Sarvatt: well, not sure about the freeze, didn't leave it installed long enough :) and dangit, no, I didn't upgrade the libdrm :/
<greg-g> I'll do that during lunch, I'm a little behind right now at work :)
<greg-g> Sarvatt: thanks!
<Sarvatt> greg-g: if you can please upgrade everything in that PPA (add it to your sources), you can install the ppa-purge package and sudo ppa-purge ppa:ubuntu-x-swat/x-updates to completely revert the changes and go back to stock packages after
<greg-g> oh, nice, didn't know that
<greg-g> that's handy
<Sarvatt> it's very possible you do get that new regression with the packages in there, the actual fix for what I believe your bug is is a minor change and that's a backport of the natty versions which have a huge amount of changes. I'll try backporting just the fix now
 * greg-g obviously didn't read the full description on the PPA page :/
<greg-g> Sarvatt: I went ahead and took the time to upgrade everything in that PPA and restart, same issue
<greg-g> I took a photo if you want to see it. The screenshot I took this time didn't show the issue.
<Sarvatt> greg-g: ok thanks, will have a new package for you to try in a bit
<greg-g> Sarvatt: rock. I'm going to be away from IRC (hopefully) for the next few hours, just fyi. Just ping me and I'll see it.
<greg-g> Sarvatt: this is the top right hand corner of my external monitor, showing the issue: http://www.flickr.com/photos/grggrssmr/5238275134/
<Sarvatt> sheesh, why did I put off such an easy backport thinking it was touching refactored code when it was just source file names changed? :)
<Sarvatt> hyperair: baah notify-osd fails to build on natty too
<hyperair> Sarvatt: lol. wait, was it the binutils-gold issue?
<Sarvatt> yeah needs -lX11
<hyperair> ah
<Sarvatt> err, can't work out where to add it, notify_osd_LIBS isn't it
<Sarvatt> greg-g: ok updated package building here if ya could purge x-updates and try it when you get a chance - https://launchpad.net/~sarvatt/+archive/gold
<Sarvatt> ah hah https://wiki.ubuntu.com/RobSavoye/GoldFixes/notify-osd
<hyperair> Sarvatt: http://people.ubuntu.com/~hyperair/compiz-crash.log <-- could you takea look at this log?
<hyperair> Sarvatt: smspillaz tells me that XGetWindowProperty should never hang, but it hung there
<Sarvatt> hyperair: just curious, whats your libxcb version?
<Sarvatt> didn't you do a screwed up natty upgrade not disabling edgers?
<hyperair> *** 1.6+git20100703.75ff427d-0ubuntu0sarvatt2 0
<Sarvatt> yeeeep
<hyperair> Sarvatt: i did a screwed up maverick upgrade not disabling edgers.
<hyperair> and i'm still on maverick.
<Sarvatt> oh you're on maverick now?
<hyperair> yep
<hyperair> and compiz is self-compiled
<hyperair> there's a nice build_compiz++ script done by soreau
<hyperair> and it stops beeping annoyingly after two rounds of hacking it
<Sarvatt> yeah I used that script for a long time on maverick
<hyperair> ah
<hyperair> Sarvatt: so anyway, i think everything's using maverick xorg-edgers
<hyperair> Sarvatt: and this particular hang happens when closing seahorse's password prompt
<hyperair> i.e. pressing enter with a valid password
<Sarvatt> hmm
<Sarvatt> hyperair: have you checked for anything in ~/.xsession-errors when it happens?
<hyperair> Sarvatt: nay.
<hyperair> Sarvatt: i could check the next time
<hyperair> i don't think compiz logs things into .xsession-errors though
<Sarvatt> was thinking about seahorse spewing an error there
<Sarvatt> hyperair: can you install libxcb1-dbg and do a echo "0x00007ff411ee22ba" | eu-addr2line -e /usr/lib/debug/usr/lib/libxcb.so.1.1.0 ?
<hyperair> Sarvatt: lol i've never managed to get addr2line to work before
<hyperair> always returns ??:0
<hyperair> well let's see..
<hyperair> yeah it's ??:0
<Sarvatt> hyperair: can you downgrade to maverick libX11 and see if it still happens?
<hyperair> alright
<Sarvatt> whats the version on your libX11 btw?
<Sarvatt> launchpad isn't loading the PPA page dangit :)
<Sarvatt> newer than 0806?
 * Sarvatt squints at http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=4b8ff7db39f2fe7ef12968d462aaf3f9054b6c18
<Sarvatt> hmm > A simple test program to reproduce the issue is appended below: just > call XGetWindowProperty on a non-existent window.
<Sarvatt> 2:1.3.4+git20100720.554da76e-0ubuntu0sarvatt3
<Sarvatt> hyperair: this is a long shot but it looks like it might be related, uploading a new libX11 to the PPA
<Sarvatt> uploaded
<Sarvatt> hyperair: maverick->natty will be screwed up if you dont disable edgers btw, I stopped updating a lot of things in natty because the PPA was getting too crazy. lucid->maverick has pretty much the same thing in both so its ok
<hyperair> Sarvatt: hmm what do you mean PPA getting too crazy?
<Sarvatt> like 200 packages
<Sarvatt> stuff in experimental is really up to date now and we synced it all so dont need git for a lot of those
<Sarvatt> darnit, I *know* I've seen an bug report about the twinview regression in https://bugs.launchpad.net/bugs/680811 somewhere but can't find it
<Sarvatt> its probably working as intended now and wasnt before :)
 * Sarvatt digs for the documentation on twinview
<Sarvatt> looks like its working as intended to me, twinview makes multiple displays appear as a single screen to X so maximize would maximize to both screens..
<Sarvatt> "When TwinView is enabled, the NVIDIA driver provides its own version of the Xinerama extension to inform window managers of where the TwinView display devices are. Without that information, window managers would only know about the size of the entire combined desktop. Some window managers ignore this information and treat the screen as one big desktop anyway. It sounds like the version of Compiz you have is one such window manager." hmm
<jcristau> maximize is a wm op
<jcristau> if the wm is xinerama-aware, it should do the right thing on twinview, like it does on randr
<bryceh> hrm, bug reporters have been busy this weekend - http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg
<Sarvatt> I see our friend vesafb in there :)
<Sarvatt> got rid of a few there
<bryceh> great
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/685767 is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=600405
<ubot4> Launchpad bug 685767 in xserver-xorg-video-intel (Ubuntu) "Dim LCD Screen After Blank Screensaver Activated (affects: 1) (heat: 6)" [Undecided,New]
<Sarvatt> looks like http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=33c08882c0d551afb28baef643279901dcc65fa9 is the fix
<jcristau> right
<Sarvatt> which package should this be, gnome-session, gnome-panel? https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/685555
<ubot4> Launchpad bug 685555 in xorg-server (Ubuntu) "window list, show desktop, rubbish bin, workspace selector - all crash on login (affects: 1) (heat: 4)" [Undecided,New]
<Sarvatt> gnome-panel sounds right
<Sarvatt> doing the bugs as they come in is great, almost back down to 0 :)
<bryceh> yeah :-)
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/680135 bugs like that really suck though
<ubot4> Launchpad bug 680135 in xserver-xorg-video-intel (Ubuntu) "natty Intel Corporation Mobile 945GM/GMS, 943/940GML bad performance (affects: 1) (heat: 503)" [Undecided,New]
<Sarvatt> oops sorry, "bugs"
<jcristau> reassign to kde
<bryceh> yeah could be kwin specific
<Sarvatt> nvidia-graphics-driver bugs condensed to 1
<Sarvatt> looks like people installing nvidia-current on a livecd with no persistant storage expecting it to work
<Sarvatt> darn, dpkgterminallog is empty, gonna have to boot the livecd and see whats happening
<jcristau> how can that ever work?  wouldn't the livecd have loaded nouveau?
<Sarvatt> these people do have persistent storage enabled, I'm guessing they dont have enough of it to do the actual install (needs like 2gb worth to do last I checked)
<jcristau> k
<Sarvatt> package nvidia-current 260.19.21-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 -- yeah I get that if I use a 1gb USB stick with the excess set to persistent storage because there isnt enough space, looked at my old bug
<Sarvatt> bug surprise, fglrx is the same as nvidia :)
<Sarvatt> bryceh: ok down to 5 bugs
<Sarvatt> we could move the nvidia/fglrx ones over somewhere else, I'm sure its the not enough persistent storage problem
<bryceh> Sarvatt, awesome
<bryceh> Sarvatt, on 685017 do you see any crash related evidence?  It's looking bare to me
<Sarvatt> nope, I just know from personal experience that's a problem, ran into that the first time back in jaunty
<bryceh> Sarvatt, think it's really an -nvidia bug, or dkms?
<Sarvatt> maybe it shouldn't be offered if there isn't enough space, but i'm not sure where that could be detected. thats why I was saying maybe we could move them all to another package
<Sarvatt> maybe wishlist on jockey?
<Sarvatt> I bet I could punt at least 50 bugs to that bug if we did that
<bryceh> ah, it's an insufficient space problem?
<Sarvatt> yeah
<Sarvatt> it's the weird way aufs works from what I saw, things like take up 2x the amount of space that they really take up
<bryceh> http://launchpadlibrarian.net/60071510/Df.txt
<bryceh> alright, let's see how we can improve this
<Sarvatt> i'm not sure how to interpret that, hmm
<bryceh> this feels like a type of bug that's going to generate lots of bug reports
<Sarvatt> bryceh: if you look at all nvidia-graphics-drivers or fglrx-installer bugs the majority are the same as this one
<bryceh> for the workflow of - if unity is notifying people they don't have 3D and so they try to install it via jockey, and this happens
<bryceh> hmm
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers
<Sarvatt> start from last page
<bryceh> Sarvatt, is there already one with a detailed write up we can dupe them all to?
<Sarvatt> subprocess installed post-installation script returned error exit status 1 is almost always installing on a livecd
<Sarvatt> I dont know, lets see
<bryceh> ah, yeah all the post-installtion errors
<Sarvatt> thats how it errors out when out of space
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bugs?field.searchtext=subprocess+installed+post-installation+script+returned+error+exit+status+1&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assigne
<Sarvatt> e=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
<Sarvatt> heh
<bryceh> OMFG
<bryceh> that's a lot
<bryceh> so...
<bryceh> jockey could check for available space before installing and issue a warning
<Sarvatt> 66 nvidia-current, 45 fglrx-installer, 3 nvidia-graphics-drivers-96, 26 nvidia-graphics-drivers-173
<bryceh> or it could indicate that installing the driver on the livecd just won't work
<Sarvatt> something like a warning that a minimum of XGB free space is needed if launched on a livecd would be nice
<Sarvatt> the loopback stuff on the livecd is odd, 500mb free space advertised isn't enough to install the packages needed for nvidia-current build it and rebuild the initrd and all that
<Sarvatt> 500MB is more than enough I mean but the way it works doesn't let it work, it duplicates stuff on the persistent storage drive and needs a ton more space
<bryceh> ok not spotting an obvious dupe of this filed against jockey
<bryceh> (but didn't look through all the bug reports)
<bryceh> shall I go ahead and turn one of these into a jockey "warn on out of space" bug?
<Sarvatt> I know I've duped a ton of bugs about this problem before when I filed one back in jaunty or karmic, wonder where that went
<Sarvatt> ohh I bet it's under nvidia-graphics-drivers-180
<Sarvatt> 15 more under that
<Sarvatt> bryceh: yeah that sounds like  a plan
<Sarvatt> it's almost like it duplicates any space used between the ram drive and the persistent storage device if you have one so things take 2x the space
<bryceh> so it installs -nvidia twice?
<bryceh> or it is reporting double the space actually used?
<bryceh> or it is reporting double the space actually available?
<Sarvatt> making a liveusb now to see if I can work it out
<bryceh> Sarvatt, how does 685017 look so far?
<Sarvatt> looks good to me
<Sarvatt> bah can only find 1gb usb sticks lying around
<bryceh> just use up 800M of space
<bryceh> put a few mesa tarballs on it ;-)
<Sarvatt> dont get enough free space to install nvidia on 1gb
<bryceh> oh
<bryceh> wow
<bryceh> seriously?
<Sarvatt> you only get like 250mb persistent storage on 1gb..
<bryceh> huh
<bryceh> Sarvatt, can you fill in the 'steps to reproduce' section on bug 685017 ?
<ubot4> Launchpad bug 685017 in nvidia-graphics-drivers (Ubuntu Natty) (and 1 other project) "Jockey should warn on insufficient disk space in LiveCD environment, else get error "package nvidia-current 260.19.21-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" (affects: 5) (dups: 4) (heat: 36)" [Critical,Triaged] https://launchpad.net/bugs/685017
<bryceh> for now, just put in what you suspect are steps to reproduce
<Sarvatt> bryceh: the livecd takes up like 750mb of it :)
<bryceh> oh right, I was thinking that was free storage aside from the livecd
<Sarvatt> got the livecd downloading now, found a 2gb stick
<Sarvatt> i'll try with different amounts of persistent and see how much is needed 
<bryceh> ok I think the bug report is good to go
<bryceh> Sarvatt, feel free to make any corrections/changes/comments to that bug you think would clarify it better
<Sarvatt> doing some livecd tests now, will look after
<Sarvatt> bryceh: we've got a new issue
<Sarvatt> this is a squashfs problem
<Sarvatt> there's an lzma problem killing initramfs-tools, then the nvidia-current setup dies
<Sarvatt> http://paste.ubuntu.com/540414/
<Sarvatt> so the natty crashes aren't related to the no free space thing
<Sarvatt> ugh my VT's are all kinds of messed up with 2.6.37-8, plymouth stuff is on VT1, resolution is wacky on all the others
<Sarvatt> I filed an automatic bug against module-init-tools that it offered, modprobe crashed with SIGBUS
<jcristau> sounds like kernel screwup
<Sarvatt> nouveau actually works on my NVc3 now though \o/
<Sarvatt> well on the kernel side, fbdev in X
<bryceh> Sarvatt, weird
<bryceh> Sarvatt, so you think this is what caused the current bug?  or do you still think disk space is a factor?
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/module-init-tools/+bug/686145 go figure everything optimized out
<ubot4> Launchpad bug 686145 in module-init-tools (Ubuntu) "modprobe crashed with signal 7 (affects: 1) (heat: 10)" [Medium,New]
<Sarvatt> definitely not disk space related in natty, there's something else
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/686147
<ubot4> Launchpad bug 686147 in nvidia-graphics-drivers (Ubuntu) "package nvidia-current 260.19.21-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 (affects: 1) (heat: 6)" [Undecided,New]
<bjsnider> wait a minute. it fails to install why?
<Sarvatt> Setting up nvidia-current (260.19.21-0ubuntu1) ...
<Sarvatt> update-initramfs: deferring update (trigger activated)
<Sarvatt> lzma: Encoder error: -2147467259
<Sarvatt> dpkg: error processing nvidia-current (--configure):
<bjsnider> well, update-initramfs is run by the postinst script
<Sarvatt> looks like that error means lzma didn't have enough space to create the archive
<Sarvatt> leading back to squashfs being screwed? :)
<Sarvatt> [  276.442208] SQUASHFS error: zlib_inflate error, data probably corrupt
<Sarvatt> [  276.442216] SQUASHFS error: squashfs_read_data failed to read block 0x2796fdc1
<bjsnider> it's not specifically an nvidia-current problem though right?
<Sarvatt> nope
<Sarvatt> wonder if it only happens with persistent storage
<Sarvatt> I guess in a way it is the same old out of space error, its just being triggered by a bug somewhere else making it think it has no space (the lzma errors)
<cnd> Sarvatt, I saw all the input module breakage this weekend :)
<cnd> will you be uploading xorg-server 1.9.99 to xorg-edgers now too?
<Sarvatt> cnd: yeah just waiting for the last big merges to go through
<cnd> Sarvatt, cool :)
<Sarvatt> tomorrow hopefully
<cnd> awesome
<cnd> once that's done I can do multitouch development on xserver master
<cnd> instead of the constant back/forward-porting between 1.9 and master
<jcristau> you don't build your drivers?
<bjsnider> Sarvatt, there's now a changelog for the .21 blob. fixed 3 issues
<bjsnider> or are we up to 26 now
<cnd> jcristau, was your question posed to me?
<bjsnider> oh right, it's 26
<jcristau> yes
<cnd> jcristau, the 1.9 server I've been keeping in ppa:utouch-team/xorg-unstable is 1.9+all input changes from master
<cnd> so it's compatible with the 1.10 drivers
<Sarvatt> oh boy
<Sarvatt> -nr changed to -background none?
<cnd> though I've only been pushing master versions of evdev and synaptics to the ppa
 * Sarvatt has to patch gdm/kdm/etc now then
<Sarvatt> i dont think i'll be using xorg-edgers with xserver 1.10 anytime soon with all of the input stuff, synaptics 1.3.0 is practically unusable here with the crappy acceleration
<Sarvatt> drop 06_dont_trap_access_to_timer_and_keyboard.diff upstream
<Sarvatt> drop 16-xaa-fbcomposite-fix-negative-size.diff fails
<Sarvatt> drop 121_only_switch_vt_when_active.diff fails
<Sarvatt> drop 189_xserver_1.5.0_bg_none_root.patch upstream
<Sarvatt> drop 190_cache-xkbcomp_output_for_fast_start_up.patch fails
<Sarvatt> drop 197_xvfb-randr.patch fails
<Sarvatt> drop 203_gestures-extension.patch fails
<Sarvatt> (thats whats needed for master)
<Sarvatt> 16-xaa-fbcomposite-fix-negative-size.diff: obsolete more like it, http://cgit.freedesktop.org/xorg/xserver/commit/?id=6118346d64e3c2fbe1fe2f041ea773dd2a3c0438
<Sarvatt> cnd: how do you want to do all the input stuff in there?
<Sarvatt> or do you want to do it separate to start?
<Sarvatt> like i'll just get everything built and ya can use that as a base for the patches and we can move it over once its worked out, or we could do separate git branches for all this somewhere
<Sarvatt> bjsnider: where do you see the changelog at?
<Sarvatt> oh sorry missed that ya thought the .21 one was .26
<bjsnider> i still can't find a changelog for 26, which makes me a bit nervous
<Sarvatt> only problem I've had with it was glxgears causing the NVRM error and a 30 second or so freeze, happened one time in the past week
<bjsnider> what if it's supposed to say "transmitted all data to the government for archiving"?
<bjsnider> or "added spambot rootkit"
<jcristau> bjsnider: they're already doing that, they just don't say it in the changelog
<Sarvatt> yeah I assume that kinda crap from any blob :)
<bryceh> Sarvatt, for bug #685017 did you think that was  a dupe of 686145 ?
<ubot4> Launchpad bug 685017 in nvidia-graphics-drivers (Ubuntu Natty) (and 3 other projects) "Jockey should warn on insufficient disk space in LiveCD environment, else get error "package nvidia-current 260.19.21-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" (affects: 5) (dups: 4) (heat: 36)" [Critical,Triaged] https://launchpad.net/bugs/685017
<Sarvatt> bryceh: nah, 685017 is still valid, what's happening is the postinst scripts cant run because of a filesystem error somewhere making it think it has no space
<bryceh> Sarvatt, would the make.log have relevant details?
<bryceh> or would it be in a dpkg log of some sort?
<Sarvatt> I described it as best as I could in https://bugs.launchpad.net/bugs/686147 still unsure where to find the actual bug on the natty livecd
<ubot4> Launchpad bug 686147 in nvidia-graphics-drivers (Ubuntu) "package nvidia-current 260.19.21-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 (affects: 1) (heat: 6)" [Undecided,New]
<Sarvatt> it wasnt in any of my logs
<Sarvatt> i got the info manually installing nvidia-current
<Sarvatt> lzma: Encoder error: -2147467259 means no space to unpack the archive
<bryceh> Sarvatt, ok, where is that seen?
<Sarvatt> Setting up initramfs-tools (0.98.1ubuntu7) ...
<Sarvatt> update-initramfs: deferring update (trigger activated)
<Sarvatt> lzma: Encoder error: -2147467259
<Sarvatt> dpkg: error processing initramfs-tools (--configure):
<Sarvatt>  subprocess installed post-installation script returned error exit status 1
<Sarvatt> after sudo apt-get install nvidia-current from a terminal
<Sarvatt> i can't find that error in any of the logs
<bryceh> ok
<Sarvatt> on my own system where I got the problem, looked through /var/log/
<Sarvatt> I mean there is still the problem where it errors out because of insufficient space, but there's another bug most likely in the kernel on the natty livecd causing it to trigger every time
<bryceh> ew
<bryceh> ok thanks, updating bug report
<RAOF> That's pretty hostile error reporting!
<Azelphur> bryceh did you get my backtrace earlier?
<bryceh> heya RAOF
<Azelphur> bryceh http://dl.dropbox.com/u/3832397/misc/gdb-Xorg.txt.tar.gz same bug as yesterday with X crashing in arecord, this time I have debug symbols, I was also on the -proposed repo
<bryceh> Azelphur, not that I recall
<bryceh> Azelphur, ah, ok busy with this other bug at the moment, I'll look in a bit
<Sarvatt> bryceh: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bugs?start=150
<Sarvatt> those are the same bug, both nvidia-current and initramfs-tools fail the same way on the natty livecd here
<bryceh> Sarvatt, https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/562312/comments/7
<ubot4> Launchpad bug 562312 in initramfs-tools (Ubuntu) "package initramfs-tools 0.92bubuntu71 [modified: usr/sbin/update-initramfs] failed to install/upgrade: lzma: Encoder error: -2147467259 (affects: 7) (dups: 5) (heat: 56)" [Undecided,Triaged]
<Sarvatt> \o/
<Sarvatt> yay, progress
<bryceh> alright, enough on that bug for now... left the OR with a couple tasks... will check back later
<Sarvatt> what a maze, so usb-creator-gtk needs a bug to make it leave free space now
 * Sarvatt gives up for now and has dinner too
<bryceh> Sarvatt, ??
<bryceh> Sarvatt, reference?
<Sarvatt> you just linked it!
<bryceh> oh
<bryceh> I thought you meant, "We are required to file bugs to request additional disk space be provided"
<Sarvatt> the disk creator is using all of the free space for the persistent storage if you slide it all the way and it needs space on the actual fat32 filesystem to store the kernel to do upgrades
<bryceh> ah
<Sarvatt> i know I always just max out the slider every time
<bryceh> Azelphur, btw it'd be helpful in the future if you post logs without compressing them... then I have to download and manually unzip and stuff
<bryceh> Azelphur, also, what is your bug report #?
<Azelphur> bryceh don't have one yet, I wasn't sure it was a bug
<Azelphur> bryceh I compressed it because it's big, it's like 20MB
<Azelphur> I guess I should get a report up for it
<bryceh> #12 is the same call as #7, so #7 -> #12 is an infinite loop
<bryceh> Azelphur, file it with ubuntu-bug.  If possible, repro the issue, reboot, and then file
<bryceh> that way it'll include some stuff like Xorg.0.log.log from the failure
<bryceh> not a big deal if that's inconvenient, I think this trace has the info needed to troubleshoot
<Azelphur> bryceh will do, fyi there's nothing at all in Xorg.*, I figure it crashes before the writing to log happens
<bryceh> I think you're right
<bryceh> my guess is that it gets stuck in a loop, fills some sort of crash handler buffer and then the crash handler crashes, or something analogous to that
<bryceh> Azelphur, also when you file the bug report, be verbose in explaining steps to reproduce the problem, please
<Azelphur> it happens completely at random unfortunately
<Azelphur> I've seen it happen on multiple occasions with nobody anywhere near any input devices
<bryceh> Azelphur, then explain in detail how you set up the machine
<Azelphur> will do :)
<bryceh> i.e. you need to explain why the record extension is turned on, and what is requiring it
<Azelphur> that'd be x11vnc I guess
<bryceh> Azelphur, think of it like a high school chemistry experiment, where randomly the solution turns blue...  explain how you set things up, what things you poured in, how hot you made the bunsen burner, etc. ;-)
<Azelphur> yup :)
<bryceh> btw, never use the word "random" in a bug report, it just means you didn't think about things enough ;-)
<Azelphur> good tip :)
<RAOF> It is possible to have bugs with random (or, rather hidden) triggers, but they're few and far between. :)
<Azelphur> although this happens all by itself, as I say it'll happen when nobody has had any interaction with the machine for the past 30 minutes with nobody anywhere near any input devices
<bryceh> hmm, poking through the source code it's not totally obvious what's going on here
<bryceh> but I still think the record extension is listening to events that it's generating from its listens
<bryceh> Azelphur, that can be a strong clue too
<bryceh> for example...
<bryceh> if it *always* happens when no one is near it, then that suggests maybe looking at screensaver or power saving relationships
<Azelphur> nope, it happens when people are using it too, and there's no screensaver :)
<Azelphur> (this is a Ubuntu machine powering the TV in the front room, MythTV \o/)
<bryceh> cron jobs?
<bryceh> mythtv starting recording something, or starting process to remove commercials or something?
<Azelphur> I have a couple, but none of them do anything with X. But I guess it could somehow have effect
<Azelphur> maybe
<bryceh> running low on memory?
<Azelphur> nah always got plenty of memory, 2GB total 1.5GB in cache
<bryceh> like raof said, there *are* some bugs which have truly random triggers, but the fact that this is occurring within a callback tree strongly suggests to me that there is *some* process that triggers it
<Azelphur> yea
<Azelphur> I'll start logging times and see if I can come up with anything.
<bryceh> Azelphur, great, yeah look for any patterns at all for when it occurs or does not occur, even wacky things
<bryceh> once there was a bug (not against X) which broke the printer driver, which only occurred on Thursdays
<bryceh> so every week bunches of people would report "me too!" then the next day on Friday everyone would chime in "Oh, it's fixed now"... only until the next week
<RAOF> That's totally awesome :)
<Azelphur> haha
<Azelphur> bryceh not as weird as my weirdest bug report, My best one was "Using volume control on keyboard changes gnome theme"
<bryceh> lol
<Azelphur> and it actually got fixed too, it was a bug.
<Azelphur> (not on the computer we're debugging) I use separate X screens, and it was causing the OSD for the volume control to flip out, so gnome-settings-daemon crashed, which caused the gnome theme to change \o/
<RAOF> Yeah.  That was my guess as to the cause :)
<bryceh> heh
<cnd> bryceh: I hope you're feeling better than me
<cnd> I think I've come down with a cold...
<bryceh> cnd, uh oh...  I'm fine myself
 * bryceh breaks out the echinecea
<cnd> heh
<cnd> feels like just a head cold, for what it's worth :)
<bryceh> cnd, bummer :-/
<bryceh> no biggie if I get it, but hopefully ogasawara escapes it
<cnd> yeah
<bryceh> cnd, air travel is hazardous to your health
<cnd> heh, the hazards of working at Canonical...
<cnd> even though this trip wasn't for Canonical :)
<Sarvatt> dang, sprint is only a month away already
<Sarvatt> we get to get felt up at the airport 6 times a year :)
<cnd> bryceh: angela liked the program today
<cnd> they give you $50 for every 30 days you bike to work :)
<cnd> it's at the top of her list so far
<cnd> bryceh, RAOF: btw, I've got a patch against maverick xserver and evdev cooking to fix crashes during gestures
<cnd> so that's your heads up :)
<RAOF> Ta :)
<cnd> RAOF, oh yeah, when I'm on the west coast, our time lines up much better :)
<RAOF> c'mon xserver.  Build!  Faster!  MUSH!
<RAOF> :)
<bryceh> cnd, :-)
#ubuntu-x 2010-12-07
<bryceh> Sarvatt, 686164 can be closed now I gather, since it's xorg-edgers-specific?
<Sarvatt> dang, _alf did an awesome job on the cairo-gl patches http://git.linaro.org/gitweb?p=people/afrantzis/cairo.git;a=shortlog;h=refs/heads/gl-remove-glew
<Sarvatt> bryceh: yeah, sorry
<bryceh> Sarvatt, btw thanks for the bug work, http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg is looking happy again
<Sarvatt> thanks for doing that man, its so much easier if we track it as we go! making it interactive helped a lot
<Sarvatt> i usually end up just looking at intel and spending hours in that mess, not even getting to the other drivers
<bryceh> yeah it's quite gratifying
<bryceh> as opposed to the more usual overwhelmed feeling ;-)
<bryceh> I dialed up the graph to regen more frequently
<Sarvatt> maybe it'd be nice to have a bug total next to the package name? gets hard to tell from the graph eventually
<bryceh> mm, good idea
<Sarvatt> fglrx-installer looks like more than one bug there but its one bug, hmm
<bryceh> you mean nvidia?
<Sarvatt> ohh
<Sarvatt> couldnt tell them apart
<bryceh> sorry, colors are pretty similar between those two
<bryceh> kinda hard with gnuplot to force what colors things show up as
<bryceh> I'm having kind of a love/hate relationship with gnuplot
<bryceh> ok, mouse-overs are fixed...  if you hover over a color it'll now show a tooltip with the package name
<bryceh> before it just said "Plot #10" or whatever, which is unhelpful ;-)
<Sarvatt> RAOF bryceh tjaalton: what do you guys think about trying to SRU xserver 1.7.7-10 to lucid minus the xsfbs abi changes?
<bryceh> Sarvatt, assuming the patches went through a careful review process, I'd not be opposed to it in principle
<RAOF> I think our SRU requirements are stricter than the stable-branch requirements for xserver; we'd need to review the patches ourselves.
<RAOF> That said, I also have no in-principle objections.
<Sarvatt> heh, I could go through every commit and recreate the bugs and file those I guess
<RAOF> Oh, apropos nothing, would you like to add an endorsement to wiki.ubuntu.com/ChrisHalseRogers/CoreDevApplication bryceh?
<RAOF> Sarvatt: I don't think that's necessary, but we should look through each of the patches and ensure they (a) fix an actual bug we could concievably care about, and (b) are appropriately minimal.\
<RAOF> I'm thinking here particularly of the discussion around the pulling of the Damage reporting changes into the 1.9 stable tree.
<RAOF> That's an example of a patch that we shouldn't SRU.
<Sarvatt> just about everything I've reviewed of it so far would be no problem to reproduce
<Sarvatt> oh yeah i'm talking about the 3 release old stable branch basically maintained by the guy maintaining debian stable now :)
<RAOF> Yeah, it's KiBi, right?  I'm actually not familiar with the reqirements for Debian-stable updates, so that's not a huge help to me :P.  I wouldn't expect them to be substantially laxer than LTS SRU requriements, though.
<bryceh> RAOF, certainly
<Sarvatt> jcristau :)
<Sarvatt> yeah quite a lot of these are good fixes and would be easy to reproduce to show its a problem, maybe just a large patch bomb would work
<Sarvatt> its not so bad now but we had patches fixed on 1.7 branch sitting on lp for review for 3-4 months at one point
<RAOF> Oh, man.  RandR 1.4 starts looking scary.
<Sarvatt> i'll start working on a patch review list since its bugging me :)
<Sarvatt> RAOF: yeah tell me about it..
<bryceh> RAOF, ok, posted
<RAOF> Thanks muchly.
<Sarvatt> ugh thanks for the reminder, i'm going to set aside a block of time to make sure my application is squared away in the morning
<Sarvatt> december 20th then
<RAOF> Ok, time to update the bgnoneroot patches so that I can actually test these X server patches.
<RAOF> Sarvatt: You haven't yet updated those patches for xorg-edgers yet, have you?
<Sarvatt> updated how?
<RAOF> So as to build against 1.9.99
<Sarvatt> oh nope, need to patch gdm/kdm/etc too :(
<RAOF> Oh, yeah, it will.
<RAOF> Hm.
<RAOF> Bah.
<Sarvatt> would it be evil to add -nr again? :)
<RAOF> It won't be that hard to update gdm & kdm for the new option name.
<Sarvatt> cus i'm thinking about it
<Sarvatt> yeah but carrying those in the PPA..
<RAOF> Oh, for xorg-edgers?  Totally.
<Sarvatt> was waiting for the proto/lib changes coming to update edgers
<RAOF> Hm.  Why could I install 1.9.99 without breaking all the drivers?
<RAOF> Heh.  False alarm.  Everything's broken :)
<DanaG> Say, how's the support for "magic trackpad" in Maverick?
<bryceh> Sarvatt, alrighty, you have your wish...  http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg
<RAOF> DanaG: You get multitouch on it; cnd has one, so it's well supported :)
<DanaG> Er, gotta go...
<bryceh> Sarvatt, note you can mouse over and/or click the entries in the legend too, which might be more click-friendly
<bryceh> hmm, why is fglrx-installer showing up with 1 bug?
<Sarvatt> there was one bug last i looked
<Sarvatt> and sweet!
<bryceh> yeah, what's odd is the line graph shows it as 0
<bryceh> btw, currently the workqueue chart excludes bugs that are open upstream
<bryceh> Sarvatt, but I'm kinda on the fence as to whether we should exclude those or keep them in the chart.  What do you think?
<Sarvatt> how much bigger does it get?
<bryceh> I think it adds 3 or so
<bryceh> for instance, bug #685767 would be excluded
<ubot4> Launchpad bug 685767 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "Dim LCD Screen After Blank Screensaver Activated (affects: 1) (heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/685767
<bryceh> nice thing about excluding them is that we can consider that a "finished for now" state, until the upstream bug gets closed, at which point it re-enters the chart
<Sarvatt> hmm thats just not pulling from debian bugs right
<bryceh> oh that's debbugs...
<bryceh> I'm not sure whether or not bug syncing works with debbugs.  I suspect not.
<Sarvatt> that one would be useful to have in there because we know the fix and could do work on it, would make sense to be in the workqueue
<bryceh> it does show up in our patches report (but only because I grabbed the patch and attached it)
<Sarvatt> to be honest I always used the non-workqueue graph for the last releases because I was interested in all of the bugs
<Sarvatt> but it might make more sense, we'll see how it goes :)
<bryceh> yeah I should linkify that one too at some point
 * Sarvatt pins the http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg tab so it's always open in chromium :)
 * RAOF looks at this patch again.  Man, I suck.
<RAOF> Amazingly enough, unless you actually initialise the struct the contents are garbage.  C doesn't magically discern your intention :/
<Sarvatt> what patch?
<RAOF> Making DRI2 swapbuffers not an exercise in server crashes.
<RAOF> Intel did it, radeon did it, I haven't tested, but it looks very much like nouveau does it now...
<RAOF> Oh, pageflipping nouveau should be in xorg-edgers, shouldn't it?
<Sarvatt> if the kernel stuff is upstream
<Sarvatt> (and its <nv50 only)
<RAOF> I think the kernel component is upstream.
<RAOF> Anyway, it's going to crash the xserver when a client goes away with a pending swap.
<RAOF> Just like when Intel implemented it, and then Radeon.
<Sarvatt> disable page flip patch for nouveau: check
<RAOF> It'd also be trivial to port those fixes to nouveau DDX, but when the big three drivers need exactly the same fix it's probably time to fix it once, in the server.
<RAOF> Plus I can make it so that the server won't accidentally send a DRI2SwapComplete event to some poor unfortunate random client :)
<RAOF> Boo.  udeb building is broken in 1.9.99
<Sarvatt> got a build log? think kibi had patches for it
<RAOF> Yeah; sdksyms dies.  I'd guess it's a binutils snafu, but DEB_BUILD_OPTIONS=noudeb is a better option anyway.
<RAOF> At least for my purposes.
<Sarvatt> hmm udeb built fine here
<RAOF> Maybe my naieve patches surgery broke it.
<Sarvatt> drop 06_dont_trap_access_to_timer_and_keyboard.diff upstream
<Sarvatt> drop 16-xaa-fbcomposite-fix-negative-size.diff obsolete
<Sarvatt> drop 121_only_switch_vt_when_active.diff fails
<Sarvatt> drop 189_xserver_1.5.0_bg_none_root.patch upstream
<Sarvatt> drop 190_cache-xkbcomp_output_for_fast_start_up.patch fails
<Sarvatt> drop 197_xvfb-randr.patch fails
<Sarvatt> drop 203_gestures-extension.patch fails
<Sarvatt> thats what i did with origin/ubuntu debian/
<RAOF> I think I dropped more; one of those is probably it.
<Sarvatt> guessing 07-xfree86-fix-build-with-xv-disabled.diff
<Sarvatt> probably should just drop 100_rethrow_signals.patch in the PPA too since it doesn't do anything
<Sarvatt> argh I really need to file a bug about the NX stuff breaking grub on warm boots, other people hitting it on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/683775
<ubot4> Launchpad bug 683775 in linux (Ubuntu) (and 1 other project) "Natty Alpha 1, i915 has blank screen after boot (affects: 12) (dups: 5) (heat: 92)" [High,Fix released]
<Sarvatt> and here comes the mass of xserver commits :)
<RAOF> âº
<RAOF> Cool, that works.  Now to prove to my satisfaction that it actually fixes the problem :)
<Sarvatt> The last two in this list fix a nasty bug, since input ABI 12 all options
<Sarvatt> set for statically configured xorg.conf devices got lost during the device
<Sarvatt> initialisation process.
<Sarvatt> eww
<DanaG> Now, does xorg.conf.d in etc still break everything (by ignoring same dirs in /usr/share)?
<ricotz> Sarvatt, hi are you around?
<ricotz> seb128, hello
<seb128> hey ricotz
<ricotz> seb128, hi, it would be great if you could add a nice comment here https://wiki.ubuntu.com/ricotz
<seb128> ricotz, what do you apply for?
<ricotz> ubuntu-members
<Sarvatt> heyo ricotz, sorry I haven't gotten to mesa yet man
<Sarvatt> ricotz: why don't you apply for contributing developer instead?
<seb128> ricotz, ok
<Sarvatt> all the perks of members only acceptance is judged based on development contributions instead of community involvement
<ricotz> Sarvatt, is there such a group, i finally wanted to get a ubuntu.com adress ;)
<Sarvatt> they hounded me about that when I became a member :)
<Sarvatt> https://wiki.ubuntu.com/UbuntuDevelopers#ContribDev
<ricotz> seb128, thank you
<Sarvatt> well either way will add a comment once this meeting is over
<ricotz> Sarvatt, thank you
<apachelogger> aloha
<apachelogger> I tried compiling Qt with opengl es2 support on armel, now I get libEGL fatal: DRI2: failed to authenticate
<apachelogger> that is with xserver-xorg-video-omap3, though a custom kernel
<Sarvatt> surely you dont want to be using the mesa libEGL?
<apachelogger> Sarvatt: what else is there?
<Sarvatt> arm platforms all have proprietary blobs for acceleration, I don't know exactly what the package names are or where you get them but they might know if you ask in #ubuntu-arm
<Sarvatt> probably has pvr in the package name
<apachelogger> ok, thanks
<Sarvatt> sorry I don't have more info on it, the arm stuff is totally separate.. I'm positive there are packages you can grab for acceleration *somewhere* though
<Sarvatt> http://ppa.launchpad.net/tiomap-dev/release/ubuntu/dists/maverick/main/binary-armel/Packages
<Sarvatt> hmm I see some in there
<Sarvatt> https://launchpad.net/~tiomap-dev/+archive/release
<Sarvatt> ah omap3.. thats all omap4
<apachelogger> the sgx stuff sounds familiar
<apachelogger> IIRC maemo is using that for gles ... what I found strange though was that meego does apparently not
<vish> Sarvatt: hi, re: the X freeze i was whining about.. finally was able to backtrace, the only way bt was possible was how you had suggested. to attach & bt when it was frozen.. thanks. :)
<vish> was able to run bt twice , both seem the same  : http://paste.ubuntu.com/540699/  & http://paste.ubuntu.com/540700/
<vish> err twice ,in the sense two occurrences oops! 
<vish> oops just sarvatt â¦
<vish>  Sarvatt: hi, re: the X freeze i was whining about.. finally was able to backtrace, the only way bt was possible was how you had suggested. to attach & bt when it was frozen.. thanks. :)
<vish>  was able to run bt , both seem the same  : http://paste.ubuntu.com/540699/  & http://paste.ubuntu.com/540700/  
<vish> is that sufficient for submitting a bug upstream..? 
<Sarvatt> vish: can you install libdrm-radeon1-dbg libdrm2-dbg, then echo 0x001ee62d | eu-addr2line -e /usr/lib/debug/lib/libdrm_radeon.so.1.0.0 ?
<Sarvatt> and do that for those other lines without info at the top of the backtrace?
<vish> sure thing.. thanks.
<Sarvatt> if you can trigger it easier just getting a backtrace with those dbg packages would be better :)
<vish> hehe, i wouldnt say easier to trigger , but just occurs randomly..
<Sarvatt> hmm thats with stock natty stuff?
<vish> nah, in maverick.
<Sarvatt> oh.. quite a lot of ddx commits to go through
<Sarvatt> ati 6.13.1 right?
<vish> yea   -ati 1:6.13.1-1ubuntu5
<apw> Sarvatt, is that machine which doesn't reboot with the graphics handoff from grub still doing that?  is there a bug?  if so could you tag it kernel-key-gfxpayload
<Sarvatt> apw: nope that bug is fixed, but I've narrowed down warm boots being broken and hanging before the grub menu to the NX commits added in 2.6.37-3.11
<Sarvatt> 2 steps left in the bisect on that one
<Sarvatt> i haven't been able to reboot since 2.6.37-2.10, mainline kernels work fine
<Sarvatt> apw: that intel commit fixed the graphics handoff for sure here
<vish> Sarvatt: what is that echo supposed to do , is it to prepare for better bt at the next freeze?
<vish> once i echo for those lines, i get   ??:0
<Sarvatt> argh, it would be nice if ath9k wouldn't die under load
<Sarvatt> <Sarvatt> apw: nope that bug is fixed, but I've narrowed down warm boots being broken and hanging before the grub menu to the NX commits added in 2.6.37-3.11
<Sarvatt> <Sarvatt> 2 steps left in the bisect on that one
<Sarvatt> <Sarvatt> i haven't been able to reboot since 2.6.37-2.10, mainline kernels work fine
<Sarvatt> <Sarvatt> apw: that intel commit fixed the graphics handoff for sure here
<Sarvatt> not sure if that went through
<vish> Sarvatt: we heard that. but you missed mine.. :)
<vish>  <vish> Sarvatt: what is that echo supposed to do , is it to prepare for better bt at the next freeze?
<vish>  <vish> once i echo for those lines, i get   ??:0
<Sarvatt> vish: ah darn
<vish> Sarvatt: and nothing else on the channel.. :)
<Sarvatt> vish: could you try https://launchpad.net/~ubuntu-x-swat/+archive/x-updates ?
<vish> sure..
<Sarvatt> x-x-v-ati 6.13.2 in there and there are quite a few commits touching the functions you're crashing in
<vish> Sarvatt: should i just install xserver-xorg-video-ati 6.13.2  alone or the xserver-xorg-video-radeon 6.13.2 too? 
<Sarvatt> both, i guess you can do that because I built ati in there before bumping libdrm :)
<vish> cool, installing..
<Sarvatt> might want the dbg packages too
<vish> yupp got those too.. restarting X â¦ brb
<vish> the frustrating thing about the random freezes is that we can never be sure(for a while) if the update really fixes the issue.. :s
<vish> i guess i'll have to stress-test scrolling  ;)
<Sarvatt> there was a site that was super good about stress testing scrolling freezes, hmm
<Sarvatt> http://www.woodtv.com/
<Sarvatt> thats it
<vish> ooh, thanks.
<bryceh> Sarvatt, is bug 686388 a known lockup?
<ubot4> Launchpad bug 686388 in xserver-xorg-video-intel (Ubuntu) "[i965gm] GPU lockup 94ada031 (EIR: 0x00000010) (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/686388
<bryceh> Sarvatt, oh btw don't forget to shoot me your ideas on how we could improve the apport crash handler.  I am planning on spending a week or two on apport hook improvements in the coming weeks
<Sarvatt> nope
<Sarvatt> Invalid GTT entry during Display B Fetch
<Sarvatt> haven't seen that one
<bryceh> Sarvatt, where do you find "Invalid GTT entry during Display B Fetch"?
<bryceh> is that in one of the logs, or an external doc?
<Sarvatt> wonder if its hotplug related
<Sarvatt> intel_error_decode on the i915_error_state.txt
<Sarvatt> https://launchpad.net/~sarvatt/+archive/intel-gpu-tools
<Sarvatt> newer ones show a lot more info
<Sarvatt> bryceh: I need to file a bug on this NX problem breaking warm boots, give me a bit
<bryceh> Sarvatt, no hurry
<bryceh> hrm, still not seeing where that display b fetch error message came from
<Sarvatt> bryceh: did you upgrade intel-gpu-tools to the one in the ppa?
<bryceh> Sarvatt, yeah
<bryceh> $ apt-cache policy intel-gpu-tools
<bryceh> intel-gpu-tools:
<bryceh>   Installed: 1.0.2+git20100927+dbc547d-0ubuntu1
<bryceh>   Candidate: 1.0.2+git20100927+dbc547d-0ubuntu1
<bryceh>   Version table:
<bryceh>  *** 1.0.2+git20100927+dbc547d-0ubuntu1 0
<bryceh>         500 http://ppa.launchpad.net/sarvatt/intel-gpu-tools/ubuntu/ maverick/main i386 Packages
<bryceh>         100 /var/lib/dpkg/status
<bryceh>      1.0.2+git20100324-0ubuntu1 0
<bryceh>         500 http://us.archive.ubuntu.com/ubuntu/ maverick/main i386 Packages
<bryceh> $ intel_error_decode ./i915_error_state.txt|more
<bryceh> Time: 1291713055 s 678993 us
<Sarvatt> huh
<bryceh> PCI ID: 0x2a02
<bryceh> EIR: 0x00000010
<Sarvatt> 0927?
<bryceh>   PGTBL_ER: 0x00000100
<bryceh>   INSTPM: 0x00000000
<Sarvatt> oh sorry man, my bad
<Sarvatt> i'm using the xorg-edgers one
<bryceh> ah
<Sarvatt> it required a newer libdrm and failed in that ppa
<bryceh> looks like your 20101029 package didn't build
<Sarvatt> you can just grab intel-gpu-tools deb from xorg-edgers, it'll work with natty
<Sarvatt> faster than a rebuild will be at least :)
<bryceh> unfortunately my scripts run on a maverick box...
<Sarvatt> hmm
<Sarvatt> intel_error_decode shouldn't need the newer libdrm
<Sarvatt> intel_gpu_dump will probably be busted though, is it a intel box?
<bryceh> radeon
<bryceh> oh well, I'll todo it for later
 * bryceh peeks at the source
<Sarvatt> i added a get-orig-source target to it to make it easier to update
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/686705 -- apport sure leaves a lot to be desired there..
<ubot4> Launchpad bug 686705 in linux (Ubuntu) "System hangs at GRUB loading screen every warm boot since 2.6.37-3.11 (affects: 1) (heat: 8)" [Undecided,New]
<bryceh> yeah, won't build from source (âI915_EXEC_BLTâ undeclared)
<bryceh> however...
<bryceh> Sarvatt, is it always just the PGTBL_ER we care about?
<Sarvatt> bryceh: http://sarvatt.com/downloads/patches/0001-Revert-Prepare-for-split-BLT-ring-on-Sandybridge.patch
<Sarvatt> nope, there usually isn't a PGTBL_ER
<bryceh> $ ./intel_pgtbl_err 0x00000100
<bryceh> 256
<bryceh>     Invalid GTT entry during Display B Fetch
<bryceh> sweet, I've rewritten it in python
<ilmari> how do i compile just a single module (i915) from a patched ubuntu kernel tree? I've checked out the tag corresponding to my currently running kernel
<ilmari> can I just copy /boot/config-$(uname -r) to .config and make oldconfig && make drivers/gpu/drm/i915/i915.ko ?
 * ilmari tries
<bjsnider> is pitti in any ubuntu channels at the moment?
<Sarvatt> ubuntu-desktop but he's gone for the night
<bjsnider> i see
<ilmari> nope, that did not work (not even with LOCALVERSION="" and EXTRAVERSION=-23-generic)
#ubuntu-x 2010-12-08
<RAOF> Would you believe it?  Destroying buffers before you've finished rendering from them makes for some crazy rendering.
 * RAOF feels rather stupid.
<RAOF> Yup.  There goes the flickering!
<DanaG> okay, so I got the magic trackpad... and it doesn't scroll or anything.
<DanaG> Is something I should go to #ubuntu for?
<RAOF> It should do 2, 3 & 4 finger gestures under Unity, IIRC.
<DanaG> ah, what I'd want is the same as regular Synaptics, at least.
<RAOF> You *should* be able to get synaptics to claim it by judicious editing of config files; you'll lose gesture support there, though.
<DanaG> Scrolling (2-finger and/or edge, though Gnome devs think nobody could possibly ever want both), and middle and right button are most important.
<RAOF> I _think_ gesture support should handle 2 finger scroll, though.  Again, only under Unity
<DanaG> Stupid apple... 2-finger right-click, but where the heck's my MIDDLE button?
<DanaG> I use middle way more than I use right, when browsing.
<DanaG> Oh, and when I hold the lower edge, all movement stops.
<DanaG> Correction: as long as two fingers are on the board, literally nothing happens when I move the fingers.
<bjsnider> DanaG, what device is this?
<DanaG> Magic Trackpad.
<DanaG> I won't go to +1 until I can get... ATI driver... to work with new X server.
<RAOF> fglrx?  We haven't got a new X server in Natty yet.
<DanaG> hmm, is there anything else significantly new in natty, anyway?
<RAOF> Well, new kernel.
<RAOF> (Slightly) newer mesa.
<RAOF> New -intel,...
<DanaG> Radeon uses too much power... runs warm and noisy.
<DanaG> Random aside: why is it even called a "trackpad", anyway?  You touch it, not track it!
<DanaG> I'm tracking my mouse.... oops, it got away!
<RAOF> Even if you set dynpm?
<DanaG> Yeah, last time I checked, dynpm didn't use lowest-power modes, and even with fixed low, it still uses like 8 watts more than fglrx.
<DanaG> Hey, if a trackpad is called such because it "tracks" you... then we should call webcams WATCHcams, because they WATCH you. =Ã¾
<DanaG> ah, I'm switching the "magic" thing to Synaptics.
<DanaG> Regression with the change from hal to xorg.conf.d: changing .conf file doesn't take effect merely by reattaching device!
<DanaG> Well, either that, or the 60-magictrackpad.conf isn't what defines the driver.
<DanaG> I changed it to say synaptics, and it's still using udev.
<RAOF> evdev, you mean.
<DanaG> er, yeah.
<DanaG> Say, does using /etc/X11/xorg.conf.d still break everything by making it ignore /usr/share/X11/xorg.conf.d/ ?
<RAOF> I don't think so.
<DanaG> I created a new file (61) with identifier "Magic Trackpad, damnit"... and it doesn't use the file.
<DanaG> I used to be able to do this for synaptics: change the fdi file, then unload and reload psmouse.
<DanaG> Well, time to ctrl-alt-backspace, then.  grr.
<DanaG> Okay, restart did it... though now i'm screwed by the "can't have both" limitation.
<DanaG> Built-in touchpad won't do multi-finger... so I get edge scrolling with magic.
<DanaG> Well, it WILL do multifinger with exactly one Windows driver that seems to patch the firmware.... and some people refuse to believe that that could possibly be true.
<RAOF> Magic should do two finger scroll with Synaptics I believe.
<DanaG> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/546697
<RAOF> Although cnd is the guy with the hardware, who wrote the driver, and who's doing the multitouch implementation :)
<ubot4> Launchpad bug 546697 in xserver-xorg-input-synaptics (Ubuntu) "enable multitouch support on older touchpads, as supported by driver v15.0.9.0 (dup-of: 554980)" [Medium,Confirmed]
<ubot4> Launchpad bug 554980 in xserver-xorg-input-synaptics (Ubuntu) "Two finger scroll not working on all old touchPads (emulation approach). (affects: 30) (dups: 3) (heat: 141)" [Medium,Confirmed]
<DanaG> RAOF: the problem is that Gnome won't let me enable BOTH types of scrolling at once.
<DanaG> And those damn developers: the special windows driver IS NOT FREAKING EMULATION!
<RAOF> I'd guess you could probably twiddle the properties yourself with xinput
<DanaG> RAOF: tried that... gnome later resets it.
<DanaG> If I have gpointing-device-settings installed, I get enable...disable...enable...disable...enable every second or so.
<RAOF> Sweet!
<DanaG> I hate those devs that REFUSE to accept that a driver could ever possibly patch the firmware!
<DanaG> wait, in that thread, the person is not a dev.
<DanaG> But in the other discussion... the one where the person sniffed the PS/2 traffic of the new touchpads, all I wanted was them to try that sniffing with the special driver.
<DanaG> Really hackish thing I'm considering trying: sniffing PS/2 traffic with my Xilinx board, and dumping it over serial.
<DanaG> Sorry about the rant.
<DanaG> Anyway: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/467258
<ubot4> Launchpad bug 467258 in gnome-settings-daemon (Ubuntu) (and 2 other projects) "Touchpad: simultaneous two-finger and edge scrolling (affects: 3) (heat: 17)" [Wishlist,Triaged]
<DanaG> I must say, wouldn't Synaptics as default have been a better default for the Magic?
<DanaG> Anyway, I'm off to go try the thing with Windows.
<DanaG> Got it for work, mainly... and they use Windows.
<DanaG> I hope we can at least get drivers to the level of NVIDIA, or preferably, fglrx, in terms of packaging.
<DanaG> Some day, I mean.
<RAOF> In terms of packaging?
<DanaG> Yeah.  Can't beat: ./ati-driver-installer-whatever.run --buildpkg Ubuntu/maverick
<RAOF> Ah.
<RAOF> Well, I think you can; the edgers PPA is pretty kickarse.
<DanaG> I mean for arm, though.
<DanaG> Does edgers do that?
<RAOF> When the ARM ppa buildds are up, yes.
<DanaG> Spiffy.  So no more asking TI for permission?
<DanaG> For me, 99% of my 3D stuff in Linux is compiz.  It just doesn't feel as nice without it.
<RAOF> Oh, permission to redistribute their drivers?  Ah.  Different question.
<RAOF> They *do* have a PPA for it already, I think.
<RAOF> At least for the OMAP boards.
<DanaG> Last time I used a beagle, you had to download a huge package from TI, and then use their failure of a build script.
<DanaG> "make" did "make clean" on a hardcoded target dir that didn't exist.
<DanaG> For me, 90% of the 3D stuff I do in Linux is Compiz, so GLX is mandatory.
<DanaG> Oh, and oddly enough, last time I checked power usage on battery with ATI binary, it was lower WITH Compiz and Aero than without!
<RAOF> Not totally odd; you get less redraw with a compositing manager.
<DanaG> I'll have to try Radeon on alpha... If power usage is tolerable, I may switch.
<RAOF> Actually drawing stuff and then blitting a texture costs more than blitting a texture :)
<DanaG> The difference between fglrx and Radeon was like 10 watts.
<DanaG> All those silly people who recommend disabling it...
 * RAOF wonders if he's mentioned that fglrx has more lines of power management code than the radeon kernel module, mesa driver, and DDX in total?
<hyperair> Sarvatt: it seems compiz is hanging at another X call now.
<hyperair> http://paste.debian.net/101860/
<Sarvatt> hyperair: so what happens, it just hangs?
<hyperair> Sarvatt: yep, compiz hangs, X hangs.
<hyperair> no wait
<hyperair> compiz hangs
<hyperair> X doesn't hang
<hyperair> killing compiz brings X back
<Sarvatt> it might be useful to attach to the X process and get a bt there
<Sarvatt> ah
<hyperair> Sarvatt: does xorg-edgers have pixman dbgsyms?
<hyperair> ah it does
<Sarvatt> -dbg yeah
<hyperair> Sarvatt: it seems that Xorg is stuck in libpixman
<hyperair> and compiz is stuck waiting on XGetWindowProperty again
<Sarvatt> what libx11 again?
<hyperair> Sarvatt: http://paste.debian.net/101876/
<hyperair> Sarvatt: the one from xorg-edgers maverick?
<hyperair> Installed: 2:1.3.4+git20100720.554da76e-0ubuntu0sarvatt4
<Sarvatt> hyperair: you use a dock?
<hyperair> Sarvatt: yes i do. docky.
<Sarvatt> on the left side of the screen like unity?
<hyperair> yep
<hyperair> wait, how did you know?
<hyperair> O_o
<Sarvatt> yah looks like its just drawing that, nothing odd there
<hyperair> you could tell that from the backtrace?
<Sarvatt> yep
<hyperair> hmm
<hyperair> but it hung there?
<Sarvatt> the last thing it drew I'm guessing
<hyperair> li see.
<hyperair> how strange.
<Sarvatt> i'm not seeing any obvious locking problems at least :(
<hyperair> =\
<hyperair> but XGetWindowProperty shouldn't block
<hyperair> meaning it's not compiz's fault, or is it? =\
<hyperair> hmm
<Sarvatt> do you have a backtrace of the hang with  libxcb1-dbg installed by any chance?
<hyperair> nope
<hyperair> oh yeah, it particularly likes happening when i'm busy killing indicator-applet
<Azelphur> bryceh: been trying for a while to figure out how to get ubuntu-bug to work, tried asking in ubuntu-uk and they told me to use apport-collect which just says "no additional information collected" so I'm kinda stuck with providing the ubuntu-bug info you wanted :(
<Azelphur> been trying to do it since yesterday
<Azelphur> I did file the bug though, https://bugs.launchpad.net/xorg-server/+bug/687412
<ubot4> Launchpad bug 687412 in ubuntu (and 1 other project) "X crashes after a while on 9500GT in arecord (affects: 1) (heat: 6)" [Undecided,New]
<apw> bryceh, Sarvatt, where are we with nouveau and 3d ?
<apw> its not going to be there any time soon i assume?
<bryceh> apw, it depends...  we've been discussing it but it's be easier to decide, if upstream was supporting it
<apw> bryceh, does that mean it is even an option?
<Azelphur> bryceh: https://bugs.launchpad.net/ubuntu/+bug/687412 I filed that bug, someone marked it as invalid for some reason
<ubot4> Launchpad bug 687412 in ubuntu (and 1 other project) "X crashes after a while on 9500GT in arecord (affects: 1) (heat: 6)" [Undecided,Invalid]
<Azelphur> I couldn't get ubuntu-bug to work, spent a day trying and asked in ubuntu-uk, they told me to use apport-collect that didn't work either, not my day :(
<tjaalton> you didn't specify the package
<Azelphur> ah
<Azelphur> don't remember it asking me to specify a package when filing
<Azelphur> I did set it to also effects X.Org though
<tjaalton> it's not a package, but a project
<Azelphur> oh
<Azelphur> tjaalton: how do I set a package?
<tjaalton> choose the ubuntu project and enter the name?
<Azelphur> tjaalton: I clicked also affects project typed ubuntu in the box and it says there is no project named Ubuntu
<Azelphur> I tried using the search, it says there are too many projects with the name Ubuntu
<tjaalton> nbo
<tjaalton> no
<tjaalton> it lists "ubuntu" there because you didn't say which package had the bug
<tjaalton> forget the projects
<Azelphur> :S
<tjaalton> click ubuntu, enter the name of the package
<Azelphur> ah
<tjaalton> dunno what to think of the backtrace
<tjaalton> it's looping somehoe
<Azelphur> and the package name is xserver-xorg, should I change it's status too?
<tjaalton> w
<Azelphur> tjaalton: bryceh said it could be caused by arecord triggering an event which it hooks creating a loop
<Azelphur> iirc
<tjaalton> so the server didn't crash, but it's flooded?
<Azelphur> yes it crashes, I drop back to gdm
<tjaalton> is it immediate?
<Azelphur> tjaalton: nope, it takes a while
<tjaalton> so the real bug is what triggers the loop
<tjaalton> the server then runs out of resources or so. that could be an nvidia bug
<tjaalton> but the backtrace is pretty much useless
<Sarvatt> we never saw anything in the logs that it was actually a crash though the other day, its still possible that it could just be some oddball mythtv session stuff dropping it back to login for some reason
<Azelphur> Sarvatt: surely if gdb picks up on the crash it's a crash and not a proper exit
<Azelphur> also this issue doesn't happen with the old graphics card I had in there (6600GT)
<tjaalton> the same driver?
<Azelphur> I think the 6600 uses an older nvidia driver, so before I upgraded I used jockey to deactivate the driver, installed the 9500, then used jockey again
<Sarvatt> X sends lots of signals gdb stops on..
<Azelphur> I could try swapping the 9500 back out with the 6600
<Azelphur> to see if it still happens
<tjaalton> you said on the bug that you don't know what triggers it?
<Azelphur> that's right, it happens at random
<tjaalton> just like the best bugs should
<Azelphur> haha, I know it's a terrible description
<Azelphur> but it happens when the keyboard is on the other side of the room with nobody nearby
<Azelphur> there's no pattern to it I can see as of yet, I will keep trying to figure it out though
<Azelphur> as I say I plan on stopping x11vnc which should stop arecord from being enabled so I can see if that stops it from happening, and switching back to the 6600 to see if that stops it
<Azelphur> and I want to start logging the times of the crashes
<bryceh> apw, yes, it's an option
<Azelphur> tjaalton: should I change the status from invalid to new again when specifying a package?
<bryceh> Azelphur, I already did
<Azelphur> bryceh: ty :D
<bryceh> it probably got set as invalid because it didn't have a detailed enough description
<Azelphur> yea, I admit the description was crap but I don't have a lot to go on
<Azelphur> getting the files you requested now :)
<bryceh> we get so many bugs, that developers tend to focus on bugs that have good descriptions and complete log information, and it's fairly plain how the bug comes about
<Sarvatt> too bad it's not reliably happening 1 minute after login like it is for these people http://ubuntuforums.org/showthread.php?t=1612704
<Sarvatt> they have nothing in their logs either
<Sarvatt> Azelphur: try passing -noxrecord to x11vnc?
<Sarvatt> no clue how its starting in mythbuntu
<Azelphur> yea was just about to say I should try that :)
<Azelphur> probably in init.d or something, I'll find it :p
<Sarvatt> grep -R x11vnc /etc/
<Azelphur> it's one attachment per comment right?
<Azelphur> Sarvatt: it's not in there, easy enough for me to find I know the maintainer of mythbuntu quite well, I can prod him :)
<Sarvatt> apport-collect -p xorg 687412 ?
<Azelphur> Sarvatt: haha, I tried to use that in the first place but didn't know that I needed to specify a package, that explains why I never got it to work. Running it now :)
<Sarvatt> yeah it's not documented very well :(
<Sarvatt> or at all
<vish> is it OK to keep getting "Program received signal SIGPIPE, Broken pipe." http://paste.ubuntu.com/541127/ ? it seems to be occurring when opening/closing animations with compiz..
<vish> seems i am noticing this because i'm debugging X, but during normal usage it would just be like a fraction of a sec stuck and then starting of the animation
<Sarvatt> vish: handle SIGPIPE nostop
<Azelphur> Sarvatt: that gives him all the files he asked for, right?
<Sarvatt> Azelphur: yea
<Azelphur> cool
<vish> Sarvatt: ah , will all that arg , but is that normal? or should it not be doing that?
<Sarvatt> vish: yep its normal
<vish> cool..
<Azelphur> next on my list is to try with -noxrecord then to see if that stops it from happening.
<Sarvatt> vish:  you want to nostop on SIGUSR1 and SIGUSR2 too or it'll stop on input events and stuff
<vish> Sarvatt: ok, sure, thanks..  this SIGPIPE seems more common for me.
<Sarvatt> Azelphur: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/525066
<ubot4> Launchpad bug 525066 in xorg-server (Ubuntu) "x11vnc able to segfault xorg (affects: 2) (heat: 23)" [High,Triaged]
<Azelphur> Sarvatt: looks like the same crash but mine happens at random while the machine is logged in, nothing to do with the login screen
<Azelphur> I can try to reproduce that bug though :)
<Sarvatt> they're just saying to boot it up to the login screen not that the login screen has any significance to it from how I read it
<Azelphur> so they are saying X crashes as soon as the open a VNC session?
<Patricia> ola
<Patricia> ingles ou portugues?
<Patricia> Hi
<Patricia> English our Portuguese?
<Patricia> because the intel video card, hangs with compiz?
<Patricia> 82945G/GZ
<RAOF> apw: Nouveau 3D status is roughly what it was for Maverick - installing libgl1-mesa-dri-experimental will get you 3D, it'll probably work, but kindly don't bug anyone if it doesn't.
<RAOF> apw: One difference is that we've enabled the 3D driver for the old cards (TNT2 â Geforce3) in the most recent mesa upload.
<apw> RAOF, thanks
<RAOF> We should also look at jocky-ifying libgl1-mesa-dri-experimental, so it's presented to users as an alternative to the binary blob.
<apw> RAOF, thats an interesting idea
<RAOF> Should be relatively simple too, and allow users to try Unity on the livecd.
<Sarvatt> Azelphur: I think I might have a patch for you to try
<Sarvatt> Azelphur: uploading it to https://launchpad.net/~sarvatt/+archive/green, will take an hour or so to show up
<Sarvatt> http://patchwork.freedesktop.org/patch/2166/
<Sarvatt> Azelphur: heading out for the night, let me know how it goes if you get a chance to test it
<Patricia> because the intel video card, hangs with compiz? 82945G/GZ
<RAOF> Patricia: That card should work; could you provide more details, like: What Ubuntu release are you using?  How often does compiz hang?  What, exactly, happens when compiz hangs?
<Patricia> Ubuntu 9.10
<Patricia> our
<Patricia> Ubuntu 10.04
<Patricia> our
<Patricia> Ubuntu 10.10
<Patricia> latch completely
<Patricia> whatever version ubuntu 9.10 after hangs
<Patricia> to return the computer, just restarting the reset button
<Patricia> the period of catch is about 5 seconds after activating compiz
<Patricia> everyone who has this video card does not work, compiz
<Patricia> :/
<JanC> I have 2 laptops with (a variation of) that videocard which seem to work okay
<JanC> it's probably the most-used GPU ever...
<Patricia> Unfortunately all they are activating compiz, this fighting, I collect data from other users of that board in #ubuntu-br
<Patricia> and does not work
<JanC> Patricia: is this with the default compiz settings?
<Patricia> Â¬Â¬
<Patricia> or not the time to fiddle around
<Patricia> you activate the effect and already hangs
<Patricia> yes default settings
#ubuntu-x 2010-12-09
<Azelphur> Sarvatt: awesome I'll get on your repo and let you know  :)
<Sarvatt> Azelphur: thanks, the patch seems to address your exact problem even though the description leaves a lot to be desired :)
<Azelphur> hehe
<Sarvatt> http://www.spinics.net/lists/dri-devel/msg06034.html -- so THATS why it wasn't working with hdmi!
<Sarvatt> I guess input-utils needs rebuilding pretty often now?
<Sarvatt> sudo lsinput
<Sarvatt> /dev/input/event0
<Sarvatt> protocol version mismatch (expected 65536, got 65537)
<Sarvatt> works when rebuilt
<RAOF> Sarvatt: Yeah, roughly once per kernel rev.
<DanaG> Say, how do you use synclient -m without SHMConfig?
<DanaG> Can't access shared memory area. SHMConfig disabled?
<DanaG> They say SHMConfig has been replaced by xinput... but xinput can't do -m.
<DanaG> 3 lines in xorg log:  (--) Apple Wireless Trackpad: no supported touchpad found    (EE) Apple Wireless Trackpad Unable to query/initialize Synaptics hardware.   (EE) PreInit failed for input device "Apple Wireless Trackpad"
<DanaG> I removed line breaks, of course.
<DanaG> I do have shmconfig on... but it's ignoring it.
<DanaG> shmget(0x5d8b, 96, 0)                   = -1 ENOENT (No such file or directory)       shmget(0x5d8b, 0, 0)                    = -1 ENOENT (No such file or directory)
<DanaG> As far as I'm concerned, that's a regression.  They should've made the SHM area read-only and root-only.
<DanaG> Maybe I should file a regression bug-report.
<DanaG> odd, despite that error, edge-scrolling still works.
<DanaG> Two-finger does not work, thanks to Gnome.  :(
<DanaG> Can't do both together.
<Sarvatt> RAOF: did you see your alt+tab bug was fixed? https://bugs.freedesktop.org/show_bug.cgi?id=32246
<ubot4> Freedesktop bug 32246 in Drivers/DRI/R600 "Compiz 0.9 switcher segfaults in mipmap generation code" [Normal,New]
<Sarvatt> new mesa uploading now
<RAOF> Sarvatt: Awesomesauce.
<RAOF> I'm surprised that's the fix, though.
 * RAOF clearly doesn't (yet?) understand the mesa code.
<hyperair> Sarvatt: all the compizes crash iwth latest mesa. what happened?
<hyperair> http://paste.debian.net/101951/
<Sarvatt> hyperair: what gpu again?
<hyperair> 965
<hyperair> 8086:2a02
<Sarvatt> thanks, passed it along to anholt
<hyperair> yeah i saw, thanks
 * hyperair starts downgrading his mesa
<RAOF> Aaah, constant buffers.
<hyperair> there also seem to be some weird issues with fonts
<hyperair> like weird font corruption that fixes itself a little later
<Sarvatt> yeah they've been going back and forth on that one in #intel-gfx for the past few days
<hyperair> ah
<Sarvatt> oh wait, http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=9b967807c2d240488a715509649663aac3583532 isn't the in ppa
<hyperair> Sarvatt: oh yeah everything's rendering smoothly but with significant latency, like half a sec late.
<Sarvatt> new one uploaded
<hyperair> weird
<hyperair> ok
<Sarvatt> i'll revert that mesa commit for now too
 * Sarvatt has to be up for work in 3 hours, ha!
<hyperair> lol
<Azelphur> Sarvatt: your patch looks good, havn't had a crash yet.
<Sarvatt> sent all the --no-add-needed patches to the xorg-devel list so they should hopefully stop needing Makefile.in patches in the next 5 years, hope I didn't miss any :)
<Sarvatt> I fail at git send-email, didn't mean for them to be threaded
<Sarvatt> ha, need to point people complaining about i915 wakeups at this thread http://comments.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/2439?set_lines=100000
<bryceh> lengthy thread
<Sarvatt> tldr; showing seconds in the clock applet with compiz kills the battery
<bryceh> yeah that's kind of funny (in a sad way)
<bdmurray> I'm planning on consolidating some fglrx package bugs about build failures that contain "kcl_ioctl.c:196: error: implicit declaration of function âcompat_alloc_user_spaceâ
<bdmurray> in the DKMSBuildLog okay?
<bdmurray> bryceh: ^
<Sarvatt> bdmurray: what release are they using?
<Sarvatt> afaik the fix is released to all releases back to lucid
<Sarvatt> they just need to enable -updates
<bdmurray> Hmm, I see the following 8.771 8.723.1 8.780 - could check releases in a minute
 * Sarvatt double checks
<Sarvatt> bdmurray: ah I see the problem
<Sarvatt> only natty has it fixed for 2.6.37 kernels
<Sarvatt> the dkms patches were limited to 2.6.36 in the previous fix
<bdmurray> Sarvatt: okay, but its all the same bug?
<Sarvatt> yep, lucid and maverick fglrx needs an update to work with 2.6.37+
<bryceh> bdmurray, merging fglrx bug reports sounds good
<Sarvatt> tseliot didn't like me fixing natty so should assign it to him :)
<bdmurray> now, I'm not gonna get involved in personal issues like that ;-)
<Sarvatt> bdmurray: really though, it's because he maintain the packaging in git that the OEM's pull from to make releases so he's got to fix it
<Sarvatt> it's a really simple fix, the regex matches in debian/dkms.conf.in need updating to not only apply to 2.6.36
<bdmurray> Sarvatt: actually shouldn't these be a dup of the one you fixed?
<Sarvatt> good point, I don't have permission to open lucid and maverick tasks for it though
<bdmurray> Sarvatt: I can help with that if you tell me the bug number. ;-)
<Sarvatt> bug #671868
<ubot4> Launchpad bug 671868 in fglrx-installer (Ubuntu) "package fglrx 2:8.780-0ubuntu2 failed to install/upgrade: fglrx kernel module failed to build (affects: 1) (heat: 109)" [High,Fix released] https://launchpad.net/bugs/671868
<Sarvatt> pain in the butt having to dig in the logs of all of these bugs though, failed to install/upgrade: fglrx kernel module failed to build is usually also a header package problem
<bdmurray> Sarvatt: if you tell me what to look for in the logs its not hard for me
<Sarvatt> bdmurray: go figure all of the ones I've looked at so far need eyes on them, most were people installing fglrx manually and things were in an inconsistent state
<bdmurray> ah that sucks
<bdmurray> Sarvatt: what about build failures due to not matching the current kernel?
<Sarvatt> *usually* it happens because they have -generic metapackages installed but a generic-pae kernel and there is no way to make fglrx require the correct type of headers
<Sarvatt> (same problem with any dkms package there)
<RAOF> Sarvatt: I thought that prospective fix for the mipmap crasher was odd, and indeed it doesn't fix it :)
<Sarvatt> really? you had maxLevels = 15 in your backtrace and someone on #radeon mentioned bumping what he pushed fixed etuxracer aborting so had me hopeful
<Sarvatt> this libsm libxt libxmu .pc thing looks like it'd fix hundreds of ftbs' if we reverted it, or am I misunderstanding?
<Sarvatt> most of the failures i've come across are from things having xt in PKG_CHECK_MODULES and not picking up -lX11
<RAOF> Let me see...
<Sarvatt> we're removing x11 from Requires: in the .pc for xt and xmu/xmuu, and ice from sm
<Sarvatt> so -lX11/-lICE gets dropped 
<RAOF> That might not actually be the correct solution, though.
<Sarvatt> I wish this --no-add-needed crap waited until after squeeze released so we didn't have hundreds of modified packages
<RAOF> Hm.  It looks like Xmu should at least have a requirement on Xt; it's headers call Xt functions in #defines.
<RAOF> Man, I'm glad that Xmu is able to handle systems with 6-bit bytes.
<jcristau> Sarvatt: i'd be ok with reverting these changes fwiw
<jcristau> a bit sad, but meh.
<RAOF> As I mentioned above, I think the dropping of the Xt requires is wrong; the headers have #defines which use Xt symbols.  The other drops still look correct.
<jcristau> ok
<RAOF> Can I commit that to debian-unstable?
<RAOF> Hm.  Why does libxmmu not ship any headers at all?
<RAOF> Bah.  Because dependency chain.
<jcristau> headers are in libxmu-headers iirc
<RAOF> Yeah, found that.
<Sarvatt> looks like xless is the only one that'll be fixed by that so far
<RAOF> Possibly Xt needs an X11 requires? :)
<RAOF> Alternatively, a lot of build systems have wrong dependencies.
<jcristau> also something we're patching out..
<RAOF> Yeah, I'm checking Xt now
<Sarvatt> most things fail at x11 before hitting the xt failure so it probably fixes part of lots more
<jcristau> Xt without Xlib doesn't really make sense, so would probably not hurt to put it back
<jcristau> dunno about sm
<Sarvatt> 136 ftbs with  libX11.so.6: could not read symbols: Invalid operation
<Sarvatt> hmm those are --as-needed failures aren't they
<Sarvatt> --no-add-needed shows up with the undefinied reference errors on http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi
<RAOF> Yup, there we go.  Xt uses XMapWindow in a #define in one of its public headers, hence needs -lX11
<RAOF> And now, for libsm
<jcristau> libSM seems only used for a SmcConn member in Xt's SessionShellPart
<RAOF> Oh, I was only looking for X11 references in Xt!
<RAOF> And libSM doesn't use any libICE symbols in it's headers; the dropped Requires is correct.
<RAOF> jcristau: Are those Requires fixes acceptable for debian-unstable, or debian-experimental, or shall we take an Ubuntu delta?
<jcristau> -unstable works
<Sarvatt> so the libSM .pc change should go upstream possible and then the smproxy ice addition to PKG_CHECK_MODULES is the only one that'd be needed out of the series I guess
<Sarvatt> or we can just patch that :)
<Sarvatt> RAOF: fixed as in it was only reported against earlier lucid and I haven't seen any other reports about it, I'm not completely sure
<Sarvatt> bah, wrong channel sorry
<RAOF> Sarvatt: I'm pretty sure it got fixed by not using the drm renderer on nouveau :)
<Sarvatt> well it would fall back to that same behavior if we ditched the vesafb junk :)
<RAOF> :)
<Sarvatt> what it looks like to me currently is: vesafb loads, picks 640x480x8 or whatever, plymouth loads framebuffer renderer and starts using that, hands off to drmfb and gets resized up to native but plymouth is still drawing to the lower color framebuffer. that's all conjecture though
<Sarvatt> will try forcing a different mode next time i reboot to see
<RAOF> Good plan; I'll do the same.
<Sarvatt> oh - [    1.673571] vesafb: mode is 640x480x32, linelength=2560, pages=0
<Sarvatt> can't remember how to get the good logs out of plymouth I used to figure out what renderer backend it was using a long time ago..
<Sarvatt> ah plymouth:debug and its in /var/log/
#ubuntu-x 2010-12-10
<shlomi> hi
<shlomi> can someone help me configure my netbook
<shlomi> it seems that the drivers have screwed up
<shlomi> in pm :)
<shlomi> please please
<RAOF> Generally the plan would be to debug in the public channel, so more people can help.
<shlomi> what public channel ?
<shlomi> ubuntu-x referred to here , no ?
<shlomi> anyways ill just post the case
<RAOF> Yes, in this channel.
<shlomi> hope someone can throw me a bone
<shlomi> first, ive installed ubuntu 9.10 and everything works like a charm
<shlomi> i needed to upgrade for reasons that irrelevant reasons
<RAOF> Ok.
<shlomi> once i upgraded to 10.4 the problems started
<shlomi> every couple of minutes the screen corrupts
<shlomi> wierd lines 
<shlomi> pictures not clear
<shlomi> font scrambled
<shlomi> yada yada
<shlomi> ive added launchpad to my repository
<shlomi> tried installing radeonhd
<shlomi> oh sorry
<shlomi> btw 
<RAOF> So, what graphics chip do you have, and what drivers are you using (if there is an option)
<shlomi> 01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200 Series]
<shlomi> that i would call is an excellent question :)
<shlomi> now, how to i know what drivers are being loaded
<shlomi> i read the xorg.log.0
<shlomi> [    15.782] (II) LoadModule: "radeon"
<shlomi> [    15.783] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so
<shlomi> [    15.783] (II) Module radeon: vendor="X.Org Foundation"
<shlomi> [    15.783]    compiled for 1.9.0, module version = 6.13.2
<shlomi> [    15.783]    Module class: X.Org Video Driver
<shlomi> [    15.783]    ABI class: X.Org Video Driver, version 8.0
<shlomi> [    15.783] (II) LoadModule: "vesa"
<shlomi> [    15.784] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
<shlomi> [    15.784] (II) Module vesa: vendor="X.Org Foundation"
<shlomi> [    15.784]    compiled for 1.8.99.905, module version = 2.3.0
<shlomi> [    15.784]    Module class: X.Org Video Driver
<shlomi> [    15.784]    ABI class: X.Org Video Driver, version 8.0
<shlomi> sorry
<RAOF> shlomi: You want to use a pastebin for that.
<shlomi> hmm
<shlomi> genious u are :)
<shlomi> sec
<shlomi> ive never used it before
<RAOF> In fact, could you pastebin your entire /var/log/Xorg.0.log and dmesg?
<shlomi> http://pastebin.com/sW5A7HRH
<shlomi> sec ill add dmesg
<shlomi> heres the dmesg
<shlomi> http://pastebin.com/5KwsAy3K
<shlomi> i think line 677 in the dmesg is the beginning of the drm init
<RAOF> Yeah.  Those logs seem to be pretty inoffensive.  Could you describe the problem a bit more?
<shlomi> $ glxinfo | grep vendor
<shlomi> server glx vendor string: SGI
<shlomi> client glx vendor string: Mesa Project and SGI
<shlomi> OpenGL vendor string: DRI R300 Project
<shlomi> it's actually really hard
<shlomi> im in fear it will screw up
<shlomi> first, i cant connect my second monitor
<shlomi> by far it screws up, big time
<shlomi> hang on, what driver is it loading ?
<RAOF> It's loading the radeon driver; that's correct.
<shlomi> how does it know to load that one
<shlomi> where is the settings
<shlomi> *are
<shlomi> let's say i wanna load the radeonhd
<shlomi> maybe that will solve the whole issue
<RAOF> Unlikely; that driver's been dead for a year and doesn't do 3D.
<RAOF> It loads radeon because that's the default for the PCIID of your GPU.
<RAOF> You could specify a different driver in xorg.conf if you wanted.
<shlomi> would u recommend that
<shlomi> so that driver i have now is the latest 
<shlomi> ?
<RAOF> Yes.
<RAOF> You've got the driver that should work, and you're unlikely to find a better driver.
<shlomi> btw, i tried turning on the visual effects
<shlomi> how can i upload a pic 
<shlomi> (to where ?)
<RAOF> imageshack?
<shlomi> thanks 
<shlomi> sec
<shlomi> http://img442.imageshack.us/img442/6489/screenshotdkp.png
<shlomi> once i turned the visual effects off the horror stopped :)
<shlomi> so what r we looking at ?
<shlomi> how do we fix this ?
<RAOF> Wow, that's really messed up :)
<shlomi> thanks, i take great pride in my creations 
<shlomi> what about mesa
<shlomi> or lets put it this way
<shlomi> what is the difference between 9.10 and 10.4
<shlomi> (although im now with 10.10)
<RAOF> If you get that *without* having desktop effects enabled, it's not to do with mesa.
<RAOF> If that only occurs when desktop effects are enabled, it may well be mesa.
<shlomi> when desktop effects are off i still get it
<shlomi> it just fixes itself alot quicker
<shlomi> u know, ive got to play around with it abit
<shlomi> click here, click there
<shlomi> and it kinda comes back
<RAOF> I wonder if it has to do with power management.
<shlomi> interesting
<shlomi> how by ?
<shlomi> btw, ive posted here 
<shlomi> http://ubuntuforums.org/showthread.php?t=1614520
<shlomi> why would TemÃ¼jin say: If you're running the r300g driver from xorg-edgers PPA, report the bug to them.
<shlomi> what's that got to do
<shlomi> ?
<shlomi> RAOF ?
<RAOF> That's saying that if you're using the packages from xorg-edgers (which are snapshots of upstream development) then filing a bug upstream is a good idea.
<shlomi> but im not right ?
<shlomi> even though ive added the repositories and updated the packages
<RAOF> You are using those packages.
<Sarvatt> hmm
<shlomi> how do u know ?
<shlomi> so frustrating
<Sarvatt> shlomi: sudo apt-get install linux-image-2.6.37-8-generic
<RAOF> Because you've got xserver-xorg-video-ati version 6.13.2, which isn't in Maverick (but is in xorg-edgers)
<shlomi> ah ok , that means i have to be sharp on the versions
<shlomi> ill keep that in mind
<shlomi> E: Unable to locate package linux-image-2.6.37-8-generic
<shlomi> E: Couldn't find any package by regex 'linux-image-2.6.37-8-generic'
<Sarvatt> RS690M is a one of the rarest radeon GPU's and I remember there being problems with the lucid kernel that might not have been fixed
 * Sarvatt forgot what the maverick backports kernel was called
<shlomi> but on karmic (9.10) everything worked like a bell
<shlomi> pitty i don't have logs from then..
<Sarvatt> if you can boot there's obviously been some progress, that GPU was completely non functional with the stock lucid release
<shlomi> k
<shlomi> but on karmic it worked
<shlomi> so someone did something %100 right in the past
<Sarvatt> latitude XT was the only laptop shipping with one of those I think
<Sarvatt> (they pulled it from the market when AMD bought ATI)
 * Sarvatt nods
<Sarvatt> we switched to KMS in lucid
<shlomi> im using a Gateway LT31 netbook
<shlomi> *respect
<Sarvatt> odd, must have codenames mixed up then, whoops!
<shlomi> ??
<shlomi> between 9.10 and 10.4 someone played with the drivers
<shlomi> and ruined my life
<shlomi> :)
<Sarvatt> does linux-meta-lts-backport-maverick exist?
<shlomi> :|
<Sarvatt> I would say disable KMS but can't do that with xorg-edgers :(
<shlomi> oh boy
<RAOF> So, given this hint you could try the kernel team PPA backport kernels.
<shlomi> i don't understand 
<Sarvatt> I thought they were in lucid-backports now
<shlomi> what are u talking about 
<shlomi> sorry guys
<Sarvatt> upgrading your kernel to fix the bug
<shlomi> ah
<RAOF> shlomi: You should be able to install the âlinux-meta-lts-backport-maverickâ kernel; this is in lucid-updates.
<shlomi> when u say lucid-updates u mean the repository
<shlomi> ?
<RAOF> Yes.
<shlomi> but im maverik
<RAOF> â¦
<shlomi> so ide have to define then, correct
<RAOF> Sorry, forgot :)
<shlomi> ?
<shlomi> are u suggesting that because it worked on 9.10
<shlomi> we should downgrade the kernel ?
<shlomi> scrap that..
<RAOF> No, that won't work.
<RAOF> I'm thinking https://wiki.ubuntu.com/Kernel/MainlineBuilds
<RAOF> Specifically, I'd try installing the kernel packages from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.37-rc5-natty/
<RAOF> Which is the most recent upstream release, and may have fixes.
<shlomi> so installing an experimental kernel it is ?
<RAOF> It's not a bad plan to experiment with :)
<shlomi> which hopefully somehow is related to misfunctioning of the GPU
<shlomi> okay
<shlomi> how do i do thatt ?
<shlomi> sorry :)
 * Sarvatt gives up, read "I just installed lucid" in the bug report
 * Sarvatt reboots for the 10th time, dang you plymouth!
<shlomi> so how do i install the kernel ?
<shlomi> download it and do dpkg 
<shlomi> just like that ?
<RAOF> Yup.
<RAOF> In fact, you can probably just double-click on the package after you've downloaded it to install.
<shlomi> respect
<shlomi> btw how do i do those cool status updates that Servatt does ?
 * RAOF wonders whether you mean like this?
<shlomi> i do
<shlomi> just to make sure
<RAOF> â/me wonders whether you mean like this?â
<shlomi> i need not the image
<RAOF> You need the image; you probably don't need the headers.
 * shlomi now knows the truth - 42
<shlomi> RAOF: download the image and install it ? no need for the headers right ?
<shlomi> i wanted it to be in red
<RAOF> Yup, that's right.
<shlomi> how do u do the red line ?
<RAOF> That's highlighting.  Generally, your client will highlight lines containing your nick.  Eg: shlomi 
<shlomi> shlomi
<shlomi> nope didn't highlight it
<shlomi> oh well
<shlomi> ill let you know how it goes
<shlomi> thanks for all the help
<shlomi> i really appreciate it !
<RAOF> No problem.
<shlomi> okay so its installed
<shlomi> now i reboot and what should i expect ?
<RAOF> Well, ideally you shouldn't notice anything except for that corruption not happening.
<shlomi> :)
<shlomi> cheers
<shlomi> see you on the flipside
<RAOF> If you need to boot the old kernel for some reason, you can hold down shift during boot.
<RAOF> To get the grub menu to come up.
<shlomi> kk
<RAOF> That'll let you select previous kernels.
<shlomi> thanks for the tip
<shlomi> never new thstt
<shlomi> RAOF ?
<shlomi> u are a true hacker
<RAOF> Ya?
<shlomi> thank you
<shlomi> amazing
<shlomi> it never looked better
<RAOF> There's still the opportunity for it to break :)
<shlomi> the other screen works 
<shlomi> how come ?
<RAOF> Didn't the corruption happen sporadically?
<RAOF> Or was that corruption _always_ there?
<shlomi> it always lurked somewhere therr
<RAOF> Oh, well then.  It's probably fixed then :)
<shlomi> but when i connected a secondary monitor it flipped
<shlomi> now im watching a movie on the other screen
<shlomi> pretty solid proof
<RAOF> Yeah.  Hurray for people fixing things :)
<RAOF> âº
<shlomi> thanks
<shlomi> in the changelog they mentioned a few things
<shlomi> about radeon stuff
<shlomi> i guess somewhere along the line it was fixed
<shlomi> wierd that it broke somewhere along the line
<shlomi> okay
<shlomi> u were right
<shlomi> its not entirely gone
<shlomi> btw 
<shlomi> i saw a kernel for maverik
<shlomi> u recomend i install the natty
<shlomi> RAOF 
<shlomi> should i try install v2.6.37-rc2-maverick
<shlomi> kernel ?
<RAOF> That's a somewhat older kernel (rc2 rather than rc5), and the natty vs maverick naming isn't really relevant.
<shlomi> ah ok
<shlomi> i thought it's actually a different branch
<RAOF> No.  It's the same (slightly older) code, but with the configuration file from maverick rather than natty.  The configuration doesn't change much over time, and generally for the better.
<shlomi> okay
<shlomi> i guess ill have to live with this
<shlomi> do u recommend i update the kernel everyone in a while ?
<RAOF> Eh; maybe.
<shlomi> is there anyway i can help debug the problem
<RAOF> If you're comfortable doing some debugging I'd suggest filing a bug upstream; then the kernel developers can ask questions, propose patches, etc and it's more likely that the problem will be fixed.
<shlomi> thanks
<shlomi> where do i fill it out ?
<RAOF> bugs.freedesktop.org, under the âDRIâ project, component DRM/Radeon
<RAOF> If you need help testing patches, pop back up in here and we can provide testing kernels.
<shlomi> thanks
<shlomi> damn it really screwed up now
<shlomi> umph
<shlomi> at least the second screen woeks
<shlomi> cheers
<vish> Sarvatt: hi, i tried the x-x-v-ati from edgers and it doesnt fix the issue, (it seemed fine for 2days though).. there are still X freezes.. http://paste.ubuntu.com/541908/ , http://paste.ubuntu.com/541909/  but this time the bt's look different.. o.0  
<vish> it happens with smooth-scrolling enabled in FF4
 * vish tries with smooth-scrolling disabled..
<vish> the first one was where i tried to ^C and then do a backtrace, which dint work.. so i had to detach and then attach again to bt.. might be the reason for the difference.
<kcimc> i'm new to ppa installs, i'm following the webupd8 tutorial http://j.mp/eIuog4 are there any other packages besides (nvidia-current nvidia-current-modaliases nvidia-settings) that i should be installing to get 260.19.26 ?
<kcimc> i'm just confused because i also see nvidia-graphics-drivers and the xserver-xorg updates
<kcimc> if this is just dev and not help let me know if there is a better place to ask
<bjsnider> you should be using jockey to get it
<kcimc> i'm in ubuntu, it looks like jockey-gtk is the 'additional drivers' app, but i don't see any options but 'remove'
<kcimc> maybe because i already ran the apt-get install
<bjsnider> opent he hardware drivers manager
<kcimc> i'm there, it's the same thing as running jockey-gtk from the terminal
<bjsnider> does it say nvidia-current is installed and it's the .26 version?
<kcimc> it says 'nvidia accelerated graphics driver (version current) [recommended]' and doesn't say the version number
<kcimc> the nvidia x server settings still says 260.19.06 but i haven't restarted yet
<bjsnider> does it indicate the driver is installed?
<kcimc> yes, 'activated'
<bjsnider> ok, you should be fine
<kcimc> ok, i'll restart and see if nvidia-settings has the new version number
<kcimc> yup, it's updated
<kcimc> so in the future i can just go to jockey-gtk and it will check the ppa?
<bjsnider> no, it will be updated through update-manager like every other package
<bjsnider> the first install and switching between drivers is what jockey is for
<kcimc> aha, i see... that makes more sense
<kcimc> and now in update-manager i see the packages i didn't install (xserver-xorg-* etc)
<kcimc> awesome, thanks for the help bjsnider :)
<kcimc> i'm making an interactive piece for a bunch of screens and the nvidia drivers are kind of important to have up to date http://farm6.static.flickr.com/5129/5248093665_890d121d55_z.jpg
#ubuntu-x 2010-12-11
<alkisg_web> Hi, my xorg has hanged with 100% CPU usage. With strace -p `pidof X` from an ssh connection I see it's on a clock_gettime/settimer loop: http://alkisg.pastebin.com/hGGVYdyt
<alkisg_web> Any hints before I start trying to kill apps in case it recovers?
<tjaalton> strace isn't useful, see https://wiki.ubuntu.com/X/Debugging instead
<alkisg_web> Thank you, looking..
<tjaalton> backtracing in particular
<alkisg_web> "Now do what you need to make the X server crash. Or, if the problem is that the X server is locked up and doesn't react, stop it with ctrl-C. Now get a backtrace: "
<alkisg_web> What if Ctrl+C doesn't stop it?
<alkisg_web> Ctrl+Z suspends the task, but Ctrl+C doesn't do anything...
<tjaalton> hmm, dunno
 * alkisg_web even killed -9 Xorg but the gdb process still wouldn't accept ctrl+C, only ctrl+Z... I'll try again on the next crash (it's too often with this openchrome driver :()
<Azelphur> Sarvatt: no crashes in 2 days, your patch is definitely working :)
<Azelphur> you should commit it :D
<jitaki> hello
<Sarvatt> Azelphur: it needs more review first, your case is rather special and it has a high probability of breaking other things :)
<Azelphur> hehe ok
<Azelphur> Sarvatt: it's getting pretty heavy testing by me, as this is the houses MythTV box
<Azelphur> so 24/7 on with multiple users, it gets a lot of use, if I see any problems I'll let you know :)
<hyperair> Sarvatt: update: when compiz hangs on XGetSomethingOrOtherThatShouldNotHang, Xorg uses 100% CPU.
<hyperair> or near there anyway
<hyperair> Sarvatt: gdb shows that the bottom of the stack trace always shows xxvi, and the top is always in libpixman
<alkisg> The stock Lucid openchrome driver, 1:0.2.904+svn827-1, crashes my PC. If I boot it with Debian Squeeze (openchrome 1:0.2.904+svn842-2), it doesn't crash. Is there any way to update only that specific driver in Lucid and test if that is indeed the cause/fix of my problem?
<alkisg> (it crashes after a few minutes of usage, but I was unable to get a backtrace, gdb wouldn't accept ctrl+c)
<bjsnider> alkisg, the openchrome driver has not had any code changes upstream (if there is such a thing in regards to that driver) since may 2k10
<alkisg> bjsnider: in the changelog I see some fixes that relate to hangs, which may be what I experience
<alkisg> From svn827, the lucid version, to svn842, the squeeze version
<bjsnider> ok, so debian has a newer version
<alkisg> I looked at xorg-edgers ppa but I don't see a new version to try out there..
<alkisg> The maverick or natty version would also do, but the packages are not compatible - can I just recompile those?
<alkisg> E.g. send them to my ppa on launchpad and have them compiled there, and then install the .deb?
<bjsnider> you could do that with the squeeze package if you think it will help
<bjsnider> lucid would have an older version because it came out before may 2k10
<bjsnider> you could upgrade the whole system to maverick
<alkisg> It's a thin client so I'd have to upgrade my server to maverick too :(
<alkisg> The squeeze package has a dependency on xorg abi 6.0 or something like that, which in not satisfiable on lucid, do I have to change some constant in the code before compiling?
<alkisg> ...anyway the most important question is this, suppose I do verify that the lucid openchrome package has some serious bug and an it hangs for some models, would it be possible to get a backport for the package?
<alkisg> Thank you, bb
#ubuntu-x 2010-12-12
<alkisg> The Lucid xserver-xorg-video-openchrome package frequently hangs my X. I did some testing and I believe that problem is fixed in newer versions of the driver.
<alkisg> Is it possible to get an SRU or a backport of that package?
<alkisg> The Maverick package (where the hanging problem is fixed) depends on xserver-xorg-dev (>= 2:1.7.6.901), which is not available on Lucid.
<alkisg> Can I just install the xserver-xorg-dev from Maverick to my Lucid box in order to compile the openchrome driver?
<jcristau> no
<alkisg> Any ideas on how to compile a backported version/
<alkisg> ?
<jcristau> remove the 1.7.6.901 build dep
<alkisg> Thank you, trying...
<alkisg> Build failure: http://launchpadlibrarian.net/60515183/buildlog_ubuntu-lucid-i386.xserver-xorg-video-openchrome_1%3A0.2.904%2Bsvn842-0ubuntu2~ppa1_FAILEDTOBUILD.txt.gz
<alkisg> There's a check somewhere in VIDEODEPS that fails...: debian/xsfbs/xsfbs.mk:	@echo 'error: xserver-xorg-dev >= 1.7.6.901 needs to be installed'
<tinjo> anyone know how to enter in installed ubuntu 10.10 with nomdest
<tinjo> i am using nvidia 8400 GS card
<tinjo> i cant get display after grub selection. what i do
<alkisg> Uh. Unfortunately that videodrvdep file is only available with newer versions of xserver-xorg-dev :(
<alkisg> VIDEODEP = $(shell cat /usr/share/xserver-xorg/videodrvdep 2>/dev/null)
<alkisg> Maybe I could try using the Lucid debian/ dir with the Maverick src/ dir :-/
<alkisg> Hmmm that looks like it might work...
<alkisg> What does the "XErrors: 24" line in xrestop mean? Where can I see those errors?
<bjsnider> alkisg, why don't you do this. install the source package for the openchrome driver in lucid. then replace the source tarball with the squeeze source. make the appropriate changes in the changelog and send it in to see if it builds
<bjsnider> also there may be different patches in the debian build scripts
<alkisg> bjsnider: I managed to compile it in launchpad by using the old debian/ folder and the new (from maverick) src/ folder, but I had to remove the debian/patches dir as they no longer applied
<alkisg> Thanks1
<alkisg> ! (damn keyboard :))
<ubot4> alkisg: Error: I am only a bot, please don't think I'm intelligent :)
<bjsnider> alkisg, there could be patches in maverick that are necessary
<bjsnider> you'd have to check the maverick build scripts
<alkisg> The maverick debian/ dir didn't have any patches at all
<alkisg> Anyway I'll do some testing with it, and hope everything works fine... :)
<bjsnider> if it doesn't work fine there isn't much you can do about it
<alkisg> ...except dive into the driver sources and spend 1 month debugging it :D
#ubuntu-x 2011-12-05
<FernandoMiguel> good afternoon
<atdiehm> Sarvatt, ping?
<atdiehm> Sarvatt, bjsnider told me to come talk to you about my zenbook
<bjsnider> he might not be awake yet. he spends his nights in a batsuit beating the criminals of gotham to a pulp
<FernandoMiguel> ahah
#ubuntu-x 2011-12-07
<FernandoMiguel> boa noite
#ubuntu-x 2011-12-08
<FernandoMiguel> nite
<broder> bah - sorry, did i miss a response?
<Sarvatt> broder: ya didnt ask anything in this channel
<broder> oh, ok. irc client must have flaked worse than it looked
<broder> on a standard desktop, is there something other than g-p-m (or g-s-d now) that will blank the screen? the kernel or something?
<Sarvatt> not that i'm aware of, should only be g-s-d now
<broder> did the kernel used to?
<broder> i have a (2-4 yr old intel chip, running natty) machine in front of me that blanks the screen after 5-10 minutes in spite of /apps/gnome-power-manager/timeout/sleep_display_ac being 0
<Sarvatt> whats the gnome-screensaver timeout?
<broder> ooh, look at that
<broder> i uninstalled gnome-ss uninstalled, but xset q tells me there's still a screensaver timeout set
<broder> Sarvatt: cool, i can chase this from here. thanks for that :)
<FernandoMiguel> oias
<Prf_Jakob> Sarvatt, RAOF: It looks like the new 12.04 installer requires a larger screen then 800x600.
<Prf_Jakob> Which happens to be the default screen size for VM's
<bryceh> Prf_Jakob, you mean for the webcam picture taker thingee?
<Prf_Jakob> bryceh: no just the installer, got a bug report saying that some controlls ended up outside the screen.
<Prf_Jakob> That is I don't know if it is that.
<bryceh> it probably is, there's a bug filed about it against ubiquity already
<bryceh> I ran into that myself doing an install on a netbook
<Prf_Jakob> ok
<Prf_Jakob> We can up the default the screen size in the driver, but that would lead to uncomfritables for netbooks.
<Prf_Jakob> bryceh: do you happen to have the bug number available?
<bryceh> Prf_Jakob, I think it really should be fixed in ubiquity.  It looks to me like they just need to scale the pictures being displayed when the screen resolution is below 800x600
<Prf_Jakob> yeah that would be better.
<bryceh> Prf_Jakob, not offhand
<Prf_Jakob> ok
<bryceh> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/869239
<ubot4> Launchpad bug 869239 in ubiquity (Ubuntu) "webcam screen should be resized for netbooks (Eee PC, 10") (affects: 8) (dups: 3) (heat: 48)" [High,Triaged]
<Prf_Jakob> thanks!
<bryceh> thank firefox url autocomplete :-)
<Prf_Jakob> haha :)
<bryceh> Prf_Jakob, if you can add your case to that bug report, I'll bump up the importance on it a notch
<bryceh> maybe it'll get some attention
<Prf_Jakob> Okay, which email/pass combo did I use..
<Prf_Jakob> bryceh: ok done.
<bryceh> alrighty
<bryceh> it should show up on the release manager's list for alpha-2 now, which should ensure it gets some attention
<Prf_Jakob> bryceh: thanks, are you guys shipping 12.04 with mesa 8.0/7.12?
<bryceh> Prf_Jakob, yep
<Prf_Jakob> right, I'm guessing you are not using the xa_branch of xf86-video-vmware repo tho.
<bryceh> not sure, I haven't looked at the -vmware package in some time
<Prf_Jakob> http://packages.ubuntu.com/precise/x11/xserver-xorg-video-vmware <-- doesn't mention it in the package log.
<Sarvatt> Prf_Jakob: speaking of that, is that branch not going to get pushed to master or something?
<bryceh> Prf_Jakob, looks like we're just pulling from debian, so probably would be best if any branch changes be coordinated through them
<Sarvatt> its probably going to be another month or so at least, need a 8.0 mesa branch to enable xatracker for it and all but was just assuming vmwgfx_branch would go to master at some point
<Prf_Jakob> Yeah that branch is going to be merged soon.
<Prf_Jakob> Sarvatt: Okay, good to know.
#ubuntu-x 2011-12-09
<cnd> bryceh, RAOF: peter is nearly done with XI 2.2 initial upstream implementation (will be done in a few hours)
<bryceh> cnd, awesome, yeah saw his blog post
<cnd> is there an xserver 1.11 branch somewhere for precise?
<bryceh> cnd, yeah RAOF has one somewhere
<cnd> I didn't see it last time I checked in the debian git repo
<cnd> I'd love to get it into a ppa for testing asap
<bryceh> cnd, definitely
<bryceh> looks like chris is on vacation today
<bryceh> returning monday (our Sunday afternoon)
<cnd> ok
<bryceh> Sarvatt, ^^
<bryceh> cnd, I believe the branch RAOF has been working on is an attempt to forward-port the old Xi2 patches; he wanted to have something to compare this new work against
<bryceh> cnd, however he got hung up on some bits of it; I suppose he may not have pushed it anywhere due to that
<cnd> bryceh, is there a branch somewhere with just the x 1.11 stuff?
<cnd> I suppose that would be the same branch minus the xi multitouch patch(es)
<bryceh> cnd, possibly in edgers (thus why I pinged robert)
<cnd> ok
<bryceh> aha yep - *IMPORTANT NOTICE* - Unity has been uploaded to this PPA on oneiric with geis support ripped out so it works with xserver 1.11.
<bryceh> https://launchpad.net/~xorg-edgers/+archive/ppa
<bryceh> hmm, that has a git snapshot of xserver, I bet we'd want to pull one of the point releases.
<bryceh> cnd, however from the changelog it sounds like it's using a congruent debian/ directory so I bet if you pulled the xserver from edgers, you'd be in the right ballpark for what we'll be shipping.
<cnd> ok
<Sarvatt> cnd: http://anonscm.debian.org/gitweb/?p=pkg-xorg/xserver/xorg-server.git;a=shortlog;h=refs/heads/ubuntu%2B1
<Sarvatt> ubuntu+1 branch
<cnd> Sarvatt, sweet!
<cnd> maybe I misread something in that branch
<cnd> I thought it was still 1.10
<bryceh> http://phoronix.com/forums/showthread.php?65446-Racing-To-Finish-X.Org-Multi-Touch-Support#post241233
<bryceh> the comments have me rolling
 * jussi waves. anyone up? 
<jussi> anyway, guy in the office has an issue with resolution on his intel based machine (doesnt offer high enough resolutions). card is 00:02.0 VGA compatible controller: Intel Corporation Device 0116 (rev 09) - is this the correct place to ask for answers or wuld you prefer I used #ubuntu ?
<tjaalton> i'd prefer a bug report
<tjaalton> ubuntu-bug xorg
<jussi> tjaalton: ok, Ill get it done. 
<jussi> tjaalton: its on lucid, just as an fyi. 
<tjaalton> not much to be done ther
<tjaalton> e
<tjaalton> probably works just fine on a later release
<tjaalton> maybe try a newer kernel
<tjaalton> lucid has backported kernels from maverick, natty and oneiric
<jussi> ahh, excellent. so just need to enable updates then? 
<jussi> tjaalton: ok, he is running 2.6.32 (64 bit). Do I manually need to install a new kernel or?? 
<jussi> backports and updats both seem to be enabled...
<tjaalton> it's in main
<tjaalton> linux-image-generic-lts-backport-{maverick,natty,oneiric}
<tjaalton> pick one
<tjaalton> ..the latest
<jussi> wow, the kernel team are superstars :)
<jussi> sigh. good news is  the resolution works. bad news, wireless is borked. guess I might have to chat to the kernel team about htis one :(
<tjaalton> those are unsupported on desktops
<tjaalton> so unless it's broken on oneiric too i wouldn't bother
<tjaalton> try an earlier kernel
<jussi> its a lenovo laptop.  and yeah, we are trying maverick  kernel now
<tjaalton> which model?
<jussi> tjaalton: its an e520 - 11433lg. maverick kernel seems to be working though - the 3 problems we had are wireless, screen res and sd card not working. 
<tjaalton> so it's sandybridge, lucid didn't even have support for the graphics
<tjaalton> which means it would use vesa
<tjaalton> or fbdev, can't remember
<jussi> ahh that would explain it. In anycase, we tried all the kernels and funnily mavericks seems to work.
<tjaalton> it's the first version that got some support
<tjaalton> there should be a public repo with stuff backported from natty, but can't find it
<jussi> yeah, not sure I want to touch it anymore - it appears to be working :)
<Sarvatt> hmm xserver-xorg-video-glide is arch: any but requires libglide3 that is i386 alpha ia64 amd64 only
<DanA_> Hello I have a question for you guys. I'm using the ubuntu-x-swat x-updates repository, however we are having an issue with nviida driver versions 290 or 285. Is there any way to switch back to the 270 one?
<bryceh> DanA_, tried grabbing the natty deb?  https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers
<DanA_> would it work with Lucid?
<DanA_> bryceh, actually I double checked and it will have to be the one for Oneiric, since the driver that we need to use is 280.
<bryceh> DanA_, why are you running edgers on lucid?
<DanA_> there is a segmentation fault specific to our application that happens on 285 and 290, this happens also when using the binary installation from nvidia
<DanA_> our application is validated to run only on lucid LTS
<DanA_> bryceh, this segmentation fault is coming directly from the nvidia driver
<DanA_> bryceh, oh and we are using opengl features available on 280+
<bjsnider> DanA_, you're using opengl features from the 280 series, and you need to switch to the 270 series. that seems to be contradictory
<bjsnider> oh, i see. you say you need the 280
<DanA_> bjsnider, actually I said 270 by mistake, I've always meant 280
<DanA_> bjsnider, however the x-updates ppa only has 290
<bjsnider> i know. i put it there
<bjsnider> have you reported this issue to nvidia?
<DanA_> no, we will need to report it
<bjsnider> do you know how to do that?
<DanA_> however we don't have time right now for them to fix it and release a new one
<DanA_> I'll ask the developer having the issue
<DanA_> he is not new to working with nvidia issues and should know how to report them
<bjsnider> DanA_, https://launchpadlibrarian.net/76434148/nvidia-current_280.13-0ubuntu1~lucid~xup1_amd64.deb
<bjsnider> that was the last in the 280 series
<DanA_> awesome. Thanks!!
<DanA_> how do you find files in the launchpadllibrarian?
<bjsnider> the url was a redirect
<bjsnider> i just typed int he likely name and it worked
<bjsnider> https://launchpad.net/~ubuntu-x-swat/+archive/x-updates/+files/nvidia-current_280.13-0ubuntu1~lucid~xup1_amd64.deb
<bjsnider> redirects
<bjsnider> i think there's an ftp browser for this stuff but i don't know what the exact url is
<DanA_> thanks, that worked for nvidia-settings too
<DanA_> exit
<cnd> jcristau, what's going on with x11proto-input?
<cnd> it's file layout doesn't match the upstream tarball
<cnd> and I can't make heads or tails of it
<cnd> jcristau, nm, I figured it out
#ubuntu-x 2011-12-10
<Sarvatt> bryceh: mind renewing my ubuntu-x-swat membership before I forget over the holidays? :)
<bryceh> Sarvatt, sure
<Sarvatt> bryceh: thanks a bunch, i know i woulda missed it and we'd both be on forced week holiday for christmas :)
<Guest44553> Trying to recompile xorg: apt-get the sources, config, make,  have a binary, swap it out with /usr/bin/Xorg  and it complains : no drivers available, no screens found
<Guest44553> do i have to do the drivers too?
#ubuntu-x 2011-12-11
<FernandoMiguel> nite
<Sarvatt> hmm libva is in main, yet playback apps dont support it in ubuntu where they do in debian
<Sarvatt> (libva in main and supported? wth)
<bjsnider> vlc supports it
<Sarvatt> not my vlc
<Sarvatt> its not on the list
<bjsnider> list?
<bjsnider> mplayer is a thorny issue since gbeauchesne's patches eliminated vdpau support, but that problem may be fixed now. i will ask him. certainly vaapi and vdpau need to coexist, not be mutually exclusive
<Sarvatt> http://sarvatt.com/downloads/scrot.png
<bjsnider> no, no
<bjsnider> you're looking in the wrong place
<bjsnider> enable gpu accel
<Sarvatt> there was just a bug where a libdrm update broke mplayer/vlc/et all on intel in debian but i couldn't reproduce because vaapi wasnt an option http://paste.ubuntu.com/766476/ too
<Sarvatt> oh
<Sarvatt> ?
<Sarvatt> whatever the deal is the options were all enabled by default in debian
<Sarvatt> hmm, where should I be looking, i dont see it
<bjsnider> input & codecs
<bjsnider> enable gpu accel
<bjsnider> start vlc from a cli and you can actually see it using libva
<Sarvatt> just ticking that enabled vaapi output?
<bjsnider> yes it did
<bjsnider> you can make sure it's working by starting it from the cli
<bjsnider> vlc doesn't do 100% gpu decoding, so cpu usage should be higher than with mplayer/vdpau
<Sarvatt> ok that did work, and its not crashing here, go figure
<bjsnider> a libdrm update in debian but not ubuntu broke things?
<Sarvatt> yeah i didn't pull it in yet
<bjsnider> try mplayer -vo vaapi -va vaapi file.mkv
<Sarvatt> its not busted in edgers though which is confusing me
<Sarvatt> i pasted my mplayer -vo help output up there, vaapi isnt an option
<bjsnider> then it hasn't been patched
<Sarvatt> mplayer is a straight sync from debian
<bjsnider> like i said the patches eliminated vdpau in favour of vaapi
<Sarvatt> and mplayer was busted in debian
<bjsnider> uau thinks vaapi's presentation queue is inferior to vdpau
<bjsnider> for technical reasons i don't understand
<bjsnider> uau's mplayer2 is preferable to mplayer at this point imo
<Sarvatt> doesn't vaapi talk to vdpau now anyway so it doesn't matter?
<bjsnider> btw, does vdpau work well on snb?
<Sarvatt> why would it? no vdpau drivers..
<Sarvatt> the mesa vdpau crap is gallium intel doesnt do gallium
<bjsnider> i thought there was one
<bjsnider> oh, intel is using vaapi?
<Sarvatt> yeah
<bjsnider> well then does vaapi work well?
<Sarvatt> installing mplayer2 to see
<Sarvatt> i have no clue
<Sarvatt> stopped caring when dedicated devices replaced all my media centers, boxee box ftw :)
<bjsnider> popcornhour
<bjsnider> in oneiric mplayer2 doesn't know what -vo vaapi is
<Sarvatt> no vaapi in mplayer2 either unless im being an idiot
<Sarvatt> mplayer2 package installs /usr/bin/mplayer and no vaapi listed in mplayer -vo help
<Sarvatt> yah i'm on oneiric
<bjsnider> http://gitorious.org/vaapi/mplayer
<bjsnider> there's the patches
<bjsnider> i guess they haven't been applied
<bjsnider> how do you know about this bug?
<Sarvatt> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651316
<ubot4> Debian bug 651316 in libdrm-intel1 "libdrm-intel1: X.org crashes when I try to play a video" [Grave,Open]
<Sarvatt> been trying to reproduce that
<bjsnider> it takes down x?
<Sarvatt> its already fixed in x-x-v-intel
<Sarvatt> yea
<Sarvatt> libdrm update broke libva and it was crashing X, but i couldn't reproduce cus i couldn't use libva easily but it was used by default in debian
<Sarvatt> your libva stuff hasn't made it to debian yet
<bjsnider> i'm working with siretart and others on it
<bjsnider> but we have to make a new intel va driver package from my barebones beginning and nobody has stepped forward to assist
<bjsnider> but i did contribute to the packaging of 1.0.15
<Sarvatt> yeah i saw it in debian-multimedia, i'm using your stuff now
<bjsnider> i just emailed gwenole with some questions about the mplayer patches so i will get back to you when he gets back to me
<bjsnider> i didn't know vaapi had been left out of oneiric
<bjsnider> i mean mplayer/vaapi
<Sarvatt> if you have to check the box in the input codec section doesn't that imply its ffmpeg/libav where it needs to be enabled?
<Sarvatt> i didn't check to see if we're behind there
<Sarvatt> well thats vlc
<Sarvatt> yeah i'm slow libva really is used there when you check it
<bjsnider> there's vaapi code in libav, and anything that uses libav can use it. so by checking that box you're telling vlc to use it
<bjsnider> mplayer still has to be patched, and totem could use it but for gstreamer getting in the way
<bjsnider> gstreamer would have to be patched and them totem could use vaapi too
<Sarvatt> its still presenting the final stream via whatever output you picked and vaapi isn't an option in vlc, mixing in subtitles before presenting it to xv or gl. i guess mplayer does it different in -vo vaapi is an option
<bjsnider> i don't know. i can ask gwenole
<Sarvatt> yeah one of the intel guys asked me to put libgstvaapi in edgers for that
<bjsnider> the fluendo guys have a vaapi lib but you have to pay
<bjsnider> if the presentation queue is xv or gl that would be inferior to vdpau and probably vaapi too
<bjsnider> of course in mplayer you can use libav-mt with vdpau as the driver if you're on a multicore cpu
<Sarvatt> that seems to be how it works in vlc if you pick it in input codecs and are still using xv or gl to present it, thats why i was confused about where to enable it
<bjsnider> maybe it uses the vaapi queue without telling the user explicitly
#ubuntu-x 2012-12-03
<bcurtiswx> in raring, what happened to the window snaps to left and right and fullscreen? did i accidentally disable a CCMs setting?
<bcurtiswx> where would that setting be in CCSM ?
<mlankhorst> snappy windows?
<tjaalton> mlankhorst: did the backport stack get copied to precise?
<mlankhorst> not yet, I need to do a rebuild of every rdepends for x11proto first..
<mlankhorst> I copied ppa10 out of my ppa to the qbp ppa so I can empty my own ppa
<tjaalton> ok
<mlankhorst> just going to throw in a test rebuild of every possible package including the ddx
<bryce> [   239.272] (II) RADEON(0): Modeline "1680x1050"x0.0  146.25  1680 1960 2136 2240  1050 1053 1059 1089 -hsync +vsync (65.3 kHz eP)
<bryce> what does the eP at the end of that mean?
<jcristau> driver preferred
<bryce> ah
<jcristau> (hw/xfree86/modes/xf86Modes.c::xf86PrintModeline)
#ubuntu-x 2012-12-04
<MCR1> ricotz: Hi :) A new fglrx has been released (12.11 Beta 11) - would be nice if you could update the xorg edgers ppa...
<ricotz> MCR1, oh, i see, i will try
<MCR1> ricotz, thx 8-)
<MCR1> ricotz: o/ Thanx a lot 4 the fglrx-update. Worx perfectly. No need for new xorg.conf this time. 8-) And seems to be more stable than beta 8, which was crashing quite often - especially during OpenGL starts...
<ricotz> MCR1, i am glad it works since these are uploads into the blue
<ricotz> i can't test those
<MCR1> It is perfect, except 4 the AMD Beta Driver overlay...
<MCR1> but this is something one can easily remove...
<ricotz> MCR1, would be nice if you could check the dkms build with kernel 3.7
 * MCR1 is shaking in fear ;)
<ricotz> MCR1, you can try to point to a patch to remove that watermark
<MCR1> there is even a script somewhere, because the manual solution involves some effort
<MCR1> wait, I'll try to find a link
<MCR1> http://areyoueye.net/?p=187
<ricotz> hahaha
<ricotz> i actually feared some kind of binary patching
<MCR1> I think the dir is wrong though (should be /usr/lib/fglrx/xorg/modules/drivers/)
<ricotz> hahaha
<ricotz> i actually feared some kind of binary patching
<MCR1> well, there is a manual solution also
<MCR1> but it involves copying a file from the non-beta to the beta
<MCR1> ricotz: See here: http://askubuntu.com/questions/206558/how-to-remove-the-amd-testing-use-only-watermark-from-ubuntu-12-10
<MCR1> ricotz, it is the second answer with 3 points...
<MCR1> ricotz, I'll try to jump into the cold water and test fglrx with Kernel 3.7 on Quantal in the next dayz && will report then...
<MCR1> ricotz: Hahaha - with the new driver I get a new error message when trying to activate Display 3:
<MCR1> The selected configuration for displays could not be applied
<MCR1> required virtual size does not fit available size: requested=(5120, 1200), minimum=(320, 200), maximum=(3840, 1920)
<MCR1> Why is there a maximum of 3840x1920 ???
#ubuntu-x 2012-12-05
<mlankhorst> RAOF: dont feed the bioman :P
<seb128> could somebody get https://code.launchpad.net/~andrikos/ubuntu/quantal/xserver-xorg-video-intel/fix-ati-hybrid/+merge/132956 review? it's in the sponsoring queue for over a month
<tjaalton> seb128: done
<seb128> tjaalton, thanks!
<tjaalton> gonna get flak for that I guess :P
<jono> hey all
<jono> is anyone else experiencing random lockups of Unity in raring? I will be using my desktop and then nothing is responsive to click on - if I switch to a virt-term and back then things are back to normal
<rZr> tjaalton, hi
<rZr> i found this line :
<rZr> [22:19] <tjaalton> ../compositor.h:334:2: error: unknown type name 'PFNEGLQUERYWAYLANDBUFFERWL'
<rZr> can you helpM
<rZr> ?
#ubuntu-x 2012-12-06
 * penguin42 has added a patch to fix bug 1043513 - but I've got some questions about whether it's complete/the right way to do it
<ubottu> Launchpad bug 1043513 in xserver-xorg-video-cirrus (Ubuntu) "Xorg crashed with SIGABRT in memcpy() via cirRefreshArea() under KVM virtual machine" [Medium,Confirmed] https://launchpad.net/bugs/1043513
* You're now known as ubuntulog
#ubuntu-x 2012-12-07
<mlankhorst> yay more stack accepted
<mlankhorst> shall I put up a raring version now?
<tjaalton> of?
<mlankhorst> the renamed stack
<tjaalton> ah
<tjaalton> not much point yet, since nothing has changed :)
<mlankhorst> testing mechanics
<tjaalton> in that case go ahead
<mlankhorst> looks like 1.14 x release will be boring, ah well, I like boring :-)
<tjaalton> so no impedance layer?
<tjaalton> 1.13.0.902, I'll merge that
<mlankhorst> ah was going to do that myself
<tjaalton> feel free :)
 * mlankhorst was reading ml first to see if he missed some announce
<tjaalton> it got tagged, didn't see the announcement
<tjaalton> yet
<ricotz> tjaalton, mlankhorst, hi
<ricotz> tjaalton, are you going to update git for 1.13.1rc2 right away?
<tjaalton> ricotz: probably
<ricotz> tjaalton, i want to push it to edgers, but i guess there wont be much packaging change
<ricotz> so might be not worth to wait
<mlankhorst> I was waking up
<mlankhorst> I don't expect much packaging change, if any
<mlankhorst> oh some packages dropped ofc
<mlankhorst> s/packages/patches/
<mlankhorst> tjaalton: did you push xorg-server to raring previously?
<tjaalton> mlankhorst: not sure
<tjaalton> not the rc1 at least
<mlankhorst> ah k
<tjaalton> 2:1.13.0-0ubuntu8 yes
<mlankhorst> yeah just saw unreleased rc1, was wondering if an error or not :-)
<tjaalton> kinda forgot to upload it
<tjaalton> but now we have rc2! :)
<mlankhorst> I'm even doing a testbuild on an environment that's almost similar
<mlankhorst> :P
 * mlankhorst still on precise, using the renamed packages to satisfy depends
<mlankhorst> blegh fails on my libGL from blob, good enough I suppose..
<mlankhorst> ricotz: uploaded the new xorg-server, enjoy!
<ricotz> mlankhorst, oh, thanks, i already pushed it to edgers too though
<mlankhorst> one packaging change, ABI_VIDEODRV_VERSION bump
<ricotz> yeah, this already happened with rc1
#ubuntu-x 2012-12-08
<penguin42> can anyone suggest how I could progress bug 1043513 a bit; I've got a patch there for it
<ubottu> Launchpad bug 1043513 in xserver-xorg-video-cirrus (Ubuntu) "Xorg crashed with SIGABRT in memcpy() via cirRefreshArea() under KVM virtual machine" [Medium,Confirmed] https://launchpad.net/bugs/1043513
<tjaalton> penguin42: please send it upstream
<penguin42> tjaalton: I have done, I mailed xorg-devel late Thursday, no one seems to have replied to the questions I asked, I guess I'll wait longer
<penguin42> tjaalton: http://lists.x.org/archives/xorg-devel/2012-December/034680.html
<tjaalton> penguin42: yeah I saw it now, cool
#ubuntu-x 2013-12-03
<mck182> hi, while trying the nvidia drivers from xorg-edgers ppa, I'm getting "WARNING: The following packages cannot be authenticated!" - is this known on 13.10?
<mck182> I'm on kubuntu, added the repo via add-apt-repository 
<mlankhorst> might need to run apt-get update again
 * mck182 tries
<mck182> aha
<mck182> W: GPG error: http://ppa.launchpad.net saucy Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 4F191A5A8844C542
<tjaalton> you need to import the key
<tjaalton> or just ignore it
<mck182> I thought the key is imported automatically :O
<mck182> tjaalton: how do I import it then?
<mck182> I'd rather have signed stuff running here ;)
<tjaalton> use apt-add-repository..
<mck182> that's what I did
<tjaalton> it should import the key
<mck182> that's what I thought
<tjaalton> does 'apt-key list' show it?
<mck182> no, it gives me... "gpg: fatal: /home/mck182/.gnupg: directory does not exist!" ...?
<mck182> (it does really not exist)
<mck182> that doesn't sound right
<mck182> shadeslayer: ^
<tjaalton> no it doesn't
<tjaalton> your environment is messed up somehow
<mck182> it's moreless a default install
<tjaalton> it shouldn't look there
<tjaalton> you ran apt-key list?
<tjaalton> not gpg-key?
<mck182> yes
<shadeslayer> I thought it looks in /etc/apt/trusted.gpg
<tjaalton> does here
<mck182> it does too
<mck182> according to strace
<tjaalton> (and no gkg-key, but gpg --list-keys)
<mck182> I'm running "apt-key list"
<tjaalton> ok run it as root then
<mck182> that's different
<tjaalton> repro'd here
<mck182> couple Ubuntu keys
<mck182> ok hold on
<tjaalton> by moving .gnupg out
<mck182> http://paste.kde.org/p59a3254c
<tjaalton> anyway, the import failed for some reason, works here
<mck182> yeah, I got that :)
<mck182> can I import it manually?
<shadeslayer> yep
<mck182> tell me
<shadeslayer> https://help.launchpad.net/Packaging/PPA/InstallingSoftware
<shadeslayer> mck182: sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys KEYS
<shadeslayer> where KEYS is the thing that you copy over from the PPA page
<mck182> shadeslayer: the whole thing? with deb...saucy main?
<shadeslayer> no
<shadeslayer> see the link I posted above
<tjaalton> or just remove the sources.list.d file and reimport using apt-add-repository..
<mck182> shadeslayer: yup, that worked
<mck182> thank you guys
<shadeslayer> cool
<mlankhorst> Prf_Jakob: hey can you make a new xserver-xorg-video-vmware release some time soon? :)
<Prf_Jakob> mlankhorst: sure :)
<Prf_Jakob> We might want to bump the major with the XA change.
<Prf_Jakob> mlankhorst: oh which XA version are you guys on?
<mlankhorst> mesa 10 soon
<mlankhorst> so the major bump
<Prf_Jakob> kay
<Prf_Jakob> I'll ask internally what we want to do, either we will just add a bunch of ifdefs in the code or do a old stable and bump the major.
<Prf_Jakob> which do you guys prefer or is it all the same?
<mlankhorst> well we're going to transition to mesa 10 soon, and we don't need backwards compat
<Prf_Jakob> kay
<ricotz> Sarvatt, hey, do forget to get some love to trusty too ;)
<Sarvatt> its all going into trust really really soon :)
<ricotz> good then :)
#ubuntu-x 2013-12-04
<Sarvatt> Prf_Jakob: should be another day or so tops for xorg-pkg-tools if you're still waiting, just needs mlankhorst to push what he's done to git.debian.org :P
<daras> hi, what about ubuntu-x PPA for ubuntu 13.10? I'm getting 404
<daras> and here there's no saucy: http://ppa.launchpad.net/ubuntu-x-swat/x-updates/ubuntu/dists/
<daras_> am I doing something wrong or there's no support for 13.10?
<daras_> ok, thanks for help :) I'll try to find anyone alive tomorrow
<tjaalton> too impatient
<aicasn> hey folks - why is the latest nvidia driver still 319 in x-swat?  i believe the curent version is 332
<mlankhorst> Sarvatt: ^
<Sarvatt> guess i could just copy them out of edgers
<mlankhorst> oh wait x-swat ;P
<tjaalton> yeah who cares
<tjaalton> just upgrade the installation
<Sarvatt> if launchpad ever lets me do the copy, so many packages :)
<Sarvatt> aicasn: there ya go
<aicasn> are we not treating LTS as a valid distribution?
<mlankhorst> ues
<Sarvatt> its more not treating a ppa as a valid distribution :P
<tjaalton> if you want nvidia updated there, poke tseliot 
<tjaalton> gently
<tseliot> :)
<tseliot> aicasn: I'm working to introduce 331 in precise. This will land together with some major changes to the way we handle hybrid graphics, so it will take a while to get it all approved
<tjaalton> he wants 332
<Sarvatt> there isnt a 332, its 331
<tjaalton> ok, a type then
<tjaalton> typo even
<tseliot> well, I would use 332 if only it existed ;).
<aicasn> sorry it's 331.20. as i understood it, x-swat was created to provide current packages to frozen ubuntu distros. i was asking why no package since 319 had been added
<tseliot> aicasn: apparently ricotz uploaded that a few minutes ago https://launchpad.net/~ubuntu-x-swat/+archive/x-updates
<tjaalton> Sarvatt did
<Sarvatt> i just copied ricotz's packages out of xorg-edgers to it, thats where he updates them
<tseliot> ah, good
<aicasn> i see. thank you. so it's not a problem of compatibility ("331 doesn't play well with 12.04"), it's just that no one had updated the repo?
<tseliot> yep
<aicasn> awesome. thanks :)
<aicasn> tseliot: just for my info, what kind of a timeframe are we looking at wrt 331 in precise?  a month or two?  six?
<tseliot> aicasn: I'm going to upload soon, possibly by the end of this week, but then I don't know when they will be approved. All I know is that they will be available in Ubuntu 12.04.4
<tseliot> aicasn: the release date is January 23th
<tseliot> *23rd
<tseliot> https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule
<aicasn> good info
<genii> Is there a way to install both nvidia and fglrx drivers if you have one of each card? There is a user in #ubuntu claiming installing one removes the other
<tjaalton> no there is not
<genii> tjaalton: Is there some reason which could be given to explain why both cannot be used simultaneously?
<tjaalton> they both try to replace libGL
<genii> tjaalton: OK, thanks
#ubuntu-x 2013-12-06
<RAOF> mlankhorst: Hey, could I prevail on you to do some mesa committtitititititititititititing?
<mlankhorst> RAOF: what do you want? :p
<RAOF> The most recent DRIImage patch series, kthxbye.
<mlankhorst> RAOF: has to wait a bit longer
<mlankhorst> I want to land mesa 10 in the archive first :P
<RAOF> Oh, I meant upstream.
<RAOF> If I wanted to land in the distro that I'd just do it in egl-platform-mir.patch :P
<mlankhorst> hahah
<mlankhorst> RAOF: I don't work on fridays, can you remind me monday? :P
<mlankhorst> I'll try to remember
<RAOF> mlankhorst: Sure.
<mlankhorst> wrote it down on a paper anyway, so I should probably see it on monday and remember :)
<RAOF> And you'll probably ping for SRUs, right?
<mlankhorst> yeah, I've done some testing yesterday and uploaded latest saucy stack to ppa
<Prf_Jakob> mlankhorst: so QE wants to take a look at the relase before we can make one.
<mlankhorst> thought they might :p
<tjaalton> qa, always spoiling progress
#ubuntu-x 2013-12-08
<ryu_> somehow 'bumblebee' managed to screw up my nvidia drivers, I think I have some remnants of it laying around, but I purged everything and did a reinstall, the driver says active but is never in use
<ryu_> anyone have any ideas how to fix this?
<ryu_> bumblebee messed up my X config, now the Nvidia driver taints my kernel, I was able to finally get rid of bumblebee, but the driver isn't loaded and clicking additional drivers (reinstalling) ..  any ideas/tips? 
<tjaalton> ask the bumblebee guys?
<ryu_> I dont use bumblebee, I removed it
<ryu_> it wont load the nvidia driver, or it taints teh kr0nel
<tjaalton> right but they might know what's going on..
<ryu_> ok
<tjaalton> tainting the kernel is what loading nvidia does.. it shouldn't prevent loading it
<ryu_> I cant run 3D
<ryu_> so it doesnt work
<ryu_> I screwed it up badly by installing that
<ryu_> :(
<ryu_> right now I have the regular driver for 12.04, not the binary for nvidia
<tjaalton> pastebing xorg log somewhere
<ryu_> ok
<tjaalton> -g
<tjaalton> like, install pastebinit and run 'pastebinit ...log'
<ryu_> http://pastebin.com/u9gfGCZN
<ryu_> sorta confusing
<ryu_> not sure why it is even using noevaeu
<tjaalton> [    27.419] (EE) Failed to load module "nvidia" (module does not exist, 0)
<ryu_> yeah, it doesnt load
<tjaalton> you don't have the x driver installed
<ryu_> I know that
<tjaalton> and the nvidia version is newer than what's in precise
<tjaalton> or even saucy
<tjaalton> so, not gonna even try to understand why it's like that
<tjaalton> the nvidia blob should install a blacklist file so that nouveau doesn't load
<tjaalton> but that's not happening either
#ubuntu-x 2014-12-01
<ricotz> mlankhorst, hi, just want to make you aware of https://launchpad.net/ubuntu/+source/wine-development
<mlankhorst> why's that in vivid?
<ricotz> i guess an auto-sync
<mlankhorst> thanks, I'll ask the archive admins
<ricotz> mlankhorst, http://source.winehq.org/git/wine.git/commitdiff/79e0cb3a26f8ddefa12a7bf1023cf442f4072b81?hp=871fc4a38fa44b5484eb651236b182efef790248 ;)
<mlankhorst> wow, that's positively nasty..
<mlankhorst> I guess working 64-bits integer support is still optional for wine..
#ubuntu-x 2015-11-30
<jcastro> mamarley: ricotz: around?
<mamarley> jcastro: I am now.
<jcastro> hey so a guy from valve mailed me and said they're talking to nvidia and apparently the 358 drivers are a hot mess
<jcastro> he recommends pulling the driver but I have no idea how feasible that is, if so what's the upgrade path, etc. 
<mamarley> jcastro: I don't think it would be a good idea to force a downgrade or even remove the driver.  How about just post a note in the PPA description saying that 358 may be buggy and if so, one should try 355?
#ubuntu-x 2015-12-02
<mamarley> ricotz: I have fixed the bug the guy reported with the "modeprobe" typo.  Since it is such a simple change and since my staging PPA already contains the drivers I modified for EGL support, I am going to upload these straight to the main PPA.
<jcastro> mamarley: ok, I added a warning on top
<jcastro> are you on 358 or 355?
<mamarley> jcastro: I am running 358.  Did the Valve guy say what the problem was?
<jcastro> he just said it caused crashes in the steam client
<mamarley> Hmm, OK.
<jcastro> but I am not sure if they got that from the client reporting home, or their own internal testing, or what.
<ricotz> mamarley, alright
#ubuntu-x 2016-12-06
<mamarley> tseliot: How's that bisect going?
<tseliot> mamarley: sorry but it's going nowhere. Too much stuff got in the way :( , and I'll be off for the rest of December, starting this Thursday
<mamarley> Darn.
<mamarley> I guess I could do it myself.  You said the problem was somewhere between 4.8.0 and 4.9-rc1 right?
<mamarley> tseliot: ^
<tseliot> mamarley: yes, that's correct
<tseliot> mamarley: between 4.8.x (whatever the latest release it) and 4.9-rc1
#ubuntu-x 2016-12-07
<mamarley> tseliot: The bisect is complete.  The commit that causes the issue with 304 and 340 is fa5386459f06dc3b9181d4c954f980b127d1a32f (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fa5386459f06dc3b9181d4c954f980b127d1a32f).  I am currently looking to see if I might be able to fix the driver myself.
<mamarley> tseliot: I tried adding DRIVER_KMS_LEGACY_CONTEXT to .driver_features in 304 and it didn't work (I still get the same "Driver 'nvidia' is already registered, aborting..." loop as before.)
<mamarley> I don't know of anything else to try.
<tseliot> mamarley: looking
<tseliot> mamarley: I'll take some time today to investigate that
<tseliot> mamarley: good work on the bisection, BTW :)
<mamarley> tseliot: Thank my computer's processor, it did the the work! :)
<Sarvatt> hmm looks like libxcb needs a merge since xcb-proto got synced and broke the build
<mamarley> tseliot: I fixed the blasted thing!  It actually needs "DRIVER_LEGACY", not "DRIVER_KMS_LEGACY_CONTEXT".
<tseliot> mamarley: I thought you had tested that
<tseliot> mamarley: ok, let me patch the driver, test and upload
 * tseliot building
<tseliot> mamarley: it works fine. You're going to get credit in the changelog ;)
<mamarley> Thanks! :)
<tseliot> thanks to you ;)
<tseliot> mamarley: was there a bug report for that?
<mamarley> tseliot: A bug report against the NVIDIA driver?
<tseliot> mamarley: or against the kernel
<mamarley> I don't think it is a bug in the kernel, it looks like a purposeful change.
<tseliot> indeed
<tseliot> I won't mention anything else in the kernel then
<mamarley> For the NVIDIA driver, somebody was complaining about it in the forum, but no-one from NVIDIA ever acknowledged it.  Later I will post a reply on that thread with the cause of the problem.  Hopefully this will save them a bit of effort.
<tseliot> yes, that's a good idea
<mamarley> Kernel bisecting is annoying, especially when your test box starts panicking on every other reboot.
<tseliot> right
<tseliot> mamarley: are you available to test the 304 driver for me?
<tseliot> it should work, but still
<mamarley> tseliot: I already tested it. :)
<tseliot> mamarley: ok, that's good enough for me
<ricotz> mamarley, nice! :)
<tseliot> mamarley: uploaded
<mamarley> Thanks!
<tseliot> I'm going on holiday. I'll be back in January
<mamarley> Have a good time!
<tseliot> you too ;)
#ubuntu-x 2016-12-08
<alkisg> I'm trying to write a script that sets the preferred mode to 1024x768 for a number of computers, i.e. it puts something like this in xorg.conf:
<alkisg> Section "Monitor"     Identifier  "VGA-1"       Option      "PreferredMode"  "1280x720" EndSection
<alkisg> My problem is that it won't always be "VGA-1", and my question is, does it accept wildcards there? If not, how can I detect the monitor name before xorg has started?
<tjaalton> probably can't, and no idea
<alkisg> Thank you tjaalton.... hacks it is then :D
<alkisg> Maybe I'll put an early xsession script that just runs xrandr -s 1024x768 before the DM greeter gets launched
#ubuntu-x 2018-12-03
<tseliot> mamarley, ricotz: the changelog.Debian.gz for both amd64 and i386 share the same md5sum in bionic in the PPA. I wonder if the issue is just in disco
<tseliot> hmm... same goes for 19.04
#ubuntu-x 2018-12-04
<tseliot> ricotz, mamarley: I have just pushed a workaround for LP: #1804738 in Disco. I am still not sure why we can only reproduce the problem in disco though (new debhelper?).
<ubottu> Launchpad bug 1804738 in nvidia-graphics-drivers-410 (Ubuntu) "package libnvidia-ifr1-410 410.78-0ubuntu1 failed to install/upgrade: trying to overwrite shared '/usr/share/doc/libnvidia-ifr1-410/changelog.Debian.gz', which is different from other instances of package libnvidia-ifr1-410:i386" [High,Confirmed] https://launchpad.net/bugs/1804738
<ricotz> tseliot, a simple rebuild didn't resolve it?
<tseliot> ricotz: no, and I could reproduce the problem in a PPA too. The pkgbinarymangler was symlinking the docs, but that messed with multiarch, I think
<tseliot> symlinking changelog.Debian.gz of some packages to the one in their dependency
<ricotz> tseliot, did you try a local chroot/pbuilder build too?
<ricotz> maybe even on plain debian
<tseliot> ricotz: yes, that's how I discovered the problem (I used sbuild)
<ricotz> I see
<tseliot> and export DH_VERBOSE=1
<ricotz> thanks
<tseliot> uploaded and pushed to git
<tjaalton> is the package M-A: same?
<tseliot> tjaalton: yes
#ubuntu-x 2019-12-03
<ricotz> tseliot, hi, are you skipping 430.64?
#ubuntu-x 2019-12-05
<enoch8592> Hi guys!
<enoch8592> I have an issue that's been bugging me for days
<enoch8592> make that weeks btw*
<enoch8592> Running Ubuntu Mate 18.04 as a server for LTSP with dual screens (one VGA and one DP) on kernel 4.10 from mainline.
<enoch8592> The DP screen is forced in ltsp.conf to be shown to the client, without it it's not comping online at all. The clients run HP T5745
<enoch8592> Problem is that when moving the mouse in between the screens, the DP screen flickers for like 1-2 seconds and then comes back. This happens randomly.
<enoch8592> I've been talking alot in #ltsp about this and they sent me here
<enoch8592> I've read in many places that editing this would help: https://bbs.archlinux.org/viewtopic.php?pid=1533863#p1533863
<enoch8592> I've also tried 12 different DP cables, from different brands and the issue presists
<enoch8592> Other than that I've tried with the latest kernel (5.0) and using that makes the screen disappear completely, not even possible to force it. Only 4.10 works afai have tested
<enoch8592> Do you have any trick in your sleeve that I could try to sort this out, or is the next step to file a bug report with intel?
<enoch8592> Thanks!
<tjaalton> 5.0 is hardly latest
<tjaalton> oh he's gone'
<ricotz> tjaalton, 5.0 is the lastest supported hwe kernel in bionic ;)
<tjaalton> still pointless to file bugs about it to intel
