#ubuntu-x 2006-12-11
<Ubugtu> New bug: #73473 in xorg (main) "Very hi CPU usage when refreshing a window. radeon driver" [Undecided,Needs info]  http://launchpad.net/bugs/73473
<Ubugtu> New bug: #75397 in linux-restricted-modules-2.6.17 "Some OpenGL apps freeze the whole system with ATI Xpress 200 (fglrx)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75397
<Ubugtu> New bug: #75399 in linux-restricted-modules-2.6.17 "DVB-T doesn't working - fw missing" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75399
<Ubugtu> New bug: #63714 in xorg-driver-synaptics "[regression]   Not working vertical scrolling touchpad in Edgy" [Undecided,Needs info]  http://launchpad.net/bugs/63714
<Ubugtu> New bug: #66417 in xorg-driver-synaptics "Synaptics Touchpad's scroll not working out of the box" [Undecided,Confirmed]  http://launchpad.net/bugs/66417
#ubuntu-x 2006-12-12
<Ubugtu> New bug: #75412 in xserver-xorg-video-ati "Support for ATI Mobility Radeon X1600" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75412
* Starting logfile irclogs/ubuntu-x.log
<Ubugtu> New bug: #72803 in xserver-xorg-video-nv (main) "gnome-login with nvidia driver screen resolution bug" [Undecided,Needs info]  http://launchpad.net/bugs/72803
<Ubugtu> New bug: #75499 in xorg "Failure to identify and use i810 driver" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75499
<Ubugtu> New bug: #75505 in xserver-xorg-input-synaptics "problems with synaptics driver on laptop Dell Latitude D610" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75505
<Ubugtu> New bug: #68109 in Ubuntu "Some library used by skype can freeze system" [Undecided,Unconfirmed]  http://launchpad.net/bugs/68109
<Ubugtu> New bug: #75519 in xorg "switch user in kde changes the screen height" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75519
<Ubugtu> New bug: #63259 in xorg (main) "Static lines across screen while scrolling" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63259
#ubuntu-x 2006-12-13
<Ubugtu> New bug: #75544 in xorg (main) "Dell XPS M1210: Screensaver leaves video corrupted (Edgy)" [Undecided,Needs info]  http://launchpad.net/bugs/75544
<Ubugtu> New bug: #75303 in xserver-xorg-video-i810 (main) "BadAlloc error when playing a video with xv" [Medium,Unconfirmed]  http://launchpad.net/bugs/75303
<Ubugtu> New bug: #75592 in xorg-server "libGLcore crash (probably screensaver-induced)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75592
<Ubugtu> New bug: #75639 in mesa "wrong version number" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75639
<Ubugtu> New bug: #75665 in xorg "Microsoft Notebook Optical Mouse 3000" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75665
#ubuntu-x 2006-12-14
<Ubugtu> New bug: #75702 in mesa "~/.drirc is not read" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75702
<Ubugtu> New bug: #75706 in xserver-xorg-video-i810 "new upstream version fixes mode save/restore problem" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75706
<Ubugtu> New bug: #75726 in xorg-server "DRI broken on r128 on dual head r128 + i965 (non Xinerama)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75726
<Ubugtu> New bug: #75728 in xserver-xorg-video-ati "xv on r128 hard locked whole machine" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75728
<Ubugtu> New bug: #75160 in linux-restricted-modules-2.6.17 "Apport crashed after a crash on pouetchess" [Undecided,Confirmed]  http://launchpad.net/bugs/75160
<Ubugtu> New bug: #65785 in Ubuntu "Mouse is freezed after Userswitch" [Undecided,Needs info]  http://launchpad.net/bugs/65785
<Ubugtu> New bug: #75770 in xorg "ATI Open source driver shows distorted unreadable image on Dell laptop + Apple Cinema Display 23 inch" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75770
<Ubugtu> New bug: #59177 in xorg (main) "gnome-session ignores TMPDIR" [Undecided,Unconfirmed]  http://launchpad.net/bugs/59177
<Ubugtu> New bug: #75798 in xload (main) "terminal-to-window fontset string conversion Edgy live CD" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75798
<Ubugtu> New bug: #75808 in xserver-xorg-video-ati "Random PC freeze in X, possible ATI video problem" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75808
#ubuntu-x 2006-12-15
<Ubugtu> New bug: #75866 in linux-restricted-modules-2.6.17 "High packetloss over Atheros wireless" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75866
<Ubugtu> New bug: #75932 in xmessage "xmessage crashes on login" [Undecided,Unconfirmed]  http://launchpad.net/bugs/75932
#ubuntu-x 2006-12-17
<Ubugtu> New bug: #76140 in xorg-server "xorg-server 1.1.1 should depend on x11proto-gl-dev >= 1.4.6" [Undecided,Unconfirmed]  http://launchpad.net/bugs/76140
<Ubugtu> New bug: #76141 in xorg-server "xorg-server rules file puts ./configure in build section" [Undecided,Unconfirmed]  http://launchpad.net/bugs/76141
<Ubugtu> New bug: #76152 in xserver-xorg-driver-i810 "extra VGA output on laptop" [Undecided,Unconfirmed]  http://launchpad.net/bugs/76152
#ubuntu-x 2007-12-10
<ubotu> New bug: #175214 in xfs (universe) "Serious problems with XFS immediatelly following clean install" [Undecided,New] https://launchpad.net/bugs/175214
<ubotu> New bug: #175262 in xserver-xorg-input-joystick (universe) "Please sync xserver-xorg-input-joystick 1:1.1.0-1  (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/175262
<ubotu> New bug: #129603 in xorg (main) "[gusty] No DRI with "ati" drivers in x800xl card: RADEONDRIGetVersion failed to open the DRM" [Undecided,Fix released] https://launchpad.net/bugs/129603
<ubotu> New bug: #101943 in linux-restricted-modules-2.6.22 (restricted) "[nvidia] braid screensaver crashes system with compiz activated" [High,Confirmed] https://launchpad.net/bugs/101943
<tedg> Can you guys get to the X.org git repository?
<tedg> $ git clone git://anongit.freedesktop.org/git/xorg/doc/xorg-docs/specs/
<tedg> Initialized empty Git repository in /home/ted/Development/xorg/specs/.git/
<tedg> fatal: The remote end hung up unexpectedly
<tedg> fetch-pack from 'git://anongit.freedesktop.org/git/xorg/doc/xorg-docs/specs/' failed.
<bryce> lemme try
<tedg> I blame 'git' ;)
<bryce> hmm, it appeared to work, but then I got a wonky error
<bryce> ...
<bryce> * refs/heads/glucose-2: fast forward to branch 'glucose-2' of git://anongit.freedesktop.org/git/xorg/xserver
<bryce>   old..new: da2c4fa..06a58f2
<bryce> fatal: Fetch failure: git://anongit.freedesktop.org/git/xorg/xserver
<bryce> but yes, I can get to the git repo
<tedg> Wow, seems to be diabetic...
<tedg> Do you have anything in your ~/.git that I should have?
<bryce> gitme the suga baby
<bryce> I don't have a ~/.git
<tedg> Hmm, is there a bazaar mirror? ;)
<tedg> Can you e-mail me the XSMP spec?  That'll probably be easiest at this point.
<bryce> where in the tree is it?
<tedg> xorg/doc/xorg-docs/specs/SM
<bryce> git clone git://anongit.freedesktop.org/git/xorg/doc/xorg-docs  worked for me
<bryce> fwiw, you can also do apt-get source xorg-docs and get pretty much the same
<bryce> in any case, here's the files:  http://bryceharrington.org/files/SM/
<tedg> bryce: Cool, thanks.
<tedg> bryce: Okay, is there a editor that humans can use for that file?
<bryce> what's so hard about troff?
<bryce> I enjoy teasing you almost as much as you me ;-)
<bryce> tedg: I've got NFI
<bryce> the xorg guys are ornery bastards and I bet they edit it in vi
<bryce> and they LIKE it
<bryce> because they can do it while walking to school uphill in the snow
<tedg> Okay, what a PITA.
<tedg> I think I'll probably use VI then.
<tedg> Or, go with a little luxury and use VIM -- not the real experience, but close.
<bryce> looking at the other specs it seems many of them just use plain text
<bryce> troff does not seem to be the typical format; maybe that was just a peculiarity of whomever wrote it
<bryce> perhaps difficulty editing it is a contributing factor to the reason why it seems unmaintained and disconnected from everything else
<tedg> Yeah, could be.  I'll just use Frontpage and put it in pseudo-HTML ;)
<bryce> there you go
<tedg> <blink>{full specification}</blink>
<ubotu> New bug: #144045 in linux-source-2.6.22 (main) "hibernate does not work on Thinkpad t42 in Gutsy Gibbon (dup-of: 121653)" [Undecided,New] https://launchpad.net/bugs/144045
<tjaalton> bryce: hey, I uploaded xorg with two small changes, and probably the last upload before -8 which drops xresprobe
<bryce> heya tjaalton
<bryce> cool
<bryce> I'm still hacking on tormod's script and trying to figure out git merge issues
<bryce> (I'm pondering if bzr's merge works any better...)
<tormod> heya bryce!
<tjaalton> we still need to figure out what to do with livecd cleaning up the xorg.conf stub
<tormod> got my last patch? :)
<bryce> tormod: yup, applied and pushed
<tjaalton> bryce: ok, I still haven't tried the script
<bryce> tjaalton: yeah...  any thoughts on that?  we seem to be accumulating bug reports about that
<bryce> tjaalton: don't worry about it, I've still got avenues to explore
<bryce> basically I think I just need better git-fu
<bryce> tjaalton: oh one question
<tjaalton> bryce: well I'm thinking that it's not our bug, but maybe the way it's handled in pre/postinst could be improved 
<bryce> tormod and I want to share access to the git repo for this script, ala svn.  I know this can be done with bzr in launchpad, but how do we achieve that with git on alioth?
<bryce> tormod: oh whoops just saw your latest patch, I do need to add that
<bryce> tormod: I got the -D option, the rest is new
<tjaalton> bryce: well, there are a lot of projects under "collab-maint", but I'm not sure how to set up one
<tjaalton> bryce: you want to share commit access?
<tjaalton> collab-maint seems to be meant for debian packages
<bryce> hrm
<tjaalton> or do you just mean to put it somewhere for people to clone?
<bryce> no, the latter's already set up
<bryce> I'm just thinking, that I'm going to be a bottleneck for tormod (or vice versa if tormod was maintaining the git repo for it)
<bryce> anyway, I guess it's fine this way for now.  I was just hoping there'd be a simple way to flip it on, like with bzr
<tjaalton> well, even though the tool uses git, does it have to be maintained in git?-)
<tormod> bryce: I think the closest we can get is that I set up my own repo, and you pull changes from me on request.
<tormod> bryce: and I can might as well send you diffs... I don't have bigger plans for it now.
<bryce> ok sounds good
<tormod> tjaalton: it's a git exercise for us :)
<tjaalton> tormod: hehe, as good a reason as any ;)
<bryce> tormod: I've applied and pushed your patch (for real this time)
<tormod> have you tested it on all libraries etc lately?
<bryce> actually it sort of is.  ;-)  I've never done a git thing from scratch, only following other people's trees, so this is exposing me to some new bits
<bryce> tormod: yes I ran it on everything a few minutes ago.  It's still failing on a large chunk, and I'm going to investigate further
<tjaalton> bryce: I haven't done that either
<bryce> I'm going to make xorg-pkg-all.sh try multiple approaches (first without dropping patches against -experimental, then against -unstable, then with patches dropped...)
<tormod> would be cool if we could have "xorg daily" packages repo! and use the cd-customization scripts to make a daily xorg CD. that's my master plan.
<bryce> yup, that's what I'm shooting for here as well
<tjaalton> almost made the xorg upload an excercise of pulling specific debian changes in it, but figured out that -8 is coming soon so wasn't worth the trouble
<bryce> although I was thinking ppa rather than daily cd, but that's a pretty good idea too
<tormod> so upstream can say instead of "please try latest from git" : try the daily xorg live cd. and by wicked conspiracy, soon everybody is using Ubuntu. 
<bryce> >-)  bwahaha
<tjaalton> get them built first ;)
<bryce> actually yeah it seems every week someone asks for this on the xorg list, so it solves a practical need
<bryce> on it
<tormod> at the moment alpha-1 is almost this, but it's only close twice a year
<tormod> thanks to tjaalton, I must say
<bryce> yes
<tjaalton> bah, its nowhere near HEAD ;)
<bryce> I meant yes, it's thanks to tjaalton ;-)
<bryce> and really, aside from xserver and a few drivers, most things should be fairly close to head right now
<tjaalton> heh, yeah
<tedg> Okay, so I can't even recreate the PDF file I have.  Is there some sort of troff stylesheet or instructions or something?
<bryce> tedg: no idea
<bryce> tedg: don't you need to run troff to turn it into a .ps first?
<tedg> Yes, but my PS file has no paragraphs.
<tedg> ps2pdf won't fix that.
<tjaalton> bryce: hey, did you say that you are going to look at the XKB hell?
<tjaalton> I just got a new keyboard and most of the special keys aren't working and I wonder how to make them produce events
<tjaalton> but I'll figure it out later, now to bed.. seeya ->
<bryce> cya
#ubuntu-x 2007-12-11
<ubotu> New bug: #175243 in xserver-xorg-video-ati (main) "screen flickers only if text tty entered (radeon)" [Undecided,New] https://launchpad.net/bugs/175243
<ubotu> New bug: #175321 in xorg (main) "slideshow screensaver makes X to crash" [Medium,New] https://launchpad.net/bugs/175321
<ubotu> New bug: #175588 in linux-restricted-modules-2.6.22 (restricted) "Occasional cursor corruption" [Undecided,New] https://launchpad.net/bugs/175588
<ubotu> New bug: #119417 in xorg (main) "Pointer goes offscreen on non-rectangular dual-head" [Undecided,New] https://launchpad.net/bugs/119417
<ubotu> New bug: #162827 in linux-meta (main) "[MadWifi] denial of service (dup-of: 156203)" [Undecided,New] https://launchpad.net/bugs/162827
<ubotu> New bug: #152512 in xorg (main) "Gutsy 7.10 RC - X will not start - warns of low res mode" [Undecided,New] https://launchpad.net/bugs/152512
<ubotu> New bug: #175685 in xorg-server (main) "VT switching broken in Xorg" [Undecided,New] https://launchpad.net/bugs/175685
<bryce> yay, first cut at the auto-packager done (about 50% successful)
<ubotu> New bug: #127173 in xorg (main) "strange Xorg screen blanking control after resume from suspend to disk" [Undecided,Incomplete] https://launchpad.net/bugs/127173
<bryce> heya tormod
<tormod> hi bryce
<bryce> tormod: did a ton of work on the script last night and just checked it in about an hour ago
<tormod> I'll check it out
<bryce> dummied up a webpage too - http://people.ubuntu.com/~bryce/BFAXoGHP/results.html
<bryce> now that I got it this far, I'm going to be shifting focus to getting the xorg-server backport completed for UME; I think the auto script builds enough of my dependencies I can do it now
<tormod> ume?
<bryce> ubuntu mobile edition
<bryce> they need bleeding edge xephyr to do some 3d app development for embedded stuff
<bryce> (that was the primary reason for me putting in time with this script, although I also wanted to see it in general for lots of other needs)
<bryce> I think the script's to a point where it might be able to auto-build all the various drivers as well, but I've not given that a shot yet
<tormod> bryce: all the failing builds with "No available dir ../xsfbs from" - is it just because Debian has dropped xsfbs for those packages?
<bryce> I think so yeah
<bryce> I tried just having the script manually copy xsfbs into place, but it's not working... not sure why
<tormod> that would get you to 90% I think :)
<bryce> exactly my thinking
<bryce> actually I think it'll take me to 80%
<bryce> then there's some packages that have some mis-mapped package names that should be easy to fix, so that should do another 5-10%
<bryce> and probably I can squeeze a few more merge workarounds to make up whatever's left
#ubuntu-x 2007-12-12
<ubotu> New bug: #158069 in xserver-xorg-video-openchrome "openchrome is not working in Gutsy  (dup-of: 145279)" [Undecided,New] https://launchpad.net/bugs/158069
<ubotu> New bug: #138880 in xserver-xorg-video-openchrome (universe) "Openchrome driver in Gutsy (on in Fujitsu-Siemens Amilo Pro V2055) (dup-of: 145279)" [Undecided,Confirmed] https://launchpad.net/bugs/138880
<ubotu> New bug: #175789 in linux-restricted-modules-2.6.22 (restricted) "package xorg-driver-fglrx 7.1.0-8.42.3+2.6.22.5-14.1 failed to install/upgrade: subprocess post-removal script returned error exit status 2" [Undecided,New] https://launchpad.net/bugs/175789
<ubotu> New bug: #175822 in xserver-xorg-video-radeonhd (universe) "radeonhd driver segfaults - edid problem" [Undecided,New] https://launchpad.net/bugs/175822
<ubotu> New bug: #175823 in xserver-xorg-input-synaptics (main) "[Hardy]Scrolling with synaptics touchpad does not work" [Undecided,New] https://launchpad.net/bugs/175823
<ubotu> New bug: #175835 in ubuntu "Can not switch to TTY terminal from X in Hardy Alpha-1 (dup-of: 131751)" [Undecided,New] https://launchpad.net/bugs/175835
<ubotu> New bug: #175883 in xorg (main) "package xserver-xorg 1:7.3+7ubuntu1 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/175883
<Q-FUNK> can the version of -radeonhd in hardy compile against gutsy dependencies?
<tjaalton> not OOTB
<tjaalton> I think it build-deps xserver 1.4
<jcristau> it should work with old stuff though
<Q-FUNK> you mean relaxing the build-dep for x 1.4 and randr 1.2 should work?
<jcristau> afaik, yes
<tjaalton> yep
<Q-FUNK> ok.  it seems to be the only obstacle to getting myself a new laptop.
<Q-FUNK> if it builds, then I'm basically ok.
<Q-FUNK> although i'll have to find a way to install ubuntu with some sort of generic driver first.  at least with the feisty Cd I tried today, even VESA failed.  it couldn't find a screen mode it likes.
<tjaalton> gutsy should work
<tjaalton> vesa&server needed patches
<Q-FUNK> aye.  it even has some older snapshot of the driver available in universe.
<Q-FUNK> I still haven't received my gutsy CD's from shipit, though.
<Q-FUNK> I I'm just making a quick test in a gutsy pbuilder after relaxing xrandr and x core build-deps
<Q-FUNK> checking for XORG... configure: error: Package requirements (xorg-server xproto fontsproto  randrproto renderproto videoproto xextproto) were not met:
<Q-FUNK> No package 'xextproto' found
<Q-FUNK> nope.  won't build on gutsy without adjustments.
<Q-FUNK> was missing a build-depends on  x11proto-xext-dev
<ubotu> New bug: #114015 in vbetool (main) "vbetool crashes error 6 on resume with nvidia (dup-of: 88152)" [Undecided,New] https://launchpad.net/bugs/114015
<ubotu> New bug: #175939 in xserver-xorg-video-nv (main) "black screen on reboot with restricted drivers and "desktop effects" enabled" [Undecided,New] https://launchpad.net/bugs/175939
<ubotu> New bug: #175071 in xkeyboard-config (main) "Please add an explanation to Finnish "Kotoistus" keyboard in installer" [Wishlist,Confirmed] https://launchpad.net/bugs/175071
#ubuntu-x 2007-12-13
<Q-FUNK> http://lists.x.org/mailman/listinfo/xorg-driver-geode
<Q-FUNK> new list just to group -amd resources and have a more open discussion than the AMD mailing lists allow
<Q-FUNK> related to this
<Q-FUNK> http://www.x.org/wiki/AMDGeodeDriver
<bryce> Q-FUNK: nice
<bryce> Q-FUNK: is there a way to unsub from the info-linux list then?
<bryce> or will we be automatically unsubscribed?
<Q-FUNK> check the message source.  you can unsubscribe following X-headers in the message
<bryce> actually no you can't - it references http://ldcmail.amd.com as the mailman server, but this doesn't appear to be accessible (maybe it's an internal amd.com machine?)
<Q-FUNK> jordan could unsubscribe you
<ubotu> New bug: #176029 in x11-xserver-utils (main) "Please sync x11-xserver-utils (7.3+2) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/176029
<tjaalton> sweet, a new xserver snapshot.. I'll merge it later today
<ubotu> New bug: #176061 in xorg (main) "System do not respond properly after rotate the screen" [Undecided,New] https://launchpad.net/bugs/176061
<ubotu> New bug: #176099 in x11-xserver-utils (main) "Please sync x11-xserver-utils 7.3+2  (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/176099
<ubotu> New bug: #156065 in xorg (main) "gdm login crashes" [Medium,New] https://launchpad.net/bugs/156065
<ubotu> New bug: #156212 in xorg (main) "Changing screensaver crashes X" [Medium,Confirmed] https://launchpad.net/bugs/156212
<ubotu> New bug: #159747 in totem (main) "video playback failure with ubuntu 7.10 (dup-of: 146455)" [Undecided,Invalid] https://launchpad.net/bugs/159747
<Q-FUNK> could radeonhd be moved to main starting with hardy?
<Q-FUNK> for all I know, http://www.verkkokauppa.com/popups/prodinfo.php?id=24558 might be supported by it, but since it doesn't come on the CD, I could not test it at the computer store.
<Q-FUNK> in gutsy, it's in universe
<bryce> that's probably a good idea
<Q-FUNK> btw, that hardware even failed to launch with fbdev and vesa, when purposely configured manually on the gutsy CD
<bryce> I can't read that page ;-)
<Q-FUNK> aye, but the specs should remain clear :)
<bryce> nÃ¤ytÃ¶nohjain ?
<Q-FUNK> X kept on reporting "screen found, but none with usable mode" or something similar
<Q-FUNK> nÃ¤ytÃ¶nohjain = display driver ~ graphic card
<Q-FUNK> so yes, that ATI card :)
<bryce> you should talk with tormod about what's actually supported; he's had his finger closest to the pulse of ati stuff lately
<Q-FUNK> oh, ok
<Q-FUNK> good to know
<bryce> I'm mostly focusing on intel stuff at present
<Q-FUNK> mind you, pretty weird that not even vesa or fbdev work.
<Q-FUNK> ok
<bryce> yes that does sound strange
<bryce> however it's not been unknown for ati to fail vesa
<bryce> I thought most of the known issues were squared away, but...
<bryce> maybe you've got a HW X curse?
<bryce> ;-)
<Q-FUNK> :D
<tjaalton> oh goody, new monitor & mb & cpu etc arrived
<tjaalton> the xserver I uploaded failed to build on most archs
<bryce> erf
<ubotu> New bug: #176186 in xorg-server (main) "[gutsy] 'Lock screen' +gnome-screensaver + XMMS OpenGL visualizer causes Xorg to crash" [Undecided,New] https://launchpad.net/bugs/176186
<tjaalton> ../../../../../hw/xfree86/os-support/linux/lnx_apm.c:43: error: expected specifier-qualifier-list before 'apm_event_t'
<tjaalton> etc
<tjaalton> only sparc finished :)
<bryce> heh
<bryce> man, I'm having a heck of a time rebuilding my pbuilder root on hardy
<tjaalton> I couldn't create one, that's why I didn't test build it :/
<bryce> uff
<tjaalton> ok, offline for a while until the machine is up and running again
<tjaalton> ->
<ubotu> New bug: #176193 in xkeyboard-config (main) "missing key description in xkb "us" keyboard" [Undecided,New] https://launchpad.net/bugs/176193
<tjaalton> bugger, my old radeon is capable of 1920x1200 via dvi after all :)
#ubuntu-x 2007-12-14
<ubotu> New bug: #176045 in xserver-xorg-video-nv (main) "nvidia driver crashing." [Undecided,New] https://launchpad.net/bugs/176045
<ubotu> New bug: #165068 in linux-restricted-modules-2.6.22 (restricted) "Enabling restricted driver causes X to start in low graphics mode, defaulting to a failsafe vesa driver" [High,Confirmed] https://launchpad.net/bugs/165068
<ubotu> New bug: #175917 in scim (main) "cannot rename folders. cannot usually finish naming folders upon creation. (dup-of: 66104)" [Low,New] https://launchpad.net/bugs/175917
<ubotu> New bug: #176323 in xorg (main) "offset of screen will not offset the nautilus desktop icons" [Undecided,New] https://launchpad.net/bugs/176323
<ubotu> New bug: #176157 in xclipboard "Thunar can not paste, if xclipboard is running" [Low,Incomplete] https://launchpad.net/bugs/176157
<ubotu> New bug: #174152 in xorg (main) "funky virtual res on gdm" [Undecided,New] https://launchpad.net/bugs/174152
<Treenaks> \o/ upstream has fixed #20283 in git
<Treenaks> after.. 1.5 years or so :)
<tjaalton> Treenaks: was it the wobbly-image one?
<tjaalton> heh, it was
<tjaalton> good to hear that it's fixed now :)
<Treenaks> tjaalton: now all I want for christmas is a package of it ;)
<tjaalton> hehe
<tjaalton> for gutsy?
<tjaalton> oh, if it needs atombios it's definately hardy stuff
<Treenaks> tjaalton: well, I think it needs more testing on other mobile rv410 hardware than mine before it can be put in gutsy anyway
<tjaalton> right
<Treenaks> tjaalton: and it's a patch on git-master
<Treenaks> but I'll happily upgrade to hardy ;)
<tjaalton> oh it's that simple
<tjaalton> but yeah, could potentially break other rv410 setups
<ubotu> New bug: #174782 in totem (main) "bad colours playing movies in totem-gstreamer with xv output driver (dup-of: 32963)" [Undecided,Invalid] https://launchpad.net/bugs/174782
<ubotu> New bug: #176377 in xorg-server (main) "Frequent crashes on i915GM (Thinkpad X41)" [Undecided,New] https://launchpad.net/bugs/176377
<ubotu> New bug: #176393 in xterm (main) "xterm on x86_64 intermittently segfaults when ~/XTerm contains "*scrollBar: true" and "*saveLines: 100000"" [Undecided,New] https://launchpad.net/bugs/176393
<ubotu> New bug: #176404 in linux-restricted-modules-2.6.22 (restricted) "Nvidia on board audio not using speakers" [Undecided,Incomplete] https://launchpad.net/bugs/176404
<ubotu> New bug: #176442 in xorg-server (main) "Xorg crashed with SIGSEGV in XkbEnableDisableControls() (dup-of: 157881)" [Medium,New] https://launchpad.net/bugs/176442
#ubuntu-x 2007-12-15
<ubotu> New bug: #150572 in libx11 (main) "gnome-panel crashed with SIGSEGV in _XimServerDestroy()" [Medium,New] https://launchpad.net/bugs/150572
<ubotu> New bug: #137735 in xserver-xorg-video-via (main) "[gutsy] wine causes hard lockup - every time" [Undecided,Confirmed] https://launchpad.net/bugs/137735
<ubotu> New bug: #132000 in kdebase (main) "Clicking on OpenGL in KInfoCenter freezes up the system in Gutsy (dup-of: 137735)" [Undecided,Confirmed] https://launchpad.net/bugs/132000
<ubotu> New bug: #147269 in kipi-plugins (main) "[gutsy] When clicking on tools > Image Viewer; the PC freezes (dup-of: 137735)" [Undecided,Invalid] https://launchpad.net/bugs/147269
<ubotu> New bug: #176555 in libx11 (main) "libx11-6 / libx11-data conflict during upgrade from Dapper" [Medium,Confirmed] https://launchpad.net/bugs/176555
<ubotu> New bug: #176562 in linux-restricted-modules-2.6.22 (restricted) "Config fails in low memory machine (64MB) " [Undecided,New] https://launchpad.net/bugs/176562
<ubotu> New bug: #149507 in xorg (main) "Amarok's "global hotkeys" become stuck often" [Undecided,New] https://launchpad.net/bugs/149507
<pochu> hey there. Every video I play is played in black&white colours, but they are full-colour. slomo told me this was X fault, since I tried running them with a different engine from mplayer and it was the same. Also, while trying to reproduce them, I've had some X crashes, one of which I reported as bug 173265 (the backtrace is completely useless). Is there something I could do to help debugging this?
<ubotu> Bug 173265 on http://launchpad.net/bugs/173265 is private
<pochu> This is with an intel gma 915 and the -intel driver
<pochu> (hardy up-to-date)
<jcristau> which xv adaptor are you using (textured or video)?
<pochu> I don't really know, and I can't find on X/Debugging how to find it.
<pochu> (II) Loading extension XVideo
<pochu> Not sure if that means video - that's in Xorg.0.log
<jcristau> mplayer allows you to choose which one
<pochu> ah
<jcristau> mplayer -vo xv:port=<number>
<jcristau> get the number from xvinfo
<pochu> mplayer -vo xv /path/to/file
<pochu> ok
<jcristau> (each adaptor has a "port base" line)
<pochu> mplayer -vo xv:port=73 Desktop/andando10.mp4 - black&white
<pochu> I only have one adaptor so the number should be the good one
<jcristau> hmm, i thought only the 965 didn't have a video adaptor
<pochu> 915 mobile, that is
<pochu> 00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 04)
<jcristau> aiui, the textured adaptor is using the 3d engine to display video, so maybe there's a bug in that part of the driver on your hardware
<pochu> I've seen more bugs on lp with similar descriptions (playing a video in totem and then crash!) - bug 175303, bug 174571
<ubotu> Bug 175303 on http://launchpad.net/bugs/175303 is private
<ubotu> Launchpad bug 174571 in xorg-server "Xorg crashed with SIGSEGV" [Medium,Incomplete] https://launchpad.net/bugs/174571
<pochu> dunno if they have the same hardware or not
<pochu> Is it crazy to try to get the crash when running X under gdb? I've never done that before
<jcristau> you need to run gdb over ssh
<jcristau> but, it usually works
<pochu> I could do that, yes
<pochu> do you think the backtrace will be helpful?
<jcristau> make sure you have debugging symbols for the server and driver
<pochu> -dbg or dbgsym?
<pochu> or both? :)
<jcristau> either, i think
<jcristau> i've never used dbgsym
<pochu_> let's get started :-)
<pochu_> I'd have expected https://help.ubuntu.com/community/DebuggingSystemCrash to explain how to run X under gdb :-/
<pochu_> https://wiki.ubuntu.com/DebuggingXorg explains how to attach to it though :-)
<pochu_> ouch, ctrl+alt+f1 corrupted the screen
<pochu_> hmm, I could have restarted X through ssh instead of a tty...
<pochu_> Program received signal SIGSEGV, Segmentation fault.
<pochu_> [Switching to Thread 0xb7c846b0 (LWP 5643)]
<pochu_> 0xb7d9df8b in strlen () from /lib/tls/i686/cmov/libc.so.6
<pochu_> \o/
<pochu_> jcristau: I've pasted it in bug 173265, in case you want to have a look
<ubotu> Bug 173265 on http://launchpad.net/bugs/173265 is private
<pochu_> bug 173265
<ubotu> Launchpad bug 173265 in xorg-server "Xorg crashed with SIGSEGV" [Medium,New] https://launchpad.net/bugs/173265
<pochu_> I still have the connection opened, in case there is something useful I can do
<pochu_> Should I attach /etc/X11/xorg.conf, /var/log/Xorg.0.log, /var/log/syslog, /var/log/dmesg ... ?
<ubotu> New bug: #173265 in xorg-server (main) "Xorg crashed with SIGSEGV in strlen" [Medium,New] https://launchpad.net/bugs/173265
<pochu> back
<pochu> I lost the connection - I shouldn't probably do this kind of things via wifi :P
<jcristau> heh
<jcristau> can you go to the i830_unbind_memory frame, and print the value of *mem?
<pochu> I'm afraid I can't - I've restarted my laptop since I lost the connection :(
<pochu> I could try to get the crash again, now wired
 * pochu vs X - round 2
<pochu> Let's give this another try
<bryce> hi guys
<pochu_> hey bryce 
<pochu> heya bryce 
<pochu> :-)
<pochu_> woah, this was faster!
<pochu_> [Switching to Thread 0xb7ca36b0 (LWP 5634)]
<pochu_> 0xb7b7810e in i830_free_memory (pScrn=0x821be58, mem=0x86d87d8) at ../../src/i830_memory.c:289
<pochu_> 289     ../../src/i830_memory.c: No such file or directory.
<pochu_> jcristau: http://paste.ubuntu.com/2779/plain/
<tormod> pochu_: type "up" until you are in i830_unbind_memory, then: print *mem
<pochu_> I had to go down :) but here it is
<pochu_> (gdb) print *mem
<pochu_> $1 = {offset = 35, end = 0, size = 32, allocated_size = 0, bus_addr = 593808606253023233, key = 0, bound = 0, agp_offset = 4294967295, tiling = TILE_NONE,  fence_nr = 0, pitch = 0, name = 0x0, next = 0x0, prev = 0x40}
<bryce> jcristau: btw, I was trying to build current xserver git-head with the current debian rules file, but it's failing in some of the glx code
<bryce> jcristau: xserver compiles fine using a default ./configure, though
<bryce> jcristau: I'm wondering if it's a mesa version mismatch or something?
 * tormod updates DebuggingSystemCrash with links
<pochu_> any idea? :)
<tormod> I don't know what bus_addr is, but that's a seriously big number :)
<pochu_> heh
<pochu_> I have 1GB of ram, fwiw
<tormod> pochu_: did you follow DebuggingXorg? Was it clear? Just would like feedback since I wrote it. Any suggestions are welcome.
<pochu_> yeah, I did, and it looks perfect :)
<tormod> well that's what I wanted to hear :)
<pochu_> although you might want to say in the part of restarting X after modifying xorg.conf that it's a good idea to do it over ssh, since you have to connect to ssh anyway
<pochu_> since ctrl+alt+f1 corrupted my screen and I had to reboot to restart it ;)
<Q-FUNK> bryce: there's been progress on the -amd driver. it appears that changes in VBE since X core 1.3 might make -amd and several other marginal drivers (such as the siliconmotion on my laptop, also) fail DDC parsing.
<tormod> pochu_: if ctrl-alt-f1 corrupts your screen that's another problem, but it's a good idea to suggest doing it remotely, thanks.
 * pochu_ looks at fdo to see if this has been reported there
<pochu_> doesn't look like
<jcristau> bryce: xserver master needs mesa master
<jcristau> pochu_: it's crashing because mem->name is NULL...
<jcristau> but, the mprotect() call just before that shouldn't have failed, i think
<jcristau> anyway, it'd be good to report the crash upstream
<pochu_> any X expert wants to do that? I'm afraid a developer will ask something I won't know how to answer ;)
<jcristau> don't worry about that, there will be people to help :)
<pochu_> :-)
<jcristau> weird, your two backtraces on #173265 are different
<pochu_> the first one looks a bit similar since frame 8 though
<pochu_> although mem isn't null in that one
<jcristau> not the same line number
<pochu_> oh, right
<pochu_> Do you want me to get a third one? ;-)
<jcristau> heh
<pochu_> not kidding :P
<pochu_> are they two different bugs, or could they be the same one?
<jcristau> i don't know
<ubotu> New bug: #132171 in xserver-xorg-video-via (main) "AntSpotlight and other screensaver freezes the system" [Medium,New] https://launchpad.net/bugs/132171
<ubotu> New bug: #70731 in xscreensaver (main) "Crash (dup-of: 122999)" [Undecided,New] https://launchpad.net/bugs/70731
<ubotu> New bug: #111645 in xserver-xorg-video-via (main) "crash when screensaver is activated" [Undecided,New] https://launchpad.net/bugs/111645
<jcristau> pochu: actually your crashes look like they're the same as https://bugs.freedesktop.org/show_bug.cgi?id=13108
<ubotu> Freedesktop bug 13108 in Driver/intel "[overlay] XV window hidden for some seconds causes SEGFAULT when taken into foreground again" [Major,New] 
#ubuntu-x 2007-12-16
<ubotu> New bug: #176638 in linux-restricted-modules-2.6.22 (restricted) "[hardy] Files to disable screen watermark missing from 8.42.3" [Undecided,New] https://launchpad.net/bugs/176638
<bryce> jcristau: ah thanks
<pochu> jcristau: looks like. specially since I it happens here when hiding the totem window, and then bringing it again a bit later
<bryce> (sorry, was afk getting xmas tree w/ gf)
<pochu> jcristau: I've left a comment in the fdo bug, and have linked my launchpad bug to upstream's. Will update both bugs when there is more info, as I've subscribed myself to the upstream report.
<pochu> Thanks a lot of for your help and good night!
<ubotu> New bug: #176671 in xorg (main) "Graphics very slow following Hardy Heron Alpha 1 upgrade on Intel 945 chipset." [Undecided,Incomplete] https://launchpad.net/bugs/176671
<ubotu> New bug: #176741 in xorg (main) "xserver fails during installation on Acer TravelMate 290" [Undecided,New] https://launchpad.net/bugs/176741
<ubotu> New bug: #176804 in xorg (main) "XRandR: Sub-pixel font rendering uses wrong LCD pixel color order after rotation" [Undecided,New] https://launchpad.net/bugs/176804
#ubuntu-x 2008-12-08
 * bryce_ waves
 * wgrant swats bryce_ from across the room.
<tjaalton> wgrant: where the heck are you then :)
<wgrant> tjaalton: I'm assuming he's in the lobby, but I admittedly can't see him down here any more.
<tjaalton> wgrant: ha, we are on the second floor
<bryce_> timo and I are on the second floor lobby
<bryce_> tjaalton: bug 306014
<ubottu> Launchpad bug 306014 in libdrm "libdrm 2.4.1 needs udev rule for /dev/dri/card*" [Undecided,New] https://launchpad.net/bugs/306014
<wgrant> Oh.
<bryce_> heya tseliot
<tseliot> hi bryce
<lool> tjaalton: okay thanks
#ubuntu-x 2008-12-09
<tjaalton> whee, the mesa snapshot seems to work
<tjaalton> at least X starts
<tjaalton> and compiz runs (intel)
<crevette> hello gents
<tjaalton> seb128: hey, there's a new pixman that is a prerequisite for the new xserver. it adds a number of new symbols, but I'm not sure if it needs a transition to rebuild all the packages that depend on it. never done transitions before myself..
<seb128> tjaalton: adding symbols doesn't require a transition
<tjaalton> seb128: that's what I thought as well, thanks
<seb128> you're welcome
<tjaalton> so uploading it shouldn't break anything, just yet ;)
<seb128> transitions are usually soname changes
<seb128> right
<tjaalton> well, it'll still have usr/lib/libpixman-1.so.0 linked to .so.0.13.2
<tjaalton> so it should be fine
<seb128> right, same soname
<crevette> seb128, sorry I didn't do a lot of things this week end
<crevette> hey federico1 
<crevette> seb128, if I can hel$p on small packages tell me
<seb128> crevette: no need to be sorry, and we are busy too here at uds ;-)
<seb128> crevette: ok will do
<bryce_> tjaalton: https://bugs.edge.launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=date_last_updated&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=ubuntu-main-sponsors&field.component-empty-marker=1&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&field.tag=&field.tags_combinator=ANY&field.has_no_package.used=&search
<bryce_> =Search
<bryce_> tjaalton: also see http://people.ubuntu.com/~dholbach/sponsoring/
<federico1> hey crevette
<crevette> yummy,  dri2 has landed 
<crevette> perhaps some better perf on X
<bryce_> tjaalton: http://people.ubuntu.com/~bryce/xkeyboard-config_1.4-1ubuntu1.debdiff
<joumetal> Does bug 306616 have enough information to be confirmed?
<ubottu> Launchpad bug 306616 in mesa "[i945] Xorg crashes with SIGABRT after GDM login when DRI is enabled" [Undecided,New] https://launchpad.net/bugs/306616
<bryce_> tjaalton: xkeyboard-config uploaded
<bryce_> tjaalton: you were right, patch 100 could be simplified greatly
<tjaalton> bryce_: yeah, most of it was included, and I was lazy with the SRU to just modify that patch directly instead of adding another :)
<bryce_> ah
<bryce_> ok, so other than x11proto-input we should be all caught up on MoM now :-)
<tjaalton> I've uploaded that too :)
<tjaalton> could also upload libxi to go with it
<tjaalton> also new xtrans and x11proto-xext were required for 1.6beta
<tjaalton> both video and input ABI-versions have been bumped btw
<tjaalton> in the 1.6beta
<bryce_> ok so we'll need to rebuild _everything_ eh?
<tjaalton> bryce_: pretty much, but I've got a script for it somewher
<tjaalton> +e
<tjaalton> btw, I uploaded the inputproto anyway because the xserver build-deps >= 1.4.4, and this was a chance to drop that change (we build-dep'd on 1.4.3ubuntu5 or so)
<tjaalton> I'll upload mesa now
<tjaalton> the script basically just runs dch & dpkg-buildpackage on every package in a directory
<bryce_> ok
 * bryce_ nods
<tjaalton> mesa uploaded \o\ /o/ \o/
<tseliot> \o/
<tjaalton> oh sweet, lpia barfs again
<tjaalton> at me
<tjaalton> and armel too, same error
<tjaalton> oh look, xorg-jaunty vanished from the schedule :)
<tjaalton> more time for crack
#ubuntu-x 2008-12-10
<bryce_> tjaalton: http://pastebin.ubuntu.com/83221/
<tjaalton> bryce_: yeah, looks very good
<kees> bryce_: xserver-xorg-input-evdev 1:2.0.99+git20080912-0ubuntu6 appears to do really evil stuff (bug 303228)
<ubottu> Launchpad bug 303228 in xserver-xorg-input-evdev "[jaunty] all entries (also passwords!) logged to terminal underlying the X server" [Undecided,New] https://launchpad.net/bugs/303228
<tjaalton> kees: they should have 2.1
<tjaalton> er, that and xserver 1.5.3
<kees> tjaalton: oh! sorry, I meant, version 2.1 seems to do evil stuff for them
<tjaalton> kees: yes, without 1.5.3 :)
<kees> aaah
<kees> weird.
<kees> tjaalton: can you answer and close that report?
<tjaalton> kees: yes, I've replied and following it
<tjaalton> the depends should probably be tightened
<kees> tjaalton: cool, thx
<bryce_> tjaalton: are you enabling DRI2 in the new xserver build?
<tjaalton> bryce: yep
<tjaalton> hmm, wrong bryce
<tjaalton> interesting, the new mesa and/or kernel makes my intel dog slow after resume
<crevette> I had such behaviour yesterday night (but I had no new mesa) after the x11proto-dri2 updated
<tjaalton> the proto is irrelevant
<crevette> for instance switch between chans in xchat was sloooow
<tjaalton> protos are just headers
<tjaalton> and only needed for building stuff
<tormod> tjaalton: while I remember it, you can remove that Xsession.d_65mesa-check-x86-64 hook from mesa now.
<tjaalton> tormod: cool, thanks
<crevette> tjaalton, ah okay, perhaps some bits elsewhere
<tjaalton> hmm, now after trying to change the vt everything else is snappy but the mouse :)
<tjaalton> bryce_: yes, dri2 is enabled
<tjaalton> there's a new beta, I'll pull that and the one patch from the proposed set that thomas jaeger suggested
<bryce_> tjaalton: kewl
<wgrant> Do we have the right mesa stuff for DRI2?
<tjaalton> wgrant: yes
<tjaalton> but there's an "intel-q4" -branch that I'm not sure what it contains
<tjaalton> nor when it's going to be merged in master
<tjaalton> maybe jesse knows
<bryce_> superm1: jesse's patch is packaged  for hardy - http://people.ubuntu.com/~bryce/Testing/Intel-Bug297245/
<bryce_> tjaalton: we have our X session right now
<tjaalton> great
<crevette> hey
<bryce_> wgrant: btw we're having the X session at this time (in Bragi)
<bryce_> wgrant: btw we're having the X session at this time (in Bragi)
<wgrant> bryce_: Argh, I didn't see that (due to the fixed width layout being chopped off), and went to identity management instead.
<tjaalton> wgrant: well, we can rehash the topics over a beer or so ;)
<tjaalton> there's a gobby document about what was discussed (xorg-jaunty)
<solarion> federico1: it doesn't work?
<federico1> solarion: what doesn't work?
<solarion> federico1: I dunno.  You were saying it, not me.  (trelane on #gnome-hackers)
<shirish> tormod: hi
<tormod> shirish: hi, got your keyboard sorted out? :)
<shirish> tormod: no, I'm on Intrepid atm
<shirish> tormod: it works when I go single, but not when I'm on the GUI
<tormod> see my mail
<shirish> tormod: saw it
<tormod> didn't help?
<shirish> tormod: still trying to figure out what to do next. 
<tormod> you installed evdev from the ppa, as the Warning said?
<shirish> tormod: there is no warning of that sort on the PPA
<shirish> tormod: https://edge.launchpad.net/~xorg-edgers/+archive
<tormod> you don't get the "PPA whiteboard" in fading blue?
<tormod> are you logged into lp?
<shirish> tormod: I'm logged into lp
<tormod> hmm it's a problem that not everybody see the page as I do...
<shirish> tormod: what do you mean "PPA whiteboard" in fading blue, where I should be looking
<tormod> on top, under the two lines "PPA for..." and "URL:..."
<tormod> before "Xorg packages pretty fresh..."
<shirish> tormod: nope, don't see anything therein
<tormod> oops I have to fix that. anyway, I posted this in the phoronix thread as well.
<shirish> tormod: cool, also aren't there two evdev packages?
<tormod> no?
<tormod> I updated the PPA page now!
<shirish> tormod: I refreshed and now do see some additional info.
<shirish> tormod: thank you
<shirish> tormod: as far as the evdev packages I meant there is :-
<shirish> xserver-xorg-input-evdev - 1:2.1.0~git-0ubuntu0tormod     
<shirish> and
<shirish> xserver-xorg-input-evdev - 1:2.0.99+git20080726.53e75257-0ubuntu0tormod     
<shirish> tormod: which of the two to choose?
<tormod> for Intrepid?
<shirish> tormod: for jaunty
<tormod> one is for Jaunty the other for Hardy...
<tormod> see the Series column
<shirish> tormod: ah, so I just have to install xserver-xorg-input-evdev and it would do the needful :)
<shirish> tormod: ah yes, my fault
<shirish> tormod: ok rebooting in jaunty now, installing that and see if I can get it working :)
<shirish> tormod: thank you for your guidance so far. 
<shirish> tormod: I am on jaunty and xserver-xorg-input-evdev has been already installed
<shirish> tormod: dunno whether its from the ppa or otherwise
<shirish> be back in a moment
<tormod> shirish: you need the ppa version.
<shirish> tormod: would check it apt-cache policy should tell me
<shirish> bbiaw
 * bryce_ waves to tormod
 * tormod waves back to bryce_
<tjaalton> o/
<shirish> tormod: I am guessing just purging xserver-xorg-input-evdev and installing it would get it from the ppa or do I have to give some specific path or something?
<tormod> shirish: either download the debs directly from the PPA page,
<tormod> or install with apt-get install package=version
<shirish> tormod: but apt-cache shows me both the archive and the one therein as same
<tormod> shirish: pastebin?
<shirish> I would have to log out and log back in
<shirish> bbiaw
<tormod> tjaalton: did you sort out the MAP_ANON breaking mesa on lpia?
<tjaalton> tormod: not yet, no idea what's going on.. but apparently it shouldn't even be built on armel and I'm fixing that now
<tjaalton> armel failed the same way
<tormod> did you ask some kernel guys?
<tjaalton> nope, not yet
<tormod> I saw there is discussion about dropping lpia altogether...
<tjaalton> yes, finally
<tormod> googling tells me ANON_MAP was deprecated long time ago
<tormod> "use "MAP_ANONYMOUS" instead"
<shirish> tormod: thank you, I'm in jaunty and everything is cool :)
<tormod> but then the failing main/execmem.c has #ifndef MAP_ANONYMOUS
<tormod> #define MAP_ANONYMOUS MAP_ANON
<tormod> #endif
<tormod> so it seems MAP_ANONYMOUS is missing on lpia...
<tormod> shirish: nice! do you run DRI2?
<shirish> tormod: I have no idea what DRI2 is ?
<tjaalton> tormod: thanks, I'll ask around!
<tormod> shirish: well it should make glxgears follow the cube when you spin it :)
<shirish> tormod: wouldn't that be for newer hardware, not for ancient chipsets like mine i845 which has a measly 8 MB of RAM
<shirish> tormod: on the chipset I mean
<tormod> shirish: oh yes, that's only for i915 I guess
<tormod> but 3D acceleration works?
<shirish> tormod: another small issue though, I do get this message, No command 33 has been defined with window named Metacity every now and then. 
<shirish> tormod: also when I installed the xserver-xorg-input-evdev from the ppa it downgraded the version 
<tormod> shirish: I get it every time I hit Up-arrow (which I usually use all the time, on the command line as well in the browser). PITA especially when I keep the key down and I get 100 metacity dialogs...
<shirish> tormod: yup, it has something to do with the terminal
<shirish> tormod: same here
<tormod> Yes, that's the catch. the needed ppa version has been superseeded by the main package which will not work.
<tormod> I will need to bump the version, or just wait for Timo to push a rebuilt evdev in main.
<shirish> tormod: yup, something has to be done, till that time can't do any normal upgrades otherwise the one which doesn't work will come up. 
<tjaalton> once xserer 1.6beta is uploaded, all drivers will be rebuilt because of the abi bumps
<tjaalton> *xserver
<shirish> http://pastebin.com/f3f589827
<shirish> tormod: now as it stands
<tormod> shirish: yes that how it should be
<shirish> tormod: ok cool, so this works, so I guess just need to be patient till next week. 
<tormod> I don't want to bump the version now, since the rebuilt main version might be just -build1 and I want it to supersede mine
<tormod> you can upgrade all other packages, except -evdev and -synaptics
<shirish> tormod: what I would like to do now is to downgrade to all the packages in main, wait for next week when the xserver-xorg which is there in the PPA as well as the driver and see if the problem persists
<tormod> you mean the keyboard mapping issue? yes I wonder if Timo also will be bitten by this.
<shirish> tormod: yup
<shirish> tormod: now the final thing how to get back to where I was, with others in archives, purging all the packages from the PPA and getting back to main
<tormod> shirish: but if you run "setxkbmap -model evdev " it helps a lot
<tormod> oh my, try setxkbmap first :)
<shirish> I did that, what is supposed to be happen with this?
<tormod> the wrong key mapping should be better. It helped me make PgUp/down work.
<shirish> tormod: I still get the No command 33 has been defined with window error in terminal
<tormod> only the damn up-key is still broken
<shirish> right
<tormod> you don't need to purge, just apt-get install package=version where version is the official version
<shirish> tormod: what about the drm-modules-2.6.28-2-ub-generic that was installed 
<shirish> tormod: shouldn't that be purged?
<tjaalton> tormod: bitten by what exactly?
<tormod> tjaalton: with the 1.6 server there's some funkiness with evdev, wrong keymapping, undefined keys so metacity complains etc
<tjaalton> tormod: hum, ok.. thanks for the heads-up then
<shirish> what should I do about drm-modules package which I configured and then installed http://pastebin.com/f5faa0a9f
<tormod> shirish: just uninstall it
<shirish> tormod: right ok cool
<shirish> tormod: thank you for all your help
<shirish> bbl
<tormod> the drm-modules-somekernelversion
<shirish> tormod: right
<tormod> you can keep the drm-module-source package
<tormod> you're welcome
<shirish> there is drm-modules-source and drm-modules as well 
<tjaalton> tormod: you might want to ping whot on #xorg-devel about these issues
<tormod> tjaalton: I first thought I missed something in the merge, like the fdi files, but I am not sure. Don't have time to look at it now.
<tjaalton> evdev ships no fdi-files
<tjaalton> at least our evdev shouldn't
<tjaalton> the debian one does, since they don't have the necessary plumbing in place just yet
<tormod> or all the debian patches I just ditched because they didn't apply...
<tormod> hmm, my evdev does ship a 10-x11-evdev.fdi
<tjaalton> tormod: that's probably it then
<tjaalton> at least worth to check out
<wgrant> tjaalton: You broke my video!
<wgrant> It's flickering constantly now :(
<tjaalton> wgrant: congrats!
<tormod> I think I might have deleted it, because I don't see it, only in  dpkg -L
<tjaalton> wgrant: the new mesa?
<wgrant> tjaalton: Possibly. I'll turn off Compiz.
<wgrant> tjaalton: No, still broken with metacity.
<wgrant> Hmm.
<tjaalton> is it with -intel? my 965 works now, with the old kernel
<tjaalton> try with .27
<wgrant> i915, -intel, yep.
<tjaalton> .28 breaks stuff for me
<wgrant> I can't, my root is ext4 and I mounted with .28 a couple of weeks ago so can't mount with .27 any more.
<wgrant> .28 worked fine for ages.
<tormod> tjaalton: I see now in .bash_history (better than brain) that I moved the fdi away to check.
<wgrant> Oh.
<wgrant> It's getting the EDID lots, so I presume something is RandRing lots.
<tjaalton> hmm, sounds like some app going crazy then
<tormod> wgrant: KDE?
<tjaalton> and you should be able to back out to ext3 btw
<wgrant> Possibly. I'll check what else I upgraded.
<wgrant> tormod: No, GNOME.
<wgrant> tjaalton: Not once it has a file with extents.
<wgrant> The new kernel is fine.
<tjaalton> wgrant: ah, ok
<tjaalton> well my intel goes crazy with the new kernel.
<wgrant> -1 froze after suspend. -2 works fine.
<tjaalton> after resume it just slows down, until you change to a vt (which will bounce back), and then everything is snappy except the mouse which is really jerky
<wgrant> Aha.
<wgrant> It's g-s-d being crap.
<tjaalton> hehe
 * tormod says good night
<wgrant> tjaalton: It's not just g-s-d's fault - something seems to go wrong when things anything does some kind of xrandr stuff. I'm trying to work it out.
<wgrant> (aplogies for atrocious typing, I can't read the screen too well)
<wgrant> Or maybe it's because X is freezing and missing keystrokes.
<tjaalton> heh
#ubuntu-x 2008-12-11
<tjaalton> bryce_: shouldn't your session start now?
<tjaalton> the x-testing-infrastructure
<tjaalton> there you are :)
<bryce_> loic martin, are you here?  We're starting the session
<bryce_> tjaalton: slangasek would love to have you in the hotkey session since there's a lot of hotkey questions he hopes to get your input on.  Could you come?
<tjaalton> xserver 1.6beta3 built, whee
<bryce_> tjaalton: yay
<tjaalton> X.Org X Server 1.5.99.3
<tjaalton> Release Date: (unreleased)
<tjaalton> X Protocol Version 11, Revision 0
<tjaalton> Build Operating System: Linux 2.6.27-7-generic i686 Ubuntu
<tjaalton> Current Operating System: Linux pris.hut.fi 2.6.27-7-generic #1 SMP Tue Nov 4 19:33:20 UTC 2008 i686
<tjaalton> Build Date: 12 December 2008  12:11:56AM
<tjaalton> the only problem is that the keyboard layout is wrong in gdm
<wgrant> tjaalton: I downgraded libxrandr2, and it has been working fine for hours.
<tjaalton> wgrant: oh, funky
<tjaalton> thanks for finding out the cause
<tjaalton> wgrant: there doesn't seem to be anything related upstream, so could you file a bug or shout on IRC about it?
<tjaalton> upstream, of course
<wgrant> tjaalton: Sure, I don't think I've got anything useful on in the next session.
<wgrant> I
<wgrant> I'll make sure I can reproduce it easily a few times with the new one again.... it's very, very odd.
<tjaalton> yes it is
#ubuntu-x 2008-12-12
<tjaalton> wgrant: toss me the url once you're done
<tjaalton> x11perf -a10text has gone from ~55k on intrepid to ~91k with the new xserver, and ~145k with the new xserver & kernel 2.6.28
<tjaalton> wgrant: I'm wondering if the problem would go away with the new xserver
<tjaalton> [ 1433.531017] irq 16: nobody cared (try booting with the "irqpoll" option)
<tjaalton> that makes my machine really slow, since i915 was using that irq
<wgrant> It's perfectly fast for me.
<tjaalton> probably hw related
<tjaalton> something crashes and as a result that irq gets disabled
<wgrant> I used to have that.
<wgrant> But with .28 I don't.
<wgrant> (the 'nobody cared')
<tjaalton> yeah :)
<tjaalton> wgrant: reported the libxrandr bug upstream yet?
<crevette> good morning
<tjaalton> 7away
<tjaalton> uh
<tjaalton> wgrant: what gfx chip do you have?
<tjaalton> wgrant: bug 307306
<ubottu> Launchpad bug 307306 in libxrandr "upgrade to 2:1.2.99.2-0ubuntu1 makes session utterly slow" [Undecided,New] https://launchpad.net/bugs/307306
<tjaalton> can't wait any longer, I'll report it upstream
<tjaalton> wgrant: piiinggg? :)
<tjaalton> (I hope you have i945)
<tjaalton> there is also bug 307150 which has i945
<ubottu> Launchpad bug 307150 in xorg "[jaunty] with kernel 2.6.28 my x hangs after 30 sec" [Undecided,New] https://launchpad.net/bugs/307150
<albert23> tjaalton: see http://bugs.freedesktop.org/show_bug.cgi?id=19037
<ubottu> Freedesktop bug 19037 in App/xrandr "Some libxrandr 1.2.99.2 requests cause hugely repeated EDID requests" [Major,New]
<tjaalton> albert23: oh, cool
<tjaalton> I didn't know it was reported
<tjaalton> I'll mark mine as a dupe then
<albert23> tjaalton: FWIW, I have no problems with the libxrandr update with server 1.6beta2
<tjaalton> I didn't have either
<tjaalton> with 1.5/1.6beta
<tjaalton> albert23: btw, you are using the 'us' layout right?
<tjaalton> with the new server
<albert23> tjaalton: yes, us/intl
<tjaalton> albert23: ok, so you are not seeing fdo bug 19048
<ubottu> Launchpad bug 19048 in debian-installer "Installer gives unhelpful error messages when it can't read from the CD" [Low,Confirmed] https://launchpad.net/bugs/19048
<tjaalton> freedesktop bug 19048
<ubottu> Freedesktop bug 19048 in Server/general "xserver 1.5.99.3 fails to set the correct layout" [Normal,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=19048
<tjaalton> although you could test it :)
<albert23> tjaalton: no, my keyboard is mostly ok.
<albert23> But I do have miising keycodes in xsession-errors
<albert23> tjaalton: switching to Nederlands seems to work fine.
<tjaalton> don't do that from the gui, that works
<tjaalton> you need to set  it in /etc/default/console-setup, restart hal & gdm and see what's used in the gdm login screen
<tjaalton> and check the Xorg.0.log that the driver is using the layout
<albert23> Tjaalton: after reboot GDM is still US. X-log and setxkbmap say I have Nederlands
<tjaalton> albert23: touchÃ©
<tjaalton> so it's not just me :)
<tjaalton> hmm, I could git-bisect it
<albert23> tjaalton: isn't gdm doing this? i.e. /etc/gdm/Xsession tries to set the keyboard map if ~/.Xkbmap exists. But I don't have ~/.Xkbmap.
<tjaalton> me neither
<tjaalton> besides it's the login screen
<tjaalton> so it's using the system defaults
<wgrant> tjaalton: Sorry, quickly-flattening battery and dodgy hotel wireless == not often checking IRC.
<tjaalton> wgrant: heh, no worries
<tjaalton> I'll upload the xserver to my ppa soonish, so jesse can start working on backporting intel modesetting :)
<wgrant> Ooh shiny.
<tjaalton> yes, apparently the backporting was accepted
<tjaalton> keybuk just asked me the status of the intel driver
<wgrant> Oh, I thought it was decided to keep the kernel in a PPA.
<wgrant> ANd not backport KMS to .28...
<wgrant> But I wasn't in the session.
<tjaalton> this is probably newer information
<wgrant> Excellent.
<tjaalton> yeah, I'm happy, since KMS support is so cool
<tjaalton> I've switched my gdm to vt1 already :Ã
<wgrant> Yep.
<wgrant> Plymouth!
<tjaalton> um, :P
<wgrant> Aha.
<wgrant> I have to mount my filesystems and do other booting stuff manually now, so I don't see the point.
<tjaalton> well, you don't have gdm running yet, right?
<wgrant> Right.
<tjaalton> so it shouldn't cause any pain if that was to happen :)
<wgrant> Right, but is there any benefit?
<tjaalton> less flicker
<tjaalton> oh, and we get to follow fedora
<wgrant> I see.
<tjaalton> well, maybe the benefit of doing so isn't that great when we still use usplash
<tjaalton> since it'll be flickery for all users
<tjaalton> hmm, I'll package intel-2.6-branch on my ppa as well
<wgrant> tjaalton: That has KMS and DRI2?
<tjaalton> wgrant: right
<tjaalton> might make jesses work a bit easier
<wgrant> When are we getting server 1.6 branch?
<tjaalton> when the layout bug is fixed
<tjaalton> the ppa will have it though
<tjaalton> there
<tjaalton> hum, intel wants a newer libdrm too, of course
<tjaalton> well, lunch
<tormod> tjaalton, arel you gonna push your mesa changes to git.d.o ?
<tjaalton> tormod: sorry, done
<tormod> oh thanks!
<tjaalton> tormod: I've uploaded the new xorg-server to my ppa
<tjaalton> and pushed the git changes now
<tormod> cool, but the keymapping on 1.6 is still broken right?
<tjaalton> the ppa branch is a local one, but essentially only the changelog has changed
<tjaalton> right
<tjaalton> otherwise it would be on the main archive
<tjaalton> :)
<tormod> your intel mentioned above, that's 2.5.1 right?
<tjaalton> tormod: no, the 2.6-branch
<tormod> I will make an intel-testing PPA and backport drm and intel for Hardy and intrepid, but not tonight, going skiing early tomorrow.
<tjaalton> wanted to push that to my ppa, but it'd need a newer libdrm
<tjaalton> heh, have fun
<tormod> yeah 2.4.2
<tormod> are you thinking of 2.6 in Jaunty soon?
<tjaalton> well I'd like to have a libdrm release first
<tormod> I have 2.6 (and 2.4.2ish) in xorg-edgers ppa
<tjaalton> which is basically required because otherwise intel would be upset
<tjaalton> ok, cool
<tormod> oh btw that's 2.4.2 + modesetting-gem, but apparently that's too buggy
<tormod> I will revert to 2.4.2 + the modesetting patch from Jesse on dri-devel
<tormod> (if I get time before he commits it to master)
<tjaalton> well eric commented that already, and there are some issues but not necessarily in functionality
<tormod> also I instruct people to compile drm modules to match libdrm, but I think that's wrong or not needed at this point. libdrm/linux-core is not up to date for some reason.
<tjaalton> they've changed the release process, so linux-core status is a bit unclear to me
<tormod> shouldn't they either ditch or update it?
<tjaalton> probably :)
#ubuntu-x 2008-12-13
<tjaalton> gotta lave the uplink here at the hotel
<tjaalton> *love
<tjaalton> 'xorg' uploaded to my ppa, so maybe the stuff there will be installable soon
<tjaalton> ok, so vmware bought tungsten graphics a couple of weeks ago
<tjaalton> wonder what that'll mean
#ubuntu-x 2008-12-14
<alex_mayorga> bryce, you there?
<alex_mayorga> or anyone that can help with bug 146706
<ubottu> Launchpad bug 146706 in xorg-server "[Hardy] Live cd graphics fail with nvidia geforce4 440 go " [Unknown,Confirmed] https://launchpad.net/bugs/146706
<alex_mayorga> I have the system this weekend for troubleshooting
<tormod> alex_mayorga: one thing that might be nice is a log from running with Option "ModeDebug"
<alex_mayorga> tormod, how do I get it? I just attached current Xorg.0.log to the bug report, FWIW
<tormod> alex_mayorga: you add Option "ModeDebug" to the Driver section and restart the xserver. It will be a little bit more verbose about how it selects mode etc. But I didn't read the bug report thoroughly. Is the same mode selected as when it was working?
<tormod> the output will still be in Xorg.0.log BTW
<tormod> if the mode is correct, ModeDebug might not be so interesting.
<alex_mayorga> tormod, there's no Driver section on my xorg.conf
<tormod> sorry I meant Device section
<alex_mayorga> OK, let me add that
<alex_mayorga> tormod, I've added that line to xorg.conf, what now?
<alex_mayorga> reboot?
<tormod> it's enough to logout and in, because that will restart X
<alex_mayorga> tormod, I have no gui, it's all garbled
<alex_mayorga> let me reboot, I'm troubleshooting over ssh now
<tormod> ctrl - alt -backspace should work
<alex_mayorga> tormod, I've rebooted and I now have GUI, odd, only thing I did was to aptitude install read-edid
<alex_mayorga> make sense
<tormod> so read-edid solved the whole issue?
<alex_mayorga> that was the only thing I did besides adding the line you suggested under Device, then sudo reboot and got video back, real odd
<alex_mayorga> tormod, what can I provide for the bug, or was all user error?
<tormod> try to make sure it was only the read-edid (remove the ModeDebug). Then attach two logs (working, with read-edid and failing, without) both with ModeDebug set. Attach both to the upstream bug.
<tormod> AFAIK, read-edid is not supposed to be needed.
<alex_mayorga> I'd try to do that
#ubuntu-x 2009-12-07
<johanbr> still the same hard lockup
<johanbr> no visible difference with nouveau.modeset=1
<Sarvatt> yeah its not working here either http://sarvatt.com/downloads/gallium.txt
<Sarvatt> gdm stuck on a garbled screen
<Sarvatt> i'm trying with noagp=1 now too
<Sarvatt> oh wait a sec, old xorg.conf... sheesh
<RAOF> Sarvatt: Yeah, I broke xserver-xorg-video-nouveau in xorg-edgers; I was updating the archive package, and forgot that the PPA nouveau-kernel-source had dropped the linux-nouveau-modules Provides:
<Sarvatt> Xorg.0.log looks fine but i'm stuck on a blinking cursor screen
<Sarvatt> no errors in dmesg either
<Sarvatt> http://sarvatt.com/downloads/nouveau.txt
<johanbr> can you do anything at that point?
<johanbr> switch tty etc?
<RAOF> Does the console work?
<Sarvatt> no go on vt's or anything, sysrq keys work
<Sarvatt> networks up, i can ssh in fine
<RAOF> Try rebooting, disabling boot splash?  I seem to recall running into strangeness where nouveau fights with usplash before.
<Sarvatt> you know i had that problem too before on that livecd i made, didnt used to have usplash installed even back then
<Sarvatt> that worked, removed quiet splash and now i'm in gnome
<johanbr> it worked for me just a week ago, with the X server from karmic
<johanbr> I upgraded the X server bits to get working xv, but everything stopped working instead
<Sarvatt> galliums alot better now on nouveau too, nice
<RAOF> johanbr: You could probably have got working xv by running the metacity compositor, too :)
<johanbr> I know :)
<johanbr> Sarvatt, you're saying the hang disappeared when you removed "quiet splash" ?
<Sarvatt> yeah
<Sarvatt> usplash definitely doesnt cooperate with nouveau
<johanbr> weird... I removed splash, but not quiet, and still got the hang
<johanbr> I don't even have usplash installed
<RAOF> Actually, it plays nicely with my nv4b; it's obviously not quite so deterministic.
<Sarvatt> you have nouveau.modeset=1 too? i have it in a /etc/modprobe.d/nouveau.conf too
<Sarvatt> options nouveau modeset=1
<Sarvatt> we have the same exact video card
<johanbr> which kernel are you running?
<RAOF> And which nouveau-kernel-source?  The latest nouveau-kernel-source should (a) enable kms by default, anb (b) add nouveau to the initramfs.
<Sarvatt> yours is a dell and mine is a HP going by the subvendor though :D
<Sarvatt> 2.6.32-6
<Sarvatt> edgers
<johanbr> I've mostly tried 2.6.32-7-generic (64-bit)
<johanbr> and same n-k-s, 0.0.15+git20091204-0~10.04~ppa1
<johanbr> anything special in xorg.conf ?
<Sarvatt> phew darn thing is gonna catch on fire trying to play neverball :D
<Sarvatt> Section "Device"
<Sarvatt>         Identifier "nouveau"
<Sarvatt>         Driver "nouveau"
<Sarvatt> EndSection
<Sarvatt> thats it
<johanbr> that's a bit less than mine - I'll try that
<Sarvatt> http://sarvatt.com/downloads/nouveau.txt
<Sarvatt> thats the working logs
<johanbr> alright, one more try...
<Sarvatt> yeah nouveau gallium is still pretty much unusable, i915 is almost the same speed as classic mesa
<johanbr> whaddayaknow, it works!
<johanbr> I think it had issues with something in my old xorg.conf
<johanbr> and xv works too :)
<Sarvatt> if you want to play with gallium for some 3D ya can just check out mesa git and run ./autogen.sh then ./configure --enable-glx-tls --with-dri-drivers= --enable-gallium-nouveau --disable-gallium-intel --disable-gallium-radeon --disable-gallium-svga --with-state-trackers=glx,dri --with-demos=xdemos,demos,trivial,tests then run any 3D app with something like LD_LIBRARY_PATH="/opt/mesa/lib/" LIBGL_DRIVERS_PATH="/opt/mesa/lib/gallium" glxinfo
<Sarvatt> i just made a bash alias for that called gallium so i run "gallium openarena"
<RAOF> Sarvatt: How does nouveau gallium fare with, say, gnome-shell?  It's kinda-sorta-almost working on my nv4x.
<Sarvatt> hmm cant start gnome shell
<Sarvatt> Typelib filoe for namespace Clutter not found hmm
<RAOF> Heh.
<Sarvatt> can't run it in xephyr either, i think its screwed up in the repos
<Sarvatt> or i need aiglx...
<johanbr> can you run compiz?
<Sarvatt> software rendering detected, falling back even though i ran it with the gallium env variables
<Sarvatt> not trying to install gallium dri system wide to get it working :D
<Sarvatt> seems exactly the same as it was 6 months ago at any rate, same bugs too.. lol
<Sarvatt> maybe the plymouth thats coming in a few days will fix that though
<Sarvatt> opened the lid 30 minutes later and its frozen with a blinking cursor again :D
<johanbr> so the machine was suspended?
<Sarvatt> guess i rebooted it after i shut it and forgot to remove quiet splash from /etc/default/grub
<Sarvatt> ...and i forgot a / in my gallium env variables on that machine and was using swrast, no wonder it was slow
<Sarvatt> thats more like it! OpenGL renderer string: Gallium 0.3 on NV86
<Sarvatt> OpenGL version string: 2.1 Mesa 7.8-devel
<Sarvatt> OpenGL shading language version string: 1.20
<Sarvatt> compiz is working but slow
<johanbr> cool :)
<Sarvatt> openarena is great, over 100 fps at 1280x800
<RAOF> How nicely is xorg-edgers playing on Lucid's intel right now?
<Sarvatt> we really need to package gallium if we're going to use nouveau, this works great
<Sarvatt> intel's got alot of problems on 2.6.32 for me
<RAOF> Sarvatt: Feel free to --enable-gallium-nouveau on your next mesa upload to xorg-edgers :)
<Sarvatt> if only it was that easy! lol
<RAOF> It builds a totally different mesa? :)
<Sarvatt> gonna have to have alternatives for the main libgl i guess
<RAOF> Or just overwrite the existing libgl, and get people to not install it on !nouveau :)
<Sarvatt> heck, I would probably stick to nouveau fulltime if gallium was packaged, this is fast enough
<Sarvatt> glxgears caused a gpu freeze
<Sarvatt> hmm guess i should be compiling in the mesa state tracker too?
<RAOF> Probably a winner.
<RAOF> I just pull in all the trackers.  Gets you bonus xvmc acceleration!
<RAOF> Ok.  I think I've ballsed up xserver-xorg-video-nouveau git sufficiently that I can now re-do the pristine-tar stuff cleanly.
<RAOF> Hm.  Darktama thinks that nouveau.ko should work with an unmodified drm from 2.6.32.  That would make nouveau inclusion substantially simpler!
<RAOF> I think it's time to play "what happens if I drop drivers/gpu/drm/nouveau into lucid's kernel tree"
<johanbr> hmm... X restarts when I resume from suspend
<RAOF> Avec nouveau?
<johanbr> oui
<johanbr> actually, it restarts with the nvidia 195 driver too
<johanbr> so it might not be nouveau-specific
<RAOF> That seems like a safe call, yes.
<johanbr> :)
<johanbr> it did resume just fine in karmic
<RAOF> Maybe it's an xserver 1.7 issue?
<johanbr> could well be
<johanbr> apparently X segfaults on resume: http://pastebin.com/f49fbee3c
<RAOF> And it doesn't seem to be anywhere near nouveau; maybe it's a synaptics issue?
<johanbr> quite possibly
<johanbr> I'll try downgrading the synaptics package
<johanbr> there was also libpthread in there... I just upgraded that
<RAOF> Man, "git add -i" has to be one of the least intuitive interfaces in the whole of the git suite.
<RAOF> ARGH!  "git add -p" -- it's like "bzr shelve" except _totally inscrutable_.
<Sarvatt> you cant really downgrade synaptics, distro stuff wont work in xserver 1.7+
<Sarvatt> wonder if it has anything to do with the new pm-utils 1.30rc that was just uploaded
<Sarvatt> or is that just video quirks..
<johanbr> yes, I noticed
<Sarvatt> whats your /var/log/pm-suspend.log look like?
<johanbr> http://pastebin.com/f238ce745
<johanbr> don't see any problems there
<RAOF> Ok.  Anyone know how to update the kernel configs?
<johanbr> but this in the X log makes me wonder: "[    0.000666] (II) Cannot locate a core pointer device."
<johanbr> RAOF, update kernel configs how?
<RAOF> As in: take the ubuntu kernel, add drivers/gpu/drm/nouveau, and update the build config to enable the build.
<RAOF> Never mind, it seems I've found the kernel team wiki.
<johanbr> depends on whether nouveau drm is built in-tree or out-of-tree
<RAOF> I'm building it in-tree.
<RAOF> The idea is to work out whether or not we can just drop drivers/gpu/drm/nouveau into the current kernel build & expect it to work.
<johanbr> in that case, I guess the nouveau drm patch itself should add a kernel Kconfig option
<RAOF> Because _that_ would mean that it'd be actually possible to ship nouveau by default without killing the other drm drivers.
<RAOF> johanbr: It does; I'm trying to find out how the kernel team runs "make silentoldconfig", because it's special.  It occurs to me that perhaps #ubuntu-kernel is going to be more helpful, though :)
<johanbr> :)
<johanbr> can't you just check out the kernel source package, patch with the nouveau patch, enable the nouveau Kconfig option and then build the deb as usual?
<RAOF> No, because the kernel build system copies a stored kernel config on build.
<johanbr> oh
<RAOF> (Because it wants to build a hojilion different configs)
<RAOF> Kernel build timer started: 3:06 pm
<johanbr> are you building all the possible flavours?
<RAOF> No.
<RAOF> Kernel build timer stopped: Error at 3:12 pm :)
<johanbr> oh :(
<johanbr> well, at least it was quick :)
<johanbr> in the nouveau part or somewhere else?
<RAOF> In the nouveau part, where I forgot to copy over the i2c directory :(
<RAOF> New start: 3:13 pm :)
<Sarvatt> how long have you been using edgers on lucid johanbr? just wondering if you had that crash on resume before the switch from hal to udev around december 2nd or so
<johanbr> that sounds about right for when the crash started appearing
<RAOF> Balls.  Things build better when you include the include files.
<johanbr> oh... another restart?
<RAOF> Yup.  3:47pm
<RAOF> :)
<johanbr> :)
<johanbr> updated a few things... off to see if resuming works better now
<johanbr> hmm... no luck... X still restarts on resume
<RAOF> 4:32pm - /home runs out of space :(
<johanbr> just no end of troubles today
<tjaalton> "Your branch is ahead of 'origin/ubuntu' by 3293 commits."
<tjaalton> merging mesa is fun
<jcristau> moving to 7.7?
<tjaalton> nah, merging with unstable
<jcristau> heh
<tjaalton> but git was neglected for a number of months
<jcristau> ok
<tjaalton> it was actually quite easy, the diff is quite manageable
<tjaalton> ok, maybe it's time to push all this crap to lucid ;)
<RAOF> Cool.  nouveau actually builds against (very nearly) stock lucid drm.  Lets see how well it works.
<tjaalton> RAOF: we need a new patch for libdrm 2.4.15
<tjaalton> or .16
<jcristau> tjaalton: lolz. even the diffstat is above the limit for commit mails.
<RAOF> tjaalton: Yeah, that's right.  I was thinking of the kernel component; I was assuming libdrm 2.4.16 would be ambling into lucid sometime in the not-too-distant future.
<tjaalton> jcristau: heh, so it seems
<tjaalton> RAOF: it should yes
<tjaalton> jcristau: there's a request to include the synaptics headers (bug 340340), fedora does it too. what should it be called, x-x-i-synaptics-dev?
<ubottu> Launchpad bug 340340 in xserver-xorg-input-synaptics "Provide header files and .pc file " [Wishlist,Incomplete] https://launchpad.net/bugs/340340
<jcristau> yeah probably
<jcristau> are you uploading the new server today?
<tjaalton> yes
<tjaalton> though the build seems to have failed..
<tjaalton> had to try it first
<tjaalton> seems like patch 177 broke it
<tjaalton> struct _DeviceIntRec has no member named 'isMaster'
<tjaalton> well, should be fixed anyway
<tormod> tjaalton, re mesa merge, do you remember I retro-pushed ubuntu releases to git (see ML)?
<tjaalton> tormod: when was that?
<tjaalton> ah, found it
<tormod> so I guess that was wasted time
<tjaalton> I was abroad when you sent that, sorry :)
<tjaalton> but it's nice that all the changes are there as separate commits.. maybe it could be force-pushed
<tjaalton> I'll check the script
<tjaalton> you should apply for pkg-xorg :)
<tjaalton> maybe the script could be used with synaptics..
<tormod> well I think Bryce reviewed it half way but did not push it
<tjaalton> though most of the changes between the previous git push and now were just added patches from upstream. the diff is almost identical
<tjaalton> pushing your repo would also add the tags?
<tormod> yes, I made tags also
<tjaalton> we haven't tagged the releases from ubuntu branches, to avoid cluttering up the list. don't know if it matters much, but
<tormod> isn't that useful, to easily git-diff between versions?
<tjaalton> normally I just diff the head of ubuntu
<tjaalton> but yes, it's useful to have the debian releases tagged ;)
<tormod> I understand, the tag list is global, so we can not "hide" ubuntu tags, they will uglify the gitweb list
<tjaalton> and tab-completion with zsh ;)
<tormod> with bash also I think
<tjaalton> tseliot: what's the status with synaptics? not maintained in git anymore it seems, but are you going to merge it or should I? (for xserver 1.7)
<tseliot> tjaalton: in the debian git, do you mean?
<tjaalton> yes
<tseliot> aah
<tseliot> tjaalton: feel free to merge it. I have a lot of things to deal with right now
<tjaalton> ok
<tseliot> and thanks
<tseliot> :-)
<tjaalton> np
<tjaalton> xserver build failed again, now due to patch 135
<jcristau> that patch seems to make the server do some things from the signal handler which i'm not sure are safe
<tjaalton> error: 'signo' undeclared
<tjaalton> well, apport isn't run anyway yet, so I'll just disable it for now
<tjaalton> yes, built without it
<tseliot> tjaalton: let me know if my patches for synaptics fail to apply and I'll adapt them for you
<tjaalton> tseliot: ok, thanks. fixing the server one more time..
<tseliot> :-)
<tjaalton> sigh.. what to do with -ati..
<tjaalton> the version is bigger than in debian, so can't be synced. maybe just a rebuild then
<tjaalton> don't feel like pulling in a random snapshot
<tseliot> a rebuild should be enough then
<tjaalton> there, pitti synced these http://pastebin.ubuntu.com/336548/
<tjaalton> apart from the xcb stuff which is in quilt3.0 format and soyuz can't handle it yet
<jcristau> nothing needs it yet so that should be fine
<tjaalton> yep, figured as much
<jcristau> new intel will, but...
<tjaalton> openchrome failed to build
<tjaalton> http://launchpadlibrarian.net/36533009/buildlog_ubuntu-lucid-i386.xserver-xorg-video-openchrome_1%3A0.2.904%2Bsvn812-1_FAILEDTOBUILD.txt.gz
<tjaalton> against the old server, but anyway
<jcristau> old xserver + new proto
<jcristau> that's expected to break
<tjaalton> ah, ok
<tjaalton> it should be the only driver without the bumped build-dep
<tjaalton> looks like fedora has had fixes for ABI_INPUT_VERSION 7 for the drivers that haven't seen releases for 7.5
<tjaalton> wonder why they haven't been pushed upstream
<tjaalton> oops
<tjaalton> correction, they are upstream but no release has been made
<jcristau> oh, i guess i forgot those had been pushed
<jcristau> maybe you can do the releases then :)
<tjaalton> heh, maybe later :)
<tjaalton> tseliot: the jumpy cursors patches don't work, since there will be no fdi file anymore
<tjaalton> and I don't know how it works in the udev world. But I guess it can be disabled for now
<tseliot> tjaalton: but the udev rule that pitti wrote makes use of it and it works
 * jcristau would like to not put any options in the udev rules
<tjaalton> tseliot: oh right, they are there
 * tseliot would like to live in a world in which quirks are not required...
<tjaalton> it's just a matter of where they should live..
<jcristau> tseliot: if quirks are required, they should not live in udev rules.
<tseliot> give me another sensible place for the quirks and I'll change my patch ;)
<jcristau> your kernel
<jcristau> or the X driver, maybe
<tseliot> jcristau: I discussed this with whot but he doesn't seem to want it in the X driver and I'm not really sure about how I could translate my patch into a kernel patch (because of what it does)
<jcristau> what it does is detect what machine it's running on and set different default values for some options?
<tjaalton> tseliot: the first part of the jumpy patch fails to apply
<tseliot> tjaalton: can you upload the synaptics source somewhere, please?
<tjaalton> I'll push it to git, clone from there
<tseliot> tjaalton: can you give me the link to the branch, please?
<tjaalton> git clone git://git.debian.org/pkg-xorg/driver/xserver-xorg-input-synaptics.git
<tjaalton> git checkout -b ubuntu origin/ubuntu
<tjaalton> guess I have to drop wacom from input-all until it works
<tseliot> tjaalton: ok, thanks I'll update the patch ASAP
<Sarvatt> we need a 190.xx or newer nvidia blob to work with xserver 1.7 too
<tjaalton> tseliot: thanks
<tseliot> Sarvatt: right. It's on my TODO list
<tseliot> tjaalton:  np
<Sarvatt> openchrome should build against xserver 1.7, i pushed a patch for it upstream like 6 months ago
<Sarvatt> oh sorry misread, old server new libs
<tjaalton> yep
<tjaalton> xserver failed to build on sparc, powerpc:
<tjaalton> /xi2/eventconvert/XIDeviceChangedEvent: **
<tjaalton> ERROR:../../../test/xi2/protocol-eventconvert.c:714:test_values_XIDeviceChangedEvent: assertion failed: (k->length == bytes_to_int32(sizeof(xXIKeyInfo)) + k->num_keycodes)
<tjaalton> /bin/bash: line 5: 13949 Aborted                 ${dir}$tst
<tjaalton> FAIL: protocol-eventconvert
<jcristau> fun.
<jcristau> endianness bug?
<tjaalton> probably something like that..
<tjaalton> shouldn't matter though
<tjaalton> at least not for a1
<tjaalton> mesa built fine.. I'll upload it and take a break
<Sarvatt> where can you see the buildlogs for debian experimental powerpc xserver?
<jcristau> you can't
<jcristau> experimental autobuilding is fucked up atm
<jcristau> http://lists.debian.org/debian-wb-team/2009/12/msg00002.html
<Sarvatt> ahh darn
<jcristau> looks like the sparc x tinderbox machine is b0rked as well.  yay.
<Sarvatt> doesnt look like they're even building xserver on powerpc either
<Sarvatt> oh sheesh i'm blind this morning
<jcristau> yeah both are failing on libs earlier
<ScislaC> I recall seeing discussion about HAL going away for 10.04, is that still planned?
<jcristau> see https://lists.ubuntu.com/archives/lucid-changes/2009-December/001427.html
<jcristau> and friends
<ScislaC> jcristau: Thanks! Is it known yet if the udev stuff is playing nicely with drawing tablets?
<tjaalton> ScislaC: 0.10.2 should work, but it's not packaged yet
<tjaalton> so wacom on alpha1 doesn't work at all
<ScislaC> tjaalton: excellent, I will hold off for now then
<tjaalton> duh, somehow missed -ark, -apm, -neomagic when requested pitti to sync the drivers
<tjaalton> ok, video drivers should be good now (apart from blobs)
<jcristau> and sparc :)
<tjaalton> obviously :)
<tjaalton> I guess only i386 and amd64 matter at this point
<tjaalton> and armel
<johanbr> is 2:1.7.99.2~git20091207.fd867387-0ubuntu0sarvatt a real, existing version of xserver-common?
<johanbr> xserver-common depends on that package
<johanbr> sorry, I mean xserver-xephyr depends on that package
<tjaalton> if you run xorg-edgers, yes
<tjaalton> or should be anyway
<johanbr> xorg-server - 2:1.7.99.2~git20091207.fd867387-0ubuntu0sarvatt exists as a source package
<johanbr> but didn't produce an xserver-common package at all
<johanbr> oh, maybe that's because the 386 build isn't finished yet
<RAOF> Sweet.  With a simple patch to export a couple more ttm symbols, nouveau build & runs against lucid's kernel drm.
<johanbr> cool
<johanbr> you cleaned out your /home ? :)
<RAOF> Indeed.
<RAOF> Why are all the git defaults exactly backwards? :(
<tormod> RAOF, I will keep on updating the -nouveau in xorg-edgers. was there something special about your upload?
<tormod> apart the broken parts :p
<RAOF> tormod: It was basiacally testing for an upload to Lucid; feel free to keep updating it in edgers.
<tormod> RAOF, okdok
<RAOF> That's also why it was broken; it was based on Karmic's package, which the PPA packages have diverged from :)
<johanbr> hmmm... just did a complete dist-upgrade to Lucid, and X still segfaults on resume: http://pastebin.com/f48826e90
<johanbr> apparently, it's probably this (just fixed) bug: https://bugs.freedesktop.org/show_bug.cgi?id=25339
<ubottu> Freedesktop bug 25339 in Server/general "segfault unplugging HAL input device" [Normal,Resolved: fixed]
#ubuntu-x 2009-12-08
<Sarvatt> johanbr: i'll add that patch and upload now, it'll probably take forever to get pushed to master
<Sarvatt> then again it'll probably take 24 hours to build on launchpad too :D
<johanbr> great, thank you
<johanbr> I just finished building the package myself
<johanbr> off to test if it works now :)
<johanbr> Sarvatt, yep, the patch works fine... no more segfault
<Sarvatt> glad to hear it, added it as a hook for auto-xorg-git too for the time being, its nice not having to manually edit anything before upload every new commit :D
<Sarvatt> oops evdev 2.3.1 overrided git master, guess we're gonna have to fake the version number for master :D
<tjaalton> upgraded, but the mouse and keyboard didn't work if I just logged out
<tjaalton> and got failsafe after reboot
<tjaalton> huh..
<mac_v> if i add <  radeon.modeset=0  > to the kernel line , it would turn off KMS?
<tjaalton> yes
<mac_v> thanks :)
<tjaalton> jcristau: so, we discussed with pitti about the udev rules and triggers. the drivers should really run udevadm, since for instance here xserver-xorg was configured before evdev, resulting in no kbd&mouse after a logout (sure, it yelled to reboot, but..)
<jcristau> ok
<jcristau> feel free to change that in git
<jcristau> and add Depends: udev [linux-any] i guess
<tjaalton> sure
<tjaalton> our 64-xorg-xkb.rules didn't work at all, fixed :)
<tjaalton> gconf settings overrode the defaults though, so I didn't notice it
<jcristau> heh
<jcristau> tjaalton: are you also adding xserver-xorg-input-{synaptics,evdev}-dev?
<tjaalton> jcristau: for the headers?
<jcristau> .h and .pc, yes
<tjaalton> maybe I could
<tjaalton> is there a postinst.in template I should use? looking at the xserver-xorg-core one..
<jcristau> yeah stealing that seems fine
<tjaalton> jcristau: ok, pushed evdev postinst with the trigger
<jcristau> looks good
<jcristau> i guess the server and synaptics need the same thing
<tjaalton> yeÃ¥
<tjaalton> uh
<tjaalton> *yep
<jcristau> :)
<tjaalton> I need lunch.. the fingers are getting stiff :)
<tjaalton> jcristau: and there goes evdev-dev
<tjaalton> now lunch ->
<jcristau> tjaalton: thanks!  i pushed a small fixup on top.  enjoy lunch :)
<tjaalton> jcristau: oh yeah, copied the deps from some lib :)
<jcristau> i figured ;)
<mac_v> why is KMS turned off by default in .32-7 ?
<tjaalton> because userspace is not ready
<tjaalton> jcristau: wondering about the version comparison in xorg/evdev/synaptics. shouldn't the trigger run every time postinst is run?
<jcristau> only when the rules changed i think
<tjaalton> oh, good point
<Sarvatt> oh good, the chrome beta build for linux is from right before all the rendering errors started happening in chromium. i thought they were intel related until i saw they happened on nvidia as well
<Sarvatt> well it started around 4.0.260 in chromium and the chrome beta is based off of 11 days before that
<notlistening> Hi, I am using the bleeding edge x release from PPA, i have two atom 330 machines both with ion graphics, one with the updated x-server and the other without and i am playing back a HD movie and getting about 90% CPU usage on the one with the PPA and 150% on the one without. Is this the updated version making a difference or do I have to look elsewhere? This is on Ubuntu 9.10 with the latest Beta Nvidia Drivers 
<notlistening> oh and using lucid 
<tormod> notlistening, you mean xorg-edgers PPA?
<notlistening> yeah sorry i was not being exact with names there
<tormod> lucid main has xserver 1.7, lucid xorg-edgers has xserver 1.8-pre-alpha, but I didn't know the nvidia blobs work with either
<notlistening> Just trying to track down the performace differences
<notlistening> oh I was just trying my luck :D
<tormod> check the logs to see if there is any big difference there
<notlistening> they wirjs fine so far as i can tell but i am not testing them beyong a media centres usage
<notlistening> oh ok, I do remember enabling DRI2 as well i think
<notlistening> should i report my findings?
<tormod> only if you can single out some clear change, so far you findings are "anecdotal" to me :)
<tormod> for instance, change between 1.7 and 1.8 on the same machine
<notlistening> Ok i will try that now as i have the setups, are the test to run like glxgears and look for performance differences etc?
<tormod> glxgears is famous for not being a good benchmark
<tormod> playing the same movie and measure CPU is a bit better
<tormod> is this a very new nvidia blob?
<notlistening> tormod, what is a blob?
<RAOF> Binary blob - proprietary, closed-source driver.
<Sarvatt> the binary driver thats not open source, just a big binary blob packaged up :D
<notlistening> thanks sorry quite new here 
<Sarvatt> you want to find vdpau enabled versions of the movie playback software and switch the renderer to vdpau on an ion platform though
<Sarvatt> the stuff in ubuntu doesn't have it enabled last i checked?
<notlistening> the driver was released on 24/11
<Sarvatt> that'll let you use the hardware acceleration on the gpu to play things back, but theres restrictions on the formats that it can accelerate so not everything can be accelerated that way even
<notlistening> I have added ppa for vdpau playback also
<notlistening> and have been trying the new flash 10.1 beta too :D
<Sarvatt> last i checked there were some packaging errors for the 190 and 195 nvidia blobs in that ppa that didnt uninstall cleanly though :(
<Sarvatt> so are you using mplayer to play back movies, and did you pick vdpau as the renderer in preferences?
<notlistening> the file i am trying is an avi file which is using Microsoft mp4 4.2 
<notlistening> I am using the built in movie player from XBMC running throught Boxee
<notlistening> and have picked Vdpau, i have almost the same machine but have enabled the ppa on one and not the other and was trying to track down the performace enhancement
<notlistening> I think i will tkae one step at a time and re do the install and see if i can pin point whats working and whats not
<notlistening> and i am using the blob directly from nvidia installed manually in run lvl 1
<notlistening> Will report back in a bit
<Sarvatt> mp4 and avi are both container types not video formats though and using h264 in avi has some *horrible* limitations.. i wouldnt be surprised if it couldnt even accelerate the sample you're using
<notlistening> Well something is giving me 50% less cpu usage so i will try to find out what
<notlistening> on the edgers website it says the the current version in lucid is not usable in karmic?
<tormod> notlistening, yes you should not install lucid packages in karmic, that means
<Sarvatt> think we should enable glsl for r600 in mesa tormod?
<tormod> Sarvatt, I did it once on request, didn't seem to break anything :)
<tormod> it's not in git master for some reason though
<Sarvatt> odd r600_context.h - Copyright (C) The Weather Channel, Inc.  2002.  All Rights Reserved.
<tormod> all the initial ati 3d work was done for a weather forecast system...
<tormod> but that was on r200 or r100, not r600 :)
<Sarvatt> yeah it says radeon 8500 after it
<Sarvatt> ohhh was that what the 0ubuntu0glsl was a few weeks ago?
<tormod> Sarvatt, the glsl is a bit depending on what upstream wants in bug reports, whether they keep saying "please try with glsl" or "oh noes you have enabled glsl"
<Sarvatt> i thought someone else on the team actually uploaded something
<tormod> it was the "glsl special edition" for phoronix junkies
<Sarvatt> surprised they didnt just make that a driconf option
<tormod> yes that, or a ENV thing would have been so much nicer
<Sarvatt> i've got fake a glsl support option in there on i915
<tormod> Sarvatt, since it's a radeon only thing, I can push glsl builds in the radeon ppa
<tormod> Sarvatt, once lucid has libdrm 2.4.16, I'll add glsl for radeon to my nightly script
<maxb> So... now X is de-HAL-ized, how does one pass config options to input drivers now/
<maxb> * ?
<Sarvatt> which input driver?
<maxb> synaptics
<Sarvatt> synclient? xinput?
<maxb> I can't survive without my circular scrolling, now I'm used to it
<maxb> Aren't those both for run-time tweaks? How do I persist the settings?
<Sarvatt> udev rule?
<Sarvatt> gpointing-device-settings doesnt have an option for circular scrolling?
<Sarvatt> i thought it did for some reason
<Sarvatt> yeah gpointing-device-settings lets ya do it
<Sarvatt> in system - preferences - pointing device - scrolling
<maxb> Hmm... I don't have it installed. I'll try it once my current apt run finishes
<maxb> thanks
<Sarvatt> can probably just add ENV{x11_options.CircularScrolling}="1" to the synaptics udev rule though
<Sarvatt> i think it's going to take input options like that in /etc/X11/xorg.conf.d/ here soon?
<Sarvatt> well probably not on xserver 1.7
<jcristau> the x11_options in udev might not stay long..
<jcristau> i'm kinda tempted to remove that
<maxb> Any idea what the replacement will be?
<jcristau> xorg.conf
<Sarvatt> about Bug #438398.. that guy has a custom gcc symlink pointing to ccache, I have the same problem with my ccache symlinks not working right with DKMS too
<ubottu> Launchpad bug 438398 in nvidia-graphics-drivers-180 "DKMS build fails, but package upgrade still successful" [Undecided,New] https://launchpad.net/bugs/438398
<Sarvatt> it runs as user nobody and tries to set up a new ccache folder for that user and fails completely yet dkms thinks it worked
#ubuntu-x 2009-12-09
<fagan> hey im trying to test out the nouveu driver and xorg is saying its not configured properly, I ran Xorg -configure but it looks like its not doing anything
<fagan> Im on lucid by the way
<fagan> I think it may have something to do with residual config from the nvidia driver 
<fagan> Anyone have any ideas?
<RAOF> fagan: How are you trying nouveau?
<RAOF> Because the version in the archives currently isn't expected to work, pending some kernel-team decision about how to get nouveau.ko in our kernel build.
<fagan> RAOF: Im using it from the nouveau ppa
<fagan> The one from the archive works though
<fagan> on my machine 
<RAOF> Really?  It doesn't build against 2.6.32 kernels, though.
<fagan> hmmmm I just installed it rebooted and it worked 
<fagan> dont ask me how 
<fagan> its definitly not the nv driver
<fagan> That sucked on my hardware
<RAOF> Its possible that you've got nouveau-kernel-source from the nouveau ppa and the DDX from lucid, I guess.
<fagan> I did install the -source package so thats it :)
<fagan> RAOF: so any ideas why im running safe graphics mode?
<fagan> It hung when I did a -configire
<RAOF> No idea, no.
<fagan> -configure 
<fagan> hmmm
<fagan> any other things I can try?
<RAOF> What's in your xorg.conf?
<fagan> the nvidia config 
<fagan> which caused the problem I think
<RAOF> Well, yes.  Can you pastebin your xorg.conf?
<fagan> damn I just rm'd it 
<fagan> sorry 
<RAOF> That's OK.
<RAOF> All it wants is "Section "driver" Identifier "nouveau" Driver "nouveau" EndSection" in it.
<fagan> oh ok then ill give it a go
<fagan> be back in 5
<notlistening> A bit later and there is no difference in the cpu usage on that machine with all the extras that i installed so there must be something different between the hardware more than just CPU and GPU
<fagan> that didnt work anyway
<fagan> so im going to go back to the nvidia driver 
<fagan> the conflict is http://pastebin.ubuntu.com/337674/
<fagan> The xorg update conflicts with nvidia's driver 
<RAOF> Yes it does.
<fagan> so what do I do?
<RAOF> Not use the nvidia driver in Lucid.
<fagan> That isnt a solution because my computer looks very crap without it
<RAOF> Beacuse it won't work.  IIUC, we need a newer nvidia driver, one that will actually work against xserver 1.7
<RAOF> fagan: Not use Lucid?  The proprietary drivers are frequently, and often long-term broken in development.
<fagan> I tried the 190 driver with no luck
<fagan> hmmmmm
 * fagan thinks maybe rolling back to an older version of xorg will help him
<RAOF> Yes, it might.  If you can :)
<fagan> Or maybe a newer one
<RAOF> Well, that won't work, because the nvidia driver won't work against it.
<fagan> Ah ill see what I can do 
<fagan> Dont ask me how but the ppa for the xorg team worked
<fagan> no conflict no nothing https://launchpad.net/~xorg-edgers/+archive/ppa
<Sarvatt> 185.18.36 worked for you with that?
<fagan> 190
<Sarvatt> oh ok
<fagan> Awesomeness 
<Sarvatt> i couldnt find a 190 in a ppa that wasnt really borked when i looked at the stuff in debian/ and one screwed up being able to downgrade back, ended up just manually installing it from nvidia for now
<fagan> Nope spoke too soon got killed at the end of installation
<fagan> damn it
<Sarvatt> i had a ton of dangling alternatives from the bad packages
<fagan> im just going to get the one from nvidia themselves
<Sarvatt> 195.22 manually installed is working great with edgers here
<fagan> got to exit the session to install it brb
<fagan> that worked well
<fagan> x and nvidia now play nice
<fagan> why are the packages so bad then?
<fagan> If the nvidia driver works why dont we just package that up that?
<Sarvatt> tseliot is working on it
<fagan> thank god
<notlistening> Can i come back to my original question, aobut the amount of CPU i am using for a video, can the frame buffer in the bios make a big difference or the amount of RAM a system has to use?
<Sarvatt> nvidia gpu acceleration requires either 128 or 256mb last i checked
<Sarvatt> cant remember which, i think its 256
<fagan> mine has 512
<Sarvatt> if you are using xbmc, i know i saw a good guide on using gpu acceleration on an ion board in ubuntu on their forums
<Sarvatt> http://blog.xbmc.org/forum/tags.php?tag=ion
<notlistening> the bios limits me to 256 at the moment as i only have a 1 gb a the moment
<notlistening> Thanks Sarvatt 
<Sarvatt> gotta be a vdpau thread out there somewhere that'll explain how to make it work, you would know if its working because you'd be getting closer to 10% cpu usage than the 80%
<Sarvatt> ewwww http://lists.x.org/archives/xorg-devel/2009-December/004029.html
<LLStarks> whois keybuk
<LLStarks> damn
<RAOF> Hm.  X seems unusually slow, and seems to be spending a lot of time in i915_gem_throttle_ioctl.  Is this something others are seeing?
<LLStarks> how would i know?
<LLStarks> jeez, that sounded rude.
<RAOF> You'd know if X was being extremely laggy for you, you had an intel card, and ran gnome-system-monitor and saw X waiting for i915_gem_throttle_ioctl :)
<tjaalton> feels quite normal here
<RAOF> Oh, wow.  ubuntu-desktop's new libgtk kills emacs!
<tjaalton> heh, funny.. we ship a cirrus driver with patches to support qemu, and then in xserver a patch that uses vesa for the hw id
<tjaalton> nevermind, it depends on what type kvm is using
<tjaalton> "std" want's mesa
<tjaalton> urgh, vesa
<tjaalton> s/'//
<tjaalton> that should be upstreamed
<tjaalton> mvo: does update-manager always run dist-upgrade, ie. remove packages when there are conflicts during the devel release?
<mvo> tjaalton: sort of, by default it does not do this, but it will prompt for "partial upgrade" mode if it has to remove stuff and tries to be clever
<tjaalton> mvo: ok, thanks
<mvo> why? anything that it should do to make transitions better or something?
<tjaalton> nah, there was just one user who claims that lucid->lucid upgrade broke everything without prompting
<tjaalton> and I don't believe him :)
<tjaalton> the result was that it removed all the drivers
<tjaalton> so the system didn't get X
<mvo> not without prompting :)
<mvo> if he used update-manager we should have logs too
<tseliot> tjaalton: what's the status of input drivers in lucid? An AMD engineer reported that xserver-xorg-core is not installable. Was it just because of synaptics?
<tjaalton> yes, but I won't bother.. told him to install video-all
<tjaalton> tseliot: no, check the mirror
<tjaalton> at least the images build
<tjaalton> tseliot: also, the current synaptics doesn't have your patch in it, had to upload it to make it installable
<tjaalton> but I'll add it now
<tseliot> ok, thanks
 * tseliot forgot about having a lucid chroot already
<tseliot> xserver-xorg-core was installed correctly here
<tjaalton> if he's using fglrx, it'll get removed
<tjaalton> only the OSS drivers work
<tseliot> ok
<hyperair> does anyone here using the nvidia-96 driver have issues with screen flickering?
<tseliot> federico1: hey, do you have a few minutes to discuss new features (one of which is more of a fix) for g-s-d and g-d?
<tseliot> otherwise I can file 2 bug reports and we'll discuss there
<federico1> tseliot: sure, what's up?
<tseliot> federico1: the 1st feature is support for transformations
<federico1> tseliot: BTW, I'm going to start integrating some of the Moblin patches for RANDR stuff
<tseliot> mainly scaling
<federico1> ah!
<federico1> there *is* a patch for that :)
<tseliot> federico1: really?
<tseliot> I'm working on Moblin too
<federico1> I just haven't looked at it closely
<tseliot> federico1: can you give me the link, please?
<tseliot> federico1: I can't find it in the Moblin 2.1 sources
<tseliot> federico1: anyway the 2nd feature is, put simply, that we check GL_MAX_TEXTURE_SIZE in addition to the max framebuffer size
<tseliot> i.e. that we check the 3D limitations in addition to the 2D limitations
<tseliot> for example on i945 chips you can have 2D up to 4096x4096 and 3D up to 2048x2048
<tseliot> and if you go beyond the 3D limit when using a compositing manager you get a black screen
<tseliot> therefore we should not validate modes that go beyond that when using, say, mutter (in Moblin)
<federico1> tseliot: makes sense
<federico1> tseliot: so, I don't know much about GL.  Is the texture size limit just for textures, or does it involve the whole screen?  I.e. could a smarter compositing manager simply create two textures for too-wide windows (or something like that?)
<tseliot> federico1: it's the area in which you get 3d acceleration
<tseliot> I have a bug report about it
<tseliot> https://bugs.freedesktop.org/show_bug.cgi?id=23718
<ubottu> Freedesktop bug 23718 in Driver/intel "[945GME] attaching external monitor causes black screen, with Compiz Fusion in Karmic" [Critical,New]
<tseliot> I've written a patch to access max texture size but I haven't tested it yet. I'll file a bug report and attach it there soon
 * tseliot -> dinner
<Amaranth> so, my mouse keeps jumping to the center of the screen now... :/
<Amaranth> federico1: btw, while a compositing manager could split the screen into smaller chunks to work around the texture size limit the only way to do so is to not use GLX_EXT_texture_from_pixmap at all
<Amaranth> the other way of doing OpenGL compositing is...slow
#ubuntu-x 2009-12-10
<Sarvatt> do chroot problems on launchpad automatically give back builds? no retry button and everything tormod uploaded an hour ago failed on amd64
<Sarvatt> looks like nouveau isn't working on 2.6.32-7 because a modalias for vga16fb was added to match all gpus just after gpu modules get checked, but nouveau builds later and is at the end of the list
<Sarvatt> in /lib/modules/2.6.32-7-generic/modules.alias
<Sarvatt> guess I should bring that up in #ubuntu-kernel instead :D
<Sarvatt> also with the udev stuff in xserver, Amaranth is having his applesmc (accelerometer) getting recognized as a joystick and moving his mouse
<Sarvatt> ack, that vga16fb change in 2.6.32-7 is making ALL kms stop working
<RAOF> Sarvatt: Want to try my 2.6.32-7 kernel that builds nouveau in-tree?  _That_ works :)
<RAOF> Amaranth: Can you now control your mouse by orienting your laptop?  Sweet!
<Amaranth> RAOF: heck yeah
<Sarvatt> RAOF: the bug actually is the vga16fb change making _all_ KMS stop working on 2.6.32-7
<Amaranth> oh, and pommed can control my backlight when using KMS so I guess whatever it does needs to be ported to the kernel to provide backlight support
<Sarvatt> radeon nouveau and intel
<RAOF> Sarvatt: Which is strange, because my 2.6.32-7 kernel appears to work fine?
<Amaranth> and I have to use KMS now since the intel driver doesn't support anything else
<RAOF> Is this a newer kernel than 2.6.32-7.10?
<Sarvatt> yeah it will if your userspace works with UMS
<Sarvatt> xorg-edgers intel doesnt have UMS support anymore :(
<Amaranth> right, which is alright since pommed works for my backlight
<Sarvatt> sudo cat /sys/module/i915/parameters/modeset
<Sarvatt> or radeon or nouveau instead of i915
<Amaranth> Sarvatt: -1
<Sarvatt> yep UMS :(
<Amaranth> err, what?
<Sarvatt> it would be 1 if you were using KMS
<Amaranth> I can assure you I'm using KMS, my terminals look awesome
<Amaranth> and if I boot with i915.modeset=0 I can't even get X
<Amaranth> oh, and VT switching just crashed my fonts :/
<Sarvatt> are you using xorg-edgers or ubuntu?
<Amaranth> xorg-edgers
<Sarvatt> dmesg | grep inteldrmfb
<Sarvatt> says its loaded?
<Amaranth> I can't tell what you said
<Amaranth> [    2.212605] fb0: inteldrmfb frame buffer device
<Amaranth> I can't tell what I said either
<Amaranth> is that good?
<Amaranth> oddly the fonts in chromium still look just fine
<Sarvatt> yep, must be something else about it then
<Sarvatt> i can't use 2.6.32-7, having that fb1 as a vga16fb screws things up
<Sarvatt> oh yeah, that applesmc being a joystick thing is supposed to be a _feature_ :D
<Sarvatt> i guess there was a hal fdi filtering it out or something before?
<Sarvatt> googled it and people wanted to use it as a joystick for neverball
<Amaranth> yeah, must have been a hal thing filtering it
<Amaranth> brb, restarting X
<Amaranth> ah, there we go
<Amaranth> I blindly trusted what you told me to run in a terminal, couldn't read it at all :P
<Sarvatt> inteldrmfb = a KMS framebuffer, it wouldn't say that if you didnt have KMS working
<Amaranth> yeah
<Amaranth> oh, fun fact, X crashes 2 or 3 times every time gdm tries to start
<Amaranth> then it loads but if I type my password incorrectly it crashes a couple more times
 * Amaranth wonders where apport is
<RAOF> Still disabled in Lucid, isn't it?
<Amaranth> yeah, that's going to be bad
<Amaranth> alpha 1 is going to be worthless wrt to people finding crashes
<Amaranth> anyway, bed time for me
<Sarvatt> RAOF: i think its something specific to that guys hardware he's using nouveau on, the vga16fb doesn't interfere with nouveau KMS here, just checked it
<Sarvatt> hyperair: got an magic fixes for a wildly unstable geany? :D
<hyperair> Sarvatt: what's up with geany?
<Sarvatt> crashing when i build 1/10 times or so, getting Gtk:ERROR:/build/buildd/gtk+2.0-2.19.1/gtk/gtkfilesystemmodel.c:295:emit_row_changed_for_node: assertion failed: (id < (model)->files->len)
<Sarvatt> maybe it just needs a rebuild against the new gtk+
<Sarvatt> building the newest svn anyway, hoping that works
<Sarvatt> nope :(
<hyperair> looks like a gtk issue O_o
<hyperair> i haven't noticed anything of this sort
<seb128> hey there
<seb128> does anybody know what code read locale.alias? and why that's done several time?
<seb128> oe
<seb128> ie
<seb128> $ strace -e open xeyes 2>&1 | grep locale.alias
<seb128> open("/usr/share/X11/locale/locale.alias", O_RDONLY) = 4
<seb128> open("/usr/share/X11/locale/locale.alias", O_RDONLY) = 4
<seb128> open("/usr/share/locale/locale.alias", O_RDONLY) = 4
<seb128> ...
<seb128> hum, same question about .ICEauthority
<tjaalton> seb128: the latter is gnome specific AIUI
<tjaalton> locale.alias comes from libx11
<seb128> tjaalton, the .ICEauthority comes from libICE
<tjaalton> seb128: heh, ok
<tjaalton> heh, linus demands redhat to merge nouveau drm in the kernel
<tjaalton> on dri-devel@
<Sarvatt> ohh i gotta check that thread out :D
<Amaranth> heh, less flames from linus then I expected
<Duke`> I often got freezes with recent drm when fast scrolling in firefox, is it a know issue?
<tjaalton> Duke`: how recent? haven't heard of such
<Duke`> well I haven't tracked this bug a lot, but if I remember it started to appear begining december
<Duke`> I have to revert to 2009-11-25's version to get back driver stability
<Duke`> when the problem happens, there's a ton of error messages in dmesg in relation with drm and gem, and the GPU is screwed
<Duke`> I can still switch to another tty to reboot properly
<tjaalton> on lucid?
 * Amaranth should figure out what pommed is doing to change his brightness
<Amaranth> Need to get that to the intel guys so they can make this all work without hacks
<Sarvatt> we might even get nouveau in 2.6.33 at this rate :D
<tjaalton> Sarvatt: yeah, I think Linus has a point..
<Duke`> tjaalton, no on karmic
<Duke`> 64 bits
<tjaalton> Duke`: so a kernel update broke it?
<tjaalton> best to file it against linux
<tjaalton> and mention that it's a regression
<Sarvatt> he's using edgers, intel has been really unstable since the beginning of november, alot of speedup related things really destabalizing things
<Sarvatt> and getting reverted
<tjaalton> ok
<Sarvatt> Duke`: 11-25 works for you? you dont have really bad rendering problems with it? are you on a 965+ maybe?
<Duke`> Sarvatt, no problem with it (945), but just the libdrm2 and libdrm-intel! I have the latest xorg-video-intel
<Sarvatt> do you see alignment errors in dmesg?
<Sarvatt> ah 11-25 is the oldest libdrm you could even possibly use with the intel ddx from git
<Duke`> ah
<Sarvatt> what kernel are you using?
<Duke`> 2.6.32
<Sarvatt> tormod: if you read the ubuntu-x log before you push some updates I updated the xserver hooks to grab the patches from people.ubuntu.com instead of my server, not sure if i'm going to renew the vps this year and it went down for a bit today
<Sarvatt> oh the irony of the patch name in #xorg-devel :D
<Sarvatt> only 91 more places to change 185 to 195 in debian/ for a new nvidia package now, yay
<johanbr> :)
<johanbr> I hope you're using sed
<Sarvatt> if i did i wouldnt see all these other dependency versions that need to be bumped in control
<Sarvatt> Conflicts: nvidia-glx-180 (<< 185.18.32)....
<Sarvatt> 185 is called Source: nvidia-graphics-drivers-180.. so convoluted
<Sarvatt> tempted to just call it nvidia-graphics-drivers-180 (185.18.36+really195.22) for the PPA to make it easy :)
<Sarvatt> oh dang, nvidia-settings never even got bumped in karmic even though the xv values changed and it was screwing it up huh
<johanbr> yikes... when I tried to switch to a tty, nouveau wedged the card hard enough that I had to install the blob to get back to a working state
<superm1> Sarvatt, i thought you just have to change it in one place, and it updates all the others?
<superm1> at least that's how it's supposed to work...
<superm1> I personally think that package needs some major cleanup though.
<RAOF> johanbr: Sweet.  Is that with or without vga16fb loaded?
<johanbr> RAOF, not sure... whatever the default is, probably
<johanbr> I didn't mess with any frame buffer modules myself, anyway
<RAOF> johanbr: If you're using Lucid's current kernel, then it's loading vga16fb, and if that gets loaded first it makes nouveau quite unhappy.
<johanbr> I am using the current Lucid kernel
<Sarvatt> if i'm not misunderstanding how it builds that only works right for the same major version? (like 185.xx to 185.yy)
<johanbr> but I had nouveau working well... this was in X, after having done several suspend/resume cycles
<RAOF> Then vga16fb probably made nouveau quite unhappy, by writing stuff to the card behind its back.
<johanbr> ahh, okay
<Sarvatt> i mean its got stuff to update the dependencies in the .in's but nothing changes the names of the actual packages or anything in all these files that i can see
<johanbr> so vga16fb wouldn't necessarily interfere with X operation?
<RAOF> No; although it appeared to sometimes cause corrupted EXA in X for me.
<johanbr> alright... I'll try blacklisting vga16fb
<RAOF> Some boots it would work fine, some boots all sorts of icons would be replaced by random parts of the framebuffer.
<superm1> Sarvatt, we really should get it to the point that it doesn't need those values hardcoded in so many places
<Sarvatt> someone in #ubuntu+1 last night couldn't even boot unless he disabled vga16fb on his machine.. it works ok on mine but i havent tried to vt switch yet actually
<superm1> i think it's ridiculous to have to update so much for simply a newer version
 * RAOF just deleted the module.
<Sarvatt> its screwing up alot of people using sketchy PPA packages (because its so hard to update) then upgrading their ubuntu version and having it mess up too, seen a ton of bugs where thats happened and people blame ubuntu for it
<superm1> yup, i don't doubt it
<RAOF> I should ask apw whether there's anything more I can usefully do to help get nouveau in lucid's kernel.  Then, make nouveau magically as good a 3d driver as nvidia, then we drop the blob, and have cake!
<Sarvatt> nouveau is going to cause 100x more problems than there already are, I think its crazy to switch to the headache that is nouveau just for people to install the blob personally lol
<Sarvatt> only works with KMS on some generations but not others, doesnt support old nvidia, if it was me I'd rather just use vesa for the initial install until I could install the blob
<Sarvatt> if it actually supported more cards than -nv maybe..
<Sarvatt> or we had gallium packaged :)
<Sarvatt> is the blob packaging in git or bzr anywhere?
 * Sarvatt doesn't understand the point of this debian.binary folder
<RAOF> Sarvatt: My understanding is that it _does_ support more cards than nv?  Doesn't support old nvidia?  You mean pre TNT2?
<Sarvatt> i haven't compared the detection to nv's in 6 months or so but it didnt before, and yeah i mean those old cards and IGP's we have patched into and working -nv
<RAOF> Nouveau doesn't have the same detection code; it doesn't rely on a list of PCIIDs like nv does.  It's entirely possible that nouveau is significantly worse on IGPs, though; I've not had experience there, but they seem more problematic.
<Sarvatt> nv doesn't either in the actual driver, thats a debian packaging thing
<RAOF> Oh, that's just so X will actually load nv?
<Sarvatt> yeah it has a big list of pci ids that debian/ubuntu pull the pci.ids out of but theres a further section that has entire ranges of pci ids that can be used generically based on generation and another section that looks behind an agp/pci-e bridge chip pci id that gets reported to see the actual chips id
<Sarvatt> i have no idea what everythings like now though, been a long time since i looked at it. fedora has a xserver patch with all the special pci id range exceptions they do for nouveau though, would dig it up if it didnt take a year to load their cvs on an atom cpu :D
<Sarvatt> hmm, guess nouveau did have some problems with vga16fb.. [   24.304799] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id and in the xorg log [    1.476598] (WW) NOUVEAU(0): Failed to retrieve fbcon fb: id 0
#ubuntu-x 2009-12-11
<johanbr> does anyone have any idea why my emacs fonts are much smaller with nouveau than with the blob?
<johanbr> does the reported dpi value differ between the drivers?
<RAOF> Probably, yes.  Particularly if you've got multiple monitors.
<RAOF> In which case, last I checked, nouveau (and X in general) will calculate the DPI based on the display size of your primary monitor, but the pixel-count of your full Virtual size.
<Sarvatt> that DanaG guy had the same problem, notification messages were really tiny too
<johanbr> xdpyinfo says "resolution:    121x120 dots per inch" with the blob
<johanbr> I'll check with nouveau later tonight
<Sarvatt> are the screen dimensions right in your Xorg.0.log?
<johanbr> hmm... actually some update seems to have made nouveau stop working altogether
<johanbr> once gdm starts, there's some kind of "soft hang" and the keyboard stops responding
<johanbr> but the power button still shuts down in an orderly fashion and the X log looks like X started normally
<johanbr> X log: http://pastebin.com/f64c1c21b
<Unggnu> hi all
<Unggnu> I have checked Lucid some days ago and radeon kms did work except of some glitches on the start but now it seems to be disabled again
<Unggnu> since the latest Kernel upgrade
<Unggnu> Is it temporary deactivated or is there a change of plan?
<tjaalton> Unggnu: it's not enabled by default yet
<Unggnu> tjaalton, but it was for a short time :)
<Unggnu> 3D doesn't work though with 4870 unlike with the edgers packages.
<tjaalton> could be, but turned off when it was reported that userspace was not ready
<Unggnu> Are the Xorg packages without hal dependency already uploaded?
<tjaalton> included in alpha1
<Unggnu> ok, cool
<Unggnu> I hope that they support Powerplay with the radeon in time for Lucid.
<tjaalton> not yet even in drm-next
<tjaalton> passive cooling ftw ;)
<Sarvatt> i'm confused, they released xorg-server-1.7.3.901 thats identical to 1.7.3?
<tjaalton> looking at the tags and changes between them?-)
<Sarvatt> yeah
<Sarvatt> he merged 1.7 branch into 1.7 nominations then 1.7 nominations into 1.7 branch again and the same things show up?
<tjaalton> probably
<malev> Hi everybody. I'm malev a newbe from the bugsquad. Yesterday someone came with a bug about compiz and totem but we are not sure what to do with it. can anyone help us?
<malev> this is the link:   https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/451974
<ubottu> Ubuntu bug 451974 in fglrx-installer "Black video minimizing Totem window" [Undecided,New]
<johanbr> malev, I think the short answer is "fglrx is buggy with respect to having compositing and xvideo at the same time"
<malev> hi johanbr 
<malev> and what do you mean with: fglrx? :D
<johanbr> the proprietary ati driver
<malev> johanbr, so you think the problem is from ati's drivers? and not compiz?
<johanbr> almost certainly
<malev> oks johanbr 
<johanbr> fglrx is known to have problems with compositing and xvideo
<malev> thanks you
<johanbr> you're welcome
<wimvanleuven> Hello all! Can I ask a question regarding Ubuntu on my laptop?
<wimvanleuven> sorry ... me again.
<wimvanleuven> had restart ... thats my problem
<wimvanleuven> so how about that question?
<wvl> anybody here?
<wvl> quiet in here
<wvl> anybody?
<verbalshadow> is ati modesetting on by default in lucid?
#ubuntu-x 2009-12-12
<maxb> Wasn't it already in karmic?
<verbalshadow> didn't seem to work for me, thought there was a PPA it
<RAOF> Oooh.  An upstreaming branch of nouveau appears.
<tjaalton> RAOF: I think it's upstream already
<tjaalton> at least Linus tested it and it worked
<tjaalton> yes, it is merged
<tjaalton> Sarvatt: what should be done to bugs about edgers packages?
<RAOF> tjaalton: That was fast - the for-airlied branch was only made 17 hours ago :)
<RAOF> So, time to update my lucid kernel branch pulling nouveau from linus instead, I guess.
<verbalshadow_> how do i tell if my lucid system is using KMS?
<cwillu> verbalshadow, does switching vt's work, and does it take less than a tenth of a second?
<tjaalton> only intel does it by default
<tjaalton> there's a new kernel upload but it's probably not built yet
<Duke`> I don't know why but for some weeks (or months?) I have no visible cursor with R200/lucid. I have to run xrandr once (without any change) and the cursor come back.
<tjaalton> damn I hate that system test app which tries to run xrandr on hw that doesn't support it, and then files tons of bugs..
<tjaalton> heh, and tons of related bugs filed against checkbox.. no-one seems to care though
<tormod> tjaalton, bugs in xorg-edgers can be filed in launchpad, but add "xorg-edgers" in the title and subscribe the uploader
<tormod> Duke`, your missing cursor: with kms?
<Duke`> tormod: yes with KMS
<Duke`_> RAAAAHHH SHIETY CONNECTIONÂ§Â§!dfÃ¹!:df
<Duke`_> I had written a long speech during disconnection ;_;
<Duke`_> did you see something of what I said during the last 10 mins?
<Sarvatt> tormod: ugh, looks like we are gonna have to replace linux-libc-dev again since intel git requires headers from 2.6.33?
<Duke`_> http://pastebin.com/m1e7a2212
<Sarvatt> ./include/drm/i915_drm.h:#define I915_PARAM_HAS_OVERLAY           7 (in libdrm)  and http://launchpadlibrarian.net/36710792/buildlog_ubuntu-lucid-amd64.xserver-xorg-video-intel_2:2.9.99.901%2Bgit20091211.8ecf70ea-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz
<tormod> Sarvatt, can't believe they unconditionally require 2.6.33 ? must be a bug
<Sarvatt> they have a patch for 2.6.32...
<Sarvatt> i think its intentional..
<Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=bd81734465912d79d6320a6fb021ce43d258b906
<tormod> they removed the #ifdefs ... way to go
<Sarvatt> the person who wrote that obviously doesn't use a debian based distro
<tormod> "now that 2.4.16 is released..." what about waiting for the kernel to release, grrr
<Sarvatt> i dont even think the overlay patches are in linus' tree yet?
<tormod> "this needs at least kernel v2.6.33 to work", well in a few months time
<Sarvatt> whatever distro he uses must have libdrm headers actually getting installed
<Sarvatt> too bad we're stuck on 2.6.32 :(
<tormod> he's probably using his own kernel with his own headers and expects the world to follow :)
<Sarvatt> pretty safe to say noone using edgers will be using the ancient 2.6.32 4 months from now anyway :D
<Sarvatt> Duke`: I have the same problem
<Sarvatt> lots of hangs with execbuff while wedged spamming dmesg
<Sarvatt> thats on the drm-intel-next kernel though
<Sarvatt> tormod: going to upload a new libdrm replacing linux-libc-dev and not deleting the headers in the rules I guess, unless you can think of something else to do
<Sarvatt> could make a hook to revert that commit every time :D
<tormod> Sarvatt, yes, sounds ok, like we once did. did you try it out locally?
<tormod> but I can't believe they did this. this will be 2.10 for their Q4 package right?
 * albert23 got -intel working that way yesterday
<albert23> I think Eric Anholt explains it here: http://marc.info/?l=dri-devel&m=125770698907397&w=2
<albert23> build against latest headers, then run-time detection if the feature is available
<tormod> albert23, thanks
<Sarvatt> hmm, someone saying a no change rebuild of nvidia 185.18.36 under lucid works, have to try that out
<tjaalton> Sarvatt: by using IGNORE_ABI? doesn't help much
<tjaalton> packaging wise
<Sarvatt> they said it worked like normal after a rebuild to not remove xorg and bump the abi even though the release notes didnt start saying it supported 1.7 until 190, will have to test it when I get home later but I put it on edgers to rebuild just incase
<Sarvatt> it sure was fun uploading the blob on a tethered cell connection :D
<Sarvatt> darn nouveau box _really_ doesn't like being run with the lid closed for days - http://paste.ubuntu.com/340114/
<Sarvatt> dlopen: /usr/lib/xorg/modules/drivers/nvidia_drv.so: undefined symbol: resVgaShared
<Sarvatt> nvidia failed to load
<Sarvatt> Why did we move away from the nvidia-glx, nvidia-glx-new, nvidia-glx-legacy naming scheme to the current nvidia-glx-(major version) one thats a major pain to update as often as nvidia bumps the major version?
<Sarvatt> seems like it would be a good idea to leave a generic version scheme for the trunk then just version all the old legacy ones like they are now
<Sarvatt> the .in's would work right if we did that too, they seem like a remainder from an old naming scheme since it just bumps the dep versions not the actual package names -- Package: nvidia-glx-185 Depends: nvidia-185-kernel-source (>= #VERSION#), nvidia-185-libvdpau (>= #VERSION#), x11-common (>= 1:7.0.0), ${shlibs:Depends}
<Sarvatt> strange.. (185.18.36) Package: nvidia-glx-185-dev Depends: nvidia-glx-185 (>= 185.18.31) Conflicts: nvidia-glx-185 (>= 185.18.32)
<superm1> personally i dont see why we dont just put all the packages into one big package (say nvidia-$MAJOR_VERSION), and then in the .in, just update that $MAJOR_VERSION if it's a bump
<superm1> there's no reason to ever go mix and match some vdpau library here, or kernel source package there
<superm1> and it would certainly help if you want to switch from nvidia->nouveaou and what not
<superm1> same goes for debian, i think the same type of change would be applicable there
<tjaalton> the older versions rarely change, so uploading four blobs every time seems a bit excessive
<tjaalton> I think the latest version should be just n-g-d, without a version
<tormod> Duke`__,  I also lose the cursor sometimes, gets back with console switching or xrandr
<tormod> just verified now it is not related to compiz
<Sarvatt> in this case all the old blobs need updating at the same time for the new xserver abi though :(
<Sarvatt> hmm if we add MAJOR_VERSION like that to debian/upstream_info it wont add the old major version package names to be removed and stuff, will still have to hand edit all those hooks
<Sarvatt> unversioned package name for the trunk is all i can see doing outside of rewriting all this stuff to pack them all together like that, would be alot easier i'd think to not have a major version in the main package name and leave the old versioned like they are?
<Sarvatt> thats just if i was doing it though, i'm not good at this stuff :D
<Sarvatt> or we could just define OLD_MAJORVERSION as well and add like nvidia-$OLD_MAJORVERSION to everything in control and leave the stuff there as well?
<Sarvatt> oh but that wouldnt account for old old major version packages so that wont work
<Sarvatt> dont mind me just thinking out loud
<Sarvatt> all the nvidia legacy drivers have updates for xserver 1.7 so those would be easy to package up right now at least, just editing the versions in debian/upstream_info
<Sarvatt> oh 71.xx hasn't been updated
<Sarvatt> ftp://download.nvidia.com/XFree86/Linux-x86/96.43.14/  ftp://download.nvidia.com/XFree86/Linux-x86/173.14.22/
<tjaalton> IIRC it newer will be
<Sarvatt> its a shame the cards that need 71 dont work in nouveau either I believe
<tjaalton> those are ancient anyway
<Sarvatt> ah just tnt1, 71 is for tnt1 to geforce2
<Sarvatt> hmm libvdpau_trace.so is gone from 195 nvidia drivers
<Sarvatt> ah its another folder down in usr/lib/vdpau/ now
<Sarvatt> libvdpau_nvidia too, ugh
<superm1> Sarvatt, no dont install them
<superm1> there is a NEW library, libvdpau
<superm1> so you only need to install libvdpau_nvidia
<superm1> and depends on libvdpau
<Sarvatt> ohh I see
<superm1> it's in debian main and ubuntu's NEW queue
 * Sarvatt backs out alllll the changes in rules he just did
<AlanBell> evening all, is there anything I can do to add to the information on bug 428769?
<ubottu> Launchpad bug 428769 in xserver-xorg-video-intel "compiz starts with a blank screen on a 2048x1152 monitor" [Undecided,Confirmed] https://launchpad.net/bugs/428769
<AlanBell> I just tried Lucid and it is the same there
<Sarvatt> so there isnt going to be an nvidia-xx-libvdpau-dev anymore then right? looks like the headers in the seperate libvdpau package now.. I need to find the libvdpau package to see if its got vdpau_x11.h too
<Sarvatt> yep both headers in there upstream, so i guess we need a transitional nvidia-185-vdpau-dev to depend on libvdpau-dev?
<tjaalton> why?
<tjaalton> doubt anything build-depends on that
<tjaalton> and if so, those should be fixed
<Sarvatt> dunno, is why i was asking :D
<tjaalton> ok :)
<superm1> mythtv build depended on it
<superm1> but it's already got it as libvdpau-dev | nvidia...blah blah
<Sarvatt> ohh superm1, mind if i copy your libvdpau and nvidia 190 drivers to xorg-edgers? didnt see ya had one in your ppa
<Sarvatt> just so it builds against the newer xorg and doesnt try to remove it installing it
<superm1> Sarvatt, grab the libvdpau from lucid NEW instead of the one in my PPA
<superm1> you can grab the 190 if you want though
<superm1> grab it from ~mythbuntu/trunk-0.22 instead of ~superm1
<superm1> why not just upload to the archive though instead of edgers?
<Sarvatt> i'm just a lowly ubuntu member :D
<tjaalton> tseliot said he was working on it
<Sarvatt> sheesh your package looks great, the others I was looking at still had nvidia-185-whatever in the dpkg hooks and stuff leaving dangling things everywhere
<Sarvatt> *almost* made it a day without intel crashing
<Sarvatt> [76508.606525] (EE) intel(0): Failed to submit batch buffer, expect rendering corruption or even a frozen display: Input/output error. and execbuf while wedged in dmesg again, can't use current git stuff with 2.6.32-7 either for some reason
<Sarvatt> yeah I need to blacklist vga16fb in order to boot with KMS on the ubuntu kernels now
<Sarvatt> failsafe x comes up with a corrupted screen otherwise
<Sarvatt> must be a side effect of the forced vga16fb loading on 2.6.32-7 and up
#ubuntu-x 2009-12-13
<Sarvatt> superm1: hmm your nvidia 190 drivers dont pull in libvdpau for me
<Sarvatt> ah maybe because Depends: nvidia-190-kernel-source (>= 190.42), libvdpau, x11-common (>= 1:7.0.0), ${shlibs:Depends} when the package is libvdpau1
<superm1> Sarvatt, it's possible i didn't add that depends (because mythtv has it inheritently when it build-depends against something with vdpau support)
<Sarvatt> might have been libvdpau in your 0.2 version and changed to libvdpau1 in this 0.3 i'm guessing
<Sarvatt> its libvdpau1 in the 0.2 in all your PPAs too incase you want to change that in the nvidia-glx-190 depends next time you upload to one without mythtv
<Sarvatt> ....not that there is one without mythtv now that i look :D
<Sarvatt> thanks for all of the help, it's working great now
<Sarvatt> hmm, updating the nvidia-glx-190 package to Depend on libvdpau1 didn't pull in libvdpau on the update either
<Sarvatt> debian/control.in was missing the libvdpau depends completely was the problem
<Sarvatt> The following NEW packages will be installed:  libvdpau1 The following packages will be upgraded:  nvidia-190-kernel-source nvidia-glx-190
<Sarvatt> phew thats more like it
<Sarvatt> now i notice no modalias getting installed :D
<superm1> nvidia-common dependencies need  to be adjusted for that 
<Sarvatt> i just made it provide nvidia-185-modaliases for now
<Sarvatt> nvidia-settings 190.42 needed a patch to compile against the x11proto-xf86vidmode-dev headers instead of the libxxf86vm-dev ones, errors trying to build against the lib's after the xorg 7.5 split. http://bugs.gentoo.org/attachment.cgi?id=208926
<Duke`> Sarvatt, is there a fix specific to our problem in this new libdrm? ([drm:i915_gem_execbuffer] *ERROR* Execbuf while wedged)
<Sarvatt> Duke`: nope, pretty sure its a kernel problem. check out the "enable memory self refresh" patch threads on the intel-gfx mailing list. the new libdrm is just overwriting the headers in linux-libc-dev and its the same as the one before it otherwise
<Sarvatt> Duke`: what kernel are you using? I haven't had it happen on the ubuntu 2.6.32 kernel yet
<Sarvatt> of course suspend/resume is broken on this and not on the drm-next kernels, flickering and eventually freezing on a solid color after resume
<hyperair> memory self refresh?
<hyperair> what's that do?
<Duke`_> Sarvatt, i use the 2.6.32
<tjaalton> my intel seems to make X eat the cpu (stock lucid)
<Sarvatt> anything special about it or is it just a stock install?
<Sarvatt> gonna check if mine does too
<Sarvatt> haven't tried the stock environment in a few weeks
<Sarvatt> KMS doesn't work unless I blacklist vga16fb though on 2.6.32-7
<tjaalton> nothing special, 965GM. booting fails ~every second time, evdev crashes for some reason and falls back to vesa (which doesn't work at all due to KMS)
<tjaalton> I'll merge new evdev & xserver tomorrow
<tjaalton> and mesa (includes r600_dri.so)
<Sarvatt> does it happen with compiz disabled too?
<tjaalton> haven't tried
<Sarvatt> sounds like a problem hyperair (i think?) had with 965 back when edgers had mesa 7.6/libdrm 2.4.14 is why i was asking
<tjaalton> I've had this before iirc
<tjaalton> happens after the first resume I guess
<Sarvatt> /proc/dri/0/gem_objects was growing huge and and x was using 100% cpu i think
<tjaalton> size is 0
<Sarvatt> now thats odd..
<Sarvatt> reverting back to stock lucid now but i doubt it'll be the same on my 945
<Sarvatt> hmm The following packages are BROKEN:  xserver-xorg-core
<Sarvatt> oh because i have a newer wacom in edgers and theres no installable wacom in the archive
<Sarvatt> sounds like yer using vesa though if theres nothing in gem_objects?
<Sarvatt> ah joystick is broken in lucid too
<Sarvatt> oops i have some newer bits in a local package archive, no wonder ppa-purge didnt work right
<tjaalton> compiz works, so doubt it's vesa :)
<Sarvatt> do you have a /proc/dri/1 ?
<hyperair> Sarvatt: which issue?
<Sarvatt> X using alot of CPU like 6 months ago
<hyperair> Sarvatt: i had two issues: one was the crazy memory leak that drove me nuts, and the other was the weird re-drawing issue.
<hyperair> X using a lot of CPU...
<hyperair> no i don't think i had that
<hyperair> i just had increased swapping activity
<hyperair> until it took up all my resources
<hyperair> if X got oom killed in the fray, then well and good, otherwise i restart
<Sarvatt> rebooting to stock lucid to see how things are here
<hyperair> or i preemtively log out and kill X before it can kill the rest of my computer
<hyperair> anyway the issue was a kernel thing
<hyperair> if lucid uses .32, it shouldn't see such an issue
<hyperair> no wait, there was a patch involved in mesa i think..
<tjaalton> I won't worry too much about it, yet
<hyperair> no wait, it was definitely the kernel. i remember sarvatt giving me a custom compiled kernel and that solved all my issues
<Sarvatt> thats strange, 4 reboots, X only started twice
<Sarvatt> the other 2 I got failsafe with vesa all garbled
<hyperair> ouch
 * hyperair makes note not to upgrade to lucid until all's clear
<tjaalton> Sarvatt: sounds like my problem. check the gdm log
<Sarvatt> cant find any gdm logs from the failed boots hmm
<Sarvatt> its only got the 2 successful ones then edgers ones, failsafe doesnt have anything in it
<Sarvatt> when it failed x tried to start on vt2, dont know if thats normal for failsafe
<Sarvatt> wonder why it fails like that with the lucid packages and not edgers though
<Sarvatt> do you have plymouth installed tjaalton?
<tjaalton> yep
<Sarvatt> me too
<Sarvatt> theres some video trickery in there, gonna try removing it
<Sarvatt> what the heck, 4 boots again, 2 failures again
<Sarvatt> got an orphaned /etc/init/usplash.conf for some reason
<Sarvatt> 164_trap-aspect-ratios.patch is the only patch we're dropping in edgers vs lucids xserver
 * Sarvatt wonders how this edid caching works in the ubuntu kernel
<Sarvatt> its happening every other boot reliably though for some reason
<Sarvatt> going to try a stock 2.6.32 just to rule out any kind of patches
 * hyperair uses 2.6.32-zen0
<Sarvatt> 10 reboots on a stock 2.6.32 kernel from the mainline thing and no errors, pretty darn safe to say its a ubuntu kernel patch messing it up
<Sarvatt> only thing ubuntu specific that stands sticks out is http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=c5155725948be57010c4a558a1b9c5ddefb864c3
<Ng> hrm, my trackpad isn't showing up in "xinput list" in lucid
<Sarvatt> that commit isnt even in 2.6.32-7 thats having problems so definitely not that then
#ubuntu-x 2010-12-13
<jewsucanuse> hi, what's the quickest way to test glsl rendering?
<jewsucanuse> ?
<ko2> hello, can you help me with that: http://dpaste.com/285764/
<ko2> what could be the error? 1) too old Intel Driver?, 2) Desktop Effects? I have no compiz installed, 3) X-Server-Settings?, 4) ?
<ko2> i wanted to update the intel driver from: https://launchpad.net/~ubuntu-x-swat/+archive/x-updates/
<ko2> But there is no version for hardy. Is there an alternative? I don't want to compile from scratch
<ko2> ?
<tjaalton> upgrade to lucid
<tjaalton> that's an alternative..
<ko2> i cannot, i MUST use hardy
<tjaalton> the compile the package
<tjaalton> +n
<ko2> ok, do you think that could make everything better? e.g. in the program i want tot use: if i select the green color and draw, then the pink color draws. 
<tjaalton> no idea
<tjaalton> note that hardy will be obsoleted next april
<ko2> ok
<bjsnider> i wonder why he MUST use hardy?
<tjaalton> didn't bother to ask
<njpatel> I had a question about intel 4500 :
<njpatel> actually, two
<njpatel> 1. Does the DisplayPort work with ubuntu?
<njpatel> 2. Through the displayport and the vga, could it drive two 1920x1080 monitors without causing a fire?
<njpatel> also, with some form of 3d performance, game level not required
<ko2> hello, i want to update my Intel Graphics driver from https://launchpad.net/~ubuntu-x-swat/+archive/x-updates/ , but there is no Hardy Version. I have Kubuntu Hardy Heron installed
<tjaalton> you asked already
<tjaalton> upgrade
<ko2> yes, but i got no answer, i cannot upgrade
<tjaalton> why not?
<ko2> i have two usb cameras whose driver only work until hardy heron
<ko2> industrial cameras
<tjaalton> which ones?
<ko2> from IDS, uEye UI-1210-C
<tjaalton> sounds weird that they wouldn't work on a newer release. have you verified it?
<ko2> i contacted the support and they said that these cameras use a closed source kernel module for the access to usb
<ko2> i did not verify 100%
<ko2> but i can do, but if the work a bit strange things may happen
<tjaalton> boot a livecd and see yourself?
<ko2> but what if the work and sometime they do strange things i cannot prove at the moment?
<ko2> "what if they work"
<tjaalton> then compile  the driver like I said earlier
<tjaalton> for hardy
<tjaalton> hmm wait
<tjaalton> iirc that driver version wouldn't work on hardy, so you're out of luck
<tjaalton> since it needs kms
<ko2> kms?
<tjaalton> kernel mode setting
<ko2> kernel module support?
<ko2> ok
<ko2> hm
<ko2> nearly everything worked under UBUNTU hardy, why this little problem with KUBUNTU?
<ko2> there are just colors inverted and some little pixels not shown
<ko2> does lucid lynx not allow closed source kernel modules to acces the usb?
<JanC> ko2: closed source kernel modules to access USB sounds pretty illegal to me  ;)
<tjaalton> ko2: you had completely different hw
<ko2> illegal? that is what the support told me, but i'll try
<ko2> but glxinfo | grep render  tells me good things
<ko2> rendering is acitve etc.
<tjaalton> it still depends on which driver/hw you have how buggy it is..
<bjsnider> tjaalton, aren't you glad you chose to enter into that last conversation?
<bjsnider> it was so rewarding
<tjaalton> yeah, a great way to start the week :P
<tseliot> Sarvatt: what do we use as a fallback in Ubuntu? fbdev or vesa?
<tseliot> I think it used to be the latter
<Sarvatt> both, vesa fails to load if a KMS driver is loaded and it uses fbdev
<tseliot> Sarvatt: ok, last time you mentioned a trick to cause the module to fail, something like radeon=sucks ?
<tseliot> on boot, I mean
<Sarvatt> yeah radeon.anythinginvalid=1 works
<tseliot> ok, so there was a dot, I wasn't just my bad memory
<mdeslaur> does our nouveau have 3d support for unity now in natty?
 * mdeslaur asks before switching from nvidia back to nouveau
<Sarvatt> mdeslaur: if you install libgl1-mesa-dri-experimental
<Sarvatt> there's 3D support for older cards (geforce 4 era) in the default package
<mdeslaur> Sarvatt: cool, I'll try that...thanks!
<cnd> bryceh, do you know what the status of xorg-server in maverick-proposed is?
<cnd> I've got a patch I need to get into maverick to fix gesture crashes
<cnd> so what should I be doing right now?
<cnd> should I based a branch off of maverick or maverick-proposed?
<bryceh> cnd, let me check
<albert23> cnd: if you do an SRU for xserver, Raof wants to fix bug 651294 in Maverick. Is it possible to combine the 2 in one SRU?
<ubot4> Launchpad bug 651294 in xorg-server (Ubuntu) (and 1 other project) "X crash on KDM logout (still - yes, really) (affects: 22) (dups: 4) (heat: 118)" [High,Confirmed] https://launchpad.net/bugs/651294
<cnd> albert23, sure
 * ScottK looks up.
<bryceh> xserver-xorg-core:
<bryceh>   Installed: 2:1.9.0-0ubuntu7
<bryceh>   Candidate: 2:1.9.0-0ubuntu7.1
<albert23> cnd: thanks
<bryceh> cnd, so yeah there's something in maverick-proposed, however it appears to not have been committed to git
<cnd> bryceh, I thought we were moving to bzr for packaging, seeing as how bzr seems to integrate with git alright
<cnd> but besides that, what should I do?
<cnd> I've got bug 670016
<ubot4> Launchpad bug 670016 in xserver-xorg-input-evdev (Ubuntu) (and 1 other project) "Xorg crashes when performing gesture (affects: 1) (heat: 8)" [High,In progress] https://launchpad.net/bugs/670016
<cnd> It has a patch for xorg-server and xserver-xorg-input-evdev to fix the issue
<cnd> and it's tested and ready to go
<bryceh> cnd, hmm, well the date on this change is Nov 22nd
<bryceh> so it looks like someone needs to fill or kill this out of proposed
<bryceh> I think that's the first step
<bryceh> (bug #650539)
<ubot4> Launchpad bug 650539 in xorg-server (Ubuntu Maverick) (and 6 other projects) "SRU: Launching a Qt app crashes X when using Xinerama (affects: 95) (dups: 10) (heat: 591)" [High,Fix committed] https://launchpad.net/bugs/650539
<bryceh> hrm it looks stuck
<bryceh> (there's a possible regression)
<bryceh> cnd, ok so number your change  2:1.9.0-0ubuntu7.2
<cnd> bryceh, should it be based on top of 7.1?
<cnd> or is that patch being dropped?
<bryceh> cnd, yes
<cnd> ok
<bryceh> cnd, assume it is being kept
<bryceh> (if it isn't, it's not something you'd need to deal with)
<mdeslaur> wow, nouveau is absolutely horrific with images.google.com
<cnd> bryceh, ok, I've updated the branches linked to the bug as appropriate
<cnd> bryceh, what should I do next?
<cnd> bryceh, btw, weren't we switching to using launchpad bzr for the X packaging, since bzr seems to have good git support now?
<cnd> or was it the other way around? :)
<bryceh> oh right, I didn't answer you
<bryceh> sorry, yeah we've been discussing that, but we're still using git for xserver
<bryceh> on my todo list is to mess around with the bzr<->git support with xkeyboard-config and see if it works as smoothly as advertised
<cnd> ahh, that's right
<bryceh> but just been too busy with other things so far
<cnd> well, I've only updated lp, but if you need me to do some git pushes I can do that
<bryceh> right, so the next step is to get the bug report in SRU shape
<bryceh> cnd, that'd be great - for most X packages we don't bother setting up a git branch for srus and just push them in, but there's enough stuff for xserver that we've been keeping a branch for all of its changes
<cnd> bryceh, ahh right, I can get it in sru shape
<bryceh> cnd, clearly we're inconsistent on doing that though, but that's the idea
<bryceh> cnd, https://wiki.ubuntu.com/StableReleaseUpdates explains what's needed
<cnd> bryceh, currently natty has the same gesture stack as maverick, but natty won't have the gesture stack in the end
<bryceh> 650539 is a pretty good example of the level of detail we shoot for in sru's
<cnd> should I worry about preparing a natty version?
<bryceh> you should either do that, or explain in the sru why/when something else will be fixing it
<bryceh> e.g. "This fix will come automatically when we update to foobar 1.2.3"
<bryceh> if there's any chance the other fix might conceivably not go in, I'd tend to upload that to the development version to, just to be safe
<cnd> bryceh, the bug report is ready for sru
<cnd> I'm working on the git sync now
<bryceh> cnd, excellent
<cnd> bryceh, you want me to push both 7.1 and 7.2 to the debian git repo?
<cnd> 7.2 includes my patch for xserver
<bryceh> yes
<bryceh> cnd, if you can do them as two separate commits, that'd be ideal in case the 7.1 change has to be reverted
<bryceh> but no biggie if that's too complicated
<cnd> nah, it was easy
<cnd> bzr diff -c <revno>
<cnd> git apply
<cnd> debcommit
<bryceh> oh nice
<cnd> I even fixed up the author for Alberto's change :)
<cnd> bryceh, http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=shortlog;h=refs/heads/ubuntu-maverick
<cnd> bryceh, anything else I can do to help?
<bryceh> cnd, all that's left is to upload it to -proposed and sub the sru team, and I'll take care of that for you, thanks for doing all the heavy lifting :-)
<cnd> great!
<cnd> now, back to multitouch work...
<cnd> bryceh, if you would, please review my xserver-xorg-input-evdev debian/control change closely
<cnd> I want to make sure I got the dependency right
<bryceh> ok
<bryceh> cnd, what would happen if someone updated to this version of -evdev without upgrading xserver?
<cnd> bryceh, probably a crash as soon as they tried to perform a gesture
<bryceh> i.e. would it break any worse than already?
<cnd> yes
<cnd> for example, I've never seen this crash
<bryceh> mm ok
<cnd> but others see it multiple times a day
<cnd> so it would be worse for me :)
<bryceh> then I think technically the control file looks correct to me
<cnd> ok, thanks
<bryceh> but I wonder if it might make the sru process easier if the patch could be done in a way that won't crash regardless of xserver version?
<cnd> I don't think there is a way, unless you check the debian package version of the server in the evdev source code
<bryceh> iow, there could conceivably be cases where someone wishes to use an older xserver for some random reason...  would be nice to let them continue doing so without having to also pin -evdev
<cnd> yeah, I understand why that would be nice, but I'm not sure how we could make that happen
<cnd> essentially, the ABI of the xserver is being bumped
<cnd> but it's a private ABI that only evdev knows about
<cnd> hence why there's no change to the header files of the server
<bryceh> cnd, what about some sort of #define in an xserver header, and then mess up -evdev with some #ifdef's ?
<bryceh> yeah, I know, fugly
<cnd> bryceh, yeah, I'd rather not touch upstream xserver headers
<cnd> and I don't want to make the patches more complicated than needed for an sru
<bryceh> Sarvatt, hey where is that edid write kernel patch you pointed me at the other week?  I've lost track of it.
<Sarvatt> bryceh: http://www.spinics.net/lists/dri-devel/msg00802.html
<bryceh> Sarvatt, thanks
<Sarvatt> hmm, hd 5xxx acceleration looks to be a bit much to just pull into x-x-v-ati 6.13.2
<Sarvatt> we still don't get 3D out of the box on those, just saw a bug on natty about it
<bryceh> Sarvatt, yeah what's still needed there?
<Sarvatt> ton of commits just after 6.13.2 released
<bryceh> I saw that it's marked on the ati features page such that it looks like it'd work, however I was messing around with it on my evergreen card the other day and couldn't get it to do other than software rendering
<Sarvatt> just the x-x-v-ati side
<Sarvatt> its supported in the kernel and mesa already
<bryceh> great, we should pull in the newer -ati then
<Milos_SD> Hi
<Milos_SD> Can nvidia binary driver cause xserver to use all the memory?
<Milos_SD> can that be the nvidia driver memory leak?
<bryceh> anything can cause a memory leak
<bryceh> however, most typically what causes X to use up memory is usually client applications
<bjsnider> he left the room before you said that
<bryceh> ah
<ion> Well, he displayed more patience than should be required of people. He waited for almost a minute before leaving.
<bryceh> ion, heh
#ubuntu-x 2010-12-14
<tjaalton> hum, what's the diminutive english word for "wave"? (wavelet?)
<tjaalton> nevermind
<ilmari> tjaalton: microwave :)
<tjaalton> hehe :)
<Sarvatt> mdeslaur: how did nouveau 3D go for you?
<Sarvatt> unity work?
<mdeslaur> Sarvatt: yeah, unity worked. But I'm back to nvidia, unfortunately. images.google.com is basically unusable with nouveau, and when I viewed a couple of large images in firefox, all my desktop pixmaps stopped working
<mdeslaur> Sarvatt: I'll try and reproduce later to file a bug
<Sarvatt> mdeslaur: hmm, what GPU do you have?
<mdeslaur> a black one? :)
<mdeslaur> hold on, I'll look
<mdeslaur> NVIDIA GPU Quadro NVS 140M (G86) at PCI:1:0:0 (GPU-0)
<bjsnider> that is what blocked it from working, instead of compiz? i'd never have guessed
<bjsnider> what about in a different browser than firefox?
<mdeslaur> bjsnider: in chromium, images.google.com works fine
<bjsnider> yeah, firefox on linux is a piece of crap
<mdeslaur> bjsnider: well, it's something particular about the way firefox handles images.google.com
<Sarvatt> don't tell me images.google.com uses webgl in firefox 4.0 now too :)
<bjsnider> i've heard people say that firefox is faster out of wine than the native linux version, so clearly it must be optimized for windows performance
<mdeslaur> Sarvatt: I had the same images.google.com issue with firefox 3 in maverick with nouveau
<bjsnider> i think we're really headed towards chromium as the default browser in ubuntu eventually
<Sarvatt> mdeslaur: thanks, was just curious what your experience was with the 3D side since we don't get much feedback. will try to reproduce that on my G86 when I can hijack it from the wife :)
<mdeslaur> Sarvatt: during the limited testing I did with unity, it worked great
<mdeslaur> Sarvatt: I did install libgl1-mesa-dri-experimental even if I didn't know if I needed it or not
<mdeslaur> oh, I guess I do...geforce 4 is ancient
<JanC> bjsnider: the Mozilla binary build for linux is also faster than the one in the Ubuntu package...
<Sarvatt> yeah it was, would like to enable it by default or make it easier to install (like through jockey) at some point, we should probably put out a call for testing for it
<Sarvatt> if anything just to get more exposure that people can use unity without the blob on a livecd with it
<mdeslaur> Would be nice to have unity working on nvidia without the binary driver
<Sarvatt> wow cairo xlib actually faster than the image backend for images.google.com on the blob
<Sarvatt> [  0]     xlib                    firefox-4    0.148    0.150   1.84%    6/6
<Sarvatt> [ # ]    image: pixman 0.18.4
<Sarvatt> [  0]    image                    firefox-4    0.160    0.162   0.95%    6/6
<Sarvatt> sure as heck isn't on intel
<Sarvatt> [  0]     xlib                    firefox-4    1.044    1.093   2.23%    6/6
<Sarvatt> [ # ]    image: pixman 0.21.2
<Sarvatt> [  0]    image                    firefox-4    0.724    0.731   1.65%    6/6
<Sarvatt> bjsnider: just waiting for the nocompat32 release to update the blob in the PPA
<Sarvatt> they didn't upload stuff to the FTP this time
<bjsnider> i don't see a new driver
<bjsnider> oh, now i see
<bjsnider> http://www.nvidia.com/content/DriverDownload-March2009/confirmation.php?url=/XFree86/Linux-x86_64/260.19.29/NVIDIA-Linux-x86_64-260.19.29-no-compat32.run&lang=us&type=GeForce
<Sarvatt> thanks, I didn't see it anywhere
<bjsnider> i just typed the no-compat32 part into the url figuring it might be there and it was
<tseliot> Sarvatt: are evergreen cards fully supported in Natty?
<Sarvatt> tseliot: nope
<Sarvatt> tseliot: needs a git x-x-v-ati
<tseliot> Sarvatt: ah, so mesa should be fine, right? I'm sure about drm
<bryceh> tseliot, Sarvatt, I'm writing the X.org report for this week... got anything I should include mention of?
<Sarvatt> hm, could mention the nvidia/fglrx xorg.conf thing maybe. nothing really exciting on my end
<bryceh> Sarvatt, ahh yes good idea
<bryceh> I've posted status to https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-12-14
<hrw> hi
<hrw> does someone know why 'intel' driver does not load on i855 chipset in maverick?
<hrw> it matches only vesa and fbdev.
<hrw> when I used Debian 'sid' on this machine months ago all was working.
<hrw> KMS works fine - inteldrmfb works
<hrw> brb
 * ilmari is getting occasional X hangs on resume from supend with the latest maverick kernel update (2.6.35-24.42)
<ilmari> i915/arrandale
<hrw> i915.... lucky you
<hrw> i855 here - piece of crap
<ilmari> it's actually core i7 integrated graphics ;)
<ilmari> i915 is just the kernel driver name
<hrw> ah
<hrw> ilmari: try http://askubuntu.com/questions/4658/how-to-install-intel-82852-855gm-driver-on-ubuntu-10-10-maverick-meerkat maybe?
<hrw> ignore 855 in it - it just gives younewer driver
<ilmari> well, it didn't do this with the previous maverick kernel, so it seems like a regression
<bryceh> hrw, the 8xx support has been decaying upstream and accumulating regressions.  It's proven too time consuming to support in ubuntu, esp. since we don't have anyone on the ubuntu-x team with that hardware
<bryceh> ilmari, I think that's a known issue... an incompatibility between the newer kernel and older -intel.  You need to update to a newer -intel to use it with the newer kernel.
<bryceh> ilmari, get a newer -intel for maverick from the x-updates ppa.
<ilmari> ppa:ubuntu-x-swat/x-updates ?
<bryceh> that's the one
<hrw> bryceh: Canonical hardware lab also lacks i855 devices?
<hrw> ~curse intel for i855
<bryceh> hrw, they do not have i855, no
<hrw> this laptop is still fine for my wife when it comes to size/hwardware (12", pentium m 1.6GHz)
<bryceh> however even if they did, I'm uncertain if their testing procedures would be sufficient to catch the types of bugs we see
<hrw> bryceh: if this can help then I can take this laptop with me for ubuntu platform rally in dallas,tx
<bryceh> hrw, no, like I said it's too time consuming to support 8xx so we pretty much don't support it anymore
<hrw> ok
<hrw> will have to live with fbdev then
<hrw> good that at least inteldrmfb works
<bryceh> it's not that we need to just fiddle a few bits to make it work, but that someone needs to sit down and do some serious debugging/development work on it, and that could take several man-weeks 
<hrw> waste of time then it would be
<bryceh> as well as routine and regular testing for regressions on new code drops (e.g. xorg-edgers), and working with upstream to get issues resolved
<hrw> 1.6GHz pentium m is still fast enough to do some desktop effects in software
<hrw> 5-6 years old hardware requires some sacrifice
<hrw> bryceh: thanks for help
<hrw> bye guys
<bryceh> hrw, sure, ssorry it isn't better news
<speakman> hi folks
<speakman> how dow I enable TCP listening on X? I'd like to connect remotely with DISPLAY env var
<Sarvatt_> good question, gdm sets that and I'm not seeing the option to disable it in a GUI anymore
<speakman> seems like it's configured in gconf nowadays?
<speakman> but no idea how..
<Sarvatt_> if it's anything like the other args passed to gdm now it might be hardcoded in the gdm source, hope thats not true..
<speakman> http://ubuntuforums.org/showthread.php?t=1590100
<speakman> That's not very clear...
<Sarvatt_> speakman: ahh /etc/X11/xinit/xserverrc:exec /usr/bin/X -nolisten tcp "$@"
<Sarvatt_> speakman: looks like you can remove it from there, and change the gconf key
<Sarvatt_> ...which i'm not finding
<speakman> is it really hard coded..?
<Sarvatt_> oh edit /etc/gdm/custom.conf and add [security]
<Sarvatt_> DisallowTCP=false
<Sarvatt_> nope, -nr is though :(
<speakman> exactly, but your paste of xserverrc looks scary
<speakman> -nr ?
<bryceh> Sarvatt, btw with pulling a new -ati into the archive, I'd be cool with it.  We've even shipped git snapshots of -ati with decent results in the past.
<bryceh> Sarvatt, is there anything to beware of that you know of with -ati 6.13.99 if I were to pull it into ubuntu now-ish?
<bryceh> (Or would it be better to wait until after we're all back from holidays?)
<Sarvatt> bryceh: nothing that I'm aware of, evergreen acceleration was making X crash with SIGBUS until recently but we have a fixed up kernel in natty
<bryceh> Sarvatt, ok I may do the -ati merge if I have time this week
<bjsnider> Sarvatt, i can do that nvidia blob if you're busy
<Sarvatt> bjsnider: sure, thanks for that. my cable modem resets every 5-10mb uploaded and haven't been able to be without net that long today to do it
<bjsnider> why the bleep does it do that?
<bjsnider> you must have north american internet to put up with that crap
<Sarvatt> you know it.. I tried to upload it on 3G earlier but apparently they dont let you upload more than 30MB at once on it, yay t-mobile
<bjsnider> what is your ISP's pathetic excuse for the cable modem issue?
<Sarvatt> they're comcast
<bjsnider> that's what they said? "we're comcast"?
<Sarvatt> got a fios install schedule for next month, goodbye comcast :)
<bryceh> yay!
<bryceh> yeah comcast sucks, although thats a level of suckatude I hadn't experienced when I was on it
<Sarvatt> bryceh: the only gotcha I forsee with an ati checkout..
<Sarvatt> they are doing funky version bumps
<Sarvatt> they change the version on master from 6.13.99 down to 6.13.x, release, then bump it back up to 6.13.99 after
<bryceh> huh
<Sarvatt> not sure if it should be 6.13.3 for a git snapshot
<Sarvatt> guess we can check what fedora is doing
<bryceh> yeah
<Sarvatt> sorry I was in a call when you asked earlier and forgot to mention that
<Sarvatt>   84 * Wed Dec 01 2010 Dave Airlie <airlied@redhat.com> 6.13.2-0.3.20101201gite142e55c5
<Sarvatt> 6.13.3 is probably going to be newer than our 6.13.99 checkout if we do it normally looking at what they did with 6.13.[12]
<Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=cc5005af61f45a3552f7358dc5aa711e42f5af54 and http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=ad999e633ff41d27eed9d2c6535e163a7181b0bd
#ubuntu-x 2010-12-15
<bryceh> Sarvatt, btw I did another test of installing fglrx with usb keys, after backing off the amount of persistent storage space by 800M.  Still got an error trying to activate the proprietary driver.  Gonna try again with only a 1G persistent partition, which should leave >2G for system files.
<Sarvatt> bryceh: it's uninstallable in general because of the second part of that bug, no vmlinuz symlink on the liveusb
<bryceh> Sarvatt, ah right
<bryceh> bug #557023
<Sarvatt> install it via apt-get and you'll see the error about the missing or broken vmlinuz instead of the lzma encoder error when you do have the free space
<ubot4> Launchpad bug 557023 in usb-creator (Ubuntu Natty) (and 3 other projects) "update-initramfs: deferring update (trigger activated) / cp: cannot stat `/vmlinuz': No such file or directory (affects: 204) (dups: 159) (heat: 1372)" [High,Triaged] https://launchpad.net/bugs/557023
 * Sarvatt pokes the bot
<Sarvatt> wooo thats a lot of dupes for a non intel bug!
<bryceh> hehe
<Sarvatt> oh heck, I completely forgot about the intel SRU!
<bryceh> alright let me re-do the bug from scratch with the /vmlinuz symlink manually created.
<bryceh> I'm gonna get this class of bug definitively off our plate
<bryceh> (if I were less lazy I'd code up a fix it myself)
<Sarvatt> bryceh: going to be around tomorrow or are you headed off on vacation too? :)
<bryceh> I'm not going on vacation.  I think I might be getting sick though so may or may not be around
<bryceh> my son's been sick the past few days and now my wife has it, and I can't imagine that I'll escape unscathed
<Sarvatt> yeesh everyone with kids is getting it right now! :)
<bryceh> everyone else will get it at the sprint
<bryceh> hmm, fglrx successfully installed... but now usb drive no longer boots.  wtf.
<bryceh> here we go
<bryceh> weird, had to specifically select usb in bios this time
<bryceh> ...and it went back to -ati instead of -fglrx.  hrmph
<Sarvatt> you installed it with jockey right? update-alternative --list gl_conf?
<Sarvatt> update-alternatives rather
<Sarvatt> dont get an xorg.conf outside of jockey and I just mentioned doing it via apt-get to see the error is why I ask :)
<ScottK> Sarvatt: Please let me know if you need sponsorship/testing for the Intel SRU.
<bryceh> yeah, used jockey to install
<bryceh>  update-alternative --list gl_conf
<bryceh>  /usr/lib/mesa/ld.so.conf
<Sarvatt> ScottK: it's going to take an hour or two to review the dupes, get the SRU justification info into the bug and get it packaged properly for -proposed, can I bother you for help with it tomorrow? been trying to get off the PC for 2 hours now
<ScottK> Sarvatt: Sure.  I'll be around.
<bryceh> fwiw, I'm using an alpha-1 image here
<Sarvatt> ScottK: thanks a ton for that!
<bryceh> hmm this is also weird
<bryceh> did an upgrade via Update Manager
<Sarvatt> bryceh: hmm, thats VERY odd
<bryceh> failed...  sudo dpkg --config -a shows this error:
<ScottK> Sarvatt: Purely selfish.  I live with a teenager who looks at me with sad eyes and asks for a Mac every time her X crashes.
<bryceh> dpkg: failed to write status database record blah blah to '/var/lib/dpkg/status': no space on device
<bryceh> df -h /var/lib/dpkg/ shows it as 'aufs  1006M' with Use%='-', mounted on /
<Sarvatt> ScottK: oh she's getting this bug? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/626967
<ubot4> Launchpad bug 626967 in xserver-xorg-video-intel (Ubuntu Natty) (and 2 other projects) "MASTER: Hang in MI_WAIT_FOR_EVENT on framebuffer switch. (affects: 30) (dups: 41) (heat: 320)" [Medium,Fix released]
<Sarvatt> I thought she was getting the logout problem
<ScottK> Yes.
<ScottK> We're getting both Bug #651294 and Bug #660152
<ubot4> Launchpad bug 651294 in xorg-server (Ubuntu) (and 1 other project) "X crash on KDM logout (still - yes, really) (affects: 22) (dups: 4) (heat: 118)" [High,Confirmed] https://launchpad.net/bugs/651294
<ubot4> Launchpad bug 660152 in xserver-xorg-video-intel (Ubuntu Maverick) (and 1 other project) "The computer logged me out without my permission. (affects: 5) (heat: 73)" [High,New] https://launchpad.net/bugs/660152
<ScottK> The first one at least has a workaround.
<ScottK> Someone said something about a patch that might help.
<Sarvatt> ahh that's a different bug
<ScottK> OK.  Can we knock them together into one SRU?
<ScottK> That's the one I thought you were doing.
<Sarvatt> ScottK: awesome, that patch referenced does indeed look like it'll fix that problem
<ScottK> Sarvatt: Right, so if you could include that, I'd be super motivated to help.
<Sarvatt> bryceh: what's the status of xorg-server in maverick? did you have a SRU queued?
<bryceh> Sarvatt, yep, posted it yesterday, but it's blocked by another sru that's been stuck in the queue since november
<Sarvatt> ahh darn, ScottK's bug needs a fix in the server too
<ScottK> bryceh: Maybe we should have that one rejected, do just this one and then reupload the other one.
<ScottK> The logout one should be very easy to quickly verify
<bryceh> alright, I'm officially done with #685017.  I can't figure it out, seems something peculiar with the filesystems.  I've documented as much as I sorted out, and I'm 95% certain it's not the driver's fault.  Someone else will need to figure it out from there.
<bryceh> so things will probably improve a smidge once timo comes on
<Sarvatt> bryceh: I'm absolutely completely 100% stumped too and have written it off to aufs magic I don't understand at the moment
<Sarvatt> last time I successfuly did it that I remember was one of the lucid alpha releases
<bryceh> hmm
<bryceh> yeah I think it's probably better debugged at this point by someone who understands the filesystem magic more deeply
<bjsnider> Sarvatt, my source package keeps freezing at 1k left. it will not finish uploading for some reason. does x-updates still work?
<Sarvatt> bjsnider: try upload.ubuntu.com?
<Sarvatt> [x-updates]
<Sarvatt> fqdn = upload.ubuntu.com
<Sarvatt> method = ftp
<Sarvatt> incoming = ~ubuntu-x-swat/x-updates/ubuntu
<Sarvatt> login = anonymous
<Sarvatt> allow_unsigned_uploads = 0
<bjsnider> no, didn't work
<Sarvatt> wow, it uploaded so slow I didnt even get booted
<Sarvatt> uploaded it all to xorg-edgers at any rate, can just rebuild copy them over if you cant get it uploaded
<Sarvatt> bryceh: 3 bugs?!
<bryceh> Sarvatt, ?
<Sarvatt> http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg
<Sarvatt> my mind is blown :)
<bryceh> :-)  staying on top of the bug queue is paying off
<Sarvatt> yeah thats crazy, post alpha 1 and 3 bugs..
<bryceh> *nod*
<Sarvatt> hmm then again
<Sarvatt> http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/totals-maverick-workqueue.svg
<Sarvatt> june 3rd maverick A1
<bryceh> yeah was just about to mention that
<Sarvatt> guess I was thinking of the lucid chart that started late in the cycle :)
<bryceh> the knee in that curve came around 2nd week of august
<bryceh> plus, we haven't pulled in all the new X bits and pieces
<Sarvatt> week after alpha 3 then
<bryceh> most of the bug reports I've seen have ended up being bugs in other non-X things
<Sarvatt> yeah true everythings just been juicy bug fixes vs lucid
<Sarvatt> err maverick
<bryceh> so maybe 50% of the bugs still aren't "fixed", it's just that the bug was misfiled
<bryceh> one of the -intel bugs I forwarded upstream today, so not technically fixed, but there's nothing more we can do about it
<Sarvatt> yeah, poor unity/compiz stealing all the bugs away :)
<bryceh> heh
<bryceh> at least it's not exposing new X issues (yet...)
<Sarvatt> yeah no clutter abusing glx in painful ways is a huge win :)
<bryceh> but my theory is that a lot of bugs that get filed are actually dupes of some underlying issue
<bryceh> so one bug closed today may mean 10 or 100 that never get filed tomorrow
<bryceh> it'd be cool to show the total bugs in maverick at the corresponding point in time, so we can see for natty how much better we're doing
<Sarvatt> bryceh: hah, registered dutch on launchpad already?
<bryceh> ok I officially hate how this computer freezes every other day
<bryceh> Sarvatt, yeah of course gotta get dutch his launchpad id!
<Sarvatt> every other day? on natty!? I've had 6 freezes today already, 2 were kernel panics
<bryceh> this is on maverick
<bryceh> pondering upgrading it
<bryceh> I suspect it might be hw or memory issues; I have lots of weird random firefox crashes too, and it seems like every freeze is different
<tjaalton> i might upgrade to natty after the holidays..
<bryceh> heya tjaalton
<tjaalton> howdy
<Sarvatt> just in time for all the really bad breakage to hit!
<tjaalton> yeah, lets upgrade everything on 23rd
<Sarvatt> well mesa is releasing the day the sprint starts
<Sarvatt> bryceh: sorry about the spam, we settled on https://launchpad.net/~canonical-hwe-team/+archive/ppa :)
<seb128> hey there
<seb128> could someone review the patches on bug #597895?
<ubot4> Launchpad bug 597895 in xorg-server (Ubuntu) "X crashes on key press (affects: 4) (heat: 26)" [Undecided,Confirmed] https://launchpad.net/bugs/597895
<tjaalton> the later patches should preferably get an upstream review
<tjaalton> oops
<tjaalton> seb128: i accidentally changed it to incomplete
<tjaalton> though I guess it's more accurate since we need bob's reply
<seb128> change it back? ;-)
<seb128> ok
<seb128> well the upstream bug has a commit and has been closed
<seb128> not sure if that one could be commited in your vcs
<tjaalton> yeah but the lp bug has several patches
<seb128> right, I've asked about those
<tjaalton> of which a couple are upstream
<tjaalton> one is in 1.7-branch, the other is at least in master
<tjaalton> i asked him to get peter to review them, since he seems to have been working with him on this
<seb128> great, thanks
<boneshaker> hello
<boneshaker> when i try to send keysequence via xvkbd to client running on Xvfb - it kills Xvfb with fatal io error 11
<boneshaker>  with other X servers (not Xvfb) it works fine
<boneshaker> any ideas how to make it work on Xvfb? ty in advance
<boneshaker> one more detail - it work with Xvfb - if i, before sending keysequence, run x11vnc on it and connect/disconnect to it, then i can send keysequences to client running on Xvfb without errors
<boneshaker> Ubuntu 10.4
<Sarvatt> awesome, braid and osmos are in the humble indie bundle this time, didn't know braid got a linux port! http://www.humblebundle.com/
<gord> Sarvatt, the guy who made braid got annoyed with windows a while back and became an ubuntu convert, thats why we got a port :)
<ion> :-)
<Sarvatt> gord: I see he's a blob user too :)
 * Sarvatt tells everyone to use the windows version in wine on intel
<Sarvatt> hitting hardware limitations with the linux port
<Sarvatt> i915_program_error: Exceeded max nr indirect texture lookups (8 out of 4)
<Sarvatt> i915_program_error: Exceeded max nr indirect texture lookups (8 out of 4)
<Sarvatt> i915_program_error: Exceeded max ALU instructions (83 out of 64)
<Sarvatt> and s3tc is required, that's going to be a lot of pain for people
<seb128> bryceh, could you try to sort out what needs sponsoring or not on bug #597895?
<ubot4> Launchpad bug 597895 in xorg-server (Ubuntu Natty) (and 2 other projects) "X crashes on key press (affects: 4) (heat: 26)" [Undecided,Incomplete] https://launchpad.net/bugs/597895
<Sarvatt> oh boy that bug, he had one of these super crappy things that was causing it http://www.dealextreme.com/details.dx/sku.16685
<bryceh> seb128, I'm out sick today
<bryceh> seb128, but looking at the three patches mentioned in his last comment they all look ok to me
<bryceh> seb128, 0001 is obviously safe, just a null pointer check
<bryceh> master_device.patch is #ifdef'd appropriately to just XDGA. 
<bryceh> dix_dont_create_core_motion_events... looks to be an error check for a particular error situation.  That's the only one that looks like it could possibly have side effects
<bryceh> seb128, I would suggest doublechecking that they are indeed upstream in xserver git, and if so they should be good to go for natty
<Sarvatt> patch 4 caused a few regressions
<Sarvatt> http://launchpadlibrarian.net/60381571/dix_dont_create_core_motion_events_for_non_xy_valuators.diff
<seb128> bryceh, ok, thanks
<Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=30267
<ubot4> Freedesktop bug 30267 in Input/Core "openarena mouse faliure since dix: don't create core motion events for non-x/y valuators" [Normal,Resolved: fixed]
<Sarvatt> plus made the test suite fail
<bryceh> Sarvatt, good catch
<seb128> Sarvatt, could you comment on the bug to say that
<seb128> ?
<seb128> thanks ;-)
<bryceh> ok, gonna un-irc for a bit
<Sarvatt> digging through fedora git to see if they implemented it another way
<Sarvatt> oh RHEL6 stuff isn't in git anymore, doh
<Sarvatt> trading off fixing things on one specific crazy device that reports voltage as an axis for breaking mouse input in SDL for a large number of people there as-is
<bdmurray> could fglrx-installer bugs with a build failure due to "kernel includes .. do not match current kernel" be combined?
<Sarvatt_> there could be multiple reasons why they get that message, they could 1) not have headers installed at all 2) have a custom kernel with screwed up versioning 3) have something like generic headers only trying to build a generic-pae module 4) are installing from an older fglrx release that isn't compatible with the utsrelease.h move in 2.6.33 (like say using stock lucid fglrx with a newer kernel)
<Sarvatt_> i'm sure i'm forgetting some but thats what I saw from a quick glance at those just now
<ilmari> what's the easiest way to test drm-intel-fixes or drm-intel-next on maverick?
<ilmari> hm, http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/ only has natty kernels
<Sarvatt> jeeze, I lost count of how many freezes that was today, alpha nvidia drivers are no joke
<Sarvatt> ilmari: for drm-intel-next I believe there is a daily build in the mainline ppa?
<ilmari> Sarvatt: only for natty afaict
<ilmari> (see the link I just pasted)
<Sarvatt> http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/
<Sarvatt> that just means it has the natty config
<Sarvatt> will work fine on maverick
<Sarvatt> oh sorry, I didn't see your link, froze right when you asked about the easiest way to test
<ilmari> ah
 * ilmari gives it a go
<ilmari> no luck :(
<ilmari> are there no brits in the intel drm development team?
<ilmari> it's the bbc iplayer backround that triggers the flickering
<Sarvatt> ickle (Chris Wilson) in #intel-gfx is, he has an x201s too which is why it's weird
<ilmari> hm, I get "can't send to channel" there
<Amaranth> Anyone tried i965g lately?
<Dr_Jakob> Amaranth: its dead jim.
<Amaranth> Well, there goes the idea of working on GLES stuff on my main computer
<Dr_Jakob> the classic driver should support gles
<Sarvatt> Amaranth: you have to play with egl env vars to pick egl_dri2 instead of egl_gallium, it defaults to gallium if mesa is built with it
<Amaranth> Dr_Jakob: Mesa 7.10-devel implementation error: Incomplete OpenGL ES 2.0 support.
<Amaranth> Sarvatt: Oh? Time to dig some more
<Sarvatt> EGL_DRIVER=egl_dri2
<Sarvatt> oh
<Sarvatt> that might be something else, sorry
<Amaranth> Sarvatt: Nope, that worked
<Sarvatt> ah cool
<Amaranth> Before I was getting some assembler debug output
<Amaranth> Now I've got something drawing on the screen! Thanks!
<Amaranth> Sarvatt: You just saved me from having to ssh to a computer with an nvidia GPU and look at the screen from across the room to see if things work :)
<RAOF> :)
 * Amaranth tosses that in /etc/environment
<RAOF> That shouldn't be *too* hard to fix properly,  I think.
<Sarvatt> probably worth repeating here, don't upgrade sudo on natty at the moment :)
<ion> Heh, ok
<Sarvatt> fun bug https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/690873
<ubot4> Launchpad bug 690873 in sudo (Ubuntu) "latest natty sudo upgrade removes admin from /etc/sudoers (affects: 2) (heat: 16)" [Critical,Triaged]
#ubuntu-x 2010-12-16
<bjsnider> that only happens if the user agrees to replace his own sudoers file with the package maintainer's version
<Sarvatt> note to self: files in /etc/sudoers.d/ need to be 0440
<RAOF> Heh.
<RAOF> ScottK: I've got some prospective packages for that KDE crash on logout bug in https://edge.launchpad.net/~raof/+archive/aubergine
<RAOF> As I mentioned on the bug, GLX reference counting is moderately scary; it'll need lots of testing.
<ScottK> RAOF: OK.  We can give them a try.
<RAOF> Thanks.
<ScottK> $TEENAGER2 is sleeping already so I can install them there ....
<RAOF> If your systems start to die from swap thrashing for no obvious reason after a day or so please do pipe up; it's probably the patch :)
<ScottK> OK
<ScottK> Oh.  Didn't build yet....
<RAOF> What, still?
<RAOF> Gah, slow PPAs.
<ScottK> I'll start a local build and we'll race.
<ScottK> RAOF: Which of the binaries from this source do I need?
<RAOF> Just xserver-xorg-core should do.
<ScottK> OK.
<RAOF> Ah, you'll also need xserver-common.
 * ScottK nods
<ScottK> There was not an immediate kaboom of any kind.  That's something.
<RAOF> Hurray!
<ScottK> I've also been able to login and logout a couple of times without crash (I did remember to remove the workaround for the logout crash first)
<ScottK> So I'll leave this on here and we'll see what happens.
<ScottK> This is also the system that's been having the random X crashes, so we can see if this helps that too.
<Sarvatt> ScottK: sorry for not mentioning this yesterday but there is still a lot of discussion going on about the glx drawable patch and it might not get taken in that form
<ScottK> Sarvatt: OK.  That would have been good to know, but oh well.  At least it's not obviously worse.
<ScottK> Thanks for letting me know.
<Sarvatt> v3 of it here now http://patchwork.freedesktop.org/patch/3252/
<ilmari> huh, why can't I send to #intel-gfx?
<Sarvatt> need to be registered with nickserv probably
<ilmari> ah, I'd failed to identify after my last disconnect
<ko2> hi, are there any newer driver releases available for the Intel 82865G for Linux Kubuntu Hardy Heron?
<ko2> mine is very old. I need a newer one
<tjaalton> ko2: for the third time, no
<bjsnider> hardy is also very old
<jcristau> 865G is also very old
<ko2> a driver drom last year could be sufficient
<ko2> drom=from
<ScottK> FWIW, I've got an 865G system that worked very well on Hardy, so I doubt what's shipped is a problem.
<ScottK> Sarvatt: When there's something worthwhile on the patch, please convince RAOF to upload it to his PPA and let me know.
<bjsnider> Sarvatt, i just emailed you some ppa usage stats for x-updates and xorg-edgers
<Sarvatt> bjsnider: neat!
<Sarvatt> ScottK: will do, v3 has problems now too
<Sarvatt> 11k downloads of intel-gpu-tools since august 30th in x-updates, hmm
<Sarvatt> number is a lot higher than I imagined it'd be actually
<Sarvatt> oh wow
<Sarvatt> thats just from december 8th to december 16th!?
<Sarvatt> and just for maverick too, wow
<Sarvatt> bjsnider: that's awesome, thanks for passing that along
<bjsnider> Sarvatt, no, it's retroactive to when the package first appeared int he archives
<bjsnider> in other words the nvidia-96 package has a lot of downloads because it's been there for a long time
<bjsnider> but the scanner started going through the logs on the 8th, and i'm still not sure if it has finished scanning them all the way back to the beginning or not
<Sarvatt> bryceh: check it out - http://sarvatt.com/downloads/ppadownloads/x-updates~maverick~2010-12-08--2010-12-16.htm
<Sarvatt> oh not here
<Sarvatt> intel-gpu-tools is a good one to compare, that's in every desktop install and hasn't been updated since aug 30th
<Sarvatt> http://sarvatt.com/downloads/ppadownloads/xorg-edgers~maverick~2010-12-08--2010-12-16.htm
<bjsnider> amd64 only
<Sarvatt> oh
<bjsnider> you can grab the i386 numbers easily
<bjsnider> i have no idea how many people still use i386
<Sarvatt> yea looking at the script now
<Sarvatt> uh because they might have netbooks for one thing? :)
<bjsnider> yeah but outside the lpia type devices
<bjsnider> but you could come up with a decent ratio with this script i suppose
<JanC> bjsnider: I use two 32-bit intel systems still, and none are "LPIA"  ;)
<bjsnider> JanC, why is that?
<JanC> why not?
<JanC> they still work fine...
<bjsnider> i think you've misunderstood what i meant
<JanC> maybe  ;)
<bjsnider> i meant i wasn't sure how many people who have 64-bit cpu-systems choose to install i386 ubuntu on them instead of amd64
<JanC> ah
<bjsnider> i didn't mean 32-bit processors
<JanC> most new users
<JanC> because the official CD is 32-bits...
<bjsnider> right, i thought of that
<bjsnider> but all of us super-nerds use amd64
<JanC> and people recommend 32-bits because of issues with flash etc.
<Sarvatt> got i386 numbers here http://sarvatt.com/downloads/ppadownloads/
<bjsnider> are the numbers higher than the amd64 numbers?
<JanC> at first sight i386 numbers are somewhat higher...
<bjsnider> perhaps it's not quite as bad as you think JanC 
<JanC> for xorg-edgers a little more i386 than amd64, for x-updates it's about 18k i386 vs. 11k amd64 -- so the more of a graphics freak you are the more likely you use amd64 I guess  ;)
<ScottK> bjsnider: I use 32bit on all my systems as 64bit doesn't offer significant advantages worth the trouble of reinstalling + flash and stuff.
<JanC> flash works fine on 64-bit if you know where to find the "developer pre-release", but that's not exactly something to explain to "newbies"
<ScottK> Next time I buy new hardware, I'll probably install 64bit.
<JanC> ScottK: you have no systems with > 4 GiB RAM ?
<ScottK> I don't.
<bjsnider> i madw a ppa that provides the 64 bit flash
<bjsnider> ScottK, if one of your 32-bit systems experienced a dead hard drive and you had to reinstall everything, would you go to 64-bit or stay with 32?
<ScottK> Probably stay with 32.  I don't see a reason to mess with something different.
<bjsnider> even though 32-bit ubuntu has all of those backdoors put there by the FBI?
<bjsnider> j/k
#ubuntu-x 2010-12-17
<RAOF> Grumble grumble stupid x11-proto updates grumble grumble.
<Sarvatt> grumble grumble compiz still no workie on sandybridge grumble
<Sarvatt> RAOF: did you see that the glx patch got a v3?
<Sarvatt> RAOF: https://bugs.freedesktop.org/show_bug.cgi?id=28181#c31 with the v2 patch :(
<ubot4> Freedesktop bug 28181 in Server/general "Combination of foss ati driver 6.13.0 and xorg-server 1.8.1 gives seg faults." [Normal,New]
<bjsnider> Sarvatt, sandybridge has not been released yet
<njpatel> So, intel 4500MHD can drive 4098x1152 through display port -> dvi and VGA, and unity is fast on it
<njpatel> however, getting the displayport up and running is a lesson in patience. Most of the time X just hangs and you need to pull out the lead for it come out of that
<njpatel> also, can't leave it plugged in and restart, everything stops while trying to start GDM until you pull out the displayport lead
<njpatel> even on a running system, it actually working is incredibly hit and miss, I was wondering if there was any knowledge of that?
<Sarvatt> njpatel: the displayport->dvi adapter is the problem there I believe, I just saw some fixes for it recently let me see if they are in already
<njpatel> i915 0000:00:02.0: DP-1: Ignoring invalid EDID block 40.
<njpatel> [  152.029383] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 1
<njpatel> getting tons of those in dmesg
<Sarvatt> njpatel: ya disappeared right when i responded :)
<Sarvatt> njpatel: the displayport->dvi adapter is the problem there I believe, I just saw some fixes for it recently let me see if they are in already
<njpatel> sorry :)
<njpatel> Sarvatt, ah, interesting
<Sarvatt> njpatel: http://git.kernel.org/?p=linux/kernel/git/ickle/drm-intel.git;a=commit;h=8316f33766a82907c694267ff911e45e256f09f9 is the fix and its queued up for .38 merge window
<Sarvatt> http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/2010-12-17-natty/
<Sarvatt> its in that kernel
<njpatel> oh, sweet
<Sarvatt> if ya want to verify it fixes it
 * njpatel tries
<njpatel> Sarvatt, thanks, will install and try it out
<njpatel> it's kinda awesome this laptop can even drive these two displays in the first place
<njpatel> i was pleasantly surprised :)
<njpatel_> Sarvatt, it works!!
<njpatel_> thank you :)
 * njpatel_ has stupidly wide desktop again
<njpatel_> it even detects all the properties off the displayport properly
<Sarvatt> no worries, I'll ping you when its in the proper distro kernel so you dont have to keep using that crack :)
<njpatel> heh, thanks :)
<njpatel> if you need any testing done on silly intel setups, let me know
<njpatel> though, as I'm developing Unity, there is already stupid testing happening ;)
<Sarvatt> I'm surprised it works too honestly :) your laptop panel turns off so you can use the vga and displayport?
<njpatel> I haven't tried switching on the laptop panel too
<njpatel> let me try.....
 * njpatel expects things will die now
<njpatel> yeah, not happening :)
<Sarvatt> naaah not worth the hassle, was just surprised it did the right thing for a change
<njpatel> it thinks it's on but nothing showing up
<njpatel> and can't move the pointer there
<njpatel> i'm just surprised it's *so* fast
<njpatel> scale/expo etc work really smoothly
<Sarvatt> yeah good riddance clutter!!!
<njpatel> heh :)
<njpatel> oh, just got a notification letting me know that the "selected configuration for displays could not be applied"
<njpatel> I hate that this makes me like the intel driver
<Sarvatt> bdmurray: duping all "failed to install/upgrade" bugs from nvidia-current and fglrx-installer's bugs to 557023 when casper is present in ProcCmdLine: in the description would knock out a HUGE chunk of bugs if you have a way to automate that easily
<bdmurray> Sarvatt: yes, I could do that
<Sarvatt> heck, https://bugs.launchpad.net/ubuntu/+source/fglrx-installer?field.searchtext=failed+to+casper grabs them too :)
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers?field.searchtext=failed+to+casper whee
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers?field.searchtext=failed+script+returned+error+exit+casper is better
<bdmurray> I've just been searching for apport-package as a parameter and the examining the bugs
<Sarvatt> casper is only there when apport collects the info off the livecd so those are all for sure dupes, that's a nice chunk of bugs to knock out
<bdmurray> I'm fairly certain LiveMediaBuild indicates that it is a live cd too
<Sarvatt> ah yeah thats even better
<Sarvatt> maybe someone decides to talk about casper the friendly ghost in the bug summary
<bdmurray> well, now my code is a bit better than that
<Sarvatt> <jbarnes> intel_reg_write 0xa090 0x88040000
<Sarvatt> <jbarnes> vs
<Sarvatt> <jbarnes> intel_reg_write 0xa090 0x88000000
<Sarvatt> <jbarnes> is a 4W difference
<Sarvatt> \o/ \o/ \o/ \o/
<Sarvatt> holy crap, huge power savings for intel incoming
<Sarvatt> well for 965gm+ at least
<ion> The byte 2 defines the number of watts to use to heat the room?
<Sarvatt> enables a power saving feature that wasn't getting enabled, and boo it's just sandybridge, already enabled on the others
<Sarvatt> heh some of these bugs have pages and pages of duplicates already too
<Sarvatt> so glad I dont have to fix that manually anymore
<bryceh> Sarvatt, wow
<Sarvatt> ok nvidia-graphics-drivers and nvidia-graphics-drivers-180 done, need to do 96 and 173
<bryceh> Sarvatt, makes me wonder what that register does...
<Sarvatt> https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=failed+script+returned+error+exit+LiveMediaBuild would all be the same bug across all packages if it would work
<Sarvatt> bryceh: enables rc6
<bryceh> what's rc6?
<Sarvatt> google intel rc6 render standby
<Sarvatt> dang https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=failed+script+returned+error+exit+LiveMediaBuild is just too much for poor little launchpad
<Sarvatt> oh it worked! 1 â 75 of 233 results	
<Sarvatt> 233 more dupes..
<Sarvatt> bryceh:  it lowers the voltage on the gpu down to almost nothing when idle
#ubuntu-x 2010-12-18
<bryceh> can't wait :-)
<BUGabundo> hi guys
<BUGabundo> using nvidia with nouveua
<BUGabundo> if I rotate my screen 90Âº, the touchpad doesn't rotate
<BUGabundo> is this known, or should I file a bug for it?
<bjsnider> nouveau
<BUGabundo>  I never write it well
<BUGabundo> sorry about that
<bjsnider> show some respect for the glorious french language
<BUGabundo> next time, choose something *easy* :p
<mdeslaur> new? :)
<bryceh> BUGabundo, yeah known issue
<BUGabundo> thanks bryceh
<BUGabundo> any bug I can sub to?
<bryceh> BUGabundo, you can rotate it manually using xinput I think
<bryceh> in fact I think there's a patch for it
<BUGabundo> I made my laptop as a semi tablet, to read feeds :D
<BUGabundo> â   â³ SynPS/2 Synaptics TouchPad              	id=12	[slave  pointer  (2)]
<BUGabundo> I guess that's the one I want
<bjsnider> mdeslaur, they could have called it "novus" which is latin for "new"
<mdeslaur> bjsnider: yeah, but then I would have trouble remembering how to spell it :)
<bryceh> I had a hell of a time trying to tell a native french speaker about the driver
<bjsnider> a driver name has to have at least 2 syllables
<BUGabundo> bryceh: LOLOLOL
<bryceh> "Yes, use the nouveau driver."  "Oh, a new driver for nvidia?  What's it called?"
<BUGabundo> new new 
<BUGabundo> what ? new new 
<bryceh> pretty much
<BUGabundo> :DDD
<mdeslaur> who's on first
<Sarvatt> hmm, wonder why they never took that orientation patch upstream now now that you mention it
<Sarvatt> ah waiting for XI2.1 https://bugs.freedesktop.org/show_bug.cgi?id=21129
<ubot4> Freedesktop bug 21129 in Input/Core "General axis inversion and rotation support" [Normal,Assigned]
<Sarvatt> (probably 2.2 now)
<jewsucanuse> hey bryceh, i'm getting a weird x error.
<jewsucanuse> after a few hours of use, most videos and images have color banding gradients
<jewsucanuse> and this perists until an x restart.
<Sarvatt> hmm its implemented for absolute devices http://cgit.freedesktop.org/xorg/xserver/commit/?id=6cccf0131c8464d8838cae2200730873d7dd9e45
<Sarvatt> what driver?
<Sarvatt> if its nvidia try changing away from the dynamic dithering mode? (shot in the dark)
<jewsucanuse> i9515
<jewsucanuse> *i915
<jewsucanuse> natty bits btw
<bryceh> jewsucanuse, no idea
<LLStarks> i wish i could take a pic
<bjsnider> libv, someone has created another via graphics driver -- "chrome" by name
<bryceh> just what the world needs
<bjsnider> at least via users have lots of choice
<bjsnider> over 3000 possible drivers and counting
<bjsnider> and none of them work!
<Dr_Jakob> bjsnider: linky?
<bjsnider> http://www.phoronix.com/scan.php?page=news_item&px=ODkzMQ
<libv> bjsnider: one of the openchrome... let's say... people, did that
<libv> bjsnider: commits are made to git by "root"
<libv> of someone who has been, let's call it, "hanging around" graphics for the last 4-5 years, one would expect better, no?
<soreau> Does anyone know if gallium will be default for radeon r3-5xx cards for natty?
<ripps> I'm gonna try out Xorg-edgers on my rv350, see how gallium is coming along
<ripps> hmmmm.... [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (1224704, 2, 4096, -12)
<ripps> tried running pcsx to test opengl with a playstation game, now X seems to crash everytime I run a complex opengl program
<ripps> cool, with r300g, I can force flash to use gpu acceleration
<Sarvatt> we're going to get yelled at for maing this font default http://sarvatt.com/downloads/mono.png :)
<Sarvatt> soreau: it already is, yeah
<bjsnider> i think that font looks cool
<ion> Iâll have to see it without the blurry font rendering to compare with the current DejaVu/Vera one.
<vish> Sarvatt: reboot after updates! ;) 
<Sarvatt> ion: without the blurry font rendering? it looks screwed up at anything but subpixel smoothing/slight hinting at the moment
<Sarvatt> http://sarvatt.com/downloads/mono-subpixel-full.png
<ripps> awesome, 3d css transforms work in chromium now. and they look awesome
<ion> If a horizontal or vertical line has subpixels that are anywhere between the background color and the text color, the rendering is using lower frequency content than would be possible, i.e. blur. That might look aesthetically nice, but nobody can claim itâs not less readable. Weâve drawn our characters with sharp lines through the human history for a reason.
<ion> Even the -full one is blurry: alas, you need to do sudo perl -i -pwe 's/\000\Klcddefault\000/lcdlegacy\000\000/g' /usr/lib/gnome-settings-daemon-2.0/libxsettings.so to get sharp fonts in Ubuntu Gnome.
<ion> The powers that be havenât provided us with a better way to do it, and i havenât got around to creating a good patch. :-)
<bjsnider> i don't see the blur in that screenshot
<ion> It would be obvious if youâd see the really sharp text next to it. You could fire up xmag and look at any horizontal or vertical line to see the between-0%-and-100% subpixels.
<bjsnider> xmag?
<ion> Alt-F2, xmag, Enter
 * bjsnider nods
<ion> The solution to get aesthetically good-looking fonts is getting displays with considerably better resolutions, not using blurry rendering to approximate it with the cost of readability.
<bjsnider> my monitor only does 96 dpi
<ion> ditto
<ion> Still waiting for the 300 DPI displays. :-P
<ion> â¦affordable ones, that is.
<bjsnider> why stop at 300?
<bjsnider> we can't even really get much past 96 at this point though
<ion> I didnât mean the progress should stop at 300. :-)
<ilmari> my home laptop is 140dpi, my work one is 147
 * mdeslaur will run his 300 DPI display at 96 DPI to get massive resolution :P
<ilmari> 1440x900 on 12.1" and 1920x1200 on 15.4", respectively
<bjsnider> at 300 dpi the windows icons would be so small that they'd be invisible
<ion> mdeslaur: That makes no sense. In LCDs, the resolution is a physical property of the display that doesnât change. :-)
<Sarvatt> vish: why'd you make me reboot, gnome classic session breaks in new interesting ways every friday update :)
<mdeslaur> ion: right, I meant massive window real estate :P
<vish> oops!
<ion> bjsnider: Toolkits should scale images (picking the closest appropriate bitmap version available for small sizes) based e.g. font size.
<ion> mdeslaur: You mean you want small fonts? Then the setting youâre after is the font size. :-)
<bjsnider> ion, windows doesn't
<ilmari> bjsnider: and?
<ion> bjsnider: Yes, i said âdecentâ. ;-) Anyway, as high-resolution displays become available, iâm sure Bill will have to follow.
<bjsnider> actually maybe windows 7 does, i dealt with a guy who had a laptop with a large resolution and small display and his icons were tiny
<bjsnider> but he was using vista
<mdeslaur> ion: okok, you win :P
<Sarvatt> ion: http://sarvatt.com/downloads/mono-full-lcddefault.png
<ilmari> icons should be vector graphics anyway
<Sarvatt> whoops lcdlegacy I meant
<ion> sarvatt: Not bad. I can see further hinting is needed, but i could get used to that.
<ion> Thanks for the screenshot. :-)
<ion> By switching between http://sarvatt.com/downloads/mono-full-lcddefault.png and http://sarvatt.com/downloads/mono-subpixel-full.png one can clearly see the difference in blurriness.
<ion> Not to mention between http://sarvatt.com/downloads/mono.png and http://sarvatt.com/downloads/mono-full-lcddefault.png
<bjsnider> Sarvatt, does the led on your wifi chip work?
<mdeslaur> ugh, I hate full hinting
<Sarvatt> bjsnider: atk9k is all kinds of screwed up in the latest kernels but yeah the led works fine
<Sarvatt> bjsnider: knew it was too good to be true that we could keep the same basic packaging between 3 releases for nvidia/fglrx :)
<Sarvatt> (see end of https://lists.ubuntu.com/archives/natty-changes/2010-December/date.html )
<bjsnider> well, dumping the modalias package is fine by me
<bjsnider> i wonder if it's possible to move all of nvidia-common into jockey and then just have jockey and the drivers
<bjsnider> of course that's not the way debian does things, they have to have separate packages for every little thing
<Sarvatt> hmm guess we could build lib32vdpau in the PPA so people can get flash acceleration on amd64, I'm totally stumped on what to do with it in the archive though
<soreau> Sarvatt: Awesome, thanks.
#ubuntu-x 2010-12-19
<RAOF> Sarvatt_: Yeah, saw the new version, won't pull it into the testing packages until there's something applied upstream.  The testing packages have the GLXDrawable refcount fix pulled, too, so shouldn't suffer from the crash.
#ubuntu-x 2011-12-12
<bjsnider> Sarvatt, i am looking into mplayer-vaapi and it seems the mplayer devs have nothing but contempt for vaapi
<bjsnider> i don't think it's going to be merged anytime soon
<bjsnider> so people will have to go and grab gbeauchesne's version of mplayer to use it
#ubuntu-x 2011-12-13
<Sarvatt> cnd: is there any way i can help with the input backport? would it make it easier to have an updated ubuntu+1 branch in git thats updated with later 1.11 stuff and actually builds? do you think it's a realistic goal still? I feel like its getting too late atm because peoples worlds could possibly be broken and they expect precise to have no problems but it might be totally unfounded :)
<Sarvatt> RAOF: we need a non-virtualized ppa to pocket copy to the archive dont we? how does that happen? it needs to builds on arm/armhtf/powerpc on top of what ppas build for im sure dto do the binary copy
<Sarvatt> to do the abi transition in a ppa so things arent broken
<Sarvatt> doing the whole transition in a ppa and copying to the archive will break armhf/armel/powerpc because the xserver-xorg-dev requirements wont be bumped to let it depwait then rebuild for most stuff and will be rebuilt against the wrong abi i imagine on those arches
<RAOFer> Sarvatt: Yeah, I guess we will need a non-virtualised PPA.
<Sarvatt> RAOFer: got a ppa in mind?
<Sarvatt> can see if i can get one non-virtualized so stuff builds on all arches
 * Sarvatt will file an rt ticket
<RAOFer> Ta muchly.
<Sarvatt> point me at a ppa, dont think ubuntu-x-xswat/x-updates makes much sense because we put other stuff there
<Sarvatt> x-testing?
<RAOFer> We should probably make a new one; x-staging
<RAOFer> Hm.  But I seem to have forgotten how to actually create a new PPA :)
<Sarvatt> done, cool beams
<Sarvatt> beans too
<Sarvatt> https://launchpad.net/~ubuntu-x-swat/+archive/x-staging :)
 * RAOFer was imagining a cooling laser.
<RAOFer> Sarvatt: Have you found i915/GM45 unstable on Precise recently?
<Sarvatt> on precise? no
<Sarvatt> on intel 2.17.0/libdrm 2.4.28 which i held off updating because of the bugs yeah :)
<Sarvatt> 3.2 problem?
<RAOFer> Maybe.
<RAOFer> It seems to like kernel oopsing.
<Sarvatt> gotta admit i havent paid attention to my only machine in those specs with precise userspace so im not sure
<RAOFer> :)
<Sarvatt> i've been hitting an oom problem on everything else with git userspace
<Sarvatt> sandybridge/ivybridge
<RAOFer> Hm.  Did that cause it to oops somewhere in drm_mm_foo?
<Sarvatt> no no oops it always triggered corruption and gigabyte+ /var/log/Xorg.0.logs full of repeating messages of oom errors
<RAOFer> Bah!
<RAOFer> Stupid oopses, making writing to disc silently fail!
<RAOFer> I'm all like "Hah!  I shall dmesg > the-damn-thing-OOPSed.log and come back to it later".
<RAOFer> And then later it's all like "I don't know what you're talking about officer"
<RAOF> cnd: Yeah, if you'd like an updated ubuntu+1 branch give a hoy.  It should build as it stands, though :)
<Sarvatt> i dont think it builds, patch 221?
<Sarvatt> or 220
<Sarvatt>         drop 210_pixman_null_ptr_check.patch fails
<Sarvatt>         drop 220_xi21_always_deliver_raw_events.diff fails
<Sarvatt> 220 still enabled and doesnt work, 210 fails with later x 1.11 checkouts
<RAOF> Hm.
<Sarvatt> RAOF: sooo, https://launchpad.net/~ubuntu-x-swat/+archive/x-staging *should* build all arches now :)
<RAOF> Nice.
<Sarvatt> that was surprisingly easy
<Sarvatt> easy enough where if we upload something and it doesn't trashing it and making another would be trivial
 * Sarvatt didn't file any rt tickets
<Sarvatt> boss disabled the "virtual builders" requirement on the ppa, i'm not sure if that does what we want but sounds right
<RAOFer> It does, doesn't it.
<Sarvatt> roll around on fire er?
<RAOF> *Run* around on fire, thank you! :)
<Sarvatt> wait RAOF is on a canonical IP, ya using a canonical server as a bouncer?
<RAOF> Yup.
<Sarvatt> WHAT!
<Sarvatt> which? :)
<RAOF> A canonistack instance.
<Sarvatt> ohh gotcha
<RAOF> Running a shiny new smuxi instance.
<RAOFer> Bah.
<RAOFer> Bye bye, GM45.
<RAOFer> This, by the way, is why there's a RAOFer.
<RAOFer> It won't even have dropped any useful debugging info to disc.
<RAOFer> Stupid thing!
<Sarvatt> sorry in advance becuase it was the libdrm 2.4.27 upgrade that caused it
 * Sarvatt TIL
<RAOFer> Oh, 2.4.27 is to blame?
<Sarvatt> that was like the only change outside of the kernel between precise and oneiric
<RAOFer> Yeah, but the kernel freezing hard is ultimately a kernel problem :)
<Sarvatt> 3.0 is so darn good for drm at this point, i'm still living on it
<Sarvatt> sent 6 commits to stable in the past 2 weeks, all the good stuff without the pain :)
<Sarvatt> ivybridge is great on 3.0 now, 3.2 is all kinds of screwed up
<RAOFer> Heh.
<Sarvatt> intel guys are living in 3.3 and dont send stuff to stable, 3.2 is kinda in limbo until it releases from what i see but thats very opinionated
<Sarvatt> stuff cced to stable now is whats supposed to go into 3.2 even if 3.2 isnt a stable release
<tjaalton> hmm, fedora17 will drop dri1 drivers
<tjaalton> not a huge surprise, just an observation
<tjaalton> actually, we'll have that for precise too, since upstream has dropped them from 8.0 :)
<RAOFer> Yup
<Sarvatt> tjaalton: rhel 7 wont though? :P
<tjaalton> Sarvatt: that's years off :)
<tjaalton> so likely will
<Sarvatt> tjaalton: recovered from the concert now? :)
<tjaalton> Sarvatt: hehe, yeah.. was great :)
<tjaalton> we drove there, so only had one beer there
<tjaalton> RAOFer: so is there something packaging wise I could do to help get the new stack in precise?
<Sarvatt> which new stack?
<RAOFer> 1.11
<RAOFer> I presume.
<tjaalton> that
<Sarvatt> mesa 7.11?
<Sarvatt> oh ok
<tjaalton> well mesa too
<Sarvatt> yea i feel the same way
<tjaalton> actually I could test mesa master on the sis crap
<tjaalton> if llvmpipe is any faster 
<Sarvatt> mesa's gonna need some love with the new source package shipping dri1 drivers from 7.11 crap
<RAOFer> Won't the answer be "We killed DRI1, suckas!"
<tjaalton> Sarvatt: no way, drop dri1 i say
<tjaalton> :)
<Sarvatt> they're going out of their way to still support dri1 drivers even though they are dropped from 8.0..
<Sarvatt> even if fedora wont rhel will later
<RAOFer> Maybe.
<tjaalton> in practice though, they haven't really been supported for years
<RAOFer> To what extent do the existing DRI1 drivers actually run GNOME3 or Unity?
<tjaalton> and seems like fedora/rhel7 will put effort in making llvmpipe more capable
<tjaalton> RAOFer: they don't, llvmpipe supports opengl 2.x so it's better
<Sarvatt> to what extent do they play openarena or use blender better than swrast? lots..
<Sarvatt> if you're using that old crap llvmpipe doesnt really help
<RAOFer> The fact that they don't support GNOME3 or Unity means that, at best, they're not well supported.
<RAOFer> Yeah, llvmpipe doesn't really scream "make old hardware more usable" to me.
<tjaalton> well, if you're using old crap they are still crap no matter which driver you use :)
<Sarvatt> who sticks a sis in a system that doesnt support sse2 where llvmpipe is faster
<tjaalton> Sarvatt: who runs openarena on one?
<Sarvatt> very true :)
<tjaalton> the point is likely just "get a session going"
<Sarvatt> like mga has been busted on compiz for years
<Sarvatt> i dont think it ever passed the unity check though but thats unrelated, having accelerated 3d regardless of using unity-2d would be helpful in some situations
<RAOF> Yeah, it's kinda helpful.
<RAOF> It's a "we won't do anything to deliberately break it" kinda helpful, though.
 * RAOF â birthday dinner.
<Sarvatt> so like airlied and ajax were the ones making sure the dri1 interface works still at the time, i really think it'd be work packaging 7.11 dri drivers even if i do it, no worries
<Sarvatt> birthday?! happy birthday RAOF!
<Sarvatt> or happy birthday to the person you are celebrating for if i misunderstood :)
<tjaalton> http://fedoraproject.org/wiki/Features/DRI2DriversOnly
<tjaalton> that suggests that having dri1 drivers around would need "very convincing arguments"
<LetoThe2nd> good morning! is there a known reason why powering off (e.g. unplugging) the screen will cause the xserver to crash?
<jcristau> power off != unplugging.  in any case, if X crashes, that's what they call a bug.
<LetoThe2nd> jcristau: i mean hard power off, not pressing the standby button. the x stays alive when i just do that.
<RAOFer> Bah.  i915!!!!!!
 * RAOFer suddenly realises why other people really hate it when the graphics stack is unstable.
<garaman> RAOFer: I'm here hoping to hear news about the random lag I get with Nvidia drivers in Unity (Quadro NVS 290 in TwinView)
<sil2100> Hi!
<sil2100> I'm a complete X newbie and I would need some help, since I need this for preparing a specific package
<sil2100> Is there a way I could get info about the xserver current video ABI on the system?
<sil2100> In the past, around natty, there was that videoabiver file which is now deprecated
<sil2100> But in the newer versions?
<sil2100> I would be grateful for some pointers
<jcristau> what are you trying to do?
<sil2100> I need my package to install selected binary drivers basing on the ABI version
<sil2100> Since there's a different driver version for every ABI
<jcristau> ewww.
<sil2100> Yep, I was thinking the same thing
<sil2100> ;)
<inetpro> hi
<inetpro> anybody willing to look at my nVidia GT215 bug on launchpad? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/897436
<ubot4> Launchpad bug 897436 in xserver-xorg-video-nouveau (Ubuntu) "Screen corrupted without nomodeset on nVidia Corporation GT215 [GeForce GTS 360M] (affects: 1) (heat: 11)" [Undecided,New]
<tjaalton> inetpro: try a mainline kernel, for instance this one http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-rc4-oneiric/
<tjaalton> and get rid of nvidia before booting it
<tjaalton> the driver, that is
<inetpro> tjaalton: you mean that as a temporary solution?
<inetpro> or do you mean I should test that to confirm whether this new kernel fixes it?
<inetpro> sorry, I may be a bit new to your processes of troubleshooting it
<tumbleweed> the latter
<inetpro> ahh
<inetpro> to be honest I don't have the laptop with me right now but will try that in a few hours time
<tjaalton> yes, the driver is in the kernel
<inetpro> cool, I'll let you know how it goes later
<inetpro> and then I guess I should also try precise alpha / daily CD
<tjaalton> it has the same kernel
<inetpro> I hope that kernel is in there as well?
<inetpro> ahh
<inetpro> sounds great
<tjaalton> you can just try the live image and report back
<inetpro> thanks tjaalton
<FernandoMiguel> boa tarde 
<cnd> RAOF, I'm currently trying to create a patchset for backporting xserver input subsystem master into 1.11
<cnd> just fyi
<RAOF> cnd: Sweet.  Anything I can do for you?
<cnd> RAOF, let me go through what I'm trying to do
<cnd> my idea is: backport everything that is input related from master on top of the 1.11 stable branch
<cnd> I started doing that, but found one general API/ABI break: options parsing
<cnd> so I left that out
<cnd> I now have a branch with a backported server
<cnd> I'm going to make sure it compiles and runs
<cnd> and then I'll package it up and push it to ppa:utouch-team/xorg-unstable
<cnd> I'm going to assimilate things in there
<RAOF> And then I'll pull those patches onto ubuntu+1, push it into the staging PPA, and rebuild the world against it.
<RAOF> ?
<cnd> that's one possibility
<cnd> I don't want to be redoing work twice unnecessarily
<cnd> but I don't know how I can do everything we need for the input side without being the one who brings up the server for precise
<RAOF> Yes!
<cnd> RAOF, have you made any changes to the server packaging or added patches in your 1.11 tree?
<RAOF> No; just the forward ports of input stuff.
<RAOF> Locally, because they don't work properly :)
<RAOF> Oh, and I've pulled in a more recent merge from Debian.
<cnd> ok
<cnd> so I'm going to try to bring up the xserver today and tomorrow
<cnd> make sure input modules work
<cnd> and try out running with the binary nvidia and fglrx drivers that are already released for 1.11
<cnd> I assume they are already released...
<RAOF> They are, yes.
<RAOF> I'm perfectly happy for you to bring up the server for precise; we'll be staging it in https://launchpad.net/~ubuntu-x-swat/+archive/x-staging
<cnd> I'm off from the 15th through the 19th, so hopefully I'll have things in a state where you can work with it
<cnd> RAOF, perhaps I'll bring up the server without XInput multitouch first
<cnd> and push it to the x-staging ppa
<cnd> and keep the multitouch stuff in the utouch-team/xorg-unstable branch for now
<cnd> sound good to you?
<ricotz> oh :)
<RAOF> That seems fine to me; the x-staging server will have the rest of the 1.12 input stack, though?  Just not the multitouch work?
<cnd> yeah
<ricotz> cnd, hi, are all input patches you are backporting in xserver master already?
<cnd> ricotz, everything I have backported so far are, yes
<cnd> it doesn't include any of the XI 2.2 multitouch patches
<RAOF> cnd: Would you like widespread (ie: pushing to the distro) testing of that, before adding multitouch?  Does Unity work without multitouch yet?
<ricotz> cnd, ok
<cnd> RAOF, if unity doesn't work without multitouch yet, please ping bregma and/or DBO
<cnd> pushing the server to distro without multitouch would be really helpful, but only after it has soaked in x-staging for a bit and we have covered all the main modules
<RAOF> We wouldn't push the server from x-staging to the distro until everything's been built against it.  Then we'll pocket-copy.
<cnd> ok
#ubuntu-x 2011-12-14
<cnd> RAOF, I tried merging my stuff into the debian-unstable packaging branch to make a package of my server
<cnd> but I get the following: http://paste.ubuntu.com/769629/
<cnd> I have to leave for the day, but if you have some spare cycles I'd appreciate if you could help me out with it
<cnd> thanks!
<RAOF> cnd: Looks like you've missed dropping the libaudit-dev selinux stuff, off the top of my head.
<inetpro> tjaalton, tumbleweed: after downloading the latest daily build last night and zsyncing this morning I burnt it to usb and just tried it out
<inetpro> unfortunately I still get the screen with the big white blocks
<inetpro> for the record, the daily build was downloaded from http://cdimage.ubuntu.com/daily-live/current/precise-desktop-i386.iso.zsync
<cnd> RAOF, so I just need to drop that from the control file and everything will be peachy?
<tjaalton> inetpro: ok
<tjaalton> RAOF: do you have the changes to -savage stashed in your local tree? :)
<RAOF> Do I have changes to -savage? :)
<tjaalton> pushed to natty at least :)
<tjaalton> hmm
<tjaalton> wait
<tjaalton> right, the ubuntu branch is missing a couple of changes
<RAOF> Yes indeed.
<RAOF> It's actually missing those changes localy, too.
<tjaalton> hehe, ok
<tjaalton> i was just looking if it could be synced
<RAOF> Looks like the answer is yes.
<tjaalton> bz.kernel.org doesn't seem to work
<jcristau> kernel bugzilla has been down since the compromise
<tjaalton> oh ok
<tjaalton> who needs it anyway..
<tjaalton> ricotz: apparently libwacom will be used by the driver too, it's the only place where tool/id handling in being done (in the future)
<ricotz> tjaalton, this sounds reasonable
<mistertim_> Hi there all -would anyone be able to advise me on a slightly mysterious xorg problem I'm having? After running an apt-get upgrade yesterday, my machine's refused to load the xserver-xorg-video-intel driver. I'm using the xorg-edgers PPA, but removing this and downgrading hasn't helped either.
<ricotz> tjaalton, so you think it fits into pkg-xorg?
<tjaalton> ricotz: maybe ron will take it when -wacom needs it
<ricotz> mistertim_, you should pastbin your Xorg.0.log which might contains something useful so someone can look at it
<tjaalton> ricotz: in the meantime I'll push it to my local repo, which will be writable by pkg-xorg like the -wacom one
<ricotz> tjaalton, ok
 * ricotz isnt member of pkg-xorg
<mistertim_> ricotz: no problem, here you go: http://pastebin.com/iUkZsAyg. Here's the output of lshw -c video, note output of driver=i915 in configuration line: http://pastebin.com/HykfCffs
<mistertim_> thank you!
<mistertim_> s/output of/absence of/
<jcristau> mistertim_: you're disabling kms.  don't do that.
<mistertim_> jcristau: aah! I thought I'd re-enabled it
<mistertim_> I removed nomodeset and i915.modeset=0 from /etc/default/grub
<mistertim_> hmm: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pcie_aspm=force"
<jcristau> run update-grub
<mistertim_> very odd. Is there anywhere else it might be picking up those options from?
<mistertim_> jristau: aah, d'oh.
<mistertim_> thank you!
<mistertim_> jcristau: that did the trick, thankyou!
<mistertim_> ls
<popey> What ho x lovers.
<popey> Given an install of Ubuntu on a portable device such as a USB stick, where nvidia-current has been installed to support ION hardware, with no xorg.conf configured. Taking the USB stick to another non-nvidia system (e.g. intel) causes the 'wrong' glx libs to load. 
<popey> Is there any way (other than removing nvidia binary driver) to not let that happen? So a stick works seamlessly auto detecting and doing glx lovelyness on any card ?
<broder> popey: without having tested this at all, dropping http://paste.ubuntu.com/770234/ into /etc/init/glx-detect.conf may do something reasonable
<broder> but the logic in there is pretty fallible (e.g. hybrid graphics systems)
<Sarvatt> popey: outside of an upstart script that calls update-alternatives/ldconfig on the fly at boot which will make people complain about boot speed problems, not really
<Sarvatt> oh cool broder already did it :)
<popey> You guys rock. 
<broder> it's just a modification of the one i sent out to ubuntu-x :)
<popey> This is for a demo, so doesn't need to be for public consumption
<broder> oh yeah - it does need to call ldconfig, too
<broder> ...hmm, is gl_conf out of date? looks like its x86_64-linux-gnu_GL.conf now
<Sarvatt> hmm that upstart script would be messed up on an nforce chipset without an nvidia gpu too, and lspci -n is needed
<broder> bah, i was testing with lspci -n
<broder> lspci -n | grep '03..: 10de:' should work
<broder> if you want to do better than that i think you need my C helper to find the boot VGA device
<Sarvatt> maybe -nn and grep for VGA and 10de, ion might be on another pci domain than 03
<Sarvatt> err pci bus rather
<broder> i was trying to match the 2nd column - i thought that was the class/subclass
<broder> looks like X would consider anything with class 00??, 03??, 0400, or 0b40
<Sarvatt> 02:00.0 VGA compatible controller: nVidia Corporation ION VGA (rev b1)
<jcristau> in a script you want lspci -mn i guess.
<broder> what's that with -n?
<jcristau> and look for $2 == 0300 && $3 == 01de for vga/nvidia
<Sarvatt> don't know, i got that ion one from google, and awesome jcristau thats perfect
<Sarvatt> broder: sorry I see what you were talking about now with the [0300]
<jcristau> broder: the kernel tells you in sysfs what the boot vga device is
<jcristau> (/sys/bus/pci/devices/*/boot_vga)
<jcristau> or does that not work?
<broder> jcristau: oh, hmm. i didn't know about that node. i just stole some libpciaccess code from x - didn't look at how it worked
<broder> but it does look like that's all pciaccess is doing
<broder> so maybe i can do this all from shell
<broder> RAOF: did you ever check whether boot_vga=1 on both GPUs on your AMD hybrid laptop?
<broder> (it looks like the ubuntu-x thread got side-tracked before you had a chance to test that)
<cnd> RAOF, my current method is:
<cnd> 1. reset ubuntu branch to debian-unstable
<cnd> 2. merge in upstream input commits
<cnd> 3. modify package as needed for ubuntu
<cnd> perhaps I should be starting from something other than debian-unstable?
<cnd> RAOF, do you think there's any issue with uploading a new x11proto-input to precise with version 2.1.99.3?
<cnd> everything is backwards compatible, and it would help speed the entire process
<cnd> I already have the package built in ppa:utouch-team/xorg-unstable
<RAOF> cnd: No, I don't think that'd be a problem at all.
<cnd> RAOF, is my process above reasonable?
<cnd> for creating the server package
<RAOF> I'd probably start on the ubuntu+1 branch; I can update that to debian-unstable for you if you'd like.
<cnd> RAOF, sure, that would be great
<cnd> RAOF, actually, how do you update it to debian-unstable?
<cnd> I'm basically missing the instructions for how to do that step
<RAOF> git merge origin/debian-unstable, basically.
<cnd> I've got the server built using my method, so I know it's just a matter of getting it working
<cnd> ok
<RAOF> Then resolve conflicts.
<cnd> I'll try that
<cnd> and let you know if I have any issues
<RAOF> Awesome.
<cnd> RAOF, when I try to merge debian-unstable, I get a ton of conflicts in the source itself
<cnd> I think many patches are cherry-picked directly into the source
<cnd> which is causing issues
<cnd> how do you handle that?
<RAOF> Oh!  You're not starting from ubuntu+1, are you.\
<cnd> oh crap
<cnd> sorry!
<broder> RAOF: did you see my earlier ping about your hybrid AMD laptop?
<cnd> RAOF, how do you merge debian/changelog?
<RAOF> broder: Yeah.  I *think* I did check, but I'll give it another whirl.
<RAOF> cnd: echo "debian/changelog merge=dpkg-mergechangelogs" >> .git/info/attributes
<cnd> uhhh... what does that do?
<cnd> and do I do it before or after the merge command?
<broder> RAOF: you know you can also have a .gitattributes file in the repository, right?
<RAOF> Sets the external merge driver for debian/changelog to be dpkg-mergechangelogs.  After you've set that, git merge will handle debian/changelog nicely.
<cnd> oh cool!
<RAOF> broder: No, I did not.  Hm!
<broder> i think you could just drop in a debian/.gitattributes
<cnd> RAOF, that didn't seem to help any :(
<RAOF> That's odd.
<RAOF> I've just now done a "git merge origin/debian-experimental" in the ubuntu+1 branch and only got a trivial conflict in debian/rules.
<cnd> I'm trying with debian-unstable
<cnd> which seems to be what we want
<RAOF> Ahem.  Indeed.
<RAOF> That's what I meant. :)
<cnd> RAOF, nm, I realized I had a stale debian-unstable local branch
<cnd> that's probably my issue
 * RAOF hates that part of git
<cnd> I tried the .gitattributes part
<cnd> no dice
<broder> i haven't played with attributes a whole lot - i was just going off of gitattributes(5)
<broder> might be something i'm missing
<cnd> argh, RAOF, still not working
<cnd> is there some output I should be seeing during the merge?
<cnd> cndougla@cndougla:~/Canonical/ubuntu/xorg-server/xorg-server$ git merge origin/debian-unstable
<cnd> Auto-merging debian/changelog
<cnd> CONFLICT (content): Merge conflict in debian/changelog
<RAOF> http://paste.ubuntu.com/770621/ is what mine says.
<RAOF> And http://paste.ubuntu.com/770623/ is my .git/info/attributes file.
<cnd> hmm
<RAOF> The warning is because there's a malformed changelog entry somewhere deep in the depths of xorg-server history.
<cnd> RAOF, have you fetched the very latest from the git repo?
<cnd> I wondered if that would be the issue, but I don't even get dpkg-mergechangelogs
<cnd> so nm
<RAOF> You, of course, have dpkg-dev installed, right?
<cnd> yeah
<cnd> I've got the utility
 * RAOF dunno
<cnd> RAOF, what version of git are you running? :)
<cnd> 1.7.5.4 here
<cnd> from oneiric
<RAOF> 1.7.7.3 from precise.
<RAOF> But it worked for me in oneiric :)
<cnd> ok
<cnd> RAOF, I think I was able to call dpkg-mergechangelogs manually :)
<RAOF> :)
<cnd> it looks sane to me
<broder> there's not currently a reasonable way for me to map a PCI device -> the value i should be setting x86_64-linux-gnu_gl_conf et al. to quickly, right?
<RAOF> cnd: Oh, you'll need to drop 220_xi21_deliver_raw_events if you haven't noticed that already.
<cnd> hadn't yet
<RAOF> broder: The numeric value?  No.  That value isn't stable; it depends on order of installation.
<broder> RAOF: no, the filename. i'm working on my hybrid cleanup script
<cnd> RAOF, was that a patch you wrote?
<RAOF> cnd: No; a backportish of something which I think is actually in 1.11 anyway.
<cnd> ok
<RAOF> Hm.  Doesn't actually seem to be in 1.11.  But 1.12, and it's a part of the input stack, so yay!
<cnd> RAOF, so I have a branch called upstream-1.11+input
<RAOF> broder: You should be able to match PCIIDâvendor pretty easily, and then it's pretty easy to match vendorâfilename, right?
<cnd> I can do a git merge of that branch
<cnd> or I can create a big diff and plop it into debian/patches
<cnd> what do you think is the best option?
<RAOF> What will be easiest for you to work on?
<RAOF> I suspect that would be a git merge, right?
<cnd> I like the git merge way because it leaves all the commits and merges available for further investigation
<cnd> but I don't know if that will throw a wrench into further merging from debian-unstable
<broder> RAOF: probably. i'd rather do it based on modalias or something, so i don't, e.g., turn on fglrx's libGL on hardware that's only supported by -ati/-radeon
<cnd> or any other workflows
<broder> RAOF: i'm thinking of requiring drivers that use update-alternatives to swap libGL also drop a file somewhere with a list of modaliases i can check against
<RAOF> cnd: It's only going to interfere if there are conflicting changes in debian-unstable, right?  And in that case, it's probably easier to learn of them at git merge time than at quilt apply time.
<cnd> yeah
<cnd> ok
<RAOF> bryceh may have a different opinion, though ;)
<cnd> well, I'm not pushing it to the archive yet :)
<cnd> RAOF, do you think we should name the package version something like 1.11.2.902+input-0ubuntu1?
<cnd> or just leave it as 1.11.2.902-1ubuntu1
<RAOF> In the past we've just done the equivalent of 1.11.2.902-1ubuntu1; that would be fine by me.
<cnd> ok
<cnd> RAOF, merging debian-unstable into ubuntu+1 is a much saner way of doing things :)
<cnd> I'm running pdebuild right now
<RAOF> :)
<cnd> I spent a few hours trying to find an automated way of creating the backport
<cnd> various ways of calling git log on specific files and directories
<cnd> but nothing worked quite right
<cnd> in the end I just manually audited all the commits/merges into upstream master
<cnd> took me an hour or two, but it was much faster
<cnd> and I'm much more confident of the results
<cnd> RAOF, just a heads up, we will need to coordinate with kubuntu and libavg when we upload the new server
<cnd> it will need a Breaks for qt and libavg
<bryceh> RAOF, git > quilt.  Large patches are ok for initial packaging but can be a PITA for future maintenance.
<RAOF> cnd: Ah, because it's a proto break?
<cnd> yeah
<cnd> libxi will need Breaks too
<RAOF> cnd: What's the ETA for compatible libqt?
<cnd> RAOF, I haven't started on it yet
<cnd> I have to get a server that works first :)
<RAOF> Fair call.
<cnd> but it will be one of my next tasks to get to
<cnd> libavg upstream is very responsive and is maintaining their packaging
<cnd> I think they'll be able to handle stuff on their own
<cnd> they wrote their own implementation in the first place :)
<RAOF> So, I think this means we'll need to stage Qt in the PPA first; breaking that will break the CDs, and that's a no-no.
<cnd> yeah
<cnd> libavg is in universe and is unseeded btw
<RAOF> Yeah; that doesn't need staging.
<cnd> RAOF, so I'm hoping to have xorg-server uploaded to the staging ppa
<cnd> I don't think I'll be getting to any of the input modules
<cnd> well, any of the modules
<cnd> they'll all need updating for at least 1.11
<RAOF> I can happily upload all the video drivers.
<cnd> can you also upload the 1.11 series input modules?
<RAOF> Yup.
<cnd> I think there shouldn't be any api or abi breaks
<cnd> just additions
<RAOF> Minus synaptics and evdev?
<cnd> I'm off after today
<cnd> I'll be back tuesday
<RAOF> They'll need XI2.2 patches, right?
<cnd> you should be able to upload the 1.11 synaptics and evdev
<cnd> for right now I don't want to worry about XI 2.2
<cnd> I want to ensure the server actually works with the backports
<RAOF> Oh, yeah!  That's right.
<RAOF> It's just the 1.12 input stack, not with multitouch.
<cnd> there are two issues:
<cnd> 1. is it stable
<RAOF> EBRIANFART
<cnd> 2. did I nick any of the video ABI/API
<RAOF> Yup.  So we'll just drop all the multitouch input patches from the input drivers for the first pass.
<cnd> yeah
<cnd> RAOF, really we should just take what's in debian/unstable
<RAOF> Yeah, most of them should be syncs.
<cnd> the inputproto I uploaded was entirely rebased on top of debian's package
<cnd> I left a branch called ubuntu-oneiric
<cnd> but the ubuntu branch has no relationship with it other than an ancestor
<cnd> I think we might as well do similar for synaptics and evdev
<cnd> if you have stuff on your plate, I'm happy to do this when I get back
<cnd> but I just wanted you to know I'll be out in case you were interested and had time to help out
<RAOF> I should be able to do this in the immediate future.
<cnd> cool
<broder> ugh, the blah-linux-gnu_gl_conf alternatives are really unfriendly to arch-agnostic scripting
<cnd> \o/ the server built
<cnd> RAOF, should I rename the ubuntu branch to ubuntu-oneiric, and reset the ubuntu branch to what I've just created?
<cnd> two other questions: what's the location of the staging ppa again, and do we use a standard suffix for versions like ~x-staging1
#ubuntu-x 2011-12-15
<RAOF> cnd: Can you keep the git branch called ubuntu+1 for now, and you don't need to use a standard suffix.  Treat the staging PPA as the main archive, just delayed :)
<RAOF> cnd https://launchpad.net/~ubuntu-x-swat/+archive/x-staging
<cnd> RAOF, ok, I'll be uploading xorg-server_2:1.11.2.902-1ubuntu1
<RAOF> bryceh: Could you add cnd to ~ubuntu-x-swat?
<cnd> does that look right?
<cnd> just double checking :)
<RAOF> That looks right to me, yes.
<bryceh> sure
<bryceh> looks like someone beat me
<RAOF> Cool ;)
<cnd> RAOF, xorg-server has been accepted into ppa:ubuntu-x-swat/x-staging
<cnd> reminder that I completely have not tested the code base :)
<cnd> it's *your* fault if your input devices catch on fire :)
<RAOF> cnd: Excellent!  I'll start throwing drivers at it.
<RAOF> Hah.  The way my hardware luck's going, *they will*
<cnd> hooray! It's built
<RAOF> Let the wave of babies begin!
<Sarvatt> cnd: who needed pinging about unity not working again with it because of libutouch-geiss?
<RAOF> DBO or bregma
<cnd> Sarvatt, it's either an issue with the utouch stack, or an issue with unity misusing it
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/860707 comment #5 will be whats hit with whats in there
<ubot4> Launchpad bug 860707 in unity (Ubuntu) (and 1 other project) "Unity crashes when started in an environment without utouch support (affects: 58) (dups: 2) (heat: 284)" [High,Confirmed]
<Sarvatt> unity side was fixed
<cnd> then bregma would be the one
<Sarvatt> by http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/1728#plugins/unityshell/src/GeisAdapter.cpp
<cnd> Sarvatt, that unity code doesn't look right to me...
<cnd> wait, nm
<cnd> read the diff wrong
<Sarvatt> i worked around it locally by ripping geis support out of unity so maybe its still a unity bug
<Sarvatt> "ripping geis support out" == commenting out 2 lines..
<cnd> Sarvatt, it looks like unity is still trying to use geis
<cnd> even when it's not supported
<cnd> otherwise it shouldn't be calling geis_configuration_get_value
<cnd> so DBO or MacSlow (Mirco, who wrote that commit) should be pinged
 * cnd is opening the code to peek
<Sarvatt> http://sarvatt.com/downloads/patches/byegeis.patch was what was needed
<cnd> Sarvatt, GeisAdapter::_root_instance is never initialized
<cnd> it must be initialized to nullptr
<cnd> Sarvatt, can you follow up on it?
<cnd> I'm on vacation now through  monday
<Sarvatt> should be easier with this ppa, ppa-purge is busted with multiarch so it took me a few hours to switch fixing it up when i was doing it in edgers
<cnd> Sarvatt, I would suggest hitting MacSlow with a clue-by-four to get it resolved :)
<cnd> you can leave bregma and DBO unharmed
<Sarvatt> cnd: yeah sorry to bug ya on vacation man, was just picking your brain trying to find out who to bug :)
<cnd> well, technically I am still working for 15 mins :)
<cnd> I just can't follow up on it
 * Sarvatt is on vacation now too, i know how it goes :)
<cnd> ahh, ok
<cnd> I can send an email right now then
<cnd> yeah, I'll just do that
<cnd> Sarvatt, I updated the bug with all the info, hopefully that's enough to see it through
<Sarvatt> ya asked me before and i didn't follow through because reproducing it with edgers is really a pain in the ass, i'm really sorry about that man
<Sarvatt> thanks :)
<cnd> Sarvatt, np :)
<cnd> if I had looked closely enough it would have been obvious
<cnd> should have done it sooner
<Sarvatt> edgers was broken for 2 months because i didn't comment out 2 lines of code, i know the feeling
<Sarvatt> so let me get this straight, we're never going to be able to update xserver at a decent schedule anymore because fglrx taking 3 months to adapt to new abis and breaking unity with fglrx isn't an option because DX uses them?
<Sarvatt> only the xserver releases where xserver releases 3 months before 2 months before final freeze
<RAOF> Sarvatt: No, this is a one-time (or at least LTS-only) deal; it was quite clear in the sessions at UDS that âuse an open-source driverâ is an acceptable work around.
<Sarvatt> the +1 will work at all times effort doesn't seem LTS only though
<Sarvatt> oh ok
<bjsnider> is the radeon driver a good alternative to fglrx at this point?
<Sarvatt> very much so
<Sarvatt> especially for the desktop where it works much better than fglrx
<Sarvatt> xv is busted on fglrx in the december release, people using it get to wait a month for a fix
<bjsnider> doesn't say much for amd
<Sarvatt> agreed :)
<bjsnider> it works "much better"?
<bjsnider> that's mind-boggling
<Sarvatt> MUCH
<Sarvatt> so much better it isnt funny, they keep implementing things like the tearing fix which is broken and it takes them a month to fix what they break
<bjsnider> does opengl work much better in radeon?
<Sarvatt> they work on 3 monthly branches at a time, fixes go in the newest one, if its really important it might make release+1 version but usually not
<Sarvatt> and for the past year its been working very bad imo
<Sarvatt> there are no stable updates so you are guaranteed to have to wait a month for a fix if somethings broken
<Sarvatt> (at least)
<Sarvatt> more likely 2, worst case 3
<Sarvatt> bjsnider: for games sure
<Sarvatt> thats what i care about so i'd have to put up with it
<Sarvatt> but if you just care about the desktop the open source ones are a much better option
<bjsnider> for games fglrx is the better option?
<Sarvatt> sane as nvidia, yeah much
<Sarvatt> s/sane/same/
<bjsnider> well, i guess that's what the firegl customers care about
<bjsnider> opengl
<Sarvatt> firegl customers care about professional 3D apps
<bjsnider> and that's the only thing fglrx does well i guess
<Sarvatt> and yea thats much faster, thats what fglrx was even released for, not much to do with a windows game in wine :P
<bjsnider> what about mobile chips?
<RAOF> If we can enable float textures & add libdxtn, radeon & intel should be reasonable for wine games, too.
<Sarvatt> bjsnider: what about mobile chips? they're usually just a speed bump behind desktop ones
<RAOF> Dunno about nouveau, but probably ok too.
<Sarvatt> nouveau scares me
<bjsnider> i meant that you qualified your remarks by saying that radeon is much better on desktops, as if mobile stuff was different
<Sarvatt> its broken on lots of crap, especially in mesa
<Sarvatt> bjsnider: nope mobile/desktop doesnt make a difference, its better for unity on everything
<RAOF> It *is* much harder to recommend nouveau over nvidia than it is to recommend radeon over fglrx :)
<Sarvatt> RAOF: we hit so many problems and have noone to escallate bugs to
<Sarvatt> QA runs tests against nouveau, suspend/resume is completely busted
<bryceh> actually we did meet the nouveau devs at the X conference, and can escalate to them
<bryceh> it's just that it's fairly hard for them to solve bugs
<bjsnider> there's a public bug tracking system for nouveau isn't there?
<bryceh> yes
<Sarvatt> nouveau devs = darktama though, escallating bugs to another distro for unreleased hardware?
<Sarvatt> for mesa when he works on the kernel mostly?
<bjsnider> why is it fairly hard for them to solve bugs?
<bryceh> bjsnider, lack of access to register documentation
<bryceh> bjsnider, and lack of man power for reverse engineering
<bjsnider> there hasn't been any amd documentation in 3 years i think
<bryceh> bjsnider, true but AMD employs several of the -ati developers who (AIUI) can get some insider info as a result
<Sarvatt> nouveau to me is really done on a best effort basis, we really rely on the vendors a lot to fix bugs on unreleased stuff which i work on
<bjsnider> that doesn't inspire a lot of confidence in nouveau
<bjsnider> what happens when everybody and their dog wants to switch to wayland? you need nouveau for that
<RAOF> Eh.  Suspend/resume is broken with nvidia, too :)
<Sarvatt> RAOF: there's always a corner case, for the most part it shouldn't be though
<Sarvatt> aka for crap thats certified its definitely not
<RAOF> Well, my experience with nouveau has tended to include working suspend/resume.  Even on this t420s (before it stopped POSTing â¹)
<Sarvatt> wait, nouveau?
<Sarvatt> thats specifically the platform i'm saying suspend/resume is broken on nouveau on :)
<RAOF> Sarvatt: It was working for me at one point, then it stopped working.  But it stopped working on nvidia at the same time :)
<Sarvatt> hmm
<Sarvatt> precise?
<Sarvatt> just curious because thats gonna be a huge problem if it is
<Sarvatt> so those systems shipped with 10.10, with acpi_osi="!Windows 2009" so it pretended to be XP so optimus wouldn't be used
<RAOF> I installed that image, and that's what it came up with.  Then I suspended, and it didn't feel like waking.  Then I reset the BIOS options, and it didn't feel like POSTing :/
<Sarvatt> installed what image?
<Sarvatt> i have a freaking weird job, i need to identify workarounds need to make specific systems work so they can be preinstalled, the make them work in that release+1 out of the box
<bjsnider> does suspend/resume work well using the blob?
<bjsnider> i read complaints
<RAOF> broder: Confirmed; hybrid-detect only prints "integrated" on the intel/ati hybrid system, even with the break removed (so, iterating over all the PCI devices)
<broder> RAOF: excellent, thanks
<broder> what happens if i start X with both nvidia-current and nvidia-173 installed?
<broder> how does it figure out which kernel module to use?
<tjaalton> dpkg-checkbuilddeps: error: --help is not a valid version'
<tjaalton> fun
<tjaalton> Build-Depends: debhelper (>= 8), dh-autoreconf, pkg-config, xserver-xorg-dev (>= --help)
<tjaalton> :P
<ricotz> cnd, hi, i think you should bump this depend x11proto-input-dev (>= 2.0.1-1ubuntu1) in 2:1.11.2.902-1ubuntu1
<Sarvatt> ricotz: configure.ac require higher?
<ricotz> RAOF, hi, ^
<ricotz> Sarvatt, i guess it is mandatory for the backport xi2.2 stuff
<ricotz> so i guess the configure bump is missing too
<Sarvatt> is it mandtory? a commit got left out of the backport if so
<ricotz> i think so
<tjaalton> patch 05/42 of the multitouch bundle
<ricotz> tjaalton, hi, do you have a link to your libwacom repo if you already pushed it?
<tjaalton> ricotz: haven't pushed yet
<ricotz> tjaalton, ok
<tjaalton> hum, left already
<tjaalton> git://anonscm.debian.org/users/tjaalton-guest/libwacom.git
<RAOF> tjaalton: Yeah, I spotted that *almost* immediately ;)
<RAOF> A suprising amount of our desktop really, really doesn't like multitouch going away.
<RAOF> Unity?  Dies.  Unity2D?  The launcher will spin at 100% CPU and not display.  Evince?  Likewise.
<FernandoMiguel> eheh
<jcristau> so you can't remote an ubuntu desktop against a $something_else X server?
<RAOF> I guess not.
<RAOF> Those are all bugs, but they're obviously bugs that no-one's cared enough about; I think it's a pretty rare corner-case.
<Sarvatt> RAOF: the evince one popped up in a precise libutouch-geis update, ricotz has a bug open about it
<Sarvatt> think it affected EOG too
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/utouch-geis/+bug/898175
<ubot4> Launchpad bug 898175 in utouch-geis (Ubuntu) "uTouch hangs using XCB back end if X server does not support gesture protocol (affects: 3) (heat: 16)" [Undecided,Confirmed]
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/utouch-geis/+bug/879348
<ubot4> Launchpad bug 879348 in utouch-geis (Ubuntu) (and 1 other project) "evince segfaults (affects: 8) (dups: 2) (heat: 49)" [Undecided,Incomplete]
<Sarvatt> RAOF: finally friggin found it http://www.spinics.net/lists/dri-devel/msg17272.html
<Sarvatt> it was on dri-devel, i was looking through lkml and intel-gfx
<RAOF> Because having just a single mailing list would have made that too hard ;)
<Sarvatt> oh boy, file system corruption for that guy from it too
<RAOF> Yeah.  Memory corruption is not my favourite thing.
<RAOF> As you can see, I'm not up-to-date on my dri-devel reading :)
#ubuntu-x 2011-12-16
<seb128> could somebody help getting https://code.launchpad.net/~vanvugt/ubuntu/precise/xserver-xorg-input-synaptics/fix-754000/+merge/80030 reviewed?
<seb128> cnd, ^
<Prf_Jakob> RAOF, Sarvatt, bryceh: So you being comfirtable picking Mesa 8.0 a branch in the beginning oj Jan would be good?
<Prf_Jakob> So for you to be comfirtable picking Mesa 8.0 to go into 12.04, a branch being created in the beginning of Jan is good?*
<Prf_Jakob> That hopefully made more sense :)
<Sarvatt> Prf_Jakob: yeah, idr said a few days ago that was still the plan too. first alpha and a branch at the end of december was still on track as of a call with them on wednesday
<Sarvatt> RAOF: did you manage to get any kind of info out of your crashes so I can forward this bug report? looks like -rc6 is going to go out busted to
<Sarvatt> RAOF: can you just grep corruption /var/log/kern.log?
<Sarvatt> its showing up as list_add corruption. prev->next should be next (ffff8800799756c0), but was ffff88005d42dcb0. (prev=ffff88005b278eb0). for other people
<Prf_Jakob> Sarvatt: ok thanks..
<ricotz> RAOF, ping
#ubuntu-x 2011-12-17
<Sarvatt> yay for buying vmware fusion 4 on black friday for $20 :) finally got around to updating, time to work out packaging of libxatracker
<Sarvatt> and see if it actually works yet unlike st/xorg svga in 7.11
<Prf_Jakob> should work
<Prf_Jakob> as long as you build xf86-video-vmware from the xa_branch
<Sarvatt> vmwgfx_branch?
<Prf_Jakob> right
<Sarvatt> ok just making sure im on the right branch
<Sarvatt> of course that doesnt work on xserver 1.11
 * Sarvatt does a bunch of cherry-picks
<broder> wait, does this get you opengl in vmware vms?
<Prf_Jakob> yes
<broder> oooooh
<Sarvatt> yup
<Sarvatt> bryceh: what system is crashy on precise?
<Sarvatt> bryceh: i'm guessing you're hitting https://bugs.launchpad.net/ubuntu/precise/+source/linux/+bug/903654 too
<ubot4> Launchpad bug 903654 in linux (Ubuntu Precise) (and 1 other project) "[i915] x200s locks up hard about once an hour (affects: 2) (heat: 12)" [High,Confirmed]
<bryceh> Sarvatt:
<bryceh> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/905505
<ubot4> Launchpad bug 905505 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "Page fault in drm while using Unity's software center overlay (affects: 1) (heat: 6)" [High,New]
<bryceh> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/905597
<ubot4> Launchpad bug 905597 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) " BUG: unable to handle kernel NULL pointer dereference at 00000048 while plugging / unplugging external DVI monitor (affects: 1) (heat: 6)" [High,Triaged]
<bryceh> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/905591
<ubot4> Launchpad bug 905591 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) ""BUG: unable to handle kernel NULL pointer dereference at 00000018" when trying to configure one display centered above another (affects: 1) (heat: 6)" [Medium,Triaged]
<bryceh> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/905109
<ubot4> Launchpad bug 905109 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "Kernel lockup/crash while using desktop switcher in unity (affects: 1) (heat: 6)" [Undecided,New]
<bryceh> Sarvatt, I'm seeing these on a toshiba, not a x200
<bryceh> also, what I'm seeing is not a random periodic freeze but is definitely triggered by modesetting activity
<bryceh> also in all cases network was fine and I could log in and get dmesg and logs
<antivirtel> good day! I'm going to buy a Lenovo ThinkPad Edge E525 with ATI Mobility Radeon HD 6470M GPU. The problem is, that there are bad feedback for the Linux driver... Can I ask if there is an working (open source) driver?
<bryceh> yes
<antivirtel> bryceh oh, and are you absolutely sure or you have one? I saw this warning: http://askubuntu.com/questions/46976/ati-catalyst-control-center-gives-error-radeon-hd-6470m (Important note...)
<antivirtel> bryceh oh, and are you absolutely sure or you have one? I saw this warning: http://askubuntu.com/questions/46976/ati-catalyst-control-center-gives-error-radeon-hd-6470m (Important note...)
<bryceh> antivirtel, google "radeon feature"
<antivirtel> I've tried bryceh 
<JanC> antivirtel: Catalyst/fglrx is the closed source driver (and that Q&A is about 11.04 so probably outdated for 11.10 anyway), and you first asked about the open source driver of course?
<antivirtel> JanC - thanks, it is same to me what kind of license it has, but I need it to work property... without as much trouble as possible
<jcristau> if you don't want trouble you don't want fglrx.
<antivirtel> :)
<antivirtel> thanks
<JanC> antivirtel: can you try out the laptop beforehand from an live USB stick or CD or such?
<JanC> that's always the best way to know for sure...  ;)
<antivirtel> JanC unfortunately I cant, the laptop is ordered, can't be tryed before
#ubuntu-x 2011-12-18
<FernandoMiguel> boa noite
<RAOF> Sarvatt: Hm.  I'm running the -rc6 mainline build kernel here, and it's been ok.  My hardware is all over the place, though, so there's currently no hard drive in my x200s.
#ubuntu-x 2012-12-10
<tjaalton> ooh, didn't notice wacom 0.18.0 was out, with proper multitouch support
<tjaalton> time to test it with intuos5
<tjaalton> well, the gestures still wont work :)
<tjaalton> hum no, need to disable the internal gestures first, then they work
<tjaalton> might replace my mouse with this thing :)
<tjaalton> although the list of gestures is pretty limited atm
<MCR1> ricotz: Hi :) FYI: fglrx from the PPA worx perfectly with Kernel 3.7.
<ricotz> MCR1, nice, btw, i won't binary patch it, i guess there should be some release at some point soon
<MCR1> ricotz, np.
#ubuntu-x 2012-12-11
<erappleman> mlankhorst, re the hybrid spec. does airlie still plan to have power management ready for 3.8? i haven't seen him prep it for -next or anything that should've been done already
<mlankhorst> seems to be delayed
<mlankhorst> I'm reviving my synchronization work though
<erappleman> your tree is very promising
<mlankhorst> it's slow work though, I never touched radeon before, the i915 commits *might* work, but didn't test it much
<erappleman> i could try rolling the kernel over the next few days
<mlankhorst> it's not ready yet, the first half deals with getting ttm locking changed in a more useful way, after that some changes for debuggability
<erappleman> thanks, i'll keep an eye on developments
<mlankhorst> it would be useful if someone could review the mutex patch I posted though
<mlankhorst> part of the changes were making ttm use an extended version of mutexes for implementing reservations, but without that patch in I can't get the rest upstreamed
<erappleman> mutex: add support for reservation style locks?
<erappleman> couldn't hurt to let dri-devel look at it
<erappleman> or would that be an lkml thing
<mlankhorst> suppose i could repost and cc dri-devel
<mlankhorst> and now that I actually got the preliminary ttm patches in elaborate a bit more in the commit on how to use it
#ubuntu-x 2012-12-12
<bjsnider> ricotz, 313.09 blob released
<bjsnider> i wonder if they still plan on making the 310 stable
<ricotz> bjsnider, already uploaded ;) and 310.19 is stable
<bjsnider> nobody's emailed me axing for it
<mlankhorst> 310 works for me, but then again my system is unstable for other reasons :-)
<bjsnider> ricotz, 310 would exclude old junk hardware right? so do you suppose it should go in x-updates anyway?
<ricotz> bjsnider, imo 310 (nvidia-graphics-drivers) should get the main version and 304 getting a legacy package (nvidia-graphics-drivers-304) with some proper replaces and provides
<ricotz> i must admit i don't care for this in edgers :\
<bjsnider> the ppa can be removed if the user has old junk
<bjsnider> ricotz, isn't it in edgers anyway?
<ricotz> bjsnider, what is it edgers anyway?
<ricotz> (currently there is only 313.09)
<bjsnider> the 310/313 blob
<ricotz> only 313
<bjsnider> it's there even though you don't want it there
<ricotz> what?
<ricotz> the 310 binaries will be purged automatically within a day or so
<ricotz> and arent available anymore through apt from the ppa
<bjsnider> i don't know what you meant by saying you "don't care for this in edgers"
<ricotz> "i dont care about supporting legacy cards" while there is only the latest avaible driver
<bjsnider> oh, i see
<bjsnider> not a big deal in edgers
<bjsnider> because of what edgers is
<MCR1> ricotz: Hi :) FYI: Latest fglrx update from the xorg-edgers PPA also successful and working.
<MCR1> ricotz: Thx && keep them coming ;)
<ricotz> MCR1, good, this one is suppose to be the stable one, so no watermark, i guess
<MCR1> ricotz, I had a watermark - it was saying unsupported hardware, which was a bit strange...
<MCR1> but seems working
<ricotz> MCR1, hmm, i see, this is suppose to be 12.12
<MCR1> ricotz: It says Catalyst Version 12.9 in AMD CCC Information
<MCR1> ricotz: haha, but it does not even detect the memory of my card correctly, so not sure how correct this info is
<ricotz> hmm, http://support.amd.com/us/gpudownload/embedded/Pages/embedded_linux.aspx
<ricotz> i guess this was the wrong one
<Sarvatt> MCR1: control+alt+f1, sudo service lightdm stop, sudo rm /etc/ati/amdpcsdb, sudo service lightdm start
<Sarvatt> and it'll update
<ricotz> Sarvatt, oh
<ricotz> but you were too late ;)
<Sarvatt> mlankhorst: argh ya need to version ppa stuff with ~ or something in a ppa, caused https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/1068165 with x-updates :)
<ubottu> Ubuntu bug 1068165 in libdrm (Ubuntu) "package libdrm2 2.4.39-0ubuntu1 failed to install/upgrade: trying to overwrite shared '/usr/share/doc/libdrm2/changelog.Debian.gz', which is different from other instances of package libdrm2:amd64" [Undecided,Confirmed]
<Sarvatt> so the next releases version is higher
<mlankhorst> yeah I usually tend to at least
<Sarvatt> tseliot: i threw a newer fglrx-installer-experimental-9 in x-updates if you want to reuse any of it for the distro
<mlankhorst> Sarvatt: that was with qbp enabled probably then?
<Sarvatt> nah thats renamed, looks pretty clear they had x-updates and tried to go 12.04 to 12.10
<Sarvatt> just noticed that there was a same version one in x-updates when i went to upload this fglrx
<mlankhorst> oh I didn't upload to x-updates though?
<Sarvatt> https://launchpad.net/~ubuntu-x-swat/+archive/x-updates
<Sarvatt> hmm
<Sarvatt> did you upload it to the distro? maybe someone pocket copied
<mlankhorst> might have been from qbp though
<Sarvatt> Copied from ubuntu precise in Xorg server 1.13 by Bryce Harrington oops :)
<mlankhorst> at one point I did upload one with the version bumped, just so it wouldn't conflict any more like that
<Sarvatt> libdrm needs an SRU :P
 * mlankhorst wants libdrm 2.4.41 :(
<mlankhorst> with the kepler abi change
<Sarvatt> are you kidding....?
<mlankhorst> nah, small one though, backwards compatible :P
<mlankhorst> I'm guessing darktama is holding it off until the kernel parts land first
<Sarvatt> oh man, was about to throw something if we needed libdrm-nouveau2a for raring
<mlankhorst> hahahah
<RAOF> libdrm-nouveau3.1415!
<mlankhorst> (â¯Â°â¡Â°ï¼â¯ï¸µ â»ââ»
<mlankhorst> Sarvatt: it's just increasing the size of a struct so I can stuff in the engine id, and drive the decoder engines on kepler
<Sarvatt> at least plymouth wont need it so its pretty painless now..
<Sarvatt> what, plymouth got updated and doesn't build device specific drm backends but still depends on device specific libdrms
<RAOF> ???
<mlankhorst> also I'm stupid and I got 1080p working now
<mlankhorst> \o/
<Sarvatt> just build depends, binaries are fine, phew
<Sarvatt> wonder if fglrx-installer-experimental-9 even works in 12.10, think it needed jocky or software-properties changes and its never been uploaded to quantal
<mlankhorst> I guess I may push the vdpau crap to mesa now
<RAOF> Sarvatt: I was under the impression that the necessary changes were already in Quantal's bits.
<Sarvatt> oh hell, FTL broken with edgers today
<RAOF> Troubling!
<mlankhorst> Sarvatt: reading it a second time I guess you meant the game, first time I thought flash transition layer
#ubuntu-x 2012-12-13
<bryce> tjaalton, http://www.bryceharrington.org/Arsenal/ubuntu-x-swat/Reports/package-status.html
<Sarvatt> and of course fglrx-installer-experimental-9 failed to build on amd64 for quantal and raring, something to fix up tomorrow in my favorite package ever
<Sarvatt> at least fglrx-installer-experimental-9 isn't as retarded as nvidia-experimental-310 they already abandoned and moved on to nvidia-experimental-313. whoever thought versioned -experimental packages were ok was silly :)
 * ScottK waves to Sarvatt.
<Sarvatt> there are going to be at least 10 packages to maintain in every previous release by 14.04, tseliot doesn't scale that well :(
<Sarvatt> maybe if we dont forward port anything but the newest one when the next dev release opens
<Sarvatt> there is going to be bugs about experimental-310 not working with the X abi in 13.04, that will never be fixed because nvidia made 313 to work with that (hypothetical, 315 or whatever wil be the one supporting xserver 1.14)
<ScottK> Sounds like "fun"
<bjsnider> Sarvatt, are you complaining about amd and nvidia again?
<bjsnider> they make good stuff
<bjsnider> really good stuff
<Sarvatt> nah amd is fine, fglrx-installer-backports-9 will cover an entire years worth of updates
<Sarvatt> its just nvidia already gave up on 310 and there wont be more, its 313 now, probably something else valve needs next :)
<Sarvatt> fglrx-installer-backports-9 means everything from 2012, nvidia revs the version every other month but the old ones need to work but dont get updated :)
<bjsnider> keeping up with the updates would be a full-time job
<bjsnider> do they still have the long-lived release too?
<Sarvatt> i'm just hoping nvidia-experimental-310 doesn't get copied to 13.10, its already irrelevant
<tjaalton> bryce: ah, nice
<mlankhorst> ok looks like I got synchronization to not hang up completely at least :P
<tjaalton> btw, isn't it true that 13.04 will be quite boring hybrid-wise?
<tjaalton> just like xserver 1.14 will be
<mlankhorst> true
<mlankhorst> vblanking is impossible to do cross-device right now for example
<bryce> Sarvatt, plan is -310 users will get moved to nvidia-current on upgrade to 13.10
<mlankhorst> shoo, go vacation
<bryce> mlankhorst, heh yep you're right
#ubuntu-x 2012-12-14
<hyperair> Sarvatt: where did you get your 3.7 kernel from? i can't seem to merge overlayfs into my build =\
#ubuntu-x 2012-12-15
<Sarvatt> hyperair: its just the raring kernel copied into quantal http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-raring.git
<jameh> hey, i can't find how to report a bug on https://launchpad.net/~ubuntu-x-swat how do i do that?
<mlankhorst> impatience
<jameh> can I report an ubuntu-x bug if i'm running linux mint?
#ubuntu-x 2012-12-16
<JanC> jameh: preferably, test on Ubuntu too before reporting a bug?
<hyperair> Sarvatt: ah, okay, thanks.
<MCR1> ricotz: Hi :) Upgraded to 13.04, fglrx worx, Docky still runs ;)
<ricotz> MCR1, nice ;)
<bjsnider> someone still uses docky?
#ubuntu-x 2013-12-10
<RAOF> mlankhorst: Time to trade SRU for mesa commits? :)
<Sarvatt> lol
<mlankhorst> RAOF: Yeah I was blocked on that, I saw that someone replied with keithp's dri3 branch, which supposedly did the same thing
<mlankhorst> but looking at it didn't show up any conflicting commits, which puzzled me
<mlankhorst> at least nothing that conflicted on first sight
<RAOF> mlankhorst: IIRC keithp's dri3 branch contains an implementation for nouveau (which might even by *your* implementation for nouveau, can't remember), and will fail on everything else.
<mlankhorst> ah
<mlankhorst> but I didn't see it in that commit list any more for the dri3 branch, hm
<RAOF> It also got pointed out on the list that my patch series was more complete, and had been hanging around since April or so; keithp may have removed the partial work from his branch?
<mlankhorst> perhaps
<mlankhorst> RAOF: I'll try to grab the patches again, see if they apply and compile
<RAOF> Pretty sure they do. I don't *think* I touched them on my recent rebasefest.
<mlankhorst> there's 2 v3 of one commit too, what one do I take? :p
<mlankhorst> hm guess I'll try the newest one
<RAOF> Oh, really? Which patch has 2 v3s?
<mlankhorst> support dri image version 7
<mlankhorst> hm they're identical
<mlankhorst> just why would you send it twice :o
<RAOF> I don't know. They're offset by significant times, too.
<RAOF> Maybe one got eaten in processing for a while?
<mlankhorst> probably
<mlankhorst> RAOF: hm, the nouveau patch failed to apply, i fixed it up. the radeon one fails with one hunk too, but it seems that one can be ignored :p
<RAOF> :)
<RAOF> Oh!
<RAOF> Has {r300,r600,radeonsi}/drm_target.c moved between patch submission and now?
<RAOF> Is that the failing hunk?
<mlankhorst> nah
<mlankhorst> was some va_size that got removed
<RAOF> Ah, coolio.
<mlankhorst> ok, trying build
<mlankhorst> ok it compiles, I guess that's all I can ask for
<RAOF> Oh. *That's* why the Mir platform bombs when I try to update it - intel preferentially calls image_get_buffers if it's non-null, and gbm always defines image_get_buffers, but returns 0 if the implementation hasn't defined that.
<RAOF> mlankhorst: There's a piglit test available!
<mlankhorst> too late :p
<RAOF> mlankhorst: Ta muchly
<mlankhorst> mir patch didn't apply and it failed at installing to debian/tmp stage somewhere, 
<mlankhorst> but shrug
<tjaalton> mlankhorst: commit the arm fix to d-exp too
<tjaalton> or was that on ubuntu only
<mlankhorst> on ubuntu only for now
<mlankhorst> our packaging diverges a lot there
<tjaalton> ah ok
<tjaalton> yeah I guess jcristau would have spotted the failure too :)
<mlankhorst> oh actually it should fail on their packaging too. :P
<tjaalton> yeah looks like it
<jcristau> i won't spot arm failures until they hit the buildds
<jcristau> no arm kit here :)
<tjaalton> I tried to find build logs yesterday but couldn't find any for mesa 10
<tjaalton> but yeah guess they do take some time..
<mlankhorst> jcristau: http://paste.debian.net/70096/ does this look good?
<RAOF> mlankhorst: I've almost got the mir bit done; I've just realised why i965 dies on it.
<mlankhorst> hm I guess I should merge it and have it inside confflags_GALLIUM below..
<jcristau> tjaalton: mesa 10 is in debian NEW
<jcristau> so no logs yet
<tjaalton> oh right
<mlankhorst> jcristau: http://paste.debian.net/70097/ v2
<jcristau> mlankhorst: not quite sure if building radeon stuff on arm makes much sense
<mlankhorst> jcristau: well .. we already do it anyway :P
<mlankhorst> and lynxeye already had nouveau working on a tegra board with pci-e
<mlankhorst> granted, the leak current of the nvidia card was probably higher than the entire tegra board itself, but still!
<jcristau> need more context to understand v2.  too many conditionals in that makefile.
 * jcristau tries to find a mesa checkout
<mlankhorst> oh  wait, i915/i965 is used outside linux right?
<jcristau> yes
<jcristau> i was just about to say that
<jcristau> need to still build them on kbsd
<RAOF> I win!
<mlankhorst> congratulations, you win a mir display
<jcristau> that sounds like losing
<mlankhorst> jcristau: http://paste.debian.net/70098/ hm this better?
<jcristau> you lose the extra_sed thing, is that on purpose?
<mlankhorst> yeah
<mlankhorst> libllvmradeon.so no longer exists
<mlankhorst> so it was a leftover in debian/rules
<tjaalton> confusing to remove it on the same commit
<mlankhorst> this is the diff I have. :P
<mlankhorst> didn't commit anything yet
<jcristau> in that case also remove the use of EXTRA_SED :)
<mlankhorst> ah right
<mlankhorst> RAOF: hm mir was broken with mesa 10?
<RAOF> mlankhorst: When switching to using gbm for the nested stuff, I think.
<mlankhorst> oh :p
<mlankhorst> didn't check nested
<mlankhorst> RAOF: oh btw for libdrm/pixman sru do I need to update quantal and raring or not? To make upgrading from precise to quantal and raring work
<mlankhorst> guess I will
<RAOF> mlankhorst: Yeah, we do like to keep upgrades working :)
<mlankhorst> ok 
<mlankhorst> testbuild in ppa seems to work
<mlankhorst> pixman_0.30.2-1ubuntu0.0.0.0.1_source.changes
<mlankhorst> weee
<tjaalton> jollas available tomorrow.. bah. no benefit in preordering it other than getting a free cap
<tjaalton> which should arrive some time next week
<mdeslaur> mlankhorst: you just overwrote my previous xorg-server changes
<mlankhorst> oh :P
<mlankhorst> sorry
<mdeslaur> mlankhorst: np, can you fix it?
<mlankhorst> sure
<mdeslaur> mlankhorst: cool, thanks!
<mdeslaur> so...looking at http://nvidia.custhelp.com/app/answers/detail/a_id/3377
<mdeslaur> seems there are new 331 319 and 304 drivers
<mdeslaur> but, I'm looking at the zillion packages we have to update in the archive
<mdeslaur> what do we do with the 310 and 313 packages?
<mdeslaur> update them to 319?
<mdeslaur> leave as-is without telling the user they have a security issue?
<mlankhorst> it's fairly theoretical
<mlankhorst> well it's still a gaping security hole but not everyone could exploit it ;)
<mlankhorst> mdeslaur: hm
<mlankhorst> The PGRAPH context switch microcode allows user to read/write arbitrary MMIO registers by submitting the firmware methods. The GF100+ video decoding etc. falcon microcodes allow you to just ask for physical instead of virtual addressing, and that includes physical system memory. Why did nVidia include such obviously security-breaking functionality in the firmware images? As I understand it, a user having access to just the FIFO submission interfac
<mlankhorst> Marcin KoÅcielnicki 
<mlankhorst> sounds like it could be fun to figure out :P
<mlankhorst> mdeslaur: I guess nouveau developers could figure it out, but anyone else is going to have to try a lot harder
<mlankhorst> mdeslaur: but tseliot knows the nvidia binary drivers better than I do, ask him ;)
#ubuntu-x 2013-12-11
<mdeslaur> mlankhorst: yeah, problem is, now that it's known, every security researcher is going to be poking at it until someone posts an exploit
<mdeslaur> mlankhorst: so the difficulty buys us time, but I'll have to get around to it eventually
<mdeslaur> mlankhorst: thanks!, I'll ask him
 * RAOF checks logs for context
<RAOF> Ah, the nvidia video decoding microcode.
<mlankhorst> mdeslaur: good luck, it's not trivial ;)
<Prf_Jakob> mlankhorst: I see that libxatracker2 has landed in 14.04
<mlankhorst> yeah, I pushed a vmware snapshot to make things work
<mdeslaur> mlankhorst: hehe, thanks
<mdeslaur> tseliot: can I ask you a few questions about the nvidia drivers?
<mdeslaur> so...looking at http://nvidia.custhelp.com/app/answers/detail/a_id/3377
<mdeslaur> seems there are new 331 319 and 304 drivers
<mdeslaur> but, I'm looking at the zillion packages we have to update in the archive
<mdeslaur> what do we do with the 310 and 313 packages?
<mdeslaur> update them to 319?
<mdeslaur> leave as-is without telling the user they have a security issue?
<tseliot> mdeslaur: speaking of 12.04, I'm going to update 319 to 331 (with the fix) and 304 to the latest 304 (with the fix). The rest should be transitional packages
<tseliot> I'll do something similar in 14.04
<tseliot> I'm not sure about 13.04 and 13.10 though
<mdeslaur> tseliot: interesting, cool
<tseliot> mdeslaur: maybe I can prepare some packages for 13.04 and 13.10 so that they go through the -security repositories, well, as soon as I'm done with 12.04 that is
<mdeslaur> tseliot: perhaps the 12.04 ones should go through -security too?
<mdeslaur> although, doing them as SRU might make sense also, given that I'm really afraid of regressions
<tseliot> mdeslaur: the main problem is that I've been working on an SRU that I want to complete this week and it involves much more than a simple update
<tseliot> going through -security first and rebasing my SRU on that would probably double my workload
<mdeslaur> tseliot: that's fine, continue as an SRU
<tseliot> mdeslaur: ok, good
<mdeslaur> I'll wait to see your packages, thanks!
<tjaalton> mlankhorst: both 1190546 and 1185035 seem to be still stuck on -proposed (raring)
<tjaalton> hmm or maybe not, the bugs are still open though
<mlankhorst> meh I'll need to verify that
<tjaalton> also https://bugs.launchpad.net/ubuntu/+source/libpciaccess/+bug/1122072 looks confusing
<ubottu> Ubuntu bug 1122072 in libpciaccess (Ubuntu Quantal) "[Precise on VirtualBox] "Fatal server error: no screen found" in Xorg.0.log" [Undecided,New]
<tjaalton> there's a quantal xserver with that bug id
<tjaalton> in proposed
<tjaalton> a typo?
<tjaalton> cleaning up open tabs and noticed these
<mlankhorst> meh dno
<mlankhorst> ok verifying raring stuff after I installed nvidia-319...
<tomreyn> hi, do you folks have some statistics about hardware and driver spread which you could make available to the world?
<mlankhorst> no, but you could try the steam survey
<tomreyn> http://store.steampowered.com/hwsurvey/ only has windows and mac
<tomreyn> is this the one you meant?
<mlankhorst> yeah, but not sure why linux stats would be much different from windows
<tomreyn> i guess linux users may tend to have older hardware, and maybe a little bit more hardware which is known to be well supported on linux.
<mlankhorst> tjaalton: well verification seems to fail, i wonder how because I knwo it fixed things before :/
<mlankhorst> tseliot: can we simply point those who have hybrid cards to saucy xserver?
<tseliot> mlankhorst: as in the documentation (wiki or whatever)?
<mlankhorst> yeah
<tseliot> yes, that's exactly what I was planning to do
<mlankhorst> dpms still seems to be broken for some reason
<tseliot> are you using modesettings?
<tseliot> it works fine here
<mlankhorst> tseliot: raring?
<tseliot> mlankhorst: hybrid graphics is officially supported in 12.04.3 and kind of supported in 13.10, what does 13.04 have to do with this?
<mlankhorst> erm raring xserver = 12.04.3 right?
<tseliot> mlankhorst: ok, so the lts-raring xserver, yes, that's what I use in 12.04
<tseliot> and I always have to disable screen blanking because it's annoying ;)
<mlankhorst> yeah, we should recommend upgrading to saucy though
<mlankhorst> much much better support
<tseliot> mlankhorst: maybe it's failing because the gsd fails and my update hasn't landed in precise yet
<tseliot> agreed
<tseliot> if they want output hotplug (and probably more) that's the way to go
<tseliot> or, even better, 14.04 ;)
<mlankhorst> oh well, verified the raring stuff
<tseliot> I'm running tests for the huge SRU in bug #1259237
<ubottu> bug 1259237 in screen-resolution-extra (Ubuntu Precise) "Hybrid graphics enablement in 12.04.4" [Medium,In progress] https://launchpad.net/bugs/1259237
<mlankhorst> tseliot: yeah it's sad that we still have no online switching, but the experience in saucy is definitely a lot better
<mlankhorst> quantal, it works if you're lucky and once in a blue moon, raring it actually works if you don't poke it too hard, saucy it actually works, but no online switching yet
<tseliot> mlankhorst: yes, I don't think X will ever get that feature. This will do for now. Also, if we could get rid of tearing...
<mlankhorst> haha I'll poke upstream some more
<tseliot> :)
<tseliot> aaronp is on paternity leave
<tseliot> so maybe when he's back you two can talk about it
<tjaalton> nice, x cursor on every vt on saucy, session somehow fooked
<tjaalton> wife tried to log in from the indicator
<tjaalton> reproducible too
<tjaalton> failed to claim drm device, wth..
<tjaalton> some permissions issue, reboot fixed it of course..
#ubuntu-x 2014-12-09
<mdeslaur> I just pushed out security updates for http://www.x.org/wiki/Development/Security/Advisory-2014-12-09/
<mdeslaur> FYI, in case there are some odd bug reports
#ubuntu-x 2014-12-10
<jderose> pull request for lp:1394348 - https://github.com/tseliot/nvidia-graphics-drivers/pull/7
#ubuntu-x 2016-12-14
<soee> mamarley: NVIDIA 375.26 Driver Rolls Out With Several Fixes
<soee> NVIDIA Updates Its Legacy Drivers For X.Org Server 1.19 Support
<mamarley> soee: Thanks!  Looks like I have some Work to do. :)
<mamarley> This should finally fix the blasted performance/lockup bugs on new hardware on 375.xx.
<mamarley> I will package it after work.
<soee> :)
<Sarvatt> mamarley: where do you get the nocompat32 versions if they aren't on the ftp?
<mamarley> Sarvatt: By manually adjusting the URL.  The files are (usually) on the HTTP site as well.
<Sarvatt> gotcha
<Sarvatt> thanks
<tjaalton> what part of nvidia drivers depends on newer vulkan?
<mamarley> ricotz: Just to make sure you saw the above, I am already handling all these driver updates. :)
<ricotz> mamarley, I saw, wait for Sarvatt's tarballs
<mamarley> Sarvatt: Are you doing 375 or just 340 and 304?
<ricotz> mamarley, just 304 and 340
<mamarley> OK, so I can proceed with 375?
<ricotz> yes
<mamarley> Thanks!
<ricotz> mamarley, thank you
<mamarley> Sarvatt: I don't know how far along you are, but for 340 and 304, the DRIVER_LEGACY part of the 4.9 patch is still necessary but the other two hunks can be dropped.
<mamarley> The DRIVER_LEGACY thing is tricky because it will compile without that, but it won't load.
<ricotz> mamarley, hmm :\, did you already confirm it?
<mamarley> ricotz: Yes, I tested it both ways on my 8600m GT.
<ricotz> ok, too bad
<mamarley> ricotz: Sadly, I had already done 90% of the work by the time you told me to wait :/
#ubuntu-x 2016-12-15
<mamarley> ricotz: 375.26 is in https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages :)
<ricotz> mamarley, currently running it ;)
<mamarley> Any reason not to copy it to the main PPA then?
<ricotz> mamarley, looks good, so no
<mamarley> OK, I will do that.
<ricotz> mamarley, thx
<mamarley> No problem
#ubuntu-x 2017-12-16
<dupondje> Guess somebody in here might know it, but Wayland and Nvidia closed driver isn't an option yet? Or does it work already?
#ubuntu-x 2018-12-12
<mamarley> ricotz: I almost forgot to mention, I have 415.22 in https://launchpad.net/~mamarley/+archive/ubuntu/staging.  I backported the fix for that documentation issue, but I didn't backport the change for the wayland libraries because the additional package it referred to doesn't exist for 415 and I didn't want to potentially break any users.
<mamarley> Also, there is a patch for Linux 4.20.  The conftest thing for atomic64_t is a hack because there is some weird assembler error that happens for that test with 4.20, but I figured it would be safe to assume that anyone running 4.20 on Ubuntu would have that functionality available, so I just NOPed it.
#ubuntu-x 2018-12-13
<mamarley> ricotz: I've got 415.23 in the normal place.  It is advertised as being compatible with 4.20-rc, but I found that there was some silly ASM error that was occurring when it ran the conftest for atomic64_t causing it to fall back to atomic_t instead.  I couldn't understand why that was happening, so I made a patch to NOP out the offending conftest for 4.20 so it still uses atomic64_t as it should.
<mamarley> I also merged in the fix for that documentation conflict issue that was happening previously, but I didn't merge in the change to drop the Wayland libraries since the package it referred to doesn't exist for 415.
<mamarley> I also rebased nvidia-settings for >=bionic on the latest from the disco repository, which fixes the problem where nvidia-settings wouldn't start on Optimus systems in Intel mode.
<ricotz> mamarley, hi, thank you, I will try to take a look soon
<ricotz> I am not running 4.20 yet, I got hit lately by the "filesystem corruption" bug in 4.19 :(
#ubuntu-x 2019-12-12
<ricotz> tseliot, hi :)
<ricotz> tseliot, are you going to upload 430.64?
<tseliot> ricotz, hi, I noticed (and uploaded) 440.44, and I am going to SRU that to bionic and eoan, as per LP: #1854485
<ubottu> Launchpad bug 1854485 in nvidia-graphics-drivers-440 (Ubuntu Eoan) "Introduce the new NVIDIA 440 series, and add 5.4 Linux compatibility to the 340 and 390 series" [Medium,In progress] https://launchpad.net/bugs/1854485
<ricotz> tseliot, I see, so 440 will replace 430 in bionic and eoan too? your 440 backport packages doesn't indicated that yet
<tseliot> ricotz, yes. If you're referring to the PPA, the packages there usually don't include transitional packages
<ricotz> tseliot, ack, thanks
<ricotz> tseliot, could you put libvdpau 1.3-1 on you list?
#ubuntu-x 2019-12-13
<tseliot> ricotz, libvdpau 1.3 was on my list, but I didn't know it was in debian already
<ricotz> tseliot, thanks!
