#ubuntu-x 2007-01-22
<Ubugtu> New bug: #80920 in mesa (main) "r300 DRI broken on big endian (edgy regression)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80920
<Ubugtu> New bug: #80925 in xorg (main) "dri image corruption i810 driver in fullscreen " [Undecided,Unconfirmed]  https://launchpad.net/bugs/80925
<Ubugtu> New bug: #80940 in xorg (main) "ati radeon driver does not autodetect displaysize on Latitude D600, therefore uses wrong resolution" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80940
#ubuntu-x 2007-01-25
* Starting logfile irclogs/ubuntu-x.log
<Ubugtu> New bug: #31876 in xserver-xorg-video-ati (main) "xorg (dapper, ati) crashes randomly" [Medium,Fix released]  https://launchpad.net/bugs/31876
<Ubugtu> New bug: #41340 in xserver-xorg-video-savage (main) "X server (S3 Savage) freezing with DRI" [Medium,Unconfirmed]  https://launchpad.net/bugs/41340
#ubuntu-x 2007-01-26
<Ubugtu> New bug: #23545 in xserver-xorg-video-ati (main) "No more X on resume after hibernate" [Medium,Needs info]  https://launchpad.net/bugs/23545
<Ubugtu> New bug: #40951 in mesa "Missing headers (gl.h) in the libgl1-mesa-dev" [Medium,Rejected]  https://launchpad.net/bugs/40951
<Ubugtu> New bug: #28925 in xserver-xorg-driver-ati "X fails to start in dapper, edgy with ati X600/X700/X800 (control not delegated to "radeon" driver, "ati" complains about Mach64)." [Unknown,Fix released]  https://launchpad.net/bugs/28925
<Ubugtu> New bug: #81572 in xorg (main) "apt-get install doesn't work" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81572
<Ubugtu> New bug: #56213 in xserver-xorg-video-i810 (main) "RandR doesn't work anymore (after suspend?)" [Undecided,Confirmed]  https://launchpad.net/bugs/56213
<Ubugtu> New bug: #45302 in xorg (main) "keyboard is not detected" [Medium,Unconfirmed]  https://launchpad.net/bugs/45302
<Ubugtu> New bug: #81346 in xserver-xorg-video-i810 (main) "Graphics doesn't work after a suspend on RAM (feisty)" [Undecided,Confirmed]  https://launchpad.net/bugs/81346
<Ubugtu> New bug: #81620 in libice (main) "Crash on every login during loding gnome-panel and beryl. It doesn't crash if the last crash is dected - message box" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81620
<Ubugtu> New bug: #81695 in xorg (main) "[Edgy]  xorg.conf contains entries for wacom tabled even if it's not installed" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81695
<Ubugtu> New bug: #76917 in xorg (main) "CTRL-ALT-F# keys bring up crazy looking screen" [Undecided,Needs info]  https://launchpad.net/bugs/76917
<Ubugtu> New bug: #47971 in xserver-xorg-input-synaptics (main) "synaptics touch pad(laptop) clicks too easily" [Critical,Confirmed]  https://launchpad.net/bugs/47971
<Ubugtu> New bug: #80318 in xorg (main) "3D desktop breaks S3 sleep" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80318
<Ubugtu> New bug: #48029 in mesa (main) "Can't load r200_dri in libGL (ATI Radeon R250 Lf [FireGL 9000] )" [Medium,Unconfirmed]  https://launchpad.net/bugs/48029
#ubuntu-x 2007-01-27
<Ubugtu> New bug: #73171 in update-manager (main) "dapper to edgy need xorg font path remapping" [Medium,Unconfirmed]  https://launchpad.net/bugs/73171
<Ubugtu> New bug: #48596 in xorg (main) "amd64 fglrx No matching visual for __GLcontextMode" [Medium,Unconfirmed]  https://launchpad.net/bugs/48596
#ubuntu-x 2007-01-28
<Ubugtu> New bug: #42049 in xserver-xorg-video-i810 (main) "no direct rendering on dapper with i810 chipset (855GM)" [Medium,Needs info]  https://launchpad.net/bugs/42049
<Ubugtu> New bug: #55948 in xserver-xorg-input-synaptics (main) "Scrolling doesn't work" [Undecided,Unconfirmed]  https://launchpad.net/bugs/55948
<Ubugtu> New bug: #44924 in xorg-server (main) "X chooses vesa driver for an ATI Radeon X300" [Medium,Needs info]  https://launchpad.net/bugs/44924
<Ubugtu> New bug: #38181 in xserver-xorg-video-ati (main) "Screensaver freezes on Dapper (ATI Radeon 8500 LE)" [High,Needs info]  https://launchpad.net/bugs/38181
<Ubugtu> New bug: #56692 in xorg-server "ATI radeon: poor 3D performance" [Unknown,Confirmed]  https://launchpad.net/bugs/56692
<Ubugtu> New bug: #43052 in xserver-xorg-video-i810 (main) "OpenGL viewport cut-off with 915gm graphics (dup-of: 23816)" [Medium,Confirmed]  https://launchpad.net/bugs/43052
#ubuntu-x 2008-01-21
<Q-FUNK> tjaalton: how does the dpi patch conflict with upstream?
<Q-FUNK> for once, I had a display with readable fonts.
<ubotu> New bug: #184717 in compiz "Totem Crashes (BadAlloc) With AccelMethod XAA on GM965 (dup-of: 148247)" [Undecided,New] https://launchpad.net/bugs/184717
<keescook> tjaalton: do you have steps to reprouce the wine regression?  It seemed it was related to nv symlinks in the bug reports.
<tjaalton> keescook: yeah, could well be just that
<keescook> tjaalton: okay, cool.
<tjaalton> what the hell.. nvidia* "diverts" the wrong libglx, no wonder there are these problems
<tjaalton> xserver-xorg-core ships libglx.so in /usr/lib/xorg/modules/extensions, and nvidia installs and diverts it's own in /modules
<ubotu> New bug: #184765 in xorg (main) "X Window system reports BadAlloc when starting Eclipse (xserver-xorg-core 2:1.3.0.0.dfsg-12ubuntu8.1)" [Undecided,New] https://launchpad.net/bugs/184765
<ubotu> New bug: #32130 in linux-restricted-modules-2.6.15 "Driver not is compatible whit option vga=323 in title kernel grub" [Medium,Invalid] https://launchpad.net/bugs/32130
<ubotu> New bug: #184440 in xserver-xorg-video-nv (main) "Blue hue in all videos" [Undecided,New] https://launchpad.net/bugs/184440
<ubotu> New bug: #184864 in xorg (main) "Hardy VMWare Guest video drivers" [Undecided,New] https://launchpad.net/bugs/184864
<ubotu> New bug: #184869 in xorg-server (main) "ALT Super keys swapped after upgrade" [Undecided,New] https://launchpad.net/bugs/184869
<ubotu> New bug: #184868 in xorg (main) "synaptics and compiz not compatibles " [Undecided,New] https://launchpad.net/bugs/184868
<ubotu> New bug: #184859 in cheese (main) "Cheese crashes on load with compiz running (dup-of: 111257)" [Undecided,New] https://launchpad.net/bugs/184859
<ubotu> New bug: #184913 in dell "[Feature Request] Option to disable touchpad in Mouse Preferences -> Touchpad" [Low,Confirmed] https://launchpad.net/bugs/184913
<ubotu> New bug: #184914 in linux-restricted-modules-2.6.24 (restricted) "Fan is set to run at 100% " [Undecided,New] https://launchpad.net/bugs/184914
<ubotu> New bug: #157726 in xkbd "Error activating XKB configuration (dup-of: 67188)" [Undecided,New] https://launchpad.net/bugs/157726
<ubotu> New bug: #183117 in ubuntu "Start up error (dup-of: 67188)" [Undecided,New] https://launchpad.net/bugs/183117
<ubotu> New bug: #184886 in ubuntu "Start up error (dup-of: 67188)" [Undecided,New] https://launchpad.net/bugs/184886
<ubotu> New bug: #153383 in gnome-control-center (main) "Error activating XKB configuration, directly after login. Ubuntu 7.10 (dup-of: 67188)" [Undecided,New] https://launchpad.net/bugs/153383
<ubotu> New bug: #184951 in xserver-xorg-video-nv (main) "nvidia graphics card, display off to the right edge ; shutdown button hidden" [Undecided,New] https://launchpad.net/bugs/184951
#ubuntu-x 2008-01-22
<ubotu> New bug: #184992 in linux-restricted-modules-2.6.24 (restricted) "Thinkpad T60 [1680x1050], ATIx1400, no X on Gutsy, Hardy" [Undecided,New] https://launchpad.net/bugs/184992
<ubotu> New bug: #183317 in xserver-xorg-video-intel (main) "[regression] Resume broken after last update to Intel video driver" [Undecided,New] https://launchpad.net/bugs/183317
<ubotu> New bug: #125334 in linux-restricted-modules-2.6.24 (restricted) "Should use NVIDIA-*-pkg0.run instead of -pkg1 and -pkg2 to save space" [Wishlist,Confirmed] https://launchpad.net/bugs/125334
<ubotu> New bug: #184986 in xorg (main) "visualisation crashes X windows" [Undecided,Incomplete] https://launchpad.net/bugs/184986
<ubotu> New bug: #124913 in linux-restricted-modules-2.6.24 (restricted) "glxinfo segfaults with nvidia-glx-legacy" [Medium,In progress] https://launchpad.net/bugs/124913
<ubotu> New bug: #184903 in xserver-xorg-video-intel (main) "Display looks garbled when Yelp starts" [Undecided,New] https://launchpad.net/bugs/184903
<bryce_> morning
<tjaalton> morning bryce_, how's London?
<bryce_> tjaalton: not too bad; was sort of sunny today
<bryce_> I've had several people ask about touchpad breakages
<bryce_> just a couple so far with X startup issues
<tjaalton> recent?
<bryce_> soren has found some issues with cirrus and kvm
<bryce_> yeah
<tjaalton> ok..
<ubotu> New bug: #144846 in linux-restricted-modules-2.6.22 "Crashed when trying to install/download Nvidia drivers" [Undecided,Invalid] https://launchpad.net/bugs/144846
<tjaalton> I'm updating lrm with latest nvidia & fglrx..
<bryce_> I've given soren some advice for fixing it, to try contacting the maintainer, etc.
<bryce_> cool
<tjaalton> and closing a shitload of bugs
<tjaalton> synaptics is dead upstream..
<bryce_> asac has a bunch of fglrx issues, that could be quite helpful
<bryce_> I spent about an hour with him this morning
<tjaalton> but mjg59 promised to do some work on synaptics
<bryce_> a couple people have complained about touchpad/synaptic issues
<bryce_> like right click
<tjaalton> well, the default config no longer has an entry for it, still waiting for i-h..
<bryce_> in any case, things seem to be a lot more stable than last time I was here :-)
<tjaalton> actually, you could ask them to try putting the fdi file from /usr/share/doc/hal/examples to /etc/hal/fdi/policy
<tjaalton> 10-x11-input.fdi
<tjaalton> and edit the keymap to that file
<bryce_> tjaalton: btw, are you planning on doing a new -intel relatively soon?
<tjaalton> if not 'us'
<tjaalton> I could
<tjaalton> just a snapshot or with XAA too?
<bryce_> I've got a patch for it, you could toss in
<tjaalton> ok, cool
<bryce_> bug 175774
<ubotu> Launchpad bug 175774 in xserver-xorg-video-intel "[hardy] Enabling "Normal" effects produces badly drawn window shadows." [Critical,In progress] https://launchpad.net/bugs/175774
<tjaalton> oh that
<tjaalton> did you notice the msgs on xorg@?
<tjaalton> if we switch back to XAA that's not an issue anymore
<bryce_> actually it is, if people wish to turn EXA on
<tjaalton> yep
<bryce_> even if we go to XAA by default, XAA is deprecated so EXA bugs are still going to be relevant unfortunately
<bryce_> so I take it you've no more hope of getting the libdrm/ttm stuff functional for hardy?
<tjaalton> currently I can't even test it :/
<tjaalton> probably due to some version mismatch with the libraries
<tjaalton> I'll wait a week and retry
<bryce_> ah
<tjaalton> I managed to build the driver, but it complained about some missing symbols
<tjaalton> then I rolled back everything on my laptop to be able to use it :)
<bryce_> are we able to configure things such that XAA is used for 965, but EXA is used for other intel chipsets?
<tjaalton> EXA is just as slow for !965 too :/
<bryce_> hrm
<bryce_> btw, I raised the issue about upstream dropping support for existing techs too swiftly when new techs are pushed out.
<bryce_> Don't know if anything will come of it, but maybe next time it'll make someone give a little thought to transition planning
<bryce_> today I think I'm going to try getting Q-FUNK's patches integrated
<tjaalton> upstream?
<bryce_> xorg
<tjaalton> i mean you are trying to get those patches upstream?
<bryce_> no, just build a ubuntu package
<tjaalton> ah, ok
 * bryce_ wonders when Q-FUNK might pop in
<bryce_> tjaalton: how things going with you?
<tjaalton> bryce_: trying to get this lrm out of the door, why?-)
<tjaalton> oh, I'm hungry too
<bryce_> mm, fuud
<bryce_> no reason, just curious
<tjaalton> lot of cruft in lrm
<tjaalton> but one thing at a time
<bryce_> yup
<tjaalton> tonight I'll receive the PS3 our choir got as a gift from the singstar world record
<tjaalton> so I'll be playing with it for a couple of days until it's installed on the choir club flat
<bryce_> cool
<tjaalton> my wife is not looking forward to that..
<bryce_> heh
<bryce_> yeah my fiancÃ©e says I can get any computer stuff no questions asked, but just no PS3's or WIii's or etc.
<tjaalton> the other day I tried 'frets on fire' (guitar hero clone), and she said that I'll never become a guitarist :)
<tjaalton> hehe
<bryce_> hehe
<tjaalton> mvo: hi, do you understand why removing nvidia-glx* on amd64 fails like on bug 184212?
<tjaalton> bad ubotu
 * tjaalton slaps ubotu with a trout
<ubotu> Launchpad bug 184212 in linux-restricted-modules-2.6.24 "package nvidia-glx-new 169.07+2.6.24.4-4.11 failed to install/upgrade: subprocess post-removal script returned error exit status 2" [Undecided,Incomplete] https://launchpad.net/bugs/184212
<ubotu> New bug: #40330 in xorg (main) "mouse pointer should flip horizontally when mouse orientation is left-handed" [Wishlist,Incomplete] https://launchpad.net/bugs/40330
<tjaalton> hmmh, I wonder if fglrx depends on libstdc++5 anymore..
<bryce_> whoa
<tjaalton> lrm build-deps on that
<bryce_> weird
<tjaalton> since Sep 2005..
<tjaalton> so I'd say no
<bryce_> maybe their old config tool needed it?
<bryce_> remove it and see if it builds?
<tjaalton> yeah
<tjaalton> it's just that installing the driver pulls in gcc-3.3-base and libstdc++5
<tjaalton> that's how I noticed
<bryce_> mpt came to me with a problem that sounds a lot like bug 184078
<ubotu> Launchpad bug 184078 in xorg "keyboard stops working until logout" [Undecided,New] https://launchpad.net/bugs/184078
<bryce_> hmm, maybe not
<bryce_> tjaalton: I am noticing a weird issue on 965 where new windows show static briefly for a fraction of a second before drawing
<bryce_> tjaalton: bdmurray says he sees it too, on 945 without compiz
<bryce_> tjaalton: have you seen this behavior?
<ubotu> New bug: #130769 in xorg-server (main) "Xephyr crashed with SIGSEGV in free()" [Medium,Incomplete] https://launchpad.net/bugs/130769
<ubotu> New bug: #44846 in xorg-server "gnome-keyboard-properties Layout Options tab blank in XNest" [Wishlist,Confirmed] https://launchpad.net/bugs/44846
<tjaalton> bryce_: yes, I think I've seen that
<bryce_> tjaalton: I asked bdmurray to post a bug for us on it
<tjaalton> cool
<tjaalton> having a beer, train leaves in 3min
<tjaalton> not in a hurry or anything :P
<tjaalton> always time for irc
<bryce_> heh
<bryce_> I'm still working through q-funk's patch
<tjaalton> doesn't merge easily?
<bryce_> looks like it requires manual application on xserver 1.4, but so far looks straightforward
<bryce_> no
<tjaalton> ok.. gotta go now ->
<bryce_> cya
<tjaalton> fck, missed the train, again
<tjaalton> more beer then
<tjaalton> I didn't upload the lrm yet, but it's finished
<tjaalton> finished as in ready
<bryce_> oops, sorry about the train!
<tjaalton> hehe
<tjaalton> next in 5min
<bryce_> oh not too bad
 * bryce_ is quiet so tjaalton doesn't miss train
<pcjc2_> hi
<bryyce> heya pcjc2_
<pcjc2_> I'm finding myself motivated to do some X11 debugging after a recent reboot ;)
<pcjc2_> I'm aware of the security update regression breaking java and wx apps..
<pcjc2_> any word on updates around this time also causing system-wide profiles to spend inordinate amounts of time in memcpy shifting textures around?
<bryyce> hmm, not that I've heard
<keescook> pcjc2_: the java/wx things is fixed.
<bryyce> this on hardy or gutsy?
<keescook> er, thing
<pcjc2_> it doesn't appear to be the 1.3.0.0.dfsg-12ubuntu8.3 update, as I just reverted it
<pcjc2_> Gutsy still
<bryyce> there haven't been any other gutsy updates to X stuff
<bryyce> can't speak about kernel things
<pcjc2_> I'm trying to decipher the update logs.. but something is slowing this box to a crawl
<pcjc2_> Work has been really hectic lately, but i'm still reading bug-mail. I heard the poor prognosis for EXA in Hardy.. shame
<bryyce> yeah
<bryyce> well, aside from the performance issues, there's a few other quirks that make EXA look not so ready for prime time
<bryyce> one of which I posted a patch for yesterday
<pcjc2_> I got the feeling more people were working on the intel driver recently
<bryyce> there's certainly more motion
<pcjc2_> I recently discovered the joys of trying to get a package into Debian.. no motion involved there
<pcjc2_> gah.. reboot time, this machine is very unhappy indeed
<ubotu> New bug: #184502 in scim (main) "Nautilus exhibits odd behavior when installing language support (dup-of: 66104)" [Undecided,New] https://launchpad.net/bugs/184502
<pcjc2> hi
<pcjc2> Bryce... it appears that slow graphics bug was hardware related.. its all unspeakably strange
<pcjc2> It only happens when I plug my AC adaptor in.. (Same adaptor I had to splice the wire on today to fix a wiggle fault).
<ubotu> New bug: #114124 in xfce4-terminal (main) "Xubuntu 7.04 xserver crashes when launching terminal (dup-of: 91849)" [Undecided,Confirmed] https://launchpad.net/bugs/114124
#ubuntu-x 2008-01-23
<ubotu> New bug: #185279 in xorg-server (main) "Xorg segfaults on startup" [Undecided,New] https://launchpad.net/bugs/185279
<bryce_> morning
<tjaalton> morning
<tjaalton> lrm uploaded.. found a minor bug 1min after upload :P
<ubotu> Launchpad bug 1 in ubuntu "Microsoft has a majority market share" [Critical,Confirmed] https://launchpad.net/bugs/1
<tjaalton> hehe
<bryce_> tjaalton: *grin*
<bryce_> tjaalton: does this include the latest fglrx?  I think mvo was interested in testing if so
<bryce_> tjaalton: and latest nvidia?
<mvo> texture_from_pixmap!
<tjaalton> yes, both
<tjaalton> please test :)
<tjaalton> it also adds a convenience package fglrx-amdcccle, which should help people updating from debs created by the ati installer
<tjaalton> but that package will end up in the NEW queue, and keep this new version from entering the archive
<tjaalton> until it's accepted of course
<bryce_> http://people.ubuntu.com/~ogasawara/qa-hardy-list-archive/sort-by-package/current-buglist.html
<tjaalton> mvo: did you notice my question about bug 184212 yesterday?
<ubotu> Launchpad bug 184212 in linux-restricted-modules-2.6.24 "package nvidia-glx-new 169.07+2.6.24.4-4.11 failed to install/upgrade: subprocess post-removal script returned error exit status 2" [Undecided,Incomplete] https://launchpad.net/bugs/184212
<tjaalton> mvo: could it be a bug in synaptic?
<mvo> tjaalton: no
<mvo> tjaalton: :P
<mvo> tjaalton: maybe, let me have a look, but its unlikely
<tjaalton> ok, thanks :)
<mvo> tjaalton: I don't think that its a synaptic/apt bug, the log says:
<mvo> Log started: 2008-01-18  18:14:37
<mvo> (Reading database ... 107849 files and directories currently installed.)
<mvo> Removing nvidia-glx-new ...
<mvo> dpkg-divert: error checking `/usr/lib32/libGL.so.1': No such file or directory
<mvo> dpkg: error processing nvidia-glx-new (--purge):
<mvo>  subprocess post-removal script returned error exit status 2
<tjaalton> but the file is there..
<mvo> the log is from 2008-01-18
<mvo> the ls -l is:
<mvo> lrwxrwxrwx 1 root root 15 Jan 21 15:47 /usr/lib32/libGL.so.1 -> libGL.so.169.07
<mvo> -rw-r--r-- 1 root root 663352 Jan 21 10:52 /usr/lib32/libGL.so.169.07
<bryce_> mesa?
<mvo> so both files are last touched 21.01
<tjaalton> hmm
<mvo> maybe he tinkered in between?
<tjaalton> maybe the installed some 3rd party version then
<tjaalton> I just tried removing it on amd64 and it worked just fine
<tjaalton> *they
<mvo> yeah, I was wondering if he might have used something like envy
<tjaalton> doesn't envy use the same version numbers as the official ones? the "Title" says that the package he tried to remove was 169.07+2.6.24.4-4.11
<tjaalton> er, version
<ubotu> New bug: #185311 in xorg (main) "hardy, locking assertion failure, xorg/libsdl" [Undecided,New] https://launchpad.net/bugs/185311
<mvo> tjaalton: I don't know :/
<jcristau> hmm #185311 is a bit worrying
<tjaalton> jcristau: yeah, I'll forward that upstream..
<jcristau> tjaalton: cool
<ubotu> New bug: #185321 in xfonts-utils (main) ""warning: /usr/lib/X11/fonts/misc does not exist or is not a directory" when installing a font" [Undecided,New] https://launchpad.net/bugs/185321
<tjaalton> heh, that ^^ bug was quickly fixed
<tjaalton> present on gutsy but not hardy
<ubotu> New bug: #185332 in linux-restricted-modules-2.6.24 (restricted) "can not enable nvidia driver" [Undecided,New] https://launchpad.net/bugs/185332
<ubotu> New bug: #185266 in linux-restricted-modules-2.6.24 (restricted) "Pixel errors" [Undecided,New] https://launchpad.net/bugs/185266
<bryce_> testing xserver with patches from q-funk and bartman... brb
<bryce_> I've finished updating, building, & testing q-funk's xserver patches
<bryce_> once we get feedback that these packages do address the issues they're supposed to, it'll be good to upload
<ubotu> New bug: #185365 in xserver-xorg-video-ati (main) "Bad artifacts at the border of screen with ATI Radeon 7000VE at 1440x900" [Undecided,New] https://launchpad.net/bugs/185365
<ubotu> New bug: #152304 in xserver-xorg-video-ati (main) "Xorg crashed with SIGSEGV in RADEONScreenInit()" [Medium,New] https://launchpad.net/bugs/152304
<ubotu> New bug: #185338 in xorg (main) "xubuntu live cd problems on sony vaio PCG-SRX87" [Undecided,New] https://launchpad.net/bugs/185338
<ubotu> New bug: #185121 in xserver-xorg-video-intel (main) "intel graphic i945 : high cpu usage" [Undecided,New] https://launchpad.net/bugs/185121
<ubotu> New bug: #185433 in linux-restricted-modules-2.6.22 "atheros wifi broken with gutsy update [madwifi]" [Undecided,New] https://launchpad.net/bugs/185433
<Q-FUNK> any FAQ on properly using displayconfig-gtk ?
<bryce_> Q-FUNK: I posted your patches for xserver for testing
<Q-FUNK> bryce_: yes, thanks, I noticed :)
<Q-FUNK> I'm currently trying to debug my laptop.  my initial run of displayconfig-gtk messed up my default mode.
<Q-FUNK> is there any way to reset that to whatever was detected at installation time?
<tjaalton> dpkg-reconfigure xserver-xorg
<Q-FUNK> pretty amazing the amount of damage displayconfig-gtk can accomplish
<Q-FUNK> it managed to really mess up the content of my gnome panels
<Q-FUNK> I wonder how I can selectively restore the content of the panels to defualt values
<tjaalton> they get confused without d-g
<tjaalton> as they did on my laptop occasionally
<tjaalton> *do
<Q-FUNK> tjaalton: it seems to have mostly restored-g ?
<Q-FUNK> tjaalton: erm, sorry, d-g ?
<tjaalton> some fullscreen GL games do that too
<Q-FUNK> tjaalton: found any way to restore the panel to defaults?
<tjaalton> nope.. just unlock and drag them :P
<Q-FUNK> argh
<ubotu> New bug: #185335 in xserver-xgl (universe) "The shadows of the windows do not show correctly (Intel GMA X3100) (dup-of: 175774)" [Undecided,New] https://launchpad.net/bugs/185335
<Q-FUNK> the list of modules loaded is no longer defined in xorg.conf since 1.3 ?
<Q-FUNK> somehow, dpkg-reconfigure server-xorg produced a config that reuslts in much slower performance than before the displayconfig-gtk mess
<ubotu> New bug: #15178 in linux-restricted-modules-2.6.15 (restricted) "fglrx hangs/crashes" [Medium,Incomplete] https://launchpad.net/bugs/15178
<ubotu> New bug: #29032 in linux-restricted-modules-2.6.15 (main) "athl0 atheros AR5212 identified but not finding access " [Medium,New] https://launchpad.net/bugs/29032
<ubotu> New bug: #185370 in xserver-xorg-video-intel (main) "[Hardy] Compiz fails with user switcher if both users have Compiz" [Undecided,New] https://launchpad.net/bugs/185370
#ubuntu-x 2008-01-24
<ubotu> New bug: #185532 in wacom-tools (main) "Enabling wacom extended input devices in hardy results in an xorg crash" [Undecided,New] https://launchpad.net/bugs/185532
<pwnguin> yawn
<pwnguin> heh
<pwnguin> that looks familiar
<pwnguin> which patches was bryce referring to earlier?
<pwnguin> cuz I'd like to request a small patch be added as well ;)
<pwnguin> https://bugs.freedesktop.org/show_bug.cgi?id=13961
<ubotu> Freedesktop bug 13961 in Server/general "xkbLEDs causes segfault on login" [Critical,New] 
<bryce_> heya
<Q-FUNK> hey
<ubotu> New bug: #45665 in xserver-xorg-video-nv (main) "kubuntu livecd garbled screen " [Medium,Incomplete] https://launchpad.net/bugs/45665
<ubotu> New bug: #181405 in linux-restricted-modules-2.6.24 (restricted) "[fglrx] aticonfig crashed with SIGSEGV (aticonfig --initial -f)" [Undecided,Confirmed] https://launchpad.net/bugs/181405
<bryce_> wooow there's a lot of angst on xorg@
<tjaalton> yep, interesting to read
<Q-FUNK> oh?
<tjaalton> discussing the benefits and downsides of merging the drivers back to xserver
<tjaalton> probably won't happen, but it was proposed
<Q-FUNK> going back to a monolithic X?
<jcristau> monolithic was about more than server+drivers
<tjaalton> right, that's why I didn't use the word :)
<ubotu> New bug: #56798 in linux-restricted-modules-2.6.15 (restricted) "shutdown, hibernate and nvidia" [Medium,New] https://launchpad.net/bugs/56798
<ubotu> New bug: #185634 in linux-restricted-modules-2.6.24 (restricted) "iSight doesn't work in Hardy Kernels" [Undecided,New] https://launchpad.net/bugs/185634
<ubotu> New bug: #185654 in linux-restricted-modules-2.6.24 (restricted) "hardy: fglrx needs amdpcsdb.default - doesn't start" [Undecided,New] https://launchpad.net/bugs/185654
<tjaalton> damn, google is fast
<tjaalton> that bug ^^ is the second hit when you search "amdpcsdb.default"
<ubotu> New bug: #151549 in xorg (main) "iMac 24" 1920x1200 screen resolution not detected" [Undecided,New] https://launchpad.net/bugs/151549
<bryce_> tjaalton: if we need to alter the H/V sync rates (modeline) used with a given video driver (i.e. cirrus), now that we're not putting that sort of stuff in dexconf, where is the proper place for it?
<jcristau> bryce_: fix the driver
<bryce_> jcristau: can you point me at an example?
<jcristau> i'm not sure what exactly you have in mind
<bryce_> to fix the driver to use the correct H/V sync rates
<jcristau> well it should get them from the monitor's edid
<tjaalton> trident is problematic as well, it goes into an endless loop when it doesn't have those values from xorg.conf
<tjaalton> yay for quality
<bryce_> in this case, I'm not sure there is valid edid (ddcprobe says edidfail)
<bryce_> it works if I specify a H/V refresh rate in xorg.conf, and I have a valid modeline for it
<bryce_> I could just plug it into dexconf, but am hoping to solve it in a more proper way
<tjaalton> bryce_: yes, I tried that as well
<jcristau> hmm, right, if edid fails, i guess there's not much the driver can do
<jcristau> standard vesa modelines don't work?
<bryce_> nope
<jcristau> sadness
<bryce_> jcristau: so you do not know of a way of solving this other than specifying it in dexconf?
<bryce_> we've got other similar bugs, and I'd sort of prefer learning the proper way, so I can solve them properly too
<jcristau> how would you get the values? ask the user?
<bryce_> no, I think it should be possible to detect that the user's in the kvm virtual environment and just set things up accordingly
<jcristau> oh, virtualization shit, ok
<jcristau> then yeah, probably adding that to dexconf would be easiest
<bryce_> ah, ok
<bryce_> hrm
<bryyce> tjaalton: we've uploaded the new dexconf for cirrus/qemu_kvm
<bryyce> oh btw, this morning I did the remaining xorg triage - we have 0 New bugs in xorg, xorg-server, -ati, -nv, and -intel
<bryyce> http://people.ubuntu.com/~bryce/Plots/ :-)
<tjaalton> hehe, that's cool
<tjaalton> bryce: there were other changes waiting for an upload in git
<tjaalton> but I'll make sure they are uploaded before alpha4
<tjaalton> and gone again ->
<ubotu> New bug: #57403 in linux-restricted-modules-2.6.17 (restricted) "Can no longer aquire IP address from certain DHCP servers" [Undecided,New] https://launchpad.net/bugs/57403
#ubuntu-x 2008-01-25
<ubotu> New bug: #179020 in linux-restricted-modules-2.6.24 (restricted) "[Hardy 8.04 alpha-2, nVidia proprietary driver]  Display resolution randomly starts at low resolution instead of the chosen resolution when using nVidia proprietary driver but not a problem with open-source driver.  New nVidia proprietary driver is in the updated Ubuntu restricted repository.  It fixes the problem." [Undecided,Fix released] https://launchpad.net/bugs/179020
<pwnguin> hey
<pwnguin> linux wacom released yesterday
<pwnguin> odd
<pwnguin> does debian host linux-wacom work now?
<ubotu> New bug: #185797 in linux-restricted-modules-2.6.24 (restricted) "package linux-restricted-modules-2.6.24-4-generic 2.6.24.6-4.15 failed to install/upgrade: failed in buffer_write(fd) (10, ret=-1)" [Undecided,New] https://launchpad.net/bugs/185797
<ubotu> New bug: #154162 in linux-restricted-modules-2.6.22 "[fglrx] GUI does not display with accelerated graphics" [Undecided,New] https://launchpad.net/bugs/154162
<ubotu> New bug: #185747 in linux-restricted-modules-2.6.24 (restricted) "aticonfig crashed with SIGSEGV in xf86nameCompare() (dup-of: 181405)" [Undecided,New] https://launchpad.net/bugs/185747
<tjaalton> bryce: do you have a debdiff of the xorg changes? they need to be pushed to git
<bryce_> tjaalton: yes
<bryce_> tjaalton: http://people.ubuntu.com/~bryce/Uploads/xorg_7.3+10ubuntu3.debdiff
<tjaalton> thanks
<ubotu> New bug: #185873 in xorg (main) "Lenovo R61: nv driver freezes system" [Undecided,New] https://launchpad.net/bugs/185873
<ubotu> New bug: #185879 in wacom-tools (main) "loading wacom breaks server (signal 11) during start of gnome-session" [Undecided,New] https://launchpad.net/bugs/185879
<ubotu> New bug: #185992 in linux-restricted-modules-2.6.24 (restricted) "3D acceleration disabled in Fglrx" [Undecided,New] https://launchpad.net/bugs/185992
<ubotu> New bug: #36462 in linux-source-2.6.15 (main) "optical mouse problem" [Medium,Incomplete] https://launchpad.net/bugs/36462
<ubotu> New bug: #186027 in totem (main) "[Hardy] totem when playing an audio file windowed corrupts the screen (dup-of: 103839)" [Undecided,New] https://launchpad.net/bugs/186027
#ubuntu-x 2008-01-26
<Q-FUNK> bryce: here, I have no Hardy host.  However, I think that Gadi or Bart might have one.
<ubotu> New bug: #186084 in xorg (main) "touchpoint device not configured" [Undecided,New] https://launchpad.net/bugs/186084
<ubotu> New bug: #155226 in linux-restricted-modules-2.6.22 "tearing artifacts in window effects, videos" [Undecided,New] https://launchpad.net/bugs/155226
<ubotu> New bug: #153705 in linux-restricted-modules-2.6.22 "[nvidia]strange artifacts" [Undecided,New] https://launchpad.net/bugs/153705
<ubotu> New bug: #186104 in linux-restricted-modules-2.6.22 "[nvidia]Artifacts in the Desktop Wall compiz plugin" [Undecided,New] https://launchpad.net/bugs/186104
<ubotu> New bug: #155458 in linux-restricted-modules-2.6.22 "Blank screen after switching users" [Medium,Confirmed] https://launchpad.net/bugs/155458
<ubotu> New bug: #186128 in xorg (main) "Random Visual Glitch (Occurs Sometimes, Sometimes Not)" [Undecided,New] https://launchpad.net/bugs/186128
<ubotu> New bug: #150859 in linux-source-2.6.22 "Prism Wifi connection losing packets and being slow" [Undecided,New] https://launchpad.net/bugs/150859
<ubotu> New bug: #185957 in mesa (main) "After install nvidia 169.09 drivers with Envy" [Undecided,New] https://launchpad.net/bugs/185957
<ubotu> New bug: #186204 in xorg (main) "X hangs the computer after upgrade to Gutsy" [Undecided,New] https://launchpad.net/bugs/186204
#ubuntu-x 2008-01-27
<ubotu> New bug: #186257 in xorg (main) "[Gutsy] Xorg initialises with wrong refresh rate" [Undecided,New] https://launchpad.net/bugs/186257
<ubotu> New bug: #94019 in linux-restricted-modules-2.6.20 (restricted) "screensaver breaks gamma correction of ati fglrx" [Undecided,New] https://launchpad.net/bugs/94019
<ubotu> New bug: #186354 in xorg-server (main) "X server has huge memory leaks" [Undecided,New] https://launchpad.net/bugs/186354
<ubotu> New bug: #186382 in linux-restricted-modules-2.6.24 (restricted) "[hardy] gtk window decorator somtimes draws decoration ugly or not at all" [Undecided,New] https://launchpad.net/bugs/186382
<ubotu> New bug: #185440 in xorg (main) "[Hardy] Toshiba laptop screen at max 800x600 rather than 1024x768 " [Undecided,New] https://launchpad.net/bugs/185440
<johanbr> bryce: I'm too lazy to register on your blog, but thought you might like to know that some of the clock applet issues you mentioned are tracked in gnome bug 511228.
<ubotu> Gnome bug 511228 in clock "Clock applet does weird things" [Normal,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=511228
<johanbr> Oh, the bug bot is smart enough to tell the difference between gnome bugzilla and launchpad.
<pochu> and debian bts and fdo and mozilla bugs and... :)
<bryce> johanbr: figured as much
<bryce> johanbr: actually looks like only two issues are listed there
<johanbr> bryce: Right. But I think those are the worst two. :)
#ubuntu-x 2009-01-19
<seb128> bbl
<ogra> tjaalton, i didnt finish the xserver stuff on the weekend, but i confirmed that the input stuff works on real HW, so i assume its something missing in the qemu kernel i use
<ogra> (using the same image/rootfs where it didnt work in qemu)
<tjaalton> ogra: nice, it helps to narrow down the possibilities. rebuilding the xserver shouldn't matter
<ogra> right
#ubuntu-x 2009-01-20
<bryce> tjaalton: whoa @ tdflanders on 318276
<raof> That's pretty weird, yes.
<bryce> heya raof, how goes?
<raof> Pretty all right.
<raof> gnome-do's sauntering towards a release, which is nice.
<raof> nouveau should be all ready to go shortly, and it's not waiting on me :)
<bryce> :-)
<raof> Although someone needs to put the headers back in libdrm-dev before the DDX will build again (at which point I'll merge the new debian version)
<mvo> nowdays ctrl-alt-backspace is disabled, right? is there a way to re-enable it?
<tjaalton> mvo: yes, Option DontZap
<mvo> thanks tjaalton
<Alexia_Death_> tjaalton: Wacom has a new package out that contains a bulid switch to navigate around the crash issue.
<Alexia_Death_> tjaalton: and the buttons patch does not apply on top of all other patches already in the xorg core package :(
<Alexia_Death_> tjaalton: and a question about udev rules for wacoms. How are they maintained and are they cast in iron? My hotplug daemon pesumes some logic from them so Id like to make it come with its own rules. It should be ok as long as /dev/input/wacom is still made.
<tjaalton> Alexia_Death_: grab the package and look
<tjaalton> the source
<tjaalton> whee, nouveau made it in
<tjaalton> nouveau-kernel-source
<Alexia_Death> tjaalton: what package is that?
<Alexia_Death> tjaalton: ignore that question. Stupid me. apt-file tells me that.
<tjaalton> Alexia_Death: wacom-tools
<tjaalton> the rules are maintained theree
<tjaalton> -e
<Alexia_Death> thats not what apt-file told me the rules were from...
<Alexia_Death> xserver-xorg-input-wacom was what apt-file returned...
<tjaalton> yes, but the source package is wacom-tools..
<Alexia_Death> aah...
<Alexia_Death> thanks
<Alexia_Death> tjaalton: are you aware of any dependendcies related to the udev rules used? Because I have looked at udev ruleset from fedora and find it a lot better for organizing the devices...
<tjaalton> Alexia_Death: nope
<tjaalton> haven't looked at it
<Alexia_Death> so replacing them if needed should not be a problem?
<tjaalton> well better discuss it with the debian maintainer
<Alexia_Death> Alternatively the hotplug daemon can just install its own set of higher priority rules but that would be rather dirty.
<tjaalton> talk to Ron, he's quite reasonable
<pcjc2> Hi tseliot
<tseliot1> pcjc2: hey, I've just replied in the bug report
<tseliot1> pcjc2: I would like to try the fix here too
<pcjc2> Its odd you can't reproduce the symptom of the slow probe for the GetScreenSizeRange request
<pcjc2> are you using an intel card?
<tseliot1> yep
<pcjc2> this problem has some strangeness to it
<pcjc2> like, its not obvious why it was never a problem in the past
<pcjc2> Either the probes weren't expensive, didn't succeed, or the notifications never got through
<pcjc2> I think the support for changing backlight via a property is relatively new - and a prerequisite for the bug
<pcjc2> but I was using the new intel driver long before I ever saw the problem
<tseliot1> pcjc2: I think the backlight property existed in 1.2 too
<tseliot1> maybe the notifications didn't go through until the upgrade of libxrandr
<pcjc2> that was my pet theory
<tseliot1> which would be weird
<tseliot1> but not unlikely ;)
<pcjc2> there was some brokenness on the wire-protocol for some of those notifications, which got fixed in the upgrade
<pcjc2> in theory, the notifications give the interested application enough information so it shouldn't need to call Xrandr
<tseliot1> yes but it never worked in the randr applet
<tseliot1> which might confirm your theory
<pcjc2> That is hidden by GDK unfortunately, so apps doing this "properly" need either to work with Xrandr directly, or GDK needs to proxy the information better
<pcjc2> interesting.. it does begin to sound like there is a picture forming.
<pcjc2> GTK / GDK doesn't make it easy to write "good" remote X11 apps
<pcjc2> I've got to dig through a load of problems with gEDA/gschem over remote X11 connections
<pcjc2> (Rather.. see if we can do anything to improve the performance).
<tseliot1> hehe
<pcjc2> Round-trips to the server -> high latency -> bad user experience.
<pcjc2> Assuming the apps are local is a luxury ;)
<pcjc2> with regards testing the server's Xrandr extension version at run-time
<pcjc2> I'll grant that it is unlikely you want to be running gnome-power-manager remotely
<pcjc2> but if you're hosting a server serving thin clients, you may find the X11 proxy / server used for that doesn't support the new extension.
<pcjc2> In the thin-client case, the whole gnome-desktop fires up as normal, power-manager included. (Although it is unlikely it would be changing the backlight brightness of the remote X11 server, those code-paths are still "live")
<tseliot1> ok, I have no experience with thin clients, this is why I asked
<pcjc2> last time I tried, I quickly came to the conclusion that they weren't commonly used
<pcjc2> had to debug some rather odd issues
<pcjc2> I might be setting up another thin-client server some time over the coming month (the last one's hardware died), so I'll have to revise this all again!
<tseliot1> ok, let me know then
<pcjc2> That was a SuSE box - due to the political reasons here
<tseliot1> new use-cases should lead to better testing
<tseliot1> oh
<pcjc2> The University has a site-license support contract with Novell, and that's what our IT manager installed on the server for me when we got it.
<pcjc2> Ubuntu is among a select few approved Linux operating systems here.. added because I asked nicely ;)
<pcjc2> Fedora is banned, as is MacOSX!
<tseliot1> hehe
<pcjc2> The only reason to use SuSE was so the IT admin guys could manage the machine for me - keep me doing my real work, but I might stick Ubuntu server on once we've figured what part of the machine is fried
<tseliot1> can't the admin use Ubuntu?
<jcristau> tjaalton: ooh, your mesa patch made it to rc3
<pcjc2> I'm sure he could use Ubuntu.. just that all the University / Engineering Department servers run SuSE, and have locally mirrored security fixes etc..
<tseliot1> ok
<pcjc2> having a SuSE box I'm "root" on is also handy.. since I put together customised SuSE packages gEDA for the Engineering Department.
<pcjc2> got to go now..
<pcjc2> bye!
<tseliot1> bye
<tseliot1> too late
<tjaalton> jcristau: whee, nice :)
<tjaalton> raof: so you wanted to have the nouveau headers in libdrm-dev?
<raof> tjaalton: Yes.  They're not going to be shipped with the kernel anytime soon.
<tjaalton> right
<raof> And since we already have the DDX synced, and nouveau-kernel-source just needs to make it through NEW...
<tjaalton> already accepted ;)
<raof> Sweet.
<raof> With the headers I can pull in some bugfixes from the new debian package
<raof> Heh.  Now in _binary_ new :)
<tjaalton> of course
<tjaalton> I'm waiting for the new kernel to arrive first
<jonpackard> Hello. My X unexpectedly restarted on me twice today, both time when I was clicking and dragging on a menu (different applications). The second time I grabbed my Xorg.0.log.. could anybody please take a look at it to help me pinpoint the problem? http://ubuntu.pastebin.com/f3881c852
<crevette> ah this is the same crash I had the previous week
<tjaalton> it's nvidia, so..
<jonpackard> yeah =X
<tjaalton> you can try getting a better backtrace though https://wiki.ubuntu.com/X/Backtracing
<jonpackard> Thanks tjaalton!
<jonpackard> The only thing I've changed today was installing moonlight in firefox.. I uninstalled it and will see if it happens again.
<tjaalton> the trace doesn't mentio nvidia_drv, so it might be a valid bug
<tjaalton> worth getting a gdb trace
<jonpackard> thanks again.. gotta run :)
<tjaalton> me too -> zzz
#ubuntu-x 2009-01-21
<Alexia_Death_> Hands up wo is going to LGM?
<tjaalton> LGM?
<bryce> libre graphics meeting
<crevette> hello
<bryce> heya
<tjaalton> hi bryce
<bryce> hi tjaalton
<tjaalton> when the new kernel upload is in the archive, I'll upload libdrm/mesa/-intel
<bryce> night
<tjaalton> wow, usplash totally hosed my nvidia based ws
<tjaalton> ogra_: pitti has uploaded a new hal that'll default using evdev for touchpads, could you try and see how it works?
<ogra_> tjaalton, sure ... though we dont have any way to calibrate yet (and i dont have a jaunty setup atm (working with my arms deeply in ARM stuff :) )
<ogra_> so i cnt promise i can do it right away
<tjaalton> sure, no rush
<tjaalton> just that you know it's out there :)
<tjaalton> hmm, nouveau-kernel-source already includes the drm headers..
<tjaalton> ..but unusable for the ddx driver
<TomJaeger> Hi.  Is anybody here running the closed-source nvidia or ati driver?  You could do me a huge favor.  It'll only take a few seconds.
<TomJaeger> Basically, I'd need someone to run the test program attached to this comment: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/217908/comments/33
<ubottu> Launchpad bug 217908 in xorg-server "Images in Firefox and Opera are extremely pixeled when zoomed" [Undecided,Confirmed]
<TomJaeger> For the open-source drivers, I could just look at the source (they're all broken - except for intel, but trivial to fix)
<TomJaeger> Also, is there a way to give me power over the bug -- there's quite a few status changes that I'd like to make
<TomJaeger> nevermind, I see I can actually change things
<tjaalton> uh oh.. what is dontzap?
<jcristau> tjaalton: wondered the same thing. seems weird to put that kind of stuff in an own package, but oh well..
<tjaalton> jcristau: yeah.. I thought the x-kit stuff was enough
<tjaalton> or would be, when it's released
<tjaalton> I also noticed that mandriva has actually patched their xserver to not care about the ABI for nvidia/fglrx
<raof> But I see (new) glitches with nvidia + IgnoreABI.  Are these not related at all?
<jcristau> who knows...
<tjaalton> raof: what kind?
<raof> tjaalton: Parts of windows being painted entirely black.
<tjaalton> raof: so nouveau_drm.h is all that's needed for libdrm-dev?
<raof> tjaalton: I believe I listed all the necessary files on the bug.  nouveau_drm is one, but there are more, I think.
<tjaalton> the rest seems to be specific to the drm driver
<tjaalton> a bug?
<raof> tjaalton: I commented on the "please remove these from libdrm-dev" bug; it was open at the time?
<tjaalton> raof: ok, well I checked the headers and _drm.h should be the only one that the ddx driver uses
<raof> Cool.
<tjaalton> they all are also in the kernel-source package, and used by the drm driver
<tjaalton> but _drm.h should be the only one for userspace
<andersk> raof: the nvidia compiz problem is bug 269904.  It seems to be a design flaw in the DAMAGE protocol; see Aaron Plattner's comment. 
<ubottu> Launchpad bug 269904 in nvidia-graphics-drivers-177 "Screen refresh problems with nvidia on intrepid" [Medium,Confirmed] https://launchpad.net/bugs/269904
<raof> andersk: I don't think that's it; this only turned up in -180
<raof> At least, I only _remember_ this turning up in 180
<andersk> I hadn't seen it in 177, but I was also using different PowerMizer settings then.  It seems to happen more often in low power mode. 
<raof> Thinking of PowerMizer... :(
<raof> Wouldn't it be great if the whole screen didn't flash black whenever the card changes state?
<andersk> Well, that's in fact why I had been using different PowerMizer settings. 
 * raof would accept a nouveau driver that resumed from suspend, too.
<raof> andersk: Locking it on minimal?  How does one do that?
<andersk> I put this into a new file in /etc/modprobe.d: 
<andersk> options nvidia NVreg_RegistryDwords="PerfLevelSrc=0x2222" 
<andersk> But I forget whether that locks it on minimal or on maximal. 
<raof> Aaah.
#ubuntu-x 2009-01-22
<bryce> heya all
<bryce> dad did great with his surgery, the doctors are all very happy with his progress, and sounds like he'll be heading home within a week or so.
<bryce> tjaalton: how are things for xserver/-intel/-mesa?
<superm1> bryce, i think nothing is still building because of https://lists.ubuntu.com/archives/kernel-team/2009-January/004178.html
<bryce> superm1: ok thanks
<bryce> superm1: heya btw.
<superm1> bryce, hiya.  seeing you pop in reminds me.  i've got a couple more platforms that appear that they wont come into X with vesa that i'm hearing of.  I should eventually be seeing some hardware for some of them.  if they are similar in that 8.04's vesa works but 8.10 and 9.04's dont, do you have ideas for what's changed to make it more stringent off hand?
<bryce> hmm
<superm1> or perhaps some proactive changes that might help for when the hardware does show up
<superm1> if perhaps it's similar to that nvidia based problem that i posted
<bryce> well, I'd start by comparing the modelines from 8.04 vs. later
<bryce> upstream had some changes to how those were calculated and there's a slight chance that those changes could break some chipsets
<bryce> (like we already saw on that one Dell system)
<superm1> yeah
<bryce> -vesa is pretty low level and pretty simplistic, so if there's a regression it's more likely going to be in the xserver or kernel
<bryce> so a second step would be to try booting an earlier kernel or an earlier xserver to see if either of those changes makes a difference
<bryce> kernel's probably easier to vary
 * superm1 nods
<bryce> if you can rule out kernel and modelines, then that strongly points to xserver badness
<superm1> and possibly being those small calculation differences then
<bryce> maybe also test booting with xdm or some other wm to rule out window manager naughtiness
<superm1> okay well great thanks for the tips.  i'll try to get one of these thats getting these reports as soon as i can
<bryce> sure
<tjaalton> bryce: nice to hear!
<tjaalton> bryce: the kernel probably is in the archive now, so I'll start uploading soon
<tjaalton> ..but it sure would be nice to find my phone
<tjaalton> oh, so the kernel upload was busted.. damn
<bryce> tjaalton: heya
<tjaalton> howdy ho
 * bryce catching up with email
<tjaalton> I reinstalled my desktop at work, and seems that usplash hangs on it (GF8600)
<tjaalton> I get a series of loud beeps etc
<tjaalton> oh and a blank screen
<bryce> eek
<bryce> kernel?
<tjaalton> possibly
<tjaalton> I happened to have bootchart installed, so I got a graph where it clearly shows that it's hung (eats the second cpu)
<tjaalton> er, core
<tjaalton> oh and when it finishes, X won't start
<tjaalton> just hangs, when it does work without usplash
<tjaalton> oh well, first I need to get my sound back
<bryce> ouch, sounds like you need a Real OS.  I hear Win7 is just around the corner...
<tjaalton> yeah, I need to download that sucker right away
<bryce> ;-)
<tjaalton> oh, so the gui is postponed?
<bryce> tjaalton: yeah
<tjaalton> heh, -nv fails to drive this 30" monitor
<tjaalton> "no modes"
<bryce> erf
<raof> tjaalton: And how about nouveau :P
<tjaalton> raof: heh, haven't tried yet :)
<bryce> night
<tjaalton> night bryce
<tjaalton> apparently there are going to be "some imminent nvidia releases", which should support the new ABI
<tjaalton> hrm, why oh why can't I assing a mouse button as a shortcut..
<tjaalton> *assign
<jcristau> any reason why libxi can't be synced from experimental?
<tjaalton> let me check
<jcristau> would allow to sync xinput too, i uploaded the 1.4.0 release
<tjaalton> well.. we already ship XInput in libxi-dev :/
<jcristau> argh. forgot about that.
<jcristau> what a mess.
<tjaalton> but that should be the only change
<tjaalton> yeah, but it's there waiting for libxi-2.0 :)
<jcristau> 10 years from now it'll be ok :)
<tjaalton> damn realist ;)
<superm1> tjaalton, "releases"?  as in not just -180?
<tjaalton> superm1: don't know..
<superm1> where did you see the reference on that?
<tjaalton> oh, yes the quote was from aaronp
<tjaalton> on #xorg-devel
<tjaalton> 02:47 < aaronp> keithp: ping?  You're the 1.6 release manager, right?  We've got some imminent  releases and I need to know whether I can mark ABI5 as no longer needing  -ignoreABI.
<superm1> ah neat
<tjaalton> Xlib:  extension "XFree86-Misc" missing on display ":0.0".
<tjaalton> I get those on .xsession-errors
<tjaalton> oh, it was removed :)
<bryce> heya
<tjaalton> hi there
<tseliot> hey bryce
#ubuntu-x 2009-01-23
<tjaalton> bryce: I'm tempted to use git for -intel.. since we need to pull in a number of commits from master for it to build
<tjaalton> I've got mesa & libdrm ready, but intel needs some work still
<bryce> tjaalton: I'd be disappointed to see that
<tjaalton> ok then
<tjaalton> merging by hand is not that straightforward, since grab-merge.sh doesn't work with experimental
<tjaalton> well, it's MoM that doesn't, but anyway
<tjaalton> libdrm & mesa uploaded
<tjaalton> and intel too
<bryce> \o/
<tjaalton> Alexia_Death: what patch did you need to xorg-server?
<soren> I'm running Jaunty on my laptop, and my X performance alternates between decent and abysmal. In the latter case, the mouse curser "jitters" somewhat when I move it around the screen, and X eats almost an entire CPU core. Disabling compiz didn't help at all.
<soren> I would say it's decent around 15% of the time, and absolutely horrible the other 85% of the time.
<soren> Oh, the graphics card is a intel 945, by the way.
<tjaalton> soren: I've uploaded a new libdrm/mesa/intel, so report back if those are any better or worse
<soren> tjaalton: When was this?
<soren> tjaalton: Ah, 48 minutes ago, according to launchpad :)
<soren> I'll wait a bit.
<crevette> soren, 1 hour ago
<soren> :)
<tjaalton> right, it'll take a while since libdrm needs to be built & published first
<soren> Right. I'll give the ones in xorg-edgers a chance until then..
 * soren restarts X
<tjaalton> hmm, I wonder if you are seeing bug 307306
<ubottu> Launchpad bug 307306 in gnome-power-manager "upgrade to 2:1.2.99.2-0ubuntu1 makes session utterly slow" [High,In progress] https://launchpad.net/bugs/307306
<tjaalton> lunch ->
<soren> tjaalton: I've just taken gnom-epower-manager out of the equation, and it's still really, really slow.
<tseliot> soren: what's the problem?
<tseliot> or what are the symptoms?
<tseliot> does killing the gnome-settings-daemon help?
<soren> tseliot: Mouse pointer jitters as I move it around the screen, and performance is absolutely horrible.
<soren> About 85% of the time.
<tseliot> soren: kill the gnome-settings-daemon
<soren> Right now, I'm experiencing the lovely 15% of the time, where everything is fine, so I'm trying to get some work done while it lasts :)
<tseliot> upstream hasn't adopted my latest patches yet
<tseliot> soren: or, if you want, you can apply the patch attached in comment 10 directly: http://bugzilla.gnome.org/show_bug.cgi?id=568160
<ubottu> Gnome bug 568160 in libgnome-desktop "Gnome Settings daemon causes high CPU usage with an expensive call" [Major,Resolved: fixed]
<soren> tseliot: Thanks for the hint. I'll look at it when it starts happening again.
<tseliot> ok
<tjaalton> sigh, missing comma in libdrm's debian/control
<tjaalton> the result was that libdrm-dev didn't depend on the new linux-libc-dev
<tjaalton> and why do the buildd's use an older version of xserver-xorg-dev..
<tjaalton> would've thought they always fetched the latest one
<tjaalton> hmm, actually it is the latest one
<tjaalton> since I didn't upload the merge yet, duh
<tjaalton> new synaptics merge uploaded
<soren> tjaalton: The buildd's should always use the most recent version of everything.
<tjaalton> soren: yes, it was my mistake
<soren> Right, I just wanted to confirm anyway. :)
<tjaalton> I'll remember now :)
<tjaalton> too bad that the ports archs have an outdated kernel, so basically nothing will build on them until they are updated to .28
<tjaalton> nothing X related.. drivers, server etc
<tjaalton> tseliot: you aware of the nvidia bug where after a while (~days) of using compiz the contents of new windows are not refreshed?
<tseliot> tjaalton: no, what bug is it?
<tjaalton> I thought it was a bug fixed long ago, but still happens in 180.22 (was using 169.12 on hardy before..)
<tjaalton> well, I just described it, but I guess no-one else is using a 30" monitor :)
<tjaalton> so I guess the video memory is exhausted or something
<tseliot> what resolution are you using?
<tjaalton> 2560x1600
<tjaalton> and sometimes when I unlock the screensaver, the whole screen is behaving like that. every redraw is painfully slow
<tjaalton> but that can be fixed by visiting a vt briefly
<tseliot> a memory leak, perhaps?
<tjaalton> maybe
<tseliot> also, can you try to reinstall nvidia-glx-VERSION and restart X
<tseliot> ?
<tjaalton> restarting X helps, but I don't think a reinstall is needed
<tjaalton> guess I need to file this
<tseliot> an update of X made the system very slow here, even without breaking direct rendering
<tseliot> it's because of a bug which I have to fix
<tjaalton> which bug?
<tseliot> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180/+bug/309116
<ubottu> Launchpad bug 309116 in nvidia-graphics-drivers-96 "when removing nvidia-glx-177 /usr/lib/libGL.so is gone" [Medium,In progress]
<tseliot> it's easy to fix
<tjaalton> ok
<tjaalton> hmm, the nvidia problem might be due to "powermizer"
<tseliot> powermizer?
<tseliot> too bad it's closed source, otherwise I wouldn't mind fixing it myself
<tjaalton> bug 270377 for instance
<tjaalton> and several threads on nvnews
<ubottu> Error: Could not parse data returned by Launchpad: Unknown host. (https://launchpad.net/bugs/270377/+text)
<tjaalton> sigh
<tjaalton> https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/270377
<ubottu> Error: Could not parse data returned by Launchpad: Unknown host. (https://launchpad.net/bugs/270377/+text)
<tjaalton> wrong package though
<tseliot> tjaalton: did you subscribe Aaron Plattner to the bug
<tseliot> ?
<tjaalton> no
<tjaalton> looks like he's well aware of it :)
<tjaalton> at least should be
<tjaalton> the driver could install the modprobe file to work around it
<tseliot> :-/
<tjaalton> duh, the amd64 buildd seems to be busy or broken somehow
<tjaalton> busy it seems..
<tseliot> what modprobe file?
<tjaalton> a file to add options for the module
<tjaalton> /etc/modprobe.d/*
<tjaalton> https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/270377/comments/32
<ubottu> Launchpad bug 270377 in nvidia-graphics-drivers-180 "content of window do not redraw automatically (intrepid)" [Undecided,Confirmed]
<tseliot> does it affect only some specific models?
<tjaalton> I don't know
<tseliot> as I would like to implement some quirks module for Jockey sooner or later
<tseliot> tjaalton: I've just tried my patch for the "nv" driver to add the support for my card and it works
<tseliot> I'll send it to Aaron Plattner
<tseliot> shall I also file a bug report about it on launchpad?
<tseliot> just to keep track of things?
<mnem0> tjaalton: I was hit by that intel waitForVBlank freeze bug and I had tested the "dont enable vblanks on disabled pipes" drm patch which worked great on my machine... but today when the .28-5 kernel installed my intel G45 machine got unbootable --> https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/320525
<ubottu> Launchpad bug 320525 in linux-meta "jaunty unbootable on intel G45 since .28-5 kernel update" [Undecided,New]
<tjaalton> mnem0: checkint
<tjaalton> uh
<tjaalton> -ing
<tjaalton> mnem0: uh.. .NEF
<tjaalton> please attach only jpegs or so
<mnem0> tjaalton: sry I converted it before but then I attached the wrong file.. I attached jpg as well now
<mnem0> plus xorg logs and dmesg
<mnem0> will check without usplash in a sec
<bryce> <bryce> jdstrand: hmm
<bryce> <jdstrand> bryce: failsafe mode does give me this:
<bryce> <jdstrand> (EE) open /dev/fb0: No such file or directory
<tjaalton> bryce: what's that?
<bryce> jdstrand ran into that after upgrading to latest X bits (but not -intel)
<bryce> he's run into a situation where it doesn't start up, and failsafe mode is also failing with corrupted screen
<jcristau> logs or it didn't happen ;)
<bryce> I suggested he update to the newest -intel
<bryce> jcristau: heh
<jdstrand> bryce: amd64 -instal is still in 'needs building'
<bryce> jdstrand: price of admission is posting your Xorg.0.log[.old] files somewhere we can see them
<jdstrand> -intel
<tjaalton> the thing is that the other amd64 buildd is stuck with qt4-x11
<tjaalton> so amd64 is left behind
<bryce> tjaalton: do the changes require a rebuild of the driver (or maybe just -intel)?
<jdstrand> I can post the logs, but it seems maybe I just don't have the necessary bits cause of poor upgrade timing
<tjaalton> bryce: if it failed to build, then just retrying is enough
<tjaalton> but "needs building" means that the queue is just too long
<tjaalton> yellow(amd64 buildd) has been building qt4-x11 for three days now
<bryce> tjaalton: no I mean, would using a new xserver/mesa with old -intel cause problems (e.g. ABI mismatches)?
<tjaalton> I know for a fact that with the old intel and new libdrm X won't start
<bryce> three days??
<jdstrand> Xorg.0.log: http://paste.ubuntu.com/108701/
<tjaalton> bryce: yes
<bryce> tjaalton: aha
<tjaalton> and without the new mesa compiz fails
<jdstrand> Xorg.0.log.old: http://paste.ubuntu.com/108702/
<tjaalton> but this is jaunty so I didn't feel like adding a bunch of Breaks :/
<bryce> tjaalton: do you think it'd make any difference if he were to manually rebuild the old 2.5 -intel against the new X bits?  e.g. is it just ABI breakage, or API stuff too?
<tjaalton> bryce: no idea.. I reported that upstream and they asked if 2.6 works. when it did, they closed the bug :)
<tjaalton> better just grab the new source and build that
<jdstrand> bingo!
<tjaalton> yeah, the logfile matches mine
<bryce> ok cool
<tjaalton> mnem0: maybe the same issue for you then
<jdstrand> bryce: apparently I did *not* downgrade libdrm2, just libdrm-intel1
<bryce> jdstrand: aha, that could do it
<jdstrand> bryce: I put both at 2.4.1-0ubuntu9 and it started
<mnemo> aha, did you downgrade libdrm-intel1 by mistake or what happened?
<jdstrand> \o/
<tjaalton> that works
<jdstrand> mnemo: both upgraded without the new -intel. during triage, I only downgraded the one
<tjaalton> damn g-s-d keeps crashing on me
<tjaalton> bryce: btw, the new mesa now uses vblank for intel, because the drm drivers were fixed. It means that we'll get a ton of bugreports saying 'glxgears showing only 50fps!!!1!' :P
<bryce> awesome
<tjaalton> it's been the default since 7.1, but it was fixed only recently (jbarnes)
<tjaalton> so we had it disabled
 * bryce nods
<bryce> was wondering about that
<bryce> keithp mentioned it to me a while back and wondered when it'd hit ubuntu :-)
<tjaalton> I git-bisected it last summer
<tjaalton> my laptop froze when the display was turned off
<tjaalton> by the screensaver
<bryce> tjaalton: do fps == refresh rate exactly now?
<tjaalton> yes
<jcristau> in general, fps <= refresh rate. in glxgears, it's ==
<tjaalton> at least in glxgears
<bryce> ok
<bryce> so regarding the worry of user complaints I think it should be straightforward to explain
<pwnguin> speaking of glxgears
<bryce> if we see a lot of bug reports to this affect I can probably rig up an automated reply
<tjaalton> bryce: yes; 'glxgears is not a benchmark'
<bryce> er, s/affect/effect/
<pwnguin> doesn't it require -iacknowledgethisisnotabnechmark option?
<jcristau> glxgearsisnotabenchmarkkthxbye
<jcristau> pwnguin: not anymore, sadly
<pwnguin> jcristau: any reason not to put it back?
<bryce> users don't appear to know what a benchmark is anyway
<mnemo> could someone explain to me what it means to have vblank enabled versus disabled? and also why would that result in lower fps in glxgears? and finally who is that lower FPS count not a problem?
<pwnguin> heh
<bryce> lol
<tjaalton> mnemo: you don't see the "extra" fps anyway
<bryce> mnemo: sure
<bryce> your monitor can only show a certain number of frames per second
<pwnguin> vblank is the interrupt that tells the hardware a new frame can be drawn
<bryce> this is called your "refresh rate"
<mnemo> right vblank used to be when the electron beam returned to the other side of the screen or somethin right?
<pwnguin> enabling vblank handling means you only need to render when a new frame is available to display
<bryce> for LCD's, 60 hz is common
<mnemo> rights to LCD is 60 FPS sort of?
<pwnguin> when its disabled, the fps count is lying to you
<bryce> so the xserver/-intel is now being **really clever** and timing its screen draws to match what your hardware is actually capable of
<bryce> so if it were putting out 120fps, your monitor would only show every other one anyway
<mnemo> aahh so with vblank enabled im actually saving some CPU by not wasting time rendering frames that wont be shown anyway?
<pwnguin> matching fps to refresh rate should reduce power consumption
<bryce> so why bother?  save some processor cycles and only send the ones that are actually going to get drawn
<tjaalton> mm, dogfood
<bryce> it's very cool
<pwnguin> mnemo: well, it gets a bit complicated, but basically yes
<mnemo> that seems like a very nice feature indeed
<pwnguin> if look up double-buffering in wikipedia
<bryce> but yeah this means glxgears is going to show much different fps measurements
<pwnguin> s/if//
<mnemo> mmkay makes sense
<tjaalton> I actually get over a 1000 now without vblank :)
<pwnguin> glxgears is a shitty measurement though
<bryce> I think we can say if your glxgears fps match your monitor refresh rate, you're running optimally
<tjaalton> on 965
<pwnguin> glxgears numbers track "buffer clearing" speed
<bryce> tjaalton: heh, you realize people are going to turn off vblank now, as a "performance improvement"  ;-)
<pwnguin> ie how fast your hardware can clear out the old frame for a new one
<tjaalton> bryce: I bet.. "here's my xorg.conf, you can use it"
<bryce> it'll be worth chuckles
<tjaalton> there were posts like that on nvnews.net.. showing everything like what modules to load and stuff
<pwnguin> glxgears has no textures, barely any geometry, no lighting, or anything relevant to the apps users actually care about
<pwnguin> you could probably replace glxgears with "grep (ati|nvidia|fglrx) /var/log/Xorg.0.log" and not lose any information
<bryce> heh
<bryce> we could be clever and hack glxgears to replace the printouts of xxx fps with % refresh rate
<bryce> so it'd print 100% 101% 99% 100% ...
<tjaalton> "don't touch the mouse!"
<tjaalton> (to keep it ~100%)
<bryce> ;-)
<tjaalton> oh, aaronp posted on the "x-server breakage" forum thread, and confirmed that the next releases will support 1.6
<bryce> yep, I saw a reply from him in one of the -nvidia bug reports saying similarly
<bryce> I need to email them again... monday maybe
<andersk> The most recent Jaunty updates caused two problems.  First, my touchpad is moving around the screen way faster than normal. 
<andersk> And second, if I drag any window to any edge of the screen, it immediately jumps to the upper-left corner. 
<andersk> (The latter occurs with Compiz only.) 
<tjaalton> drag with the touchpad or same with the mouse?
<andersk> With the touchpad.  Let me go find a mouse... 
<tjaalton> there probably are some issues with the new synaptics
<tjaalton> because some defaults have been changed
<andersk> With the touchpad only.  So yeah, this points to a synaptics problem. 
<tjaalton> ok, please file a bug against it
<andersk> Will do. 
<jcristau> maybe you could play with xinput to see which settings affect it
<tjaalton> right, there are not many changes upstream since 1.0rc3
<andersk> It looks like most synaptics bugs are being reported against the source package xserver-xorg-input-synaptics, even though it was renamed in Hardy to xfree86-driver-synaptics. 
<tjaalton> yes, because it's called that in debian
<tjaalton> but we "support" the old name too
<tjaalton> well, the debian package really should be renamed to that
<tjaalton> so in future it should be called x-x-i-synaptics again
<jcristau> yeah xfree86-driver-synaptics doesn't make much sense anymore
<tjaalton> especially as the git repo is called x-x-i-s
<jcristau> it's to make sure you get confused
<tjaalton> I have :)
<jcristau> every time
<tjaalton> you surely have the power to rename it?-)
<andersk> bug 320639 
<ubottu> Launchpad bug 320639 in xserver-xorg-input-synaptics "Touchpad movement problems in 0.99.3" [Undecided,New] https://launchpad.net/bugs/320639
<jcristau> i think i'd rather rename the source package than the git repo
<tjaalton> jcristau: of course :)
<tjaalton> andersk: thanks
<pwnguin> what's the xorg.conf setting i need to re-enable zapping?
<jcristau> pwnguin: Option "NoDontZap"
<andersk> Option "DontZap" "False" in ServerFlags. 
<pwnguin> ok
<pwnguin> nouveau isn't quite to the point where i don't need it ;)
<jcristau> (it's like Option "NoXaaNoOffscreenPixmaps" "false" all over again)
<pwnguin> well, i agree with the idea
<pwnguin> i just live more dangerously than is prudent
<jcristau> i meant the fact that the option name has a negation in it
<pwnguin> oh
<_MMA_> I switched video cards (both nvidia) now I cant get X to start at all. Blew out my Xorg. Tried to use vesa in xorg. No screens found. Nothing. Is there some trick to get it to build the module again or something? DKMS?
<tjaalton> either specify the BusID or take one out
<tjaalton> oh
<tjaalton> I misread :)
<_MMA_> :P
<bryce> _MMA_: you forgot to post a link to your Xorg.0.log ;-)
<_MMA_> :P
<_MMA_> I should note this is a SLI setup so it could have to do with the busID.
<tjaalton> so you _do_ have two of them? yes you need the BusID with 8.10 or jaunty
<_MMA_> tjaalton: Yeah. Went from 1 card (9 series) to 2 (both 7 series). Runnin' Intrepid.
<_MMA_> I guess X wasn't as bullet proff as I thought. :P
<tjaalton> the bug is upstream, but unfortunately not seeing much action
<_MMA_> ouch
<tjaalton> although it's on the list of blockers for xserver 1.6
<tjaalton> (well, I added it)
<_MMA_> I think I have the old xorg with both cards somewhere.
<_MMA_> Thing is, the live disk gives me X. Im just trying to get, *something*
 * _MMA_ pokes around.
<tjaalton> livecd does? strange
<tjaalton> it shouldn't
<andersk> So here's another problem.  gnome-screensaver always fails to unlock the screen now. 
<andersk> After I enter the correct password, gnome-screensaver-dialog sits there displaying "Checking..." 
<andersk> And top shows that the CPU is spinning, with about 65% gnome-screensaver-dialog and 35% Xorg. 
<tjaalton> works here
<_MMA_> tjaalton: It was the BusID. Thanx for the reminder.
<andersk> I've bisected the gnome-screensaver unlock problem to the gtk+2.0 2.14.5-1ubuntu2 -> 2.15.0-0ubuntu1 upgrade. 
<tjaalton> I've got it too
<tjaalton> that version of gtk+
<andersk> Huh. 
<tjaalton> maybe you are missing something..
<tjaalton> which mirror?
<andersk> archive.ubuntu.com 
<tjaalton> ok, same
<andersk> Aha, got it.  I can only reproduce with "export GTK_IM_MODULE=xim" in ~/.gnomerc. 
<tjaalton> nice
<tseliot> tjaalton: did you upload a new version of the synaptics driver?
<tjaalton> tseliot: yes
<tjaalton> some defaults have chagned
<tseliot> I have noticed these 2 bug reports:
<tjaalton> -nged
<tseliot> https://bugs.launchpad.net/ubuntu/+source/xfree86-driver-synaptics/+bug/320632
<tseliot> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/320639
<ubottu> Launchpad bug 320632 in xfree86-driver-synaptics "tap-to-click and edge-scrolling broken in Jaunty" [Undecided,New]
<ubottu> Launchpad bug 320639 in xserver-xorg-input-synaptics "Touchpad movement problems in 0.99.3" [Undecided,New]
<tseliot> I'll try the new driver tomorrow and if it bugs me I'll write a patch
<tjaalton> ok
<tseliot> tjaalton: oh and did you read about my patch for nv
<tseliot> ?
<tjaalton> yes, and saw that you posted it upstream
<tseliot> what are we going to do about it?
<tseliot> shall we include it as a patch in ubuntu or wait for a new release of nv?
<tjaalton> a patch is fine
<tseliot> and do you want me to file a bug report about it?
<tjaalton> preferably yes
<tjaalton> might get lost otherwise
<tseliot> ok, good
<tseliot> yes, it better if we keep track of the patch
<tseliot> s/it/it's/
<tjaalton> what the heck
<tjaalton> DRI2 works, but I do get bigger fps than vblank with glxgears
<tjaalton> this is with UXA
<tjaalton> s/vblank/refresh-rate/
<tseliot> how much is it?
<jcristau> does it matter? :)
<tseliot> or is it too fast?
<tjaalton> well it should show ~50
<tjaalton> but it's not
<tjaalton> with EXA it does
<tjaalton> but then I get no DRI2
<jcristau> i'm not sure dri2 has a mechanism for vsync yet
<tjaalton> probably so
<tjaalton> oh well, EXA is the default anyway
<andersk> I reported bug 320666 for gnome-screensaver and gtk+2.0. 
<ubottu> Launchpad bug 320666 in gtk+2.0 "gnome-screensaver fails to unlock with GTK_IM_MODULE=xim after gtk 2.15.0 upgrade" [Undecided,New] https://launchpad.net/bugs/320666
<bryce> tjaalton: http://people.ubuntu.com/~bryce/totals.svg
<tjaalton> bryce: wow :)
<tjaalton> btw, we should probably move the -mouse/-kbd bugs over to evdev if they still apply
<bryce> yep
<bryce> how do we determine that they still apply?  ask users to retest jaunty?
<tjaalton> something like that..
<tjaalton> not that many of them
<bryce> yeah
<tjaalton> and some are likely misfiled
<tseliot> tjaalton: here's my report with the patch: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nv/+bug/320671
<ubottu> Launchpad bug 320671 in xserver-xorg-video-nv "nv driver doesn't include the pci-id of my GeForce 7300 GT" [Undecided,New]
<tjaalton> tseliot: ok thanks
<bryce> there might also be some -evdev bugs misfiled against xkeyboard-config
<bryce> I took out all the hotkey bugs from there and that cut it down a lot
<tjaalton> yep
<tjaalton> so unplugging a wacom tablet really kills the xserver
<tjaalton> ..and that concludes my day, night!
<bryce> night
<Alexia_Death> tjaalton: It wont if you take the 0.8.2-2 (I hope, ping put a build swithc in that one)
#ubuntu-x 2009-01-24
<bryce> http://people.ubuntu.com/~bryce/totals.svg
<pwnguin> hmm. i need a better way of querying xrandr status
<pwnguin> xrandr -q is too variable
<pwnguin> actually, maybe not
<pwnguin> if the manpage isn't lying to me =/
<pwnguin> sigh
<tjaalton> tseliot: the .ids parsing code is probably just incomplete for your card. try move nv.ids elsewhere, it should load nv then
<tjaalton> even without your patch
<tseliot> tjaalton: ok, I'll try it
<tjaalton> could be that you need to move xorg.conf too
<mnemo> tjaalton: how can I disable or enable vblank waiting???  (that stuff you talked about yesterday that made glxgears fps sync to monitor Hz)
<tjaalton> mnemo: by disabling it in drirc
<mnemo> tjaalton: could you explain in more detail?
<mnemo> i suspect disabling the vblank sync will be a useful experiment in debugging this issue --> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/320813
<ubottu> Launchpad bug 320813 in xserver-xorg-video-intel "with EXA compiz animations cause temporary freezes" [Unknown,Confirmed]
<tjaalton> well you have the new driver already, right?
<mnemo> yeah I got the 2.6.1 ddx driver
<tjaalton> ok, so this bug is new?
<tjaalton> I mean didn't happen with the old one?
<mnemo> I didnt have this problem with the .28-4 kernel and the old intel driver, old libdrm etc
<mnemo> like jaunty two weeks ago didnt have this one for sure
<tjaalton> http://users.tkk.fi/~tjaalton/foo/drirc
<tjaalton> resuming from suspend seems broken here
<tjaalton> I'm dropped in the login screen
<mnemo> what should I change i965 to if I got an intel G45 card?
<mnemo> or can I keep i965 ?
<tjaalton> it's the same driver I guess
<tjaalton> dri driver
<mnemo> yeah ok I'll try with i965
<tjaalton> so put that either in /etc/ or as ~/.drirc
<mnemo> tjaalton: awesome, that did indeed fix it
<mnemo> my guess was correct
 * mnemo does a little dance
<mnemo> well, hmm.. the poster said that he normally doesnt see this behavior until xorg has been running for a while so many I should declare victory prematurely
<tjaalton> maybe mesa 7.3 would help
<mnemo> tjaalton: will you package 7.3 final?
<tjaalton> maybe
<tjaalton> jcristau: would it be possible to use the tarballs from the git tags?
<tjaalton> afk->
<tseliot> tjaalton: my patches for the synaptics driver are ready
<tjaalton> tseliot: ok, cool. maybe wgrant should take a look at those, since he actually has a touchpad :)
<tjaalton> some of the settings (like speed) do vary by device, so that patch likely would be a regression for others
<tseliot> tjaalton: I also made a big debdiff and attached it here (the single patches are attached to the 2 different reports): https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/320632
<ubottu> Launchpad bug 320632 in xserver-xorg-input-synaptics "tap-to-click and edge-scrolling broken in Jaunty" [Undecided,Confirmed]
<tjaalton> that's what I was looking at
<tseliot> speed is either autodetected or can fallback to some default values
<tseliot> the other changes should be ok since they restore the behaviour of the driver in Intrepid
<tseliot> for example I have physical buttons in my touchpad but I don't use them because I prefer tapping
<tseliot> according to the author, tapping is disabled if physical buttons exist
 * tseliot > dinner
<tjaalton> tseliot: I've uploaded a new synaptics, can't be worse than the one we have now :)
<tseliot> tjaalton: I hope my patches still work with it
<marijus> compiz is killing my x since yesterdays x, mesa and intel driver update... i wonder why because x seems to start well... any help? 
<marijus> btw... im using jaunty
<tjaalton> marijus: running the new kernel too?
<marijus> tjaalton: .28-5
<tjaalton> is it -5.15 or earlier?
<tjaalton> uname won't tell
<tjaalton> I had that problem without the new mesa..
<marijus> latest jaunty kernel
<tjaalton> ok then
<tjaalton> a logfile from the crash might give some clue
<marijus> actually i didnt find any logs from the crash in xsession-errors at least not about compiz
<tjaalton> that's not the place to look..
<tjaalton> but the X logfile
<marijus> ok
<tjaalton> if it's killing X..
<marijus> as soon as i start compiz (manaualy) it brings me back to gdm
<tjaalton> ok, so what's in /var/log/Xorg.0.log.old?
<albert23> tjaalton: kdm.log shows i915_dri.so undefined symbol intel_wait_flips
<tjaalton> albert23: bug 320690
<ubottu> Launchpad bug 320690 in mesa "Hardware acceleration broken on gma950 with libgl1-mesa-dri-7.3rc3-1ubuntu1" [High,Confirmed] https://launchpad.net/bugs/320690
<marijus> may i send you the file tjaalton?
<albert23> tjaalton: for me it fails on login. I cannot even try to run glxgears
<tjaalton> marijus: pastebin.ubuntu.com or similar is fine
<albert23> marijus: maybe you can check /var/log/gdm/:0.log?
<tjaalton> if X crashes, there's usually a backtrace of some sort in the Xorg logfile
<tjaalton> maybe even in the gdm log, dunno
<marijus> http://pastebin.ubuntu.com/109135/
<tjaalton> oh it's a 855GM
<tjaalton> filed a bug yet?
<marijus> no
<marijus> i also tried with UXA
<marijus> no diffrence
<tjaalton> looks like a kernel bug
<marijus> i used the xorg edgers repo before... had no problems there...
<marijus> that was libdrm-2.4.3 and mesa-7.3-rc1
<tjaalton> ok
<tjaalton> well, file a bug :)
<marijus> ok, thanks... i will
<marijus> well... maybe it's the same problem as here  https://launchpad.net/bugs/320690
<ubottu> Launchpad bug 320690 in mesa "Hardware acceleration broken on gma950 with libgl1-mesa-dri-7.3rc3-1ubuntu1" [High,Confirmed]
<tjaalton> don't think it is
<marijus> at least the output of "LIBGL_DEBUG=1 glxgears" is the same
<tjaalton> compiz would fail to run
<marijus> :-[ well it does fail actually
<tjaalton> I'll add that commit to mesa
<tjaalton> there
<tjaalton> it'll take a few hours to propagate to the archive
<marijus> cool :)
<tjaalton> or you can build it yourself
<marijus> never tried to build mesa till now... how long does it take to on a 7 year old computer? :-D
<tjaalton> quite some time I guess
<tjaalton> but you have 32bit x86?
<marijus> yes
<tjaalton> ok, it'll take maybe 15min on my laptop
<tjaalton> counting..
<tjaalton> you just need libgl1-mesa-dri
<tjaalton> marijus: http://users.tkk.fi/~tjaalton/foo/libgl1-mesa-dri_7.3~rc3-1ubuntu2_i386.deb
<tjaalton> ok, so it took nearly 30min
<marijus> thanks... i was to lazy actually 8-) and even if... i would still build now... :)
<marijus> ill give it a try now... brb...
 * albert23 has working X again :-)
<marijus> tjaalton: got my wobbly windows back :)
<tjaalton> marijus: ooh, great
#ubuntu-x 2009-01-25
<pwnguin> is there a patch in X to try drivers in a specific order for a given PCI?
<pwnguin> like, try nouveau, then nvidia, then nv?
<tjaalton> pwnguin: no
<tjaalton> the selection only works if there's no xorg.conf
<tjaalton> that's why there's no patch to add those
<pwnguin> obviously
<pwnguin> i mean, obviously it only auto selects if you dont have an xorg.conf
<tjaalton> it's a different codepath
<pwnguin> what is?
<tjaalton> and likely fixable to apply also to the case where you have an xorg.conf but no driver specified
<tjaalton> the auto selection uses the ids files in /usr/share/xserver-xorg/pci
<tjaalton> look at hw/xfree86/common/xf86AutoConfig.c :)
<tjaalton> hrm, the intel vblank freezes are annoying
<tjaalton> sigh, braindead check for xserver 1.6 in wacom
<tjaalton> grr, I hate this drier
<tjaalton> -ver
<tjaalton> after poking configure it does recognize the headers are from xserver 1.6 but still leaves the variable undefined
<tjaalton> Alexia_Death: I wonder how you managed to build wacom on jaunty :)
<tjaalton> it took some time to make 0.8.2.2 build
<Alexia_Death> tjaalton: I havent built 0.8.2-2...
<tjaalton> ok
<tjaalton> well someone has posted the patches there to make it build
<Alexia_Death> tjaalton: I have selfpatched 0.8.2-1
<tjaalton> and if fails
<tjaalton> *it
<Alexia_Death> why it fails?
<Alexia_Death> You got it building?
 * Alexia_Death is trying now
<tjaalton> first because it only checks for xserver 1.6.0 (which doesn't exist), and when I make it to match 1.5.99 it still doesn't generate a correct src/include/xdrv-config.h
<tjaalton> WCM_XORG_XSERVER_1_6 is left undefined
<tjaalton> so how do I use your daemon?
<Alexia_Death> http://a.death.pri.ee/watahod-0.3.2.tar.gz
<tjaalton> I've got that
<Alexia_Death> tjaalton: thats the latest version
<Alexia_Death> some bugs fixed.
<Alexia_Death> it contains an udev rules file.
<Alexia_Death> that tho not mandatory should be used instead of the current wacom one.
<Alexia_Death> tjaalton: it depends on python-gtk2 and python-notify.
<Alexia_Death> then run watahod and plug in your tablet.
<Alexia_Death> eraser starts with wrong bottomX bottomY, bug in wacom driver. You can set it to correct values with xsetwacom and then save defaults and every time you plug it in they are set correctly
<tjaalton> I need to restart udev first?
<Alexia_Death> reload, yes
<tjaalton> usbParse: Exceeded channel count; ignoring the events.
<Alexia_Death> It uses device names to remember prefs so if you change your rules later it wont pick up the prefs again
<tjaalton> that's all I get in the logfile, maybe the driver is just buggy for me
<Alexia_Death> thats a bug in the driver yes.
<Alexia_Death> it was debugged in the list...
<Alexia_Death> and there was even a patch for it...
<Alexia_Death> but it wasnt passed publicly, ping just let someone try it out...
<Alexia_Death> IRC
<Alexia_Death> IIRC*
<tjaalton> it should be included in 0.8.2.2
<Alexia_Death> what tablet do you have?
<Alexia_Death> can you pass me a patch for your build fix?
<Alexia_Death> I have a bamboo and an old inuos one serial tablet. neither have exhibited this behaviour...
<tjaalton> aiptek 10000U, a waltop OEM model
<Alexia_Death> and it works with wacom driver?
<tjaalton> used to
<Alexia_Death> It was recognized and loaded by the daemon?
<tjaalton> only the first hunk of the patch is included in 0.8.2.2 ....
<tjaalton> your daemon? yes
<Alexia_Death> Ping hasnt been that good with this release...
<Alexia_Death> Perhaps patching 0.8.2 with the crashfix patch and the other one gives better results.
<tjaalton> the crashfix is in
<tjaalton> doesn't crash X when I unplug it
<Alexia_Death> Thats the broken define
<Alexia_Death> that you fixed.
<tjaalton> ah
<Alexia_Death> It basically removes a double free. X insists now freeing somehing that the driver has already freed and assigning NULL to it did not get where it should have gotten to.
<Alexia_Death> jot the driver just wont free it for now
<tjaalton> doesn't work even with the other hunk
<Alexia_Death> it worked with 0.8.2?
<tjaalton> no, with 0.8.1.6
<Alexia_Death> hmm
<tjaalton> I'll restart X to see if it helps
<tjaalton> nope
<Alexia_Death> hmm
<Alexia_Death> Can I see your x log?
<tjaalton> hmm, now even the previous version fails to work
<Alexia_Death> and Id still like to have a build patch for the 0.8.2-2 if you can make one...
<Alexia_Death> ?
<tjaalton> I'll try to make one
<tjaalton> but all you need to do is change the VERSION in configure to be 1, 5, 99
<tjaalton> and then change src/include/xdrv-config.h.in to #define WCM_XORG_XSERVER_1_6
<tjaalton> then it should build, at least the package
<Alexia_Death> OK. Will try
<tjaalton> 0.8.1.6 does work after all, I just needed to kill X first
<tjaalton> because the new module was loaded
<Alexia_Death> does it work hotplug for you?
<Alexia_Death> or does it crash on remove?
<Alexia_Death> it should crash.
<Alexia_Death> tjaalton: but look up where that define is used, you should see the bad free immediately.
<tseliot> tjaalton: hey you uploaded my patches, I thought you had taken a new release from debian instead.
<tseliot> tjaalton: which is good :-)
 * Alexia_Death is going to have to kill x to test the new module
<Alexia_Death> brb
<tjaalton> Alexia_Death: it does crash
<tjaalton> tseliot: new release?
<tseliot> tjaalton: of synaptics
<tseliot> I thought you did another merge
<tjaalton> there is no new release
<tseliot> Alexia_Death: is the crash caused by that xfree(priv); in wcmConfig.c?
<Alexia_Death> yes
<tjaalton> debian has 0.99.3-1
<tseliot> tjaalton: well, I didn't check
<Alexia_Death> Xserver tries to free that again
<tseliot> Alexia_Death: why don't you add something like if (priv != NULL)
<Alexia_Death> there is.
<Alexia_Death> it does not wotk
<Alexia_Death> tseliot: Is I understand the problem, it checks if the priv elements pointer in driver controll structure is NULL
<Alexia_Death> however, the priv in driver is just a local variable
<Alexia_Death> so doing priv=NULL means nothing to the server.
<Alexia_Death> and it tries to free it again.
<Alexia_Death> tseliot: I can find you the bug about this in X bugzialla
<tseliot> this one, right? http://bugs.freedesktop.org/show_bug.cgi?id=19176
<ubottu> Freedesktop bug 19176 in Server/general "CheckMotion for uninitialized devices segfaults the server" [Critical,Resolved: fixed]
<tjaalton> Alexia_Death: http://users.tkk.fi/~tjaalton/foo/Xorg.0.log
<tseliot> ok, so we have a patch for X and a patch for the wacom driver
<Alexia_Death> tseliot: in the end of that is the discussion yes
<tseliot> Alexia_Death: so doing "local->private =NULL;" should fix it in the driver
<Alexia_Death> possible
<Alexia_Death> I havent had time to investigate it much further
<tseliot> tjaalton: do we have the patch in comment 18 of the bug report?
<tseliot> if we do, then I can experiment with the wacom driver and fix this problem
<Alexia_Death> tseliot: checkmotion patch is in
<tseliot> good
<Alexia_Death> the buttons patch isnt and it does not apply right either :(
<tseliot> why?
<Alexia_Death> Not on top of other patches in the source package anyway...
<Alexia_Death> something conflicts..
<tseliot> ok, I'll fix that too
<Alexia_Death> I dont know why yet. 
<Alexia_Death> :) that would be great.
<tseliot> Alexia_Death: did you touch the udev rules to make sure that multiple devices are hotplugged?
<Alexia_Death> ?
<tseliot> e.g. for the pen, pad, eraser, etc.
<tseliot> you said that you created a script which uses dbus
<Alexia_Death> tseliot: the pack contains a new udev rules mainly to make sure that the wacom devices have sane disdinguishable names.
<tseliot> to make sure that not only the pen but also the other components work when you plug in the tablet
<Alexia_Death> not directly. indirectly I need to know what devices a particulat tablet has. So currently theres some guessing based on name
<tseliot> did you create a package?
<tseliot> a deb package
<Alexia_Death> tseliot: no, right now theres just a tar archive.
<Alexia_Death> Its not stable enough to package yet
<tseliot> can you give me the link to it?
<Alexia_Death> tseliot: http://a.death.pri.ee/watahod-0.3.2.tar.gz
<Alexia_Death> tested yesterday on some arch users.
<Alexia_Death> should more or less work.
<Alexia_Death> tseliot: if you are already debugging the wacom driver, perhaps you can also fix the erasers bottomX and bottomY not being initzialized right.
<Alexia_Death> on hotplug that is. its done right when added in conf AFAIK.
<tseliot> doesn't that depend on the specific tablet?
<Alexia_Death> the values yes, but the tablet is capable of guessing them
<Alexia_Death> driver that is.
<tjaalton> it's likely "updated wcmUSB.c to ignore unparsed data" which broke it for me
<tjaalton> yay for version control
<Alexia_Death> it does it right on coldplug and for stylus in hotplug
<tjaalton> or the nonexistence
<tjaalton> *of it
<Alexia_Death> ?
<tjaalton> I've no idea what kind of a patch that was
<tjaalton> or is there a public VCS repo somewhere?
<tjaalton> with history and all
<Alexia_Death> wacom has a a git repro somewhere
<Alexia_Death> Ive built it once...
<tjaalton> on git.debian.org, but it's not what ping uses
<tseliot> Alexia_Death: I would like to modify xsetwacom so that it can read settings from a configuration file, so that we can apply the settings once the device is hotplugged
<tjaalton> http://git.debian.org/?p=collab-maint/linux-wacom.git;a=summary
<Alexia_Death> tseliot: it works now, but having conf dump&load would be good.
<tseliot> ok
<Alexia_Death> tseliot: look in the python code, its very simple.
<Alexia_Death> tseliot: the daemon even mainains a conf directory under .wacom
<tjaalton> maybe better use .config/wacom
<Alexia_Death> tjaalton: why?
<tjaalton> to not pollute ~/
<Alexia_Death> right about that...
<Alexia_Death> the .xxx mess is annoying.
<Alexia_Death> its just a path anyway. easy to change. but Im reluctant to do so untill there is no conf tool.
<Alexia_Death> decent conftool.
<Alexia_Death> wacomcpl does not count.
<tseliot> my tool will be written in Python and will write a configuration file which the C program will parse and apply
<Alexia_Death> tjaalton: I have the url of the git that ping uses in my mail archives somewhere, but since kmail is not installable right now its abit hard to acccess.
<Alexia_Death> tseliot: why not use the same format Ive used in my tool?
<Alexia_Death> tseliot: lets just collaborate and make one thing?
<Alexia_Death> daemon+conf tool.
<Alexia_Death> Ive requested a sf project for it.
<tseliot> sf?
<tseliot> freedesktop?
<Alexia_Death> but perhaps laouncpad would be better.
<tjaalton> sourceforge
<tseliot> aah
<tjaalton> sf is crap :)
 * Alexia_Death shrugs
<Alexia_Death> I like SVN:P
<tjaalton> svn is too :)
<Alexia_Death> yeah. git lovers.
<tjaalton> dvcs ftw
<tseliot> launchpad should be good enough
<tseliot> and so is bzr (IMO)
<tseliot> Alexia_Death: the daemon should be written in C though
<Alexia_Death> tseliot: why?
<Alexia_Death> why is not python good enough?
<tseliot> not many people would like to see another daemon written in python
<Alexia_Death> it does not do anything much
<tseliot> because they want something which doesn't slow down startup
<Alexia_Death> it does not
<tseliot> and they are concerned about wasting resources
<tseliot> I love Python ;)
<Alexia_Death> its too trivial a task to complicate it with C.
<Alexia_Death> it needs to be flexible.
<tjaalton> where should this daemon be run? in the user session?
<Alexia_Death> tjaalton: yes
<Alexia_Death> it needs to run in user rights.
<Alexia_Death> this daemon only listends to dbus and reacts to some device add events... does nothing else.
<tjaalton> but maybe not on every desktop
<Alexia_Death> tjaalton: ?
<tjaalton> I mean that the users should install it themselvers
<tjaalton> -r
<tjaalton> it can't be a dependency of wacom, since it's installed on every machine
<tseliot> Alexia_Death: people were not happy at the UDS when I talked about daemons in Python
<Alexia_Death> tjaalton: not for wacom, but for wacom tools perhaps
<Alexia_Death> tjaalton: or may be even completely different.
<Alexia_Death> independent*
<tjaalton> right
<Alexia_Death> it does need xsetwacom
<tjaalton> the driver only Suggests -tools, so it's not installed by default
<Alexia_Death> xsetwacom is in tools?
<tjaalton> yes
<Alexia_Death> then tools depend on this daemon.
<Alexia_Death> err
<Alexia_Death> saemon depends on tools
 * Alexia_Death is wee bit hung over today...
<tjaalton> my sympathies :)
<Alexia_Death> tseliot: Id agree about system daemons. this is a user daemon and very much optional.
<tjaalton> hmm, maybe I'll take a break and do something else for a change ->
<tseliot> we already have a printer applet and the update notifier
<tseliot> which run as daemons and are written in Python
<Alexia_Death> those are much more common. this one is just for wacom users.
<Alexia_Death> tseliot: I do have a command line utility with all the same fucntions for people who do not want to run the daemon.
<Alexia_Death> uses the same "lib" python file as the daemon.
<tseliot> Alexia_Death: do you suggest that we enable the daemon only after users configure their tablet in the UI?
<Alexia_Death> yes
<Alexia_Death> the daemon has no deep point unless theres a a tablet configured. It should be just a wizard that ends with registering the daemon for startup
<Alexia_Death> and in the configuration utility there needs to be a way to remove it from startup easy.
<tseliot> ok, this is better than I thought
<Alexia_Death> and people can even chose to run it manually when they are using a tablet and not on startup at all.
<tseliot> something like pressing a "detect" button in the UI?
<tseliot> or "load settings"
<Alexia_Death> More like just selecting the daemon from the menu as a common app and running it.
<Alexia_Death> those functions you listed are present in the daemon now
<Alexia_Death> as menu items from the icon
<Alexia_Death> Mostly for serial tablet
<Alexia_Death> I have one connected through USB serial adapter.
<Alexia_Death> Currently serial tablets are configured in a conf file.
<tjaalton> I agree that this is good as a 'proof-of-concept' daemon, but in the long run there should be maybe only one user session daemon to handle input devices. frontends can be whatever the desktop requires
<Alexia_Death> on load serial it checks if listed device nodes exist and loads them, if they do.
<tjaalton> it could just be the generic configuration daemon of the desktop
<tjaalton> which means extending the current one(s)
<Alexia_Death> So the daemon runs without GUI and is driven by DBUS calls?
<tjaalton> something like that, I don't know how it all works 
<tseliot> I would like to see one daemon to deal with input devices and tablets
<tjaalton> integration is the hard part, applies to everything
<Alexia_Death> All tablets and input devices? 
<tseliot> Alexia_Death: in the case of tablets we could use dbus
<tseliot> xinput for the rest of input devices
<tjaalton> Alexia_Death: I meant that integration in general is what's lacking from the linux "desktop"
<tseliot> and of course the same should be done for outputs
<Alexia_Death> tseliot: the problem is, only wacoms are nicely configurable through xsetwacom.
<tseliot> Alexia_Death: doesn't a C library for wacoms exist?
<Alexia_Death> tjaalton: what does integration mean in this context?
<tjaalton> why couldn't wacom support X input properties
<Alexia_Death> tseliot: I dont know what you mean by c library...
<Alexia_Death> I dont know those things...
<tseliot> Alexia_Death: a library which we could use for the daemon instead of having to call xsetwacom
<tjaalton> Alexia_Death: integration with the existing desktop tools.. especially when it's not clear what the ultimate solution is
<Alexia_Death> tseliot: I dont think so.
<Alexia_Death> tjaalton: right now, I see a doable wacom daemon/conf tool. and even that is hard to do right because I just dont have the hardware to test it.
<tjaalton> Alexia_Death: what hw are you missing?
<Alexia_Death> tjaalton: tablets. theres tonns of tablets.
<tjaalton> why would you need all of them?
<Alexia_Death> tjaalton: not all of them. But there are some types.
<Alexia_Death> tjaalton: like screen tablets.
<tjaalton> which are serial
<Alexia_Death> not all of them
 * tseliot reboots
<tjaalton> no, but most
<Alexia_Death> I have a serial tablet and an usb tablet.
<Alexia_Death> screen tablets have something that is totally unhandled gui wise, thats the callibration.
<tjaalton> but how does a serial screen tablet differ from a serial handheld tablet?
<tjaalton> ok
<Alexia_Death> calibration.
<tjaalton> well that's what tseliot is doing
<Alexia_Death> tseliot has one to test?
<tjaalton> a screen tablet? dunno
<Alexia_Death> thats hard to do right If you dont have one.
<tjaalton> sure
<tjaalton> but now some LittleBigPlanet ->
<Alexia_Death> :)
 * Alexia_Death takes her hangover elsewhere too.
<Alexia_Death> tseliot: do you have a screen tablet?
<tseliot> Alexia_Death: no, only a USB tablet
<Alexia_Death> :(
<tseliot> but I know someone who owns 20 tablets
<tseliot> he could help us testing things
 * Alexia_Death has serial and usb, but somebody with screentablet needs to do calibration
<Alexia_Death> tats good
 * tseliot nods
<tseliot> Alexia_Death: do you know what kind of patch system does wacom-tool use?
<tseliot> s/does//
<Alexia_Death> xsewacom? its maintained in GIT afaik.'
<tseliot> s/use/uses/
<tseliot> the debian package
<Alexia_Death> dunno...
<tseliot> hehe "checking XInput extension version... >= 2.0"
<tseliot> I would like to see how it uses Xinput
<tseliot> tjaalton: any ideas on how to apply patches to wacom-tools?
<tseliot> Alexia_Death: setting local->private to NULL did the trick
<tseliot> X doesn't freeze if I plug in and then unplug my tablet
<tjaalton> tseliot: there is no patch system afaik
<Alexia_Death> tseliot: send patch to ping?
<tseliot> tjaalton: yes, I applied the patch manually
<tseliot> Alexia_Death: sure
<tjaalton> what patch is this
<tjaalton> ?
<tjaalton> 0.8.2.2 doesn't crash on unplug
<tseliot> tjaalton: and is 0.8.2 in jaunty?
<tjaalton> no
<tjaalton> because it doesn't work for me, and I think it might break for others too
<Alexia_Death> tjaalton: its the proper fix instead of the build switch.
<tjaalton> I've got it packaged though
<tjaalton> Alexia_Death: ok
<Alexia_Death> tjaalton: it should be enough to make 8.1-6 not crash too
<Alexia_Death> so you should get your tablet working.
<tjaalton> sure, maybe just use that for now
<Alexia_Death> jep.
<tseliot> tjaalton: what do you mean by "it doesn't work for me"?
<Alexia_Death> tseliot: pastebinify the patch?
<tseliot> yes, let's stick with 8.1.6
<tseliot> Alexia_Death: http://pastebin.com/d3a66dcb7
<Alexia_Death> tseliot: tjaalton has a tablet that has a problem with 0.8.2
<tseliot> ok
<tseliot> Alexia_Death: now I would like to make sure that your patches for X apply
<tseliot> Alexia_Death: can you document your patches, please?
<tjaalton> I just get a bunch of those "usbParse: Exceeded channel count; ignoring" -errors when the pen is close to the tablet
<Alexia_Death> tseliot: the patch set I gave you is no longer needed.
<tjaalton> with 0.8.2.2 that it
<tjaalton> *is
<Alexia_Death> tseliot: X went up a version.
<tseliot> Alexia_Death: aah, right
<Alexia_Death> The patch that does not apply cleantly and does not is this:
<Alexia_Death> https://bugs.freedesktop.org/show_bug.cgi?id=19282
<ubottu> Freedesktop bug 19282 in Input/Core "Events handled wrong when master button map differs from the originating device..." [Normal,Resolved: fixed]
<Alexia_Death> It should apply on clean rc1 but it does not apply on top of the already included patch set at least.
<tseliot> Alexia_Death: so are you saying that upstream has it already but we don't or what?
<Alexia_Death> tseliot: yes
<tseliot> ok, so I'll make sure that this patch applies: https://bugs.freedesktop.org/attachment.cgi?id=21775
<Alexia_Death> yep. that should fix the buttons issue.
<tjaalton> perhaps it's in master but not 1.6-branch
<Alexia_Death> Let me know when you are done.
<Alexia_Death> tjaalton: AFAIK it was cherrypicked on 1.6 a little after rc1 tag.
<tseliot> ok
<tjaalton> Alexia_Death: nope, there are no commits after rc1 was tagged
<Alexia_Death> hmm
<Alexia_Death> then im wrong
<Alexia_Death> its just in master then.
<tjaalton> but it's on the list of proposed patches
<tjaalton> http://www.x.org/wiki/Server16Branch
<Alexia_Death> Its somewhat important tho. the stylus buttons are mapped wrong without it.
<tjaalton> we'll get it with the next rc
<Alexia_Death> yeah, but tablets are serious pita to use as is.
<tseliot> so is it useless if I get it to work now?
<tjaalton> yeah, crashing and all :)
<Alexia_Death> when is next rc due?
<Alexia_Death> I wouldnt say useless...
<tjaalton> dunno
<Alexia_Death> no schedule?
<tjaalton> no
<tjaalton> maybe next week though, since LCA is over
<Alexia_Death> tseliot: untill next week we can make due with the hack if we must ;)
<tjaalton> hehe, now phoronix has picked up the intel "regressions"
<Alexia_Death> tseliot: I looked at your patch... you have removed the free.
<tseliot> Alexia_Death: ok, the patch applies now
<Alexia_Death> the free should stay if the NULL trick works.
<Alexia_Death> tseliot: Great. Share?
<tseliot> Alexia_Death: ah, right. so I should add just add that line instead of replacing the xfree one with it
<Alexia_Death> yep
<tseliot> Alexia_Death: it applies but I'm trying to build X now
<tseliot> applies != works
<tseliot> ;)
<Alexia_Death> yes:D
<Alexia_Death> hmm... 8.1-6 wont build for me
<tseliot> ok, X compiled
<tseliot> I've rewritten the patch for wacom
<tseliot> ok, wacom driver built. Now, I'll restart X to try it. Then I'll try the new (patched) X
 * tseliot restarts X
<tseliot> wacom doesn't freeze X
<tseliot> \o/
<Alexia_Death> what version of wacom driver you have?
<tseliot> the one in jaunty
<tseliot> 8.1.6
<Alexia_Death> hmm
<Alexia_Death> It wont build for me.
<tseliot> what's the error?
<Alexia_Death> xf86Version.h is missing.
<Alexia_Death> and some interface error
<tseliot> weird
<Alexia_Death> I think my env is borked somehoe.
<tseliot> it could be
<tjaalton> no, you just need to include the right headers
<Alexia_Death> but I dont have clue how to fix it.
<tseliot> let me try the new X
 * tseliot restarts X
<tjaalton> look at 8.2.2 how it's done
<tseliot> Alexia_Death: what can I do to see if the patch for X fixes the bug?
<tseliot> or how can I reproduce the problem with button mapping?
<Alexia_Death> tseliot: if you can click by taping with the stylus it works
<Alexia_Death> tseliot: the maping used to be shifted. tap does nothing, first stylus button clicks etc...
<tseliot> yes, I can click and double click
<Alexia_Death> then it works.
<Alexia_Death> btw, the source package from repro does build. so Id be happy if I got your patch for wacom&for X... 
<Alexia_Death> tseliot: do you have a ppa?
<tseliot> Alexia_Death: yes, but I haven't uploaded my patches
<Alexia_Death> Let me know when I can have them from somewhere...
<tseliot> ok, first, I'll send the patch to Ping so that we can have the fix accepted by upstream
<Alexia_Death> yes
<tseliot> tjaalton: if you're interested, I can do a debdiff or simply upload the patch for X somewhere
<Alexia_Death> debdiff?
<tseliot> yes, it's like a diff between different versions of the same package
<Alexia_Death> never used it...
<tseliot> https://wiki.ubuntu.com/PackagingGuide/HandsOn#Tutorial%201:%20Providing%20a%20Debdiff
<tseliot> point 7-8
<tseliot> Alexia_Death: I've just sent the patch to Ping and CCed you
<tseliot> and this is the patch for X
<tseliot> http://pastebin.com/d363c62b9
<Alexia_Death> thanks
<Alexia_Death> :)
<tseliot> np
<tseliot> tjaalton: I've just attached the patch for the wacom driver to this bug report: https://bugs.launchpad.net/ubuntu/+source/wacom-tools/+bug/320753
<ubottu> Launchpad bug 320753 in wacom-tools "unplugging wacom tablet in jaunty reboots X" [High,Confirmed]
<tjaalton> tseliot: thanks, but like I said, that's included in 0.8.2.2
<tjaalton> without the #ifndef stuff
<tjaalton> I mean  *with*
<tseliot> oh, right
<tseliot> if we ship with the current version though you may want to use my patch
<tjaalton> I'll add it, tired of fighting with it
<tseliot> at this point a more conservative approach wouldn't be a bad idea
<tseliot> add what?
<tjaalton> 0.8.2* is supposed to be the stable branch
<tjaalton> the patch...
<tseliot> ok
<tseliot> hehe it's *supposed* to be stable
<Alexia_Death> tseliot: the patch wont apply for me.
<tseliot> which one?
<Alexia_Death> the  X one
<tjaalton> Alexia_Death: what version are you using?
<tjaalton> oh
<Alexia_Death> patch: **** Only garbage was found in the patch input.
<tjaalton> wrong patch :)
<tseliot> shall I reupload my patch?
<tseliot> without using pastebin
<tseliot> ?
<Alexia_Death> yes please. it seems theres a formating issue somewhere.
<tjaalton> Alexia_Death: how did you copy it?
<Alexia_Death> copy from text box below. trying download now
<tseliot> http://albertomilone.com/ubuntu/157_button_mappings.patch
<tjaalton> what editor did you use? maybe the lines were wrapped
<tseliot> wget it ;)
<Alexia_Death> patch had cr-s ... O_o
<Alexia_Death> Thanks again:D
<tseliot> ;)
<tjaalton> well, patched 0.8.1.6 doesn't work either
<tjaalton> but I uploaded the update before I got to test
<tjaalton> hmm
<tjaalton> silly me, didn't actually install the driver package, only -tools
<tjaalton> works now
<tjaalton> tap-to-click too, without patching the xserver
<tjaalton> Alexia_Death: so your daemon should add more than just the stylus?
<Alexia_Death> yes, it does. the whole set
<Alexia_Death> sometimes pad might be missed
<tjaalton> it doesn't seem to do anything for my device
<Alexia_Death> eraser is sinitally misconfigured tho
<Alexia_Death> tjaalton: you have a bit different device. What is its device node?
<tseliot> it seems to add the eraser and the cursor here, however, if I try to use the eraser I can't see the mouse cursor
<tjaalton> Alexia_Death: where do I get that?
<Alexia_Death> tseliot: you need to set bottomx bottomYfor eraser. thats the bug in the driver.
<tseliot> ok
<tjaalton> Alexia_Death: Bus 005 Device 006: ID 172f:0501  
<tjaalton> ?
<Alexia_Death> tjaalton: what you have under /dev/input?
<Alexia_Death> Your ID is not wacom
<tjaalton> Alexia_Death: the udev rules don't match
<Alexia_Death> yes.
<tjaalton> but...
<Alexia_Death> You can set it up as a serial device...
<tjaalton> the device nodes shouldn't matter
<tjaalton> because it breaks the idea of input hotplug
<tseliot> tjaalton: it works with the current udev rules too
<tjaalton> tseliot: your device, which is listed in the rules file
<Alexia_Death> the add does not match the add device notify criteria the daemon lists.
<tseliot> ah
<Alexia_Death> I use the rules to know WHAT was added.
<Alexia_Death> and to load devices that are present at the moment of start.
<Alexia_Death> it works hotplug just fine, it just expects some info from UDEV nodes.
<tjaalton> but you do understand that this doesn't scale
<tjaalton> you need to add every tablet there or things don't work right
<Alexia_Death> what do you mean?
<Alexia_Death> there arent that many tablets.
<Alexia_Death> by type
<Alexia_Death> theres perhaps 3 new models per year.-
<tjaalton> well you need to have every product id there
<Alexia_Death> your waltop is special.
<Alexia_Death> there already is.
<tjaalton> and how many special devices are there?-)
<Alexia_Death> waltop is the only one I know of.
<Alexia_Death> there is no other way.
<tjaalton> ok, enough ranting then, I'll add this sucker there
<Alexia_Death> Wont be enough.
<tjaalton> why not?
<Alexia_Death> DeviceAdd notifies.
<Alexia_Death> they are filtered by the manufacturer ID.
<Alexia_Death> Yours needs to be added.
<tjaalton> where?
<Alexia_Death> tjaalton: give me your device specs, Ill make a new pack in 5 minutes.
<Alexia_Death> its in the waatahod script tho.
<tjaalton> ok, can't find it.. the vendor id is 172f and product id 501
<Alexia_Death> Name?
<tjaalton> "Waltop Media Tablet" I guess
<Alexia_Death> Ok
<tjaalton> there are many products with the same hw
<tjaalton> don't know what the equivalent wacom device would be
<Alexia_Death> tjaalton: http://a.death.pri.ee/watahod-0.3.3.tar.gz
<Alexia_Death> should work.
<Alexia_Death> tjaalton: that was exactly what I had in mind when I was talking about hardware issues... there a are changes I have to do blind and just hope they work.
<tjaalton> ok, now we are talking
 * Alexia_Death giggles
<tjaalton> I've got a stylus and an eraser
<Alexia_Death> no pad...
<tjaalton> no cursor, no pad, no touch
<tjaalton> what's a pad?
<Alexia_Death> it has all of those?
<tjaalton> I don't know
<Alexia_Death> pad is a set of putons
<Alexia_Death> buttons*
<tjaalton> this has 26 buttons around the area
<tjaalton> K1...K26
<Alexia_Death> ok, then you have pad.
<Alexia_Death> cursor is a mouse... it has it?
<Alexia_Death> its a screentablet?
<Alexia_Death> no..
<Alexia_Death> tjaalton: there is no way to know what device has what, thats why device database is needed.
<Alexia_Death> if its an USB tablet it has no touch devce anyway.
<tjaalton> it has a pen and an area to draw on, no external mouse
<tjaalton> adn two rotating wheels with a button in the middle
<Alexia_Death> Ok, then it has stylus, eraser and pad for buttons.
<tjaalton> *and
<Alexia_Death> give me 2 minutes
<Alexia_Death> tjaalton: http://a.death.pri.ee/watahod-0.3.4.tar.gz
<Alexia_Death> should give you a pad too.
<tjaalton> yes
<tjaalton> should I be able to configure them?
<tjaalton> I see the device in the list but no properties for it
<tjaalton> and what is the kernel module for? it's unused
<tseliot> Alexia_Death: hotplugging my tablet just works now. I made the daemon set the bottomx and y for the eraser too
<Alexia_Death> tseliot: theres conf files for that, I hope you found them
<tseliot> I simply get those values from the stylus and apply them to the eraser automatically
<Alexia_Death> tseliot: the rigth way (tm) is to use defaults files under .wacom...
<Alexia_Death> and the best is a patch to fix it tin the drvier ofcourse
<tseliot> I agree with the latter
<tseliot> I only used the daemon
<tseliot> nothing else
<tseliot> therefore I have no .wacom
<tseliot> directory
<Alexia_Death> yes. its created if you save defaults once
<Alexia_Death> its an option under menu.
<Alexia_Death> tseliot: it supports setting options with watever and dumping them mostly to file and reloading.
<tseliot> aah, in the icon tray
<tseliot> ok
<Alexia_Death> buttons dumping is disabled for now...
<tseliot> ok, I hope to have time to play with it sooner or later
 * tseliot > dinner
<bryce> tjaalton: http://www.phoronix.com/scan.php?page=article&item=ubuntu_904_intel&num=1
<tjaalton> bryce: yeah.. pissed me off
<tjaalton> maybe they didn't have DRI
<tjaalton> I'd appreciate if they'd come here to see if there's something going on to cause something like that
<tjaalton> but I guess the media don't have to ;)
<bryce> I've emailed him to ask for Xorg.0.log's
<tjaalton> I almost did, but couldn't find the right words
<bryce> also asked for glxinfo and xdpyinfo
<bryce> http://www.phoronix.com/forums/showpost.php?p=59669&postcount=6
<tjaalton> hehe
<bryce> are you seeing the performance issues yourself?
<jcristau> isn't phoronix a load of crap most of the time?
<tjaalton> I'm seeing the EXA freezes with vblank
<tjaalton> veery annoying, but I think it only happens after the first time you suspend/resume
<tjaalton> UXA OTOH crashes on resume
<bryce> jcristau: all performance testers are loads of crap, it's just a matter of how high the particular pile is
<tjaalton> I'll reboot to see if it helps with the periodic freezes
<bryce> http://www.phoronix.com/forums/showpost.php?p=59698&postcount=16
<bryce> oh hey I have something to show off
<tjaalton> shoot
<bryce> http://people.ubuntu.com/~bryce/Graphs/
<tjaalton> nice colors
<bryce> thanks
<tjaalton> might want to do the same for totals :)
<tjaalton> good to see the grid
<bryce> yeah, still experimenting a bit
<bryce> +1 for alpha blending :-)
<tjaalton> yeah
<bryce> since these are svg, there's a good bit I can do to them further
<bryce> these are basically straight from gnuplot
<bryce> but I like having all the states in one graph; in the old plots each went to a different chart so you had to do a lot of mental comparisons
<bryce> also I think viewing 3-months at a time is better than 1 month or 6 months
<tjaalton> having a dynamic one would probably be overkill :)
<bryce> http://people.ubuntu.com/~bryce/Graphs/xorg-2008q4.svg is my favorite - that's a monster!
<bryce> I was surprised how quickly they generate; takes less than 30 sec to generate all the plots 
<bryce> what do you think happened in q2008 that drove the xorg bug numbers so high?  was that simply from testing?
<tjaalton> it's the "default" component that triagers reassing the bugs
<bryce> reassing :-)
<tjaalton> -sign, duh
<bryce> I like reassing better
<tjaalton> hehe
<tjaalton> certainly does ring a bell
<bryce> I like in these charts that you can quite clearly see where I've been running my new/expire scripts thursday each week
<tjaalton> so much fun trying to figure out what those bugs are about..
<tjaalton> true
<bryce> I don't have the data for it yet, but I want to also track triaged-bugs-forwarded-upstream, too
<tjaalton> btw, what do you think about not having an xorg.conf by default?
<bryce> jaunty+1
<tjaalton> hmm ok
<bryce> I'd like to see Virtual become completely unnecessary before we switch to xorg.conf-less
<tjaalton> well it's the gui that adds those
<tjaalton> I was going to point out bug 319854 as an example, but then again the driver fails to load if it doesn't list the pci-id
<ubottu> Launchpad bug 319854 in xserver-xorg-video-ati "x.org not using ati/radeon driver" [High,Triaged] https://launchpad.net/bugs/319854
 * bryce nods
#ubuntu-x 2010-01-25
<verbalshadow> how do you debug a x crash that causes a hardlock and you can't get a backtrace even with when you remote in
<verbalshadow> if the crash the machine can't even accept new ssh connections
<verbalshadow> s/if /and
<RAOF> verbalshadow: You can try mounting the root filesystem with the âsyncâ flag; that'll probably slow disc i/o substantially, but should ensure that (almost) all of the log files get written out to disc before it dies.
<RAOF> You can also try netconsole, to send dmesg out over the network to another machine.
<verbalshadow> RAOF: thanks do i just add sync to the boot command ??
<RAOF> I think you'd want to edit /etc/fstab
<verbalshadow> ok, i wish i could figure out what the hell is wrong it is killing me
<bryyce> tjaalton, are your xorg (1:7.5+1ubuntu1) changes in git?
<tjaalton> bryyce: uh, seems not
<tjaalton> bryyce: I can fix the changelog version when I push
<tjaalton> also will add wacom back to -input-all
<tjaalton> bryyce: do you want to release it too?
<AlanBell> morning all
<AlanBell> I am wondering if there is anything I can do to assist with progress 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> any further information I can add, or point me in the direction of the code responsible and I will have a poke about and see what I can find
<AlanBell> the issue occurs with Lucid Alpha 2
<AlanBell> compiz works perfectly on the same hardware in Jaunty
<tseliot> superm1: it looks like more transitional packages will be needed: bug #510390
<ubottu> Launchpad bug 510390 in nvidia-graphics-drivers "broken alternatives broke vdpau in mplayer" [Medium,Fix released] https://launchpad.net/bugs/510390
<tseliot> you're gonna love it :-P
<apw> bryyce, about?
<superm1> tseliot, i'm not convinced
<superm1> does mplayer build-dep on libvdpau?
<superm1> (eg does it do it right..)
<superm1> i can double check tonight if a fresh install has the same problem with mythtv
<superm1> which does have a proper build-dep on libvdpau
<tseliot> superm1: that would be welcome
<tseliot> I guess it built against the old (nvidia?) libvdpau
<superm1> tseliot, for now, i think just a C/R on that 185 package should be sufficient for upgraders though, no?
<superm1> looking over https://edge.launchpad.net/ubuntu/+source/mplayer/+changelog i'd agree with that
<bjsnider> that old mplayer has an ancient vdpau in it
<bjsnider> it does not play well with the newer libvdpau
<superm1> okay so lets get that fixed before we get any new transitional packages in place
<bjsnider> i'm sure reinhard has it in mind to refresh it
<superm1> bjsnider, do you by chance have a patch for it that you might share with siretart?
<bjsnider> he had to fix that stupid ffmpeg problem first though
<tseliot> superm1: this is exactly why I pinged you before doing any actual work
<bjsnider> superm1, i just used reinhard's update command from the debian scripts
<superm1> bjsnider, the ffmpeg problems should be fixed now i think
<bjsnider> so my version is newer out of svn or whatever it is. may e git. i don't remember
<bjsnider> yeah that's good, so everything should be refreshed, all of the encoding libs like theora, x264 etc. and vlc and mplayer
<tseliot> superm1, bjsnider: can you add a comment in bug #510390
<ubottu> Launchpad bug 510390 in nvidia-graphics-drivers "broken alternatives broke vdpau in mplayer" [Medium,Fix released] https://launchpad.net/bugs/510390
<tseliot> so as to explain what's required
<bjsnider> why does it say fix released?
<tseliot> bjsnider: because there was a bug
<tseliot> maybe we should open a different bug report
<tseliot> the bug was the lack of libvdpau.so in /usr/lib/
<tseliot> which is no longer the case
<bjsnider> my ppa still has that newer mplayer from a few months ago. if someone wants to try it they're welcome.
<bjsnider> but i don't use lucid
<bjsnider> i could ask somebody in +1 i guess
<bjsnider> tseliot, is the nvidia vdpau lib now int he same place as it always was?
<tseliot> bjsnider: it's compliant with what Nvidia explained in bug #432172
<ubottu> Launchpad bug 432172 in nvidia-graphics-drivers "nvidia-180-libvdpau packages both libvdpau and libvdpau_nvidia" [Medium,Fix released] https://launchpad.net/bugs/432172
<bjsnider> wait a minute. how could fta have both nvidia-current and the 185 libvdpau package both installed? they contain the same files. so obviously the locations must have changed
<bjsnider> mplayer needs to be refreshed so that it finds the new location and that old package has to be forced out
<bjsnider> in my view
<tseliot> right but the links will make it work
<tseliot> no doubt on the fact that mplayer needs to be rebuilt against the new vdpau
<Q-FUNK> on Lucid, since a few days, I seem to have a situation where pressing ALT+F* makes the system switch to a vcons, instead of calling whatever shortcut the desktop has defined.
<Q-FUNK> has the kernel and/or X server suddenly changed from CTRL+ALT+F* to ALT+F* to change vcons?
<tseliot> maybe gnome did?
<Q-FUNK> tseliot: gnome still has its shortcuts as before.  as son as I return from whichever vcons I was sent to, the correct gnome action took place and is waiting for me to interact.
<tseliot> oh
<tseliot> tjaalton: ^^
<superm1> bjsnider, okay well i filed a bug in debian to get mplayer patched to stop hacking it's own vdpau support in
<superm1> are there any other packages yo uknow that do this?
<superm1> ffmpeg should be fixed now
<bjsnider> what i meant by the notion that there are problems witht hat build vis a vis vdpau is that there are playback bugs and things that were fixed in 2008
<bjsnider> not that it couldn't find the vdpau libs or drivers
<jcristau> mvo: i resent your xserver patch, hopefully keithp will take it now :)
<mvo> jcristau: cool, thanks. fingers crossed :)
<superm1> well the new stuff dlopen's from a new place too I thought, so that's a bit important as well
<superm1> debian bug 566868 if you'd like to subscribe
<ubottu> Debian bug 566868 in mplayer "mplayer: VDPAU build hacks need to be dropped" [Normal,Open] http://bugs.debian.org/566868
<AlanBell> where is the upstream for the intel graphics driver?
<johanbr> intellinuxgraphics.org
<AlanBell> johanbr: thanks
<AlanBell> I think I found an upstream bug https://bugs.freedesktop.org/show_bug.cgi?id=22996 that should be associated with 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
<ubottu> Freedesktop bug 22996 in Driver/intel "[945GM] external lcd does not work on high resolution" [Normal,Reopened]
<AlanBell> how do I tell launchpad to link to that bug?
<johanbr> click on "Also affects project"
<AlanBell> johanbr: done, thanks.
<johanbr> you're welcome
#ubuntu-x 2010-01-26
<Sarvatt> one day i'll learn mesa master builds are broken after 7.7 branch merges almost every time... always end up packaging mesa right after it happens
<bryyce> Sarvatt, heya
<Sarvatt> might be a good time to update ati soon, quite alot of bug fixes in the past 2 months on master like signifigant speedups for r600 2D, low memory EXA fixes (and fixing NoAccel to work with KMS), a ton of dpms/incorrect resolution fixes, and a fix for a VT problem I've seen people having
<Sarvatt> heyo bryyce
<bryyce> update just the -ati ddx ?
<Sarvatt> had a question for ya, with this new archive restructuring thing, is X going to have a team or is it going to be part of desktop (or core-dev still)?
<Sarvatt> yeah
<bryyce> ok I'll todo getting -ati updated either this week or next
<bryyce> (next week is the developer sprint so I may not get much done)
<bryyce> re: restructuring
<bryyce> well there's certainly advantages either way
<bryyce> I think I'd like to see Ubuntu-X be its own team  separate from the desktop
<Sarvatt> noone really wants to work on X stuff, really strange
<bryyce> heh
<bryyce> Sarvatt, I don't know, I guess I don't have a strong feel either way.  What do you think?
<bryyce> it seems like "X stuff" is distinct enough from "Gtk application stuff" that it splits off easily
<bryyce> on the other hand, if having it be two teams means that there's an extra barrier of entry to people who might get involved, that'd be bad...
<bryyce> I suppose the thing to look at would be if the desktop team is set up to include both gnome and kde; if not, and if there are separate teams for each, then having X be a separate team may make sense
<bryyce> if gnome and kde are both included in the desktop team, then there's less reason to have X separate
<Sarvatt> probably not enough people to even make it worth splitting off, I was just reading the ubuntu-motu logs earlier and was confused where X packages would fall with the new changes since one day down the line when I have enough experience with it i'd be interested in helping out there and dont know which team or whatever I should look into joining. have to dig up the wiki pages again, was reading on my phone :)
<Sarvatt> like is there still going to be a core-dev team and the desktop team has a subset of upload permissions of that? I'm not really interested in stuff outside of X components so I've been on the fence about MOTU and it seems like thats dissolving or something
 * bryyce nods
<bryyce> that's another reason favoring a stand-alone X team... there may be people who are *only* interested in X, and joining the full Desktop team just to get access to X stuff might seem a bit too broad for them
<Sarvatt> oh nice, didn't know -ati disabled EXA pixmaps for cards with <=32MB vram under KMS now, that should fix up those problem cards that needed XAA under UMS back in the day now that KMS is on by default
<Sarvatt> wonder why they didnt branch intel 2.10, post 2.10 is in even worse state right now than 2.10 was for me, compositing is all messed up here
<superm1> bryyce, does that mean you're gonna hire more people to work on X? =]
<bryyce> superm1, you can bet on it
<superm1> that's great! you can never have too much love hacking on X stuff
<Sarvatt> yay for blindly reverting random batchbuffer related commits in -intel 2.10 around when it started to try to find the problem since I cant bisect it :D
<bryyce> :-(
<Sarvatt> -intel master was unusable from 11-11 to 12-10 on 945 here
<Sarvatt> hmm theres a few commits that change things for just <965, maybe that'd be a better place to start
<Sarvatt> hmm, -joystick has some issues
<Sarvatt> took over the mouse
<Sarvatt> ah I had my weirdo udev rule I was experimenting with still installed
<Sarvatt> cant move the mouse away from the top gnome-panel bar with a controller plugged in
<Sarvatt> got it, adding ENV{x11_options.MapAxis1}="disable-mouse", \ to /lib/udev/rules.d/67-xorg-joystick.rules worked
<Sarvatt> hmm that cant be right, thats a MapButton option, it probably disabled that axis or something. should have read the man better
<bryyce> yeah every so often I have to go through doing a full reinstall in order to clear out all the experimental crap I'd been playing with :-)
<bryyce> which has made me be quite strict about not doing any testing on my main desktop
<Sarvatt> i've had this install since intrepid and used devel releases the day they opened since jaunty,  probably really due a reinstall here sometime
<Sarvatt> ext3 converted to ext4 didn't help fsck times at all, my 40gb ext4 native partition fscks in seconds vs a minute or two for the 10gb / so I'm due a reinstall there for that too
<Sarvatt> hmm havent seen this one http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-server/xserver-1.7.1-gamma-kdm-fix.patch?view=markup
<Ng> ugh there's that segfault on USB plug again
<Ng> and that wasn't even crazy confused USB afaict, that was just me unplugging my hub and plugging it back in
<Ng> did I ask last time I was talking about this why apport doesn't catch Xorg server crashes?
<seb128> Ng, because the xorg change to allow that was crashy
<seb128> Ng, it's on the todolist for sprint to rewrite it
<Ng> ah ok :)
<Ng> I'd really like to be able to give a good quality bug report for this segfault other than "erm, I just kinda plug/unplug USB a bit and it crashes" :)
<tjaalton> Ng: log in remotely and run gdb?
<tjaalton> if it's the server crashing
<Ng> tjaalton: I can't reliably reproduce it though
<Ng> it's just sometimes USB insertions seem to make X segfault. weirdly it doesn't get restarted, so I'm left looking at the last state of the framebuffer and think the machine has wedged hard, but I can still ssh in
<tjaalton> Ng: ok
<Sarvatt> Duke`_: if you want something to try -- https://edge.launchpad.net/~sarvatt/+archive/ppa
<Sarvatt> (use it on top of edgers)
<jcristau> Ng: there's a related bug that got fixed upstream recently iirc
<Duke`_> Sarvatt, do I have to add it to my source.list (periodic updates) or just download it once now?
<Sarvatt> just download it once
<Duke`_> ok
<Ng> jcristau: ooh :)
<Duke`_> what did you add in it?
<Sarvatt> i'm just blindly trying to find what broke it but its better than doing nothing for 2 more months :D
<Sarvatt> Revert "uxa: Don't treat prepare_access as a flush synchronisation point."
<Sarvatt>       Commit 637f003b047e426901cab6b1fe3a0924bcb9a38a
<Duke`_> is it compatible amd64? I'm running X86_64
<Sarvatt> uptime
<Sarvatt>  10:21:05 up 10:40,  3 users,  load average: 0.02, 0.05, 0.15
<Duke`_> ah, build finished.
<Sarvatt> yeah whenever it builds, i just uploaded it
<Sarvatt> whoa
<Sarvatt> mozilla must be on a break :D
<jcristau> Ng: http://bugs.freedesktop.org/show_bug.cgi?id=25640
<ubottu> Freedesktop bug 25640 in Server/general "Reattaching USB keyboard causes double free" [Critical,Assigned]
<Ng> ah, that was pointed out to me last time I mentioned this. The one key difference is that theirs was really reliably reproducible
<Sarvatt> hmm i thought that was fixed a month ago
<Ng> mine really isn't
<Ng> I plug in to a USB hub at least 5 times a week and it doesn't even crash once a week atm
<jcristau> Sarvatt: the patch is 2 weeks old, but not pushed, i think
<Sarvatt> ah thats a totally different issue now that i'm looking at it, it was Xi: reset device properties to NULL after deleting them. (#25374) that I was remembering
<johanbr> hmmm... suspend does not seem to work anymore with nouveau
<johanbr> suspending with nvidia on the same kernel works (but gives graphical artifacts on resume)
<apw> bryyce, hey ... how did that testing go?
<bryyce> apw, sorry, got sidetracked on another issue.  It's on the todo list for today.
<apw> bryyce, np
<kees> jcristau: say, can this bug get some love? I'd like to figure out what next-steps are: https://bugs.freedesktop.org/show_bug.cgi?id=9209
<ubottu> Freedesktop bug 9209 in Server/general "Xlib: Maximum number of clients reached" [Normal,New]
<jcristau> talk to ajax, i guess
<kees> hm, ok
 * kees when is he usually online?
<kees> oh, he is, just not in here
<jcristau> he's at RH in boston, so daytime there
<AssertFalse> hi
<AssertFalse> anyone to help me configuring my display settings with Dell Latitude E5400 / Ubuntu here ?
<jbarnes> AssertFalse: also see /topic :)
<jbarnes> lots of good links there
<AssertFalse> have tryied many many thing involving xrandr, modeline, xorg.conf but I can't get my resolution above 1024x800 ; which (i guess) is not the max I can get
<jcristau> what resolution you can get depends mostly on the monitor..
<AssertFalse> (and the /topic is mysteriously not visible with irssi)
<jbarnes> https://wiki.ubuntu.com/X
<jbarnes> that's /topic
<AssertFalse> xrandr says "Screen 0: minimum 320 x 200, current 1280 x 800, maximum 8192 x 8192", am I misunderstanding that i can get 8192 x 8192 resolution ?
<jcristau> probably not
<jcristau> it's the max size of the framebuffer.  but your monitors won't display that much
<AssertFalse> i guess
<strycore> Hi
<strycore> I've set a wrong resolution on my laptop , how do i reset it to default in a TTY ?
<strycore> X has detected wrong refresh rates, i'm getting a black screen on lower resolutions
<johanbr> strycore, try "DISPLAY=:0 xrandr --output <OUTPUT NAME> --mode <MODE NAME>"
<johanbr> where you get the output and mode names from "DISPLAY=:0 xrandr"
<strycore> arrh , I get a X Error of failed request: Badmatch (invalid parameters or attributes)
<strycore> Major opcode : 148 (RANDR) , Minor: 7 (RRSetScreenSize)
<strycore> if that makes any sense
<RAOF> When you run âDISPLAY=:0 xrandrâ?
<strycore> i got the wrong resolution with gnome-display-properties
<strycore> RAOF, no with the output and name
<strycore> DISPLAY=:0 xrandr --output LVDS --mode 1280x800
<RAOF> And âDISPLAY=:0 xrandrâ had LVDS as an output and 1280x800 as a possible mode?
<strycore> yes that's the native resolution
<RAOF> Can you pastebin the output of âDISPLAY=:0 xrandr -qâ?
<strycore> I'm afraid i can't , I would need a command line version of pastebin ;)
<RAOF> pastebinit!
<RAOF> sudo aptitude install pastebinit.
<RAOF> The worlds finest remote debugging tool.
<strycore> ah ok :)
<RAOF> Then you'd run âDISPLAY=:0 xrandr -q | pasetbinitâ
<strycore> hmm, I would need network-manager now :(
<strycore> oh wait, xterm session works
<RAOF> Oh.  You don't have your wireless set up as a system-wide thing?  That's a good thing to do :)
<strycore> I know but I haven't configured my laptop that much since i installed lucid
<RAOF> Heh.  Setting my home's wireless to system-wide is one of the first things I do - for pretty much this reason :)
<strycore> well , I'm trying to figure out in gnome-display-properties' source code where it saves its settings
<RAOF> In ~/.config/gnome-something-or-other/monitors.xml
<strycore> ah
<strycore> i typed Alt+F2 and typed xrandr -s 0 blindly , it worked :)
<RAOF> :)
<strycore> how does xrandr "guesses" the resolutions and refresh rate ?
<strycore> 1360x768 , that pretty new to me ! 
<RAOF> By asking your monitor for the resolutions and refresh rates it supports.
<RAOF> IE: X grabs the EDID via DDC.
<RAOF> Whoops!  Phoronix is wrong about xserver-xorg-video-nouveau.
<RAOF> Also, yay for the kernel team!
<strycore_> http://pastebin.com/m7b1ec797
<strycore_> 1280x800 and 1024x768 works , that's all
<RAOF> None of the other ones do?
<RAOF> I'm surprised by that output, though.
<strycore_> nope, black screen
<RAOF> You might want to submit a bug against your video driver; it would appear to be returning invalid modes (which probably means that your monitor has a broken EDID).
<strycore_> I'm pretty sure there's something wrong with the monitor
<RAOF> And filing a bug with the EDID attached means we (or, rather, upstream) can add a work-around.
<strycore_> I had a really hard time to get it working on gutsy and dapper (back when fglrx supported my chipset)
<RAOF> https://wiki.ubuntu.com/X/Troubleshooting/Resolution is the page of wonder.
<strycore_> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/513011
<ubottu> Ubuntu bug 513011 in xorg "Wrong refresh rates on low resolutions with HP NX 7000 on Lucid" [Undecided,New]
#ubuntu-x 2010-01-27
<Cyber-Kun> yO
<Cyber-Kun> Damn it.
<bwh> o_O ?  The following packages have unmet dependencies:
<bwh>   xserver-xorg-video-nouveau: Depends: xserver-xorg-core (>= 2:1.6.2) but it is not going to be installed
<LLStarks> bryce. you're never around when i need you.
<LLStarks> anyone here?
<LLStarks> bryceh, sup.
 * bryceh waves
<LLStarks> bryceh, did you get my pm about vbe blanking and unblanking?
<bryceh> nope
<LLStarks> https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/496842
<ubottu> Ubuntu bug 496842 in gnome-power-manager "gpm lacks proper vbetool blanking and unblanking" [Undecided,Confirmed]
<LLStarks> this problem was present in karmic and is still present in lucid.
<bryceh> do you have a patch?
<LLStarks> nope.
<LLStarks> sorry.
<LLStarks> with the semester starting, this bug will piss me off continually.
<LLStarks> if i close my lid, i have to reboot.
<LLStarks> it's a system-crippling bug.
<LLStarks> unless you can access a terminal and do a manual vbetool unblank without a working display
<LLStarks> bryceh, what i would like to know is if there is any additional information that bug report might need that would aid in it getting fixed.
<LLStarks> i'd be happy to provide.
<bryceh> well one problem is you've stated a solution rather than a problem
<LLStarks> i question it's viability as a solution.
<LLStarks> unblanking is still spotty with that code snippet
<bryceh> I don't think you care whether gpm has vbetool blanking, if there was some other fix that solved your issue you'd be happy with that
<bryceh> so first fix the title
<bryceh> secondly, you've filed it against gpm but who knows if it's actually a bug in gpm.  could be (likely) a kernel bug
<LLStarks> "Ubuntu lacks proper vbetool blanking and unblanking"?
<bryceh> I am guessing since you are here in the X channel you also wonder if X might be involved (maybe, although most blanking bugs end up needing kernel fixes in my experience).  Anyway, whenever you think X may be involved, attach all the usual X debug files
<LLStarks> Xorg.0.log and what else?
<bryceh> LLStarks, you're thinking too much there - state the nature of the problem.  "Inspiron 640m won't unblank after a lid close unless dpms is turned off
<bryceh> LLStarks, wiki.ubuntu.com/X/Reporting
<bryceh> LLStarks, or use apport
<bryceh> (man apport)
<LLStarks> heh. i can do x collection.
<LLStarks> how convenient
<bryceh> probably you should talk to ogasawara or one of the kernel team people, they're the ones with expertise on debugging lid close bugs
<bryceh> -> #ubuntu-kernel
<bryceh> and you should at least test with a lucid livecd; few developers will bother looking at your bug until they know it also exists on lucid, since that's what they're working on.
<LLStarks> i have confirmed it on a fresh alpha 2
<LLStarks> live environment included
<LLStarks> also afflicts lucid with latest packages or with xorg-edgers
<RaiN88> Hi everyone, I had thist problem: 
<RaiN88> When I click restart, then my laptop process to restart and flikering lines appears (Flikering Lines also appears when I Shut Down before it's totally Turn Off.), but when it should be restarted it just stay's there with Blank black screen, ready to reboot but it wont.Then I have to actually hold the power button in to shut it off and boot it again. It is so very annoying. Laptop : Asus X80n, 1GB RAM, 160GB HDD, Nvidia Geforce 700m = 256mb, Ubuntu 9.10 fu
<RaiN88> lly updated. I hope you can able to help me solve this problem. Kind regards, and thanks in advance,
<vish> hmm , if anyone wants to have a look at the aboe problem the user wrongly filed the bug in irc bots >  https://bugs.launchpad.net/ubuntu-bots/+bug/513056
<ubottu> Ubuntu bug 513056 in ubuntu-bots "Won't Restart" [Undecided,Invalid]
<knittl> do i have to blacklist any modules to make standby work with nvidia cards?
<knittl> i tried nvagp in xorg conf and blacklisted agpgart and amd64_agp, but my pc still won't wake up properly
<RAOF> knittl: What driver are you using?
<knittl> nvidia-current
<knittl> when waking up i only see colorful squares on my screen
<knittl> my laptop stays responsive, i can even kill x with ctrl-alt-x
<knittl> but that's not a real solution â¦
<knittl> * ctrl-alt-backspace
<RAOF> Hm.  I dunno.
<knittl> i'm also willing to troubleshoot, if i only knew how
<RAOF> If it were nv I'd be able to say âyes, that's expectedâ, but it's pretty easy to tell if you're not using the binary blob - you don't get 3d :)
<knittl> no, it's nvidia-current
<RAOF> Has this worked on any prior Ubuntu release?
<knittl> yes
<knittl> oh
<knittl> i'm talking about lucid here
<knittl> the problem exists since i upgraded to lucid
<RAOF> Yeah, I could tell - you're using nvidia-current, which only exists in Lucid :)
<knittl> thought i'd mention it anyway, in case you didn't notice ;)
<RAOF> I don't think I know of anyone else having this problem; it might be a bug in the new nvidia driver?
<knittl> i searched for the problem, and didn't find any similar reports for lucid yet
<knittl> so yes, it might only be me â¦
<RAOF> The binary drivers are always a bit... fun.
<RAOF> Fine when they work... :)
<knittl> yup :D
<knittl> my "only" problem is, that the screen doesn't come back after standby
<knittl> everything else works
<knittl> so maybe it's a problem with re-initializing?
<RAOF> Why don't you pastebin the output of lsmod; maybe I'll see something obviously wrong.
<knittl> http://paste2.org/p/635105
<RAOF> That would seem to be the obvious candidate for problems, yeah.
<knittl> agpgart and amd64_agp are blacklisted, nvagp is set to 1 in xorg
<RAOF> You know, I wonder if vga16fb could have anything to do with this.
<knittl> dunno
<RAOF> Feel like trying a little experiment?  Move the vga16fb module out of /lib/modules/$KERNEL and rebuild your initramfs; then reboot.
<knittl> why not blacklist it?
<knittl> and yes, i feel like experimenting :)
<knittl> gotta go home now from university, bb in a few minutes, then i'll try and tell the results
<RAOF> knittl: You could blacklist it, but I'm not sure if the blacklist makes it into the initramfs; the framebuffer is loaded pretty early.
<knittl> ok, i'll move it then
<knittl> RAOF: i can't see the file in /lib/modules
<knittl> i did a find -name '*vba16fb*' and no results
<jcristau> vga, not vba
<knittl> wops
<knittl> ok, rebooting
<knittl> no wait
<knittl> what about nvagp and blacklisted modules?
<knittl> agpgart and amd64_agp respectively
<RAOF> If you didn't blacklist them before Lucid, don't worry about them.
<RAOF> IIRC, loading vga16fb is something new in Lucid (to support plymouth, I think).
<knittl> ok, then i'll remove the blacklist stuff
 * knittl reboots
<RAOF> It won't hurt t ohave them blacklisted (although given that you've got intel_agp loaded, blacklisting amd64_agp probably won't do anything :))
<tseliot> RAOF: right that's exactly why we have vga16fb
<knittl> i can resume from standby
<knittl> but it does not work 100 %
<knittl> i have to turn the screen on with one of the fn-keys (crt/lcd or widescreen/4:3)
<knittl> and my desktop wallpaper is cyan, instead of a beautiful red flower
<fmarl> knittl, do the same thing to vgastate.ko
<fmarl> I'm doing this while testing the nouveau driver.
<knittl> okaydokay
<knittl> then rebooting another time :)
<RAOF> fmarl: Nouveau isn't providing its own framebuffer driver for you?
<RAOF> We'll be getting 2.6.33's nouveau kernel stack in linux-backport-modules soon; it's time for me to update the DDX & make noises about nouveau-firmware.
<fmarl> RAOF, nouveau provide its nice framebuffer but these two drivers break nouveau badly
<jcristau> does vgastate get autoloaded?  i'd expect it to only get loaded as a dependency for another module
<fmarl> jcristau, yep, vga16fb load vgastate (?)
<jcristau> right so blacklisting vga16fb should be enough
<RAOF> Why is vga16fb getting loaded?
<RAOF> It doesn't for me.
<RAOF> Where are you getting nouveau from?
 * RAOF is fairly sure that the xorg-egders nouveau should be adding an initramfs hook that'll get nouveau up and running before it attempts to load vga16fb
<fmarl> RAOF, I'm not using the packages, compiling from source.
<knittl> still no luck
<knittl> removing both modules seem to work the least
<knittl> with only vga16fb disabled my cpu goes crazy when fading the screen out before the screensaver activates
<RAOF> fmarl: Ah.  Ensuring nouveau.ko is in your initramfs should make vga16fb go away.
 * hyperair wonders if those strange GPU-switching notebooks are supported on linux.
<RAOF> I seem to recall mjg poking at the ACPI tables required to switch.
<hyperair> =O
<hyperair> but does X support such a thing?
<RAOF> Maybe not.
<RAOF> I dunno; I'd guess the macbook nvidia/nvidia switch could fly.
<hyperair> hmm
<RAOF> That's probably easier than the intel/nvidia combos some laptops have.
<tseliot> no, X doesn't support that yet
<vish> ... i'm noticing this repeat error in the gdm log files> http://paste.ubuntu.com/363843/ there are two files now nearly 2.7GB in size with those errors.. 
<vish> seems to have started somewhere around the 19/20th , probably with updates xserver-xorg-core (2:1.7.3.902-1ubuntu8) to 2:1.7.3.902-1ubuntu9 ???
<vish> xorg logs show nothing of the sort :s
<tseliot> vish: it looks more like radeon issue to me i.e. xserver-xorg-video-ati
<vish> tseliot: hmm , but last xserver-xorg-video-ati update was around 12th.. this seems to be since somewhere around the 19/20... earlier gdm logs are clean
<jcristau> did you restart X in the mean time?  and used Xv?
<vish> X has been running for 6days .. just now restarted the system
<tseliot> vish: I can't reproduce the problem here (but I'm using r600 instead of r500). Does the X log say anything interesting?
 * vish checks
<vish> tseliot: i dont think there is any mention  ,  Xorg.log>  http://paste.ubuntu.com/363891/ , Xorg.1.log> http://paste.ubuntu.com/363889/
<vish> it maybe something from the time i used , gnome-shell? [i think i was using it during that time]
<tseliot> (EE) RADEON(0): Kernel modesetting setup failed
<tseliot> the other file looks good though
<tseliot> vish: maybe dmesg can help^
<vish> tseliot: dmesg.0.log >  http://paste.ubuntu.com/363897/  , not sure if it is the same time frame though
<tseliot> there's nothing wrong in it
 * vish digs into older dmesg
<vish> tseliot: what should i be looking out for in the dmesg? [things got a little dizzy here :s]
<tseliot> vish: errors ;) ?
<vish> ;)
<tseliot> vish: BTW in what log did you find those weird errors about textured video?
<vish> tseliot: gdm logs > /var/log/gdm/:0.log [was 2gb, just deleted right now] , /var/log/gdm/:0.log.3
<tseliot> vish: so it was the X log. Weird...
<vish> yeah.. i'v restarted the session , log seems quiet .. will check if it kicks in again
<vish> tseliot: hmm , i also was earlier having this gdm related X error > Bug #506510  where X kept crashing... anyways , will try to notice when it starts again
<ubottu> Launchpad bug 506510 in xorg-server "Xorg crashed with SIGSEGV in FatalError() when using guest session" [High,Fix released] https://launchpad.net/bugs/506510
 * vish hasnt tried guest session for a couple of days due to those errors 
<tseliot> vish: maybe try booting without the "splash" parameter
<vish> ok.. will do that in a few
<Sarvatt> where is this nouveau kernel at? whats the versioning on it? want a xserver-xorg-video-nouveau with nouveau-kernel-source | linux-image-2.6.32-x dependency? libdrm needs a few commits past 2.4.17 to work with the current ddx also. was just nouveau added or did they pull in all of drm-core-next that'll mess with radeon as well (r600+ wont work without additional firmware if so)?
<bryceh> hi sarvatt
<Sarvatt> heyo!
<bryceh> Sarvatt, apw made me a backports module thingee for us
<bryceh> I'm using the -nouveau &tc. from edgers
<bryceh> although I booted and the screen's scrambled so something's still not right
<apw> bryceh, whats with the rotating nicks?
<Sarvatt> that ddx brings nouveau-kernel-source in with it and overwrites the other though
<apw> bryceh, hows the testing with that ?
<Sarvatt> (just something to watch out for)
<bryceh> apw, eh, I lost 'bryce' over the holidays so am trying out a new nick
<bryceh> Sarvatt, yeah that's what I suspect
<apw> lost it?  someone else stole it?  annoying
<jbarnes> bryceh: why don't you register with nickserv?
<bryceh> apw, do I need to do anything special to get your backport nouveau module loaded?
<bryceh> jbarnes, actually I did
<bryceh> jbarnes, so I'm not sure why the nick got taken.  very frustrating.
<jbarnes> bryceh: lame
<tseliot> bryceh: you can recover your username then
<apw> those who have the h/w have said they had to blacklist nv
<bryceh> apw, ah
<Sarvatt> purge all the nouveau stuff, grab the xserver-xorg-video-nouveau source, install libdrm from edgers, change the nouveau-kernel-source dep to whatever the backport thingy is called from the ddx and rebuild and reinstall the backport would work
<tseliot> bryceh: http://docs.dal.net/docs/nickserv.html#4.2
<Sarvatt> backports isnt installed by default though, what does it gain doing it that way over just keeping nouveau-kernel-source?
<bryceh> tseliot, doesn't appear to work
<bryceh> tseliot, just get "invalid command"
<bryceh> Sarvatt, btw here's apw's ppa with the nouveau stuff https://edge.launchpad.net/~apw/+archive/blue/+packages
<tseliot> bryceh: try with "/msg NickServ" command
<tseliot> instead of "/nickserv" command
<bryceh> tseliot, same thing
<tseliot> weird
<bryceh> I like 'bryyce' but got no end of questions about it.  bwh seems logical but no one would guess that to be me (not sure yet if that's a pro or a con). 
<tseliot> bryceh: this is what freenode says: "if you don't sign onto the network for at least 60 days, or you don't identify to nickserv for at least 60 days, the nick is considered expired"
<jcristau> bwh is one of the debian kernel guys on oftc :)
<bryceh> jcristau, great...
<tseliot> bryceh: and I don't think I've ever seen you far from irc for so long
<tseliot> bryceh: therefore maybe you simply have to use the "ghost" command?
<tseliot> i.e. "/nickserv ghostÂ nicknameÂ [password]"
<tseliot> and then just identify as usual
<tseliot> (after changing your nick)
<tseliot> :-)
<tseliot> bryce: was it the ghost command?
<bryce> no
<tseliot> hmm
<bryceh> what's annoying is that you can't change your password back if you're logged into registered channels.
<bryceh> feh, anyway, freenode is annoying.
<tseliot> ;)
<RAOF> apw: Thanks for the nouveau kernel PPA.
<RAOF> Sarvatt: l-b-m means we get to build the package, rather than have it built locally.  That bypasses a bunch of possible bugs.
<Sarvatt> oh good point, didn't think about that. what to do about the firmware is the next question then
<RAOF> Yes.
<RAOF> I'm not really sure what to do about it, really.
<RAOF> We've (implicitly) had that firmware in the repository for a couple of releases, now.
<Sarvatt> another pro for lucid+1, firmware wouldnt be needed by then most likely :D
<RAOF> If we really wanted to we could not need firmware for < geforce9 cards.
<Sarvatt> ya mean < geforce 8xxx?
<RAOF> No; the 2.6.33 code already has voodoo generators for < geforce8; if we wanted to, we could pull in the ctxprog generators for geforce8 and a bunch of nvAx cards that (mostly?) work :)
<bryceh> heya RAOF
<RAOF> Howdie bryceh.
<RAOF> Sexy âhâ you've got there ;)
<bryceh> heh
<bryceh> like it better than my yy's?
<RAOF> yys have a certain charm, too.
<bryceh> anyway, so what's our next step for nouveau?  are there changes needed to the xorg-edgers ddx bits to get them to load on top of apw's kernel bits?
<RAOF> There are, yes.  We basically need to not depend on nouveau-kernel-source anymore.
<RAOF> I'll prepare an update to the DDX in the archives & upload that to the xorg-edgers PPA.
<RAOF> We also need to work out what to do about the ctxprogs/ctxvals firmware-like stuff.
<RAOF> Writing the debian/copyright for that package will be... interesting.
<bryceh> heh
<bryceh> RAOF, ok I stand ready to test.  Are there other things I can do to help you right now?
<jcristau> 'this stuff is copyright nvidia.  we may have the right to distribute it.  or not.  maybe.'
<jcristau> archive admins would love it
<bryceh> what's the license on it?  is it at least distributable?
<RAOF> jcristau: We're not even sure if it actually _is_ copyright nvidia; it's not necessarily copyrightable.
<RAOF> bryceh: There is no licence on it; it's been extracted from mmio traces of how the binary driver prods the cards.
<bryceh> hmn
<bryceh> kees, thoughts on the last ~10 lines in the backlog?
<RAOF> It's also possible to programatically generate the voodoo; 2.6.33 includes a generator for nv4x cards, and there's a guy who's got a mostly-working generator for nv5x+.
<bryceh> that sounds like more the way to go
<bryceh> I've added a todo to doublecheck on the licensing
<RAOF> Absolutely.  That's the way it is going, but I don't know if it'll be ready for Lucid.
<bryceh> ok, I've noted to bring it up as an issue when I meet with the kernel team next week
<kees> bryceh: where does the firmware exist normally?  on the chip?
<kees> bryceh: or do windows drivers load it?
<kees> why do we need to ship firmware, I guess is my question?
<bryceh> kees, I assume it's loaded from the hw.  RAOF?
<bryceh> <kees> bryceh: where does the firmware exist normally?  on the chip?
<bryceh>  bryceh: or do windows drivers load it?
<bryceh> <kees> why do we need to ship firmware, I guess is my question?
<bryceh> RAOF ^
<RAOF> It's actually a program to make hardware context switching work.
<RAOF> Without the context switching you lose all acceleration, but nouveau will work.
<kees> so where did it come from originally?
<RAOF> From watching what the binary driver does to the card when it brings it up.
<bryceh> kees, reverse engineered from the -nvidia driver using a capture tool
<RAOF> It's lifted from the mmio traces of the binary driver initialising the card.
<RAOF> We *can* ship without it, and we'll still get KMS out of nouveau, but a totally unaccelerated driver is hella slow.
<kees> okay, so the code representing the firmware lives in the proprietary driver?
<kees> then it should have the same redistribution rules as the driver itself.
<kees> (in the worst case)
<RAOF> Actually, we think that the code represeting the firmware *generator* lives in the proprietary driver, but apart from that, yeah.
<bjsnider> RAOF, you talkin' about the nouveau microcode?
<RAOF> Yes.
<bjsnider> i thought they wrote new microcode
<RAOF> I haven't checked their git logs in the last week or so, but last I checked they didn't have a voodoo generator that'd drive cards newer than geforce8
<RAOF> Yeah.  Unless they've sneaked it in under a strange commit log message there still isn't a ctxprog generator for nv5x+ in their kernel tree.
<bjsnider> my thinking is that if it's pushed out and enough people use it, nvidia couldn't really do anything to stop it
<RAOF> Whatever give you that idea?
<RAOF> s/give/gives/g
<bjsnider> after some period of time the cat would be out of the bag
<RAOF> As I understand it, copyright isn't like trademarks - you don't lose it because you haven't sued the pants of infringers yet.
<RAOF> They could quite happily stop us from distributing it.
<bjsnider> but who would you take legal action against, and how much would it cost, and how long would it take to win,a nd what would be the aftereffects of winning, ie. bad realtionship with redhat, linus, linux community etc.
<RAOF> You'd take legal action against Canonical; after all, they'd be distributing your stuff without a license.  But we don't distribute things that we don't have a license to distribute.
<bjsnider> fedora is
<bjsnider> which is red hat
<bjsnider> does nvidia really want a contentious relationship with red hat?
<RAOF> You're right that nvidia probably doesn't care (now).  Still, we don't ship things because we don't think we'll get sued over them; we ship things that we've got a clear license to ship.
<bjsnider> well, red hat obviously has more confidence that nvidia won't bother them about it
<RAOF> We're more strict about licensing than RH :)
<jcristau> or they have confidence that they can remove stuff from fedora easily if nvidia asks
<jcristau> it's not like they're shipping that stuff in rhel
<RAOF> Right.
<bjsnider> no, but they're responsible for fedora
<bjsnider> hasn't anybody asked nvidia about this?
<jcristau> pretty sure a c&d from nvidia is all it would take for fedora to drop that stuff
<bryceh> do you guys want me to approach nvidia about it?
<bjsnider> yeah but hasn't somebody already approached them?
<bjsnider> this is what airlie and the rest of them said was blocking it from going into the kernel
<RAOF> A statement from nvidia would make the status of the firmware-ish stuff clearer.
<jcristau> it involves lawyers, which usually means it takes some time
<RAOF> If it's easy to ask, sure.
<bryceh> alright, I'll add this to my todo list as well, but will wait to do it until after I've spoken with the kernel team
<bjsnider> could someone approach adobe about distributing the amd64 flash alpha? or tell me who to talk to?
<bryceh> bjsnider, kees might be able to answer that one
<bryceh> RAOF, ok, so leaving aside the blob licensing, anything else I can help with?
<RAOF> bryceh: I don't think so, until it comes time to move stuff to main.
<RAOF> bryceh: If I run into something I'll give you a ping.
<bryceh> RAOF, okie great
<kees> bjsnider: you need to convince asac
<bjsnider> convince him to what?
<bjsnider> talk to adobe?
<kees> use the 64bit flash
<bjsnider> no, you misunderstand
<kees> ah, sorry.  what did you mean?
<bjsnider> i just need approval to distribute it as a package in a ppa, not in the main archive
<bjsnider> i need to know that adobe isn't going to send goons after me
<kees> avoid it by downloading it from adobe; that's what I do with my flashplugin-nonfree in my PPA that uses the 64bit flash plugin.
<bjsnider> you mean it's 100% ok to distribute it as long as the package downloads the plugin from adobe's website?
<jcristau> if the package downloads stuff from adobe, you're not distributing the plugin
<bjsnider> kees, how does yours work? i suspect it's practically the same as mine
<bryceh> bjsnider, I've been running his on my 64-bit system and it works acceptably well
<bryceh> I think it gets tripped up by pulseaudio sometimes, but restarting firefox seems to be enough to make it sane again
<bryceh> also, frequently after doing a system upgrade I have to reinstall kees' package.  Probably don't have it pinned right or something.
<kees> bjsnider: https://edge.launchpad.net/~kees/+archive/ppa/+packages
<bjsnider> i found it earlier
<bjsnider> but i designed one myself awhile back
<kees> cool
<bjsnider> it cuts out nspluginwrapper and uses the alpha
<bjsnider> so i wondered if that's what you've done here
<kees> yeah, I really don't like nspluginwrapper
#ubuntu-x 2010-01-28
<bryceh> I'm going to update -ati to a newer snapshot; anyone know of any glaring issues in the -ati we have in -edgers currently?  Else I'll snag that snapshot for lucid.
<ScislaC> bryceh: Does this have all of the info you need for a decent report? https://bugs.edge.launchpad.net/ubuntu/+source/xf86-input-wacom/+bug/511844 (I'm not asking you to fix my bug, I'm asking about the quality of the report)
<ubottu> Ubuntu bug 511844 in xf86-input-wacom "Wacom Tablet is only recognized on first plug" [Undecided,New]
<ScislaC> wasn't expecting that, you guys think of everything :)
<bryceh> ScislaC, maybe also syslog... like boot with it plugged in, capture that syslog to the bug report, then unplug it, note whatever new stuff shows in the log, then plug it in again, and get that as well
<bryceh> ScislaC, this may be a general usb hotplug issue unrelated to X, it's probably a kernel issue, but the syslog output would (hopefully) be informative of what is going on
<bryceh> another thing which might be of interest is to look at the output of lsusb for the three configurations as well
<bryceh> in theory the first and third cases should have identical lsusb output
<ScislaC> bryceh: wrt general hotplug, would a wireless usb mouse with a usb receiver suffice to test?
<bryceh> I don't know, try it
<ScislaC> I did and it has no issues on multiple plugs
<bryceh> but from what I've seen the usb issues can be hardware-specific
<ScislaC> ahhh
<bryceh> e.g. I have a keyboard with a similar usb issue, but a usb mouse connected to the same port works fine
<bryceh> and on another machine it's vice versa
<bryceh> (and varies depending on what kernel I boot into)
<ScislaC> bryceh: you're not giving me confidence that any amount of information I provide will help to make the bug report any more useful ;)
<bryceh> ScislaC, it would only be false confidence I could supply in any case; my bet is it's not an X bug but rather a kernel issue
 * ScislaC shakes his fist at the kernel
<Sarvatt> regarding ati - none that I know of bryce, just alot of fixes people were having to use edgers to get and thats why I was recommending it.
<bryceh> Sarvatt, great - know of particular bugs the xorg-edgers version solves?
<Sarvatt> not LP bugs I'm afraid, lets see if any stand out :)
 * bryceh looks too
<ScislaC> bbiab... going to collect that syslog and lsusb info
<Sarvatt> <Sarvatt> [22:16:55] might be a good time to update ati soon, quite alot of bug fixes in the past 2 months on master like signifigant speedups for r600 2D, low memory EXA fixes (and fixing NoAccel to work with KMS), a ton of dpms/incorrect resolution fixes, and a fix for a VT problem I've seen people having
<Sarvatt> (some symptoms to help narrow it down)
<bryceh> thanks
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/494672
<Sarvatt> fixed
<ubottu> Ubuntu bug 494672 in xserver-xorg-video-ati "[Radeon Xpress 200M] VT switch freezes X" [Undecided,Confirmed]
<Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=3a30210d50b27f8772fc5045133940246764fce9
<Sarvatt> possibly of course
<bryceh> lp 333377 fixed too
<ubottu> Launchpad bug 333377 in xserver-xorg-driver-ati "[RS480] HP Dv8000 laptop suspends but does not resume" [Unknown,Fix released] https://launchpad.net/bugs/333377
<bryceh> lp 487204 is fixed by mesa 7.7
<ubottu> Launchpad bug 487204 in xserver-xorg-driver-ati "radeon_lock.c:65: radeonGetLock: âdrawable != ((void *)0)â Assertion" [Unknown,Fix released] https://launchpad.net/bugs/487204
<bryceh> ditto 500607 I guess
<RAOF> Argh.  I *always* miss xutils-dev when building nouveau orig.tar.gzs.  Where does it go?!
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/511520  -- already fixed, exact same version that was in the archives :D
<ubottu> Ubuntu bug 511520 in xserver-xorg-video-ati "Ubuntu Karmic: DVI output not working with radeon 4350" [Undecided,Fix released]
<Sarvatt> what do you mean RAOF? I have 7.5+2 in edgers because we need the newer xorg macros
<bryceh> 465958 -> heh, not an -ati bug, how'd that get here
<bryceh> lp 465958 -> heh, not an -ati bug, how'd that get here
<ubottu> Launchpad bug 465958 in x11-xserver-utils "effect of xmodmap ~/.Xmodmap " [Undecided,Incomplete] https://launchpad.net/bugs/465958
<Sarvatt> oh it doesnt get added to your debian/control? I'm not sure, it works fine with auto-xorg-git
<RAOF> Sarvatt: Building the nouveau original tarballs requires that I have xutils-dev installed, because I autoreconf to build the tarball.
<RAOF> Sarvatt: And each time I go to do that it seems that xutils-dev has been uninstalled...
<Sarvatt> oh you install it with apt-get build-dep and it gets autoremoved later? do you use aptitide/synaptic?
<Sarvatt> do you get it installed via apt-get build-dep I mean
<RAOF> I don't know.  It's possible that I just reinstall frequenly enough that I seem to always be missing xutils-dev :)
<RAOF> Or maybe it's my multiple laptops.
<Sarvatt> huh, this bug is confusing
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/507000
<ubottu> Ubuntu bug 507000 in xserver-xorg-video-ati "2.6.32-10 xserver-xorg hang ati radeon mobility 7500" [Undecided,New]
<Sarvatt> hes crashing with the kernel that enables KMS globally, but his logs show it trying to use XAA
<Sarvatt> is there still a force XAA patch in the ubuntu -ati?
<Sarvatt> he has no xorg.conf
<Sarvatt> ahhh
<Sarvatt> he got hit with the xserver trashing libdri/libglx.so during the alternatives switch a few weeks ago
<bryceh> ah
<bryceh> yeah close that bug and ask him to retest and reopen if it's still an issue
<Sarvatt> doing that now
<bryceh> hrm, I see my automatic xorg bug repackager has been a bit too aggressive at refiling bugs against -ati
<ScislaC> bryceh: bug updated with that info, thank you for telling me what might be of use :)
<bryceh> I bet lp 493057 is fixed from the r6xx performance improvements
<ubottu> Launchpad bug 493057 in xserver-xorg-video-ati "in top Xorg CPU usage is always 23+ with frequent spikes to 60+ and sometimes higher" [Undecided,Confirmed] https://launchpad.net/bugs/493057
<Sarvatt> so many incorrect resolution in X bugs on ati that could possibly be fixed now
<Sarvatt> dont think so Bryce, thats a x1600 and the huge 2D speed improvement was only R600
<bryceh> ah right
<Sarvatt> 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc M56P [Radeon Mobility X1600] [1002:71c5]
<bryceh> x1600 is an R5xx
<bryceh> Sarvatt, btw if you run into bug reports which you know have been fixed by upstream code (e.g. a fix is confirmed in xorg-edgers packages), then if you mark the bug report Fix Committed, that clues us for the changelog in when we update the package
<bryceh> ok, uploading new -ati
<Sarvatt> huh, your logs are confusing ScislaC, that XorgLog.gz shows hotplug working, that syslog looks fine too
<ScislaC> Sarvatt: I know... that's why I'm especially confused...
<Sarvatt> is that all over the same boot?
<ScislaC> Sarvatt: given that I don't know how things work internally, is there anything in particular that would make the pen not work after the tablet is replugged? (I don't know if it ties the pen to a device id of sorts on first use)
<ScislaC> Yep, I followed bryce's instruction on how to do it. Booted w/ tablet plugged in, captured syslog, unplugged, grabbed change from syslog, replugged, grabbed change from syslog again (I did attempt to use the pen on the three times, it worked for the first only)
<Sarvatt> first time as in before you unplugged it the first time? because it looks like it loaded right on boot and the first unplug/replug at least
<Sarvatt> maybe try rmmod wacom after you unplug before you plug it in again to see if its any different?
<Sarvatt> it looks like the kernel sides working though, maybe watching what happens with sudo udevadm monitor might be interesting?
 * Sarvatt isn't sure
<Sarvatt> have you ever had that kind of issue with any other usb devices on that system?
<Sarvatt> did you try plugging it in and such before the wacom driver got updated? curious if it was having the same problem with evdev
<Sarvatt> i tried my 2 tablets on 4 systems now and hotplugging works fine multiple times on them all :(
<RAOF> I'm scared and confused.  Why does my 2.6.32-10-generic initramfs have a nouveau kernel module?
<Sarvatt> installed it with dkms ever? it installs to the latest 2 kernels
<RAOF> Ah, I probably just hadn't rebuilt the initramfs after removing dkms.
<RAOF> Man we pack the kitchen sink into our initramfs.
<Sarvatt> especially now with plymouth!
<Sarvatt> pango and such
<RAOF> There are probably *some* kernel modules that don't end up in there... :)
<Sarvatt> i dread anything calling update-initramfs because it takes a good 5-10 minutes here :D
<johanbr> pango?! yikes...
<johanbr> at least it's better after dpkg triggers were implemented
<Sarvatt> i have it set to rebuild all every time
<RAOF> And you've got every kernel since Warty installed?
<Sarvatt> nah i build my own weekly and forget to remove them until it annoys me enough, removing just one takes forever
<Sarvatt> rebuilds all initrd's twice and calls update-grub twice.. silly kernel-package hooks
<RAOF> Gah.  Why does the nouveau DDX think l-b-m-n's kernel module doesn't have KMS enabled?
<Sarvatt> stopped doing that though and am just living with having to remount my SD every resume, wish the ubuntu kernels had mmc unsafe resume enabled
<Sarvatt> weird it should *only* have kms by now?
<RAOF> Yes.
<RAOF> Also, that's why X isn't starting; the UMS code just isn't there.
<RAOF> It's mis-detecting KMS.
<RAOF> At least I get a 210x65 console to debug from.
<Sarvatt> did you build it against lucid's libdrm 2.4.17? i thought the ddx needed a post 2.4.17 update to even build anymore
<Sarvatt> could something be screwy with the lbm-* module renaming?
<RAOF> I built it against xorg-edgers 2.4.17+git20101020
<RAOF> You're right, it does need to be built against > 2.4.17.
<RAOF> I'm just checking how it checks for kms.
<bryceh> ouch, it needs a git snapshot of libdrm?
<bryceh> hope we can cherrypick what it needs
<RAOF> I'd be surprised if we couldn't; I'm fairly sure it's just #defines in the nouveau headers again.
<Sarvatt> cant cherrypick i dont think because it adds a new symbol
<Sarvatt> well could and define that symbol in libdrm-nouveau1.shlibs I guess, i'm slow
<RAOF> We've done that before.
<Sarvatt> whats the error in Xorg.0.log? [drm] KMS not enabled?
<ScislaC> Sarvatt: Yes, first time as in before it was unplugged. I've never had issues like this on this system, and it worked as expected in Karmic. I will try your suggestions after I eat. :)
<Sarvatt> ahh i better get off the pc, wife wants to watch a few house episodes before we pass out :D will try the nouveau stuff out tomorrow, i'll try making NVPciProbe() always assume KMS is enabled and see if it works that way too
<RAOF> I *think* the problem is that we've renamed the drm directory under /sys/stuff to lbm-drm.
<RAOF> Well, dropping the KMS check makes everything work nicely.
<tseliot> bryceh: are you around?
<Cobalt> Hello. Does anyone know if Xorg Edgers has a IRC channel?
<tseliot> you can ask here
<tseliot> Cobalt: maybe ask Sarvatt and RAOF
<Cobalt> tseliot: Thanks.
<Cobalt> Sarvatt, RAOF: It's regarding a change made to the Intel Xorg driver after xserver-xorg-video-intel_2%3a2.9.1~git-0ubuntu0tormod_i386.deb. I noticed there's a bug filed for this on Launchpad: #502663. I'm having the exact same problem, with the latest packages (from 20100127). Is there any information I can supply that might help fix this issue?
<Cobalt> That is, any package made after that one causes a crash, back to the log-in screen. It always crashes, but the amount of time it takes to do that varies.
<Sarvatt> [drm:i915_gem_object_bind_to_gtt] *ERROR* Invalid object alignment requested 4096
<Sarvatt> thats the error you get?
<Sarvatt> I have gotten that at one point before but only on the 2.6.31 kernel, it didn't happen on the 2.6.32 kernel
<Cobalt> Sarvatt: It is, I just wrote an entry in the bug report.
<Sarvatt> can you try with a mainline kernel? I recommend 2.6.32.6 http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32.6/
<Cobalt> I am on 2.6.31-18-generic. I ought to look into how to upgrade to .32, test that and report back.
<Cobalt> Sarvatt: I'm going out right now, I'll do that when I get back.
<Cobalt> How different is the mainline kernel from the -generic Ubuntu one, do you know?
<Sarvatt> I have to run too, if you dont have any luck with it I'll see it in the irc logs though and come back when I can :)
<Cobalt> Sarvatt: No worries, this is a lot better than no interaction at all. Thanks for the pointers.
<Sarvatt> its basically the newest upstream kernel with the karmic kernel configuration
<Sarvatt> upstream stable kernel that is
<Cobalt> That's nice. I'm definitely getting it. Hope that solves some the nasty bluetooth pairing issues I've been having with my aluminium Mac keyboard at the same time.
<Cobalt> It's downloading, I'll install and test after I get back. Laters. And thanks again.
<ScislaC> Sarvatt: So, I did the couple of things you recommended last night (rmmod wacom & udevadm monitor), everything looked fine. I even tried a dummy test to have the tablet plugged in, NOT use the pen, and then on replug to test if the pen works... nope, it truly will only work on the first plug only.
<bryceh> ScislaC, :-(
<ScislaC> bryceh: Yeah... it is SO strange. As mentioned, with the X stuff from Karmic (because that is the one piece I held off on upgrading), it all worked as expected.
<ScislaC> brb
<ScislaC> yay for a newer ati driver :)
<bryceh> ScislaC, did it solve any issues for you?
<ScislaC> bryceh: the transition from plymouth to gdm looks less scary (before the whole screen was corrupted, this last start was only about 25% of it). I haven't done much more yet to know.
<bryceh> ok
<bryceh> ScislaC, if you post bugs about those issues, sub me to them and also include a photo
<ScislaC> bryceh: ok... I will reboot in a bit with my camera available. There is also interruption of plymouth on shutdown that I don't know if it's known or expected right now.
<tjaalton> ScislaC: try with a 2.6.33-rc package
<tjaalton> it's likely something in the kernel drm driver, since it's using kms anyway
<ScislaC> tjaalton: is there a ppa I should use?
<tjaalton> ScislaC: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33-rc5/
<ScislaC> brb :)
 * bryceh waves to tjaalton
<tjaalton> hi bryceh, nice nick :)
<ScislaC> tjaalton: No plymouth at all with that kernel... also no wacom action either (I had to test)
<tjaalton> ScislaC: you have to boot it with the kernel option to turn kms on
<tjaalton> can't remember what it was
<tjaalton> option radeon modeset=1
<tjaalton> radeon.modeset=1 on the kernel cmdline
<tjaalton> sauna ->
<ScislaC> tjaalton: when you say kernel cmdline, would that be the line in grub?
<ScislaC> well, that's what I'll try... brb
<ScislaC> tjaalton: I had no plymouth on boot, but it showed up on shutdown.
<tjaalton> ScislaC: do you have kms on boot, better vt's etc?
<ScislaC> vt's?
<tjaalton> virtual terminal
<tjaalton> c-a-fN
<ScislaC> I added radeon.modeset=1 in grub... I'm back in my 32 kernel at the moment (it seemed that video acceleration wasn't working for me in 33)
<tjaalton> ok
<ScislaC> I will test again in a bit to see about the vt's though 
<RAOF> bryceh: Oh, I do have something I'd like a pointer towards - how to make nouveau the first autoprobed driver in X.
<tjaalton> see what the nvidia/fglrx patches do
<tjaalton> though they are disabled
<bryceh> right
<RAOF> In the xorg-server package?
<tjaalton> yes
<bryceh> RAOF, yes
<bryceh> basically there's a case statement that selects a driver by chip manufacturer id
<bryceh> so look for the line with "nv" and change it to "nouveau"
<RAOF> We're in a bit of a bind with the combination of nouveau (a) not being a part of the base kernel and (b) not working *at all* when its kernel module isn't available, so I think the best way to reliably get to X is to have it try to autoload nouveau, then fall back on nv (then VESA, or whatever).
<tjaalton> rather put it above nv
<bryceh> actually what we really want is to try "nouveau" first and then "nv" if it's unavailable
<bryceh> however I'm not sure that fallback function will work
<tjaalton> it works if nouveau fails to init
<RAOF> I'll have a look & give it a try.
<jcristau> does it only work if probe fails, or also if preinit fails?
<tjaalton> at least when the driver doesn't support the chip
<tjaalton> not sure what stage that is
<RAOF> nouveau fails fairly early in the init when its kernel module is unavailable
<RAOF> I can test it out & see.
<RAOF> *After* I bisect the kernel to work out when suspending started to work again in 2.6.33
<tjaalton> gimp crashes when wacom is unplugged, nice
<tjaalton> on karmic though, don't know about lucid
<Sarvatt> tjaalton: pretty sure thats fixed in xserver 1.7, i had the same issue all during karmic and it didnt happen with the early pre-1.7 releases
<tjaalton> Sarvatt: ok, good
<Cobalt> Sarvatt: Using the mainline kernel you gave me a link to fails to load proper ath5k modules, get no wifi, and hence can't test for the most usual test case and reproduce the crash (ie, opening pages in Firefox). As an aside, apparmor profiles also fail to load, and /proc/mount fails to mount as well.
#ubuntu-x 2010-01-29
<bryceh> RAOF, hey how are things looking with nouveau at the moment?  got anything worth testing?
<RAOF> Hm.  Testing the nouveau->nv->vesa fallback patch would work better if I had xserver-xorg-video-nv or xserver-xorg-video-vesa installed.
<RAOF> Strange.  It'll fallback to VESA, but not to nv.
<tjaalton> logfile?
<RAOF> Bah, it got overwritten.  I'll get a new one.
<RAOF> tjaalton: http://pastebin.com/f3d8d0b6c
<tjaalton> RAOF: huh, that's funny
<RAOF> Yes.
<RAOF> tjaalton: http://pastebin.com/f2ab1e6fc is a log with the nouveau kernel module available, if that's interesting to compare.
<tjaalton> that looks normal
<RAOF> If the vesa DDX isn't available & the nouveau kernel module isn't available, then X just fails to load.
<tseliot> RAOF: doesn't it use fbdev instead of vesa?
<tseliot> tjaalton: ^^
<RAOF> tseliot: Not in my log; X can't load that module (because I don't have the package installed for some reason).
<tseliot> I think fbdev should be our first fallback
<RAOF> A can change the patch if that's the case.  Will fbdev actually work well, though?  I'm not familiar with it, but isn't our framebuffer going to be vga16fb?
<tjaalton> vesa doesn't work at all with kms
<RAOF> But if we're falling back to vesa in this case then that means that nouveau has failed, which probably means that kms isn't available.
<tjaalton> it can fail for other reasons too
<tjaalton> like intel
<tjaalton> or ati
<bryceh> I've got wayland built
<RAOF> Does that have any input yet?
<bryceh> haven't booted it yet.  maybe not
<RAOF> Heh.
<bryceh> just getting it to build is a challenge
<RAOF> There's now something worth testing in ppa:xorg-edgers/nouveau
<bryceh> awesome, I'll todo that for tomorrow
<bryceh> have you had a chance to test it?  any tips?
<tseliot> bryceh: are we going to have nvidia cards at the sprint?
<bryceh> tseliot, I can bring some, but it'd be for a desktop system
<tseliot> right
<RAOF> bryceh: Yeah, I've tested it with my laptop; it works :)
<RAOF> Well, apart from suspend, because my laptop still doesn't quite manage to actually suspend with the Lucid kernel.
<bryceh> tseliot, I'm going to be coming from home each day so if it turns out we want a desktop box we can slap cards into, I can bring one.  and an lcd monitor, kbd, mice, etc. too
<tseliot> bryceh: right, I forgot that you live near Portland
 * RAOF goes to check on the status of his kernel bisect for that.
<tseliot> bryceh: I was asking as I'm not sure that I'll be able to test Jockey today and I'll leave tomorrow
<bryceh> gahh buildd's too slow
<bryceh> "Start in 49 minutes (2505)"
<tjaalton> why not test it locally?
<bryceh> tjaalton, it builds fine locally
<tjaalton> so autoreconf helped?
<bryceh> I didn't have the original problem locally
<tjaalton> hmm ok
<bryceh> well, but I'm not building in a clean pbuilder environment
<vish> tseliot: its happening again :(   gdm log is logging X errors :(
 * vish reboots again without splash
<vish> same error repeats http://paste.ubuntu.com/365081/ , not sure how it starts :s
<vish> not sure why gdm logs it , but i'v noticed one problem , conky stops being displayed for some reason , even if i restart it it wont be displayed
<bryceh> tjaalton, rats.  make: autoreconf: Command not found
<bryceh> guess tseliot was right, probably needs explicit automate build-dep
<tjaalton> autoconf
<vish> anyone? any suggestions on how to debug the above error ^ also KMS doesnt seems to setup from xorg.1.log > http://paste.ubuntu.com/365090/
<vish> seem*
<tseliot> vish: I think I missed the 1st error. I can only see the one about KMS
<vish> tseliot: the same error i showed you couple of days ago> http://paste.ubuntu.com/365081/
<vish>  not sure why gdm logs it , but i'v noticed one problem , conky stops being displayed for some reason , even if i restart it it wont be displayed
<vish> it seems to start after a few hours ... I dont notice any errors when the system is started
<vish> the gdm logs just eat my / space :s
 * tseliot looks for hints in the -ati driver
<vish> thanks :)
<tseliot> vish: do videoclips work?
<vish> tseliot: yeah , i can watch videos
<tseliot> vish: maybe you need this patch? http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=e1200cb89218930d01330ba0114e013438655cce
<tseliot> which reverts another commit that we have in Lucid
<vish> yeah , maybe , tseliot when was the earlier commit?
<vish> this is something very recent  , has been happening since less than 10days
<tjaalton> tseliot: umm, that's old
<tjaalton> vish: check the kernel changelog then
<tseliot> tjaalton: that commit, yes, but we still don't have it
<tjaalton> tseliot: how come? the snapshot is from master
<vish> kl;'
<vish> kl;'
 * vish hmm...  still trying to figure out what starts it :s
<tseliot> vish: how much ram does your card have?
<vish> 2GB
<bryceh> tseliot, btw got cairo-drm built
<tseliot> bryceh: ah, nice, what was it?
<tseliot> vish: really? What does the bios say?
<bryceh> you put me on the right track.  just kept throwing deps at it.  libtool, automake, autoconf...
<vish> tseliot: ah.. the radeon card is 512mb [i guess] let me check.. how do i check BIOS from session?
<tseliot> the easiest way is to just enter the bios
 * vish brb
<tseliot> bryceh: which explains why it was building in your environment and failed in buildds
<bryceh> exactly
<tseliot> tjaalton: I guess airlied fixed that in master (after that revert)
<tseliot> bryceh: it looks like a few macros in -ati trigger these errors: http://paste.ubuntu.com/365081/
<tseliot> e.g. BEGIN_ACCEL, FINISH_ACCEL, etc.
<tseliot> I'm wondering if we're missing something is mesa
<bryceh> weird
<bryceh> anyway I'm going to bed
<tseliot> good night
<bryceh> looks like I've got wayland in the bag, but a few odds and ends to finish up tomorrow
<tseliot> sounds good
<tseliot> apw: I think we'll be on the same flight to Portland (from Washington DC)
<tjaalton> tseliot: I'm confused.. fixed in master means we have it in lucid
<tseliot> tjaalton: right, so I was taking back what I said before ;)
<vish> tseliot: hehe... 128 MB  .. [with some humbug about being upto 512mb HyperMemory]  so 128 i guess ;D
<ripps> Okay, not cool. I've lost my glx extensions in X. I can't start compiz
<tjaalton> tseliot: ah :)
<ripps> glxinfo just spits out: Xlib:  extension "GLX" missing on display ":0.0" a bunch of times
<tseliot> ripps: log?
<ripps> tseliot: which one?
<tjaalton> bryceh: the same build-deps as on every X module :)
<tjaalton> which run autoreconf on build
<tseliot> ripps: Xorg.0.log
<tjaalton> automake, libtool should be enough
<ripps> tseliot:  http://pastebin.com/f666e8286
<ripps> ookkaayy,,nnooww  mmyy  kkeeyybbooaarrdd  hhaass  ggoonnee  ssccrreewwyy!!
<ripps> there, undid an option in keyboard prefences, but I can hold down backspace to delete anymore, I have to press it a dozen times. Wth is going on?
<ripps> ^can^can't
<vish> ripps: that was something wrong with the >  keybindings reported an issue with the keybinding code not loading yes
<vish> ops bad quote :/
<vish> ripps: just set the keypress setting again ;) and all will return
<tseliot> ripps: try with sudo update-alternatives --config gl_conf and select mesa (if you're using ati), then sudo ldconfig
<tseliot> and reboot
<ripps> tseliot: ah that was it, it was trying to load it from nvidia-current
<ripps> vish: turning on repeated keypressess does this: hheelllloo  wwoorrlldd
<ripps> and backspace still doesn't work correctly
<tjaalton> ripps: why do you have nvidia installed?
<vish> ripps: weird , well for me and a few others the slider was all the way to the left... switching the setting back on and adjusting the slider fixed it... 
<ripps> tjaalton: I don't know, it installed itself with the recent lucid updates
 * tseliot -> lunch
<tjaalton> ripps: ok, that's a bug then
<ripps> should I remove it?
<tjaalton> yes
<ripps> tjaalton: oh, i see what happened, my latest mplayer ppa package is pulling it in. Why would it do that?
<tjaalton> probably broken libvdpau depends
<ripps> vdpau is supposed to be optional, not forced
<ripps> it's never forced an nvidia install before, just the one I built an hour ago...
<tjaalton> show the deps
<ripps> http://pastebin.com/f320e864b
<tjaalton> Depends: nvidia-current
<ripps> the package is automatically making nvidia-current a depend, how do I change it to a recommend?
<ripps> or rather, a suggest
<tjaalton> fix the source instead
<tjaalton> it shouldn't need to do that
<tjaalton> there's libvdpau1 you know..
<ripps> tjaalton: but libdpau1 is only available for lucid, what do i do with my hardy->karmic backports?
<tjaalton> ripps: your problem :)
<ripps> vish: yeah that worked. I wonder how they got set all the way to the left.
<ripps> whew... everything worked after I uninstalled nvidia-current. I had to downgrade my mplayer though. I'll have to test some builds to see if I can fix the nvidia-current dependency.
<Cobalt> Hello.
<Cobalt> Sarvatt: I tried the mainline kernel. It does not load the ath5k driver which I require for wifi connection; modprobe loads it but it does not find the appropriate interfaces, and without that, could not use the most common test-case to reproduce the crash.
<Sarvatt> Cobalt: Thats no good, do you have something installed that would interfere with it like madwifi? does grep -R "ath5k" /etc/modprobe.d/ show anything blacklisting it? you might want to try a newer kernel like 2.6.33-rc5 out or try using the lucid kernel instead of the kernel-ppa ones, I do have the same problem as you when I try to use the karmic .31 kernel with newer git libdrm and intel (invalid alignment 4096 errors) and I'm pretty sure it i
<Sarvatt> s kernel related. To be honest I would recommend just putting the intel driver on hold with 2.9.1 and still using edgers for mesa and such, thats what I'm doing currently because of all of the problems
<Cobalt> Sarvatt: No, I don't. Just Wicd, but that wouldn't interfere.
<Cobalt> Sarvatt: grepping shows nothing.
<bryceh> morning
<Sarvatt> oh thats another can of worms, i have no idea about that because I use network-manager
<Cobalt> Sarvatt: The problem occurs before that. There are no wireless interfaces. Wicd is not that low-level.
<Cobalt> Sarvatt: I've been withholding upgrading the driver as well, but as it appeared after one of the updates, I thought there was a regression introduced.
<Sarvatt> does iwconfig show the network? 
<Cobalt> Sarvatt: No, it does not.
<Sarvatt> was just thinking maybe it changed from ath0 to wlan0 recently
<Cobalt> There wasn't _any_ wireless interfaces of any sort. :)
<Cobalt> AAAAHHGGHGT.
 * Cobalt headdesks.
<Cobalt> Sarvatt: You know why no network interface was showing up? That's cos I don't have an Atheros NIC. I have Ralink. Damn, I need to reboot that thing and find out.
<Cobalt> Sarvatt: Having said that, it also complained about /proc/mount not working and it was not able to load my Apparmor profiles.
<Sarvatt> ahh that'd explain it
<Sarvatt> try the lucid kernel
<Sarvatt> staging is disabled for the mainline kernel-ppa builds
<Sarvatt> yeah theres no apparmor in those
<Sarvatt> its a clean kernel, apparmor is a ubuntu patch and not upstream
<Cobalt> You have an address handy for those later kernels?
<Sarvatt> try 2.6.32-12 from the lucid archives
<Cobalt> What about /proc/mount, what is that, and do I need it?
<Sarvatt> should be on packages.ubuntu.com
<Cobalt> Let me have a look at that.
<Cobalt> I had like 15 kernels installed. I pruned it quite a bit, saved about 800MB. So much clutter since I had Hardy in this box.
<Sarvatt> /proc/mount? do you mean /proc/mounts?
<Sarvatt> packages.ubuntu.com isnt even loading for me, i have a really spotty connection where i am
<Sarvatt> RAOF: try adding an alias for lbm-nouveau to nouveau?
<Cobalt> Something like that, I didn't grab the exact error message. What does /proc/mounts do? Is that a list of current mounts?
<Sarvatt> hmm drmOpen is looking for "nouveau"
<Sarvatt> yeah it is
<Sarvatt> the lucid kernel should work for you if its just the ralink problem, that would break because its a driver in staging in the kernel and thats not enabled
<Sarvatt> in those mainline kernel builds
<Cobalt> I see. And Ubuntu includes it for greater hardware support?
<Sarvatt> RAOF: maybe something like this? http://sarvatt.com/downloads/0001-lbm.patch
<Sarvatt> yep, stuff in staging breaks constantly during the -rc cycle and gets fixed up before the final release usually, would be a major pain to track whats broken and rebuild a bunch of times for the daily kernel builds
<Cobalt> I'm new to all that kernel stuff. Wouldn't have known about it.
<Sarvatt> alot of the changes for intel are in the kernel, if you're using edgers its usually a good idea to keep that up to date too :D
<Cobalt> Do I need to mess with the linux-firmware package?
<Cobalt> I couldn't NOT use Edgers either, on that Eee PC, the stock drivers offered like 5FPS at best, with Compiz. And that was as fluid as anything in Hardy, if you didn't go too crazy with effects. I just use a tiny amount of transparency and whatnot.
<Sarvatt> what kernel are you using now? -generic -generic-pae or x64?
<Sarvatt> intel on karmic shouldnt be bad at all, there shouldnt be much of a difference using edgers. jaunty on the other hand...
<Cobalt> Lucid does not seem to have a headers package. I'm using -generic. My 1000H is 32-bit.
<Sarvatt> do you need headers? building external modules?
<Sarvatt> http://packages.ubuntu.com/lucid/i386/linux-image-2.6.32-12-generic/download
<Cobalt> Sarvatt: Yeah, for VirtualBox, via dkms.
<Sarvatt> http://packages.ubuntu.com/lucid/i386/linux-headers-2.6.32-12-generic/download
<Cobalt> I'm actually getting that package your link is pointing to.
<Sarvatt> http://packages.ubuntu.com/lucid/i386/linux-headers-2.6.32-12/download
<Sarvatt> err well
<Sarvatt> theres a bit more of a problem there
<Cobalt> What kinda?
<Sarvatt> i dont think the karmic virtualbox works with 2.6.32+
<Cobalt> It seemed to compile the modules without complaining, however, I didn't use it. Still, I've not used it much lately (I have it to run XP for Nokia PhoneManager to back stuff up). Been lazy.
<Sarvatt> the full featured ones from the virtualbox website work though
<Cobalt> I could always boot to something lower just for that.
<Cobalt> Ah I see. That's what I use. Not the -OSE.
<Sarvatt> gotta run, too much time sitting in the car and i'm late for the next job, good luck with it :)
<Cobalt> Thank you again. Will drop in a line about what's going down.
<Sarvatt> morning bryce! missed you saying that in all the talk :D
<Sarvatt> apw: are your changes to add lbm-nouveau in git anywhere?
<bryceh> Sarvatt, https://edge.launchpad.net/~apw/+archive/blue/+packages
<herman_> how can i see the driver of my graphic card?
<bryceh> your /var/log/Xorg.0.log
<herman_> is there a specific line?
<Sarvatt> it should be really obvious in the first 2 or 3 pages of it, if you can put it on pastebin we can tell you
<Sarvatt> this lbm-nouveau stuff really looks like it will cause more problems than just building it with dkms, packing in a whole new drm and such with different names, is it really removing the old drm/ttm and such when it loads? i dont have my nvidia machine handy to mess with it to see
<herman_> s
<herman_> Sarvatt, i have 3 log's Xorg: Xorg.0.log Xorg.0.log.old Xorg.20.log. What do i put in pastebin?
<Sarvatt> 0
<Sarvatt> first one
<herman_> Sarvatt, here: http://pastebin.com/m76625838
<Sarvatt> the i915 intel driver
<Sarvatt> version 2.6.3
<herman_> version i find
<herman_> what line is i915?
<Sarvatt> around line 107, its the xserver-xorg-video-intel driver
<Sarvatt> i highly recommend upgrading to karmic though, there were quite alot of problems with intel on jaunty
<herman_> Sarvatt, it's why i'm asking this to you
<herman_> my ubuntu looks "strange"
<herman_> maximizing and minimizing is slow
<herman_> everything looks slow 
<Sarvatt> yeah that should be *much* better on karmic
<Sarvatt> if upgrading is an option at all
<herman_> i will try
<Sarvatt> you can try a karmic livecd out and see how much better it will be
<herman_> because, this way is terrible
<Sarvatt> it was unfortunate but jaunty was released when intel was doing some major restructuring with their drivers and there were quite alot of problems, there are some things you can do to work around it if you want to stick with jaunty though
<herman_> and the version 8.10, do you know about it?
<Sarvatt> sorry, gotta run for a few minutes but i'll give you some xorg.conf options that will help on jaunty when i get back
<Sarvatt> 8.10 is good but 9.10 fixes most of the problems from 9.04, i'd recommend upgrading instead of wiping and downgrading :D
<herman_> i understading
<herman_> because i work for a project, and we use 8.10 to develop 
<herman_> Sarvatt, do you have to go out?
<Sarvatt> herman_: the "Performance regressions on intel graphics" section on this page might help - http://www.ubuntu.com/getubuntu/releasenotes/904
<Sarvatt> the Option "MigrationHeuristic" "greedy" part in particular helped alot in those days on my system with firefox scrolling speed
<Sarvatt> yeah I had to drive to my next job but I'm back now for a bit :)
<Sarvatt> from a terminal, type sudo gedit /etc/X11/xorg.conf and add Option "MigrationHeuristic" "greedy" at the end of the Device section (but before EndSection) and reboot
<Cobalt> Shouldn't logging out and back in again do the trick?
<Sarvatt> need to restart the xserver
<herman_> Sarvatt, i don't want to disrupt you
<herman_> thanks for the help until here
<herman_> i will try update my ubuntu to karmic koala
<herman_> i'll find you here other days
<Cobalt> Well, logging out and in seems to do that.
<Cobalt> Gonna reboot to that new kernel.
<Cobalt> Gah. Got lazy instead.
<herman_> Sarvatt, hey, my ubuntu feels a bit better
<herman_> i think
<Cobalt> Sarvatt: Interestingly, it does load my rt2860sta module. But it does not automatically put my wlan0 interface up. Maybe because the scripts originally look for ra0. Once I do that, things go okay. I still need to test the latest drivers now.
<bryceh> my kid's first experience hacking on Ubuntu:  http://www2.bryceharrington.org:8080/files/images/ubudutch.jpg
<Duke`> a future packager!
<virtuald> hack the planet!
<Ng> bryceh: laptop on the duvet! think of the airflow! ;o
#ubuntu-x 2010-01-30
<Duke`> I've noticed a little performance regression between dri-20100121 and dri-20100127 packages
<bryceh> trick is measuring it
<Sarvatt> yep same here Duke`, its just glxgears though
<Duke`> Sarvatt, ok, no regression on quake3 for example?
<Duke`> I may still git bisect, for curiosity
<Sarvatt> none here for openarena or qgears2, its more like glxgears got sped up 50% for a few weeks rather than it dropped back to normal now :D
<Duke`> I hoped that normal would be the 50%+ :D
<Sarvatt> i noticed it went back down around the 24th or 25th
<Sarvatt> intel: Remove DRI1 junk from blit glBitmap.	
<Sarvatt> around that time in mesa
<Sarvatt> i looked at the log when i noticed it was slower
<Duke`> hum, junk code removal making it slower?
<Sarvatt> nah not pointing at that commit specifically, was just saying that was the time frame where it happened here
<Duke`> ok
#ubuntu-x 2010-01-31
<ripps> Hey, I enabled agpmode 8 in my xorg.conf, and my r300 ati isn't crashing instantly. I guess that's thanks to KMS.
<ripps> Of course, I've probably jinxed it now.
<jcristau> ripps|sleep: with kms, agpmode in xorg.conf is unused
<Duke`> Sarvatt, so I bisected mesa a bit in order to find the glxgears fps regression and it seems to be http://cgit.freedesktop.org/mesa/mesa/commit/?id=c7fc9bfb2207638a479ddaff3ad108ffd9cd294a
<Duke`> Sarvatt, btw, have you applied some special patchs/reverts to edgers package to fix the execbuf problem? I haven't seen it for some days... (but eh)
#ubuntu-x 2011-01-24
<kva> hello, all
<RAOF> Hello.
<RAOF> Ok, so - you've managed to get all the way through to Unity at one point?
<kva> yep, from live cd
<RAOF> (If it said âyour hardware doesn't support Unityâ before running unity perfectly wellâ¦ that's a bug âº)
<kva> unity gave many errors with starting plugins and install link
<RAOF> Can you describe your symptoms more?
<kva> sure
<kva> ok, booting from live cd gives blank screen and error proposing classical desktop
<kva> after it it fails to load plugins and permits to run installer
<RAOF> You've skipped a lot of pre-X stuff there - what happens before then?
<kva> after installing system won't boot
<kva> nothing. blank dark screen
<kva> problem isn't in X drivers, it's before,,,
<RAOF> So, you stick in the CD, boot up, and seeâ¦?
<kva> dark screen and then message saying that unity won't run on this hardware
<RAOF> So, when you turn on your computer you don't get BIOS messages, then a LiveCD boot menu, then something, then the Unity thing?
<kva> no boot menu. that's the problem
<kva> sure I do get bios messages
<RAOF> Hm.  I'm surprised that you don't get the Ubuntu livecd boot menu.
<kva> well, I am talking to you using same laptop :-) it boots :-)
<kva> no, black screen, maybe boot menu is right there, but I can't see it
<kva> even switching to text console doesn't works
<RAOF> That's quite odd.
<RAOF> If you're on the livecd now, could you please pastebin /var/log/Xorg.0.log and dmesg?
<kva> I am on debian
<kva> sure I can
<kva> what are you're interested in? I can send whole file
<RAOF> I'm interested in the whole file, and the whole dmesg, but you'll want to send it to a pastebin.
<kva> give me a minute
<RAOF> Obviously I'd like these from the livecd session :)
<RAOF> kva: No, you should paste the *links* to the pastebin here :)
<RAOF> !pastebin
<ubot4> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<bryceh> RAOF, mightn't it be better just to have him 'ubuntu-bug xorg' ?
<RAOF> bryceh: Yes, it probably would!
<bryceh> (him or her)
<RAOF> kva: That's a much better idea; run âubuntu-bug xorgâ and give us the bug number.
<kva> http://paste.ubuntu.com/557530/
<kva> http://paste.ubuntu.com/557531/
<kva> once again, I am not running ubuntu
<RAOF> But you could do that from the livecd.
<kva> sure, but not right now. if you really need it I can try :-)
<kva> you have all details on the hardware for now, problem isn't there
<RAOF> Yeah.  What I was after was some sort of logs containing the problem, which you obviously can't get from running Debian :)
<kva> don't tease me :-) I just reinstalled the system like for 6th time in a row :-) I'll be glad to help
<RAOF> Mesa builds much, much, *much* faster with a hot ccache when btrfs isn't making disc access painfully slow!
<kva> but right now I have something running :-)
<RAOF> kva: You don't have to *install* Ubuntu, just start up the livecd.
<kva> ok, let me find it. 5 min
<RAOF> And once you're there, âubuntu-bug xorgâ will be the quickest way to collect a bunch of relevant information.
<bryceh> what is the problem description here?
<bryceh> RAOF, there's a boot sequence outlined at https://wiki.ubuntu.com/X/Troubleshooting/BlankScreen
<RAOF> bryceh: Ah, that's where that got to :)
<kva> hm. sorry I have to download livecd first
<kva> I owerwrited it with debian image :-(
<kva> which image I can download for you?
<kva> I mean which image will give you more details?
<RAOF> The latest natty desktop cd would be the most useful one to test.
<kva> which one i32 or amd64?
<kva> or either
<RAOF> Either.
<kva> ok, downloading i32
<kva> 10 min to go, 5 min to write, hope it'll reboot, you'll be here in a half an hour?
<RAOF> Yeah.
<RAOF> Hm.  I should perhaps look at the clock first.
<RAOF> Mr Clocky says â5:45pmâ, which makes half an hour less of a sure thing :)
<kklimonda> :D
<kva> I am lucky, mine says 7:48 :-)
<kva> well, I cannot reboot faster :-)
<kva> thank you for your help and good morning and nice dreams :-)
<RAOF> Running âubuntu-bug xorgâ will put the interesting logs into a launchpad bug, though.  And you can probably try the things listed on https://wiki.ubuntu.com/X/Troubleshooting/BlankScreen
<kva> well. problem is that I can't access grub menu... 
<bryceh> why not?
<RAOF> The livecd won't be using grub, anyway.
<RAOF> But you really should be able to get *some* form of boot menu from the livecd.
<kva> yup. live cd boots and gives an error, installation on hard drive can't even access to grub menu
<RAOF> How are you trying to get access to the grub menu?  You need to hold left-shift during early boot to bring the menu up.
<kva> but you're right, symptoms as described
<kva> escape, never tried left shift 
<evilvish> we dont need grub to boot live cd.. just make sure the BIOS is set to boot the cd first..
<kva> sure I did
<evilvish> once the cd boots, you'd have two options install/ try
<evilvish> if cd is not loading â¦ then either the iso(daily?) is bad atm..
<evilvish> bad or broken.. some folks in ubuntu+1 did complain about installation not working..
<kva> well, hope I will be able to install irc running livecd :-)
<evilvish> kva: or you can just use IRC webchat from firefox.. ;)
<kva> oups, it worked anyone here?
<RAOF> kva: For a short while, yes.
<kva> well, I sent a report but I don't have a number
<kva> ubuntu-bug crashed
<kva> but it listed all what you wanted :-)
<RAOF> ubuntu-bug crashed?
<kva> can you catch it up by ip?
<kva> yep
<kva> it reported that all is sent and crashed so I don't have a number
<RAOF> It should have brought up a web browser for you to finish the thing?
<kva> nope. only gnome window
<kva> well, I can try again, disk is ready
<RAOF> Yeah, that would be good.
<kva> well, when you're sure :-)
<kva> wait for me 5 min
<kva> sorry for taking it so long
<kva> 705078 and a couple of tries to report about gnome panel applets
<Sarvatt> RAOF: looks like theres a new libglapi we need to ship now too
<Sentynel> hi guys, the last nvidia update from x-updates seems to have royally screwed my system up
<Sentynel> updated today and post-reboot, x wouldn't start, it just hung on a plain screen. wouldn't even accept ctrl alt f1 to drop to tty. I have a) ppa-purged x-updates, b) completely apt-get purged the nvidia-* packages, and c) tried xorg.conf from multiple backups I know worked in the past, as well as using nvidia's software to generate a new one. I am stumped as to what could be left that's causing problems. any ideas?
<bjsnider> Sentynel, distro/hardware?
<Sentynel> bjsnider: kubuntu 10.10, nvidia 9600GT
<Sentynel> 64bit
<bjsnider> does it still work without the 270 blob?
<Sentynel> if I use the failsafe xorg.conf or completely remove all nvidia packages, I can get it to boot with the free software drivers
<bjsnider> i think you should go to the nvforums linux site and generate one of their bug reports and submit it to them. until they release a new blob use the older blob in maverick
<Sentynel> the version from the main ubuntu repo doesn't work eitehr
<Sentynel> *either
<Sentynel> after this issue, anyway; it worked prior to upgrading to the ppa version
<Sarvatt> bjsnider: have you used those 270.18 packages? I didn't upload it for maverick/lucid because it has all kinds of problems on xserver 1.9.x here
<bjsnider> yep
<bjsnider> they work well here
<bjsnider> i figured it was safe because nvidia doesn't usually break backwards compatibility
<bjsnider> and if they did break something they'll probably release an update quickly
<Sentynel> any ideas why the previously working 260.19 version from the main repos is no longer working? if I can just get that restored I'm not personally overly bothered about 270 for the time being
<Sentynel> I guess something must have been left over from 270, but I cannae find it
<bjsnider> Sentynel, try dkms status
<Sentynel> nvidia-current, 260.19.06, 2.6.35-24-generic, x86_64: installed
<bjsnider> now try ls -l /usr/lib/nvidia-current
<bjsnider> make sure all of the versions match 260.19.06
<Sentynel> yup
<Sentynel> AH
<Sentynel> er
<Sentynel> no
<Sentynel> grep fail
<Sentynel> everything matches 260
<bjsnider> have you got any strange stuff on your system, like xorg/mesa stuff from other ppas?
<Sentynel> nope, this is the only vaguely graphics related ppa I've used
<bryceh> RAOF, anything needing uploaded?
<Sentynel> man, I can't get anywhere. only thing I've found which might be vaguely related is nvidia-detector returns "none"
<Sentynel> any way of getting useful error output out of the x server trying to start?
<jcristau> don't use nvidia is a good start
<Sentynel> unfortunately I need a CUDA capable card
<kva> strange, problem Sentynel had is quite close to mine...
<Sentynel> kva: please tell me you fixed it
<kva> but I am not using nvidia
<kva> nope
<Sentynel> arse
<kva> just managed to send a bug report I hope
<kva> also black screen and no text console at all
<Sentynel> that's the one
<kva> but that's on intel card, not nvidia
<bryceh> "black screen" is a generic symptom, not a specific bug
<bryceh> you guys could both have that same symptom but completely different underlying bugs causing it
<kva> well, I explained, from live cd it boots finally but after install no chances
<bryceh> also black screen bugs tend to be very hardware specific, so since you don't have the same hw it's 99.999% certain you *don't* have the same bug
<bryceh> troubleshooting directions @ https://wiki.ubuntu.com/X/Troubleshooting/BlankScreen
<kva> I won't be so sure, it has something to do with brightness controls
<kva> maybe
<bryceh> what we're telling reporters right now is to boot natty xorg-edgers and file a bug with 'ubuntu-bug xorg' (or attach info to an existing bug report via 'apport-collect <bug-num>'), and then we can forward the bug upstream.
<kva> it has nothing to do with X directly, because even before X there's blank screen
<kva> already done that this morning
<kva> 705078
<bryceh> also, the majority of black screen bugs on intel/ati/nouveau are actually bugs in the kernel kms/drm code, so testing a newer kernel snapshot can be worthwhile to do
<bryceh> kva, yeah, so you're already narrowing it to kernel most likely
<kva> sure
<kva> but I am writing you from debian running older kernel
<kva> same hardware :-) I am scared
<kva> so when debian upgrades the kernel it won't start anymore? any ideas how I can report the problem so you can pin it?
<kva> strange point is that livecd is working somehow after with a bunch of errors, but installed system won't even boot
<bryceh> well those errors might be pertinent
<bryceh> you should write them down and include them in the report
<bryceh> e.g. maybe it's disabling something in livecd that it doesn't disable with install
<bryceh> I don't know what kernel version debian plans to update to in the future, but if they happen to go to the same version you're on now it wouldn't surprise me to hear the bug is there too.
<kva> well, actually I have a suspicion. I saw very fade, not black screen with choice try/install I know how it looks like
<bryceh> but I'm guessing the problem will not be present in a .38 kernel, and I suspect debian will be targeting something newer than .37
<kva> because to start livecd to the point where it lights up takes some punching on enter. you see what I mean?
<bryceh> kva, nope sorry
<kva> well, very fade screen with sidebar with choosing language on right and two big square buttons left - try, right - install
<kva> normally it should be bright readable screen
<kva> after pressing try it boots, after it says that unity isn't supported by my hardware and proposes to change session
<kva> messages about changing session are well readable
<kva> unity shall run normally, I don't see any problem. compiz runs
<kva> are you able to access logs from my report this morning?
<bryceh> kva, what's the bug #?
<kva> 705078
<kva> I attached logs to it this morning
<kva> it was suggested and it's likely this one
<bryceh> kva, no that bug belongs to Mario Limonciello, you need to file your own
<kva> there's no logs attached from me?
<bryceh> who suggested your issue was 705078?  That doesn't seem to match the problem you've described.
<bryceh> kva, nope no logs on that bug from anyone but mario
<bryceh> besides, it's not appropriate to attach your logs to someone else's bug report ;-)
<kva> well. ok I have livecd so I'll reboot and file my own :-)
<Sentynel> if anybody has any bright ideas for files or configuration that could be left over from the 270 drivers, now would be a good time, otherwise I'm going to have to reinstall, I fear
<kva> well, 707088. need any more details?
<kva> it proposed to file it against xserver but I am totally sure it's not where it belongs
<kva> bryceh: that helps?
<bryceh> kva, yes that helps a lot
<bryceh> in fact, this proves indeed it is the same bug as 705078
<bryceh> kva, I coded a patch for that bug, which you could test if you like.  Install this PPA:  https://launchpad.net/~bryce/+archive/bug705078/+packages
<kva> well, could you join it to it? there were bugs launching applets, but I don't think that applets are in cause
<bryceh> yeah those are unrelated issues (and I think already known)
<bryceh> ok I'll join it
<kva> well, I can't test it, patching livecd is a strange thing :-) but well, hope it helped you. will test when new livecd shows up
<kva> thank you
<kva> by the way, if you can pass it to where it belongs, livecd doesn't has any irc client which I know of, even chatzilla won't install on that version of firefox
<kva> pidgin installs but well, you have to do it manually
<bryceh> you need to bring that up elsewhere, we just look at X issues here
<bryceh> I think they are pointing people to using web irc clients now
<kva> sure, that's not really my concern here
<jcristau> web irc clients?  eww.
<kva> :-)
<kva> soon we won't need hard drives, we'll boot from web :-)
 * jcristau hates the web so much..
<bryceh> jcristau, not to mention those damn kids on your lawn
<evilvish> kva: we already have that.. cloud computing ;)
<bryceh> anyway, I agree... I dunno why we haven't moved to a dvd image or something.  seems like we waste too much time shaving the .iso down to fit on cds and lose too many niceties as a result
<kva> but really issue isn't there. if you can track it... from first purple screen till starting X the screen is completely blank, after it there's unity error and finally crash like this
<kva> sure, I am burning iso on dwd-rw :-)
<kva> losing like 3G of useful space
<evilvish> irc client wont be a priority in the default even if we switch to dvd, irc is for geeks  :D
<Sarvatt> RAOF: please please pleaseee dont upload ati based off debian-experimental branch, I get a crapload of complaints when r600g is broken
<bryceh> evilvish, it is needed for providing tech support
<kva> chatzilla is fine for me, just firefox coming with natty isn't supported yet :-) but well, that's not against you :-)
<evilvish> bryceh: yea.. but still techsupport should not be the priority, it should just work â¢  :)
<kva> lol! :-)
<bryceh> evilvish, I like the idealized world you live in ;-)
<evilvish> ;)
<kva> since when bleeding edge linux is just working without tricks and patches? :-)
<evilvish> kva: you dont need to install any plugin, just use Â» http://webchat.freenode.net/
<kva> well, never knew it :-) anyway you can install pidgin running from livecd image, I tested
<cnd> bryceh, RAOF: I wanted to give you guys a heads up that we will likely be keeping the xserver gesture patches in natty
<cnd> there are resource issues that are causing the change in plans
<cnd> do you know what's going on with those patches in alpha 2 (pre-xi2.1 merging)?
<cnd> I plan to forward port the patches onto xi 2.1 changes after alpha 2
<evilvish> kva: we are already embedding it on some of the sites Â» http://unity.ubuntu.com/contact-us/ , http://loco.ubuntu.com/irc/ , once it gets better protection, we could just have a bookmark in FF linking to #ubuntu â¦ 
<evilvish> (else we'd have spam bots attacking)
 * evilvish wanders off.. ;)
<bryceh> cnd, I've not been tracking them upstream no.
<bryceh> cnd, sounds like there are still potential abi bumps upstream coming in the next week or so, so we might hold off on xserver updates a bit longer
<bryceh> was anticipating getting mesa in today but sounds like raof may need another day or so
<cnd> bryceh, meaning they would drop into ubuntu after alpha 2?
<bryceh> I think we can merge in newer drivers this week
<cnd> but still the old xserver?
<bryceh> cnd, potentially
<bryceh> cnd, personally I'd really like to see all this get in for alpha-2 though.
<bryceh> cnd, right that'd be new drivers, old xserver
<cnd> k
<bryceh> but I need to sort out plans with raof
<bryceh> cnd, given that you're thinking of using the same patches as before, does that lessen your requirements for xserver 1.10?
<cnd> bryceh, nope :)
<cnd> 1.10 is needed for multitouch
<cnd> our patches are for gestuers
<Sarvatt> 1.10 or input abi 13 from 1.11...?
<cnd> we really want 1.10, but either way we'll be patching in input abi 13 from 1.11
<cnd> 1.9 just makes my life crazy hard :)
<Sarvatt> were going to need to force IgnoreABI in xorg.conf for the nvidia blob in jockey for this non standard input abi tseliot
<Sarvatt> ah not here
<bryceh> Sarvatt, file a bug
<bryceh> food, bbiab
<ricotz> Sarvatt, hi :), is xserver update complete, it segfaulted with the latest xserver update on intel (without the intel driver update)
<Sarvatt> ricotz: nope, new xserver video abi break got uploaded last night and i didnt see it until a few hours ago, things are still building
<Sarvatt> actually, it looks like it's all built now
<ricotz> Sarvatt, so the nvidia blob 270 wont run with this update?
<Sarvatt> it wouldn't run with the last one
<Amaranth> well that was fun :)
<Amaranth> upgraded xserver-xorg-core from edgers but didn't have the -intel to go with it, hello segfault
<Sarvatt> Amaranth: should be all fixed now, sorry about that.. a new server with the abi break got uploaded last night and the drivers didn't get updated but its all fixed up now
<ricotz> Sarvatt, ok, i will try on my intel again ;)
<Amaranth> yeah, it's all fixed now
<Amaranth> now to get the data bryceh wanted
<Sarvatt> RAOF: is this edgers-scratch branch you're pulling xserver packaging from public anywhere?
<tjaalton> Sarvatt: nvidia doesn't care about the input abi ;)
<tjaalton> only the input drivers do
<Amaranth> huh, I think apport is crashing while trying to collect info
<ricotz> tjaalton, so 270 might run with all other drivers updated?
<tjaalton> ricotz: probably
<ricotz> tjaalton, would be a hard time to revert everything if it fails :P
<Sarvatt> oh I guess it might load anyway, they use input for their hotkey stuff.. [  2354.991] (WW) NVIDIA: This server has an unsupported input driver ABI version (have 12.1, need < 12.0).  The driver will continue to load, but may behave strangely.
<Sentynel> ricotz: just a warning, upgrading to the 270 drivers completely screwed up my (kubuntu 10.10 64bit) system; currently reinstalling it
<Sarvatt> i'm using 270.18 on the 0111 checkout of xserver 1.10, glx wont load because of the newer x extension abi though
<ricotz> Sentynel, i already using it with xserver 1.10 on natty
<Sentynel> ricotz: well, it appears not to work with the older xserver in maverick, for me at least
<tjaalton> Sarvatt: oh, bah
<Sarvatt> ricotz: yep nvidia 2D is busted now too with the latest server update
<RAOF> Sarvatt: Yeah, it's a private git.debian.org repository.  You should be able to find it in ~raof-guest/public_git/xorg-server.git
<bryceh> morning RAOF
<RAOF> Morning bryceh.
<bryceh> tjaalton, Sarvatt, RAOF, alpha-2 is coming up soon
<RAOF> Feel like a little running of the unity teststuite on a new mesa?
<bryceh> RAOF, sure
<RAOF> Let me add the changelog entry and push.
<bryceh> what issues exist for us to solve in order to get the X stack into alpha-2 ?
<bryceh> I think that basically means getting it all uploaded by Friday, which gives us a few days for any final fixes
<RAOF> We need a new x11proto-randr & x11proto-xext to build the server, a rebuild of evererything against the new server, and a new wacom upstream release.
<Sarvatt> do we really want to do a libdrm-nouveau1a transition?
<RAOF> What we *really* want to do is have a libdrm-nouveau2 transition, but that requires upstream participation.
<bryceh> For  x11proto-randr & x11proto-xext, is that just a merge from debian?  would it break anything if we went ahead and uploaded that now?
<kva> RAOF: we found my problem but it isn't linked with X for real, any ideas where I can ask?
<RAOF> x11proto-randr & -xext require updating to a snapshot; they haven't seen a release yet.
<bryceh> kva, your next step is to test the PPA I pointed you at.
<kva> bug report is already treated by bryceh
<bryceh> RAOF, that's ok
<kva> well, problem is before starting X
<RAOF> bryceh: So, it requires more than a merge from debian, but should be easy.
<bryceh> RAOF, is the version in xorg-edgers the one we'd want in?
<kva> all is cool :-)
<RAOF> bryceh: Yeah.
<bryceh> RAOF, Sarvatt, tjaalton, shall I go ahead and upload those two packages from xorg-edgers now?
<RAOF> Ah, they'd want a cleaner changelog.
<bryceh> I can take care of that
<bryceh> tjaalton, didn't you have a script for doing rebuild requests?
<bryceh> it would be nice if we could minimize the amount of driver broken time after updating the xserver
<RAOF> I'd be ok with the x11proto-{randr,xext} from edgers being uploaded.
<bryceh> regarding wayland, is there an existing release that just needs packaging or merging, or are we still awaiting the release?
<RAOF> A release of wayland, or it's dependencies?
<bryceh> er
<bryceh> s/wayland/wacom/
<bryceh> sorry finger muscle memory
<RAOF> Heh.
<bryceh> in any case wacom probably isn't a blocker
<RAOF> I've got it packaged locally, needs uploading.
<RAOF> It's a member of -input-all, which makes it moderately blockerfull.
<bryceh> RAOF, ok can you dput it somewhere for me to grab?  Or shoot me a debdiff or whatever
<RAOF> Certainly.
<bryceh> ok, libdrm-nouveau1a 
<bryceh> Sarvatt sounds concerned that's going to be a bit messy, what do you think raof?
<RAOF> I don't think it'll be too bad.  We're already committed to rebuilding all its rdepends.
<RAOF> I don't think that it'll prove to be much of a problem, and it will prevent people getting segfaulty partial-upgrades.
<bryceh> alright
<bryceh> ok, now to drivers...  we've got an -intel Q4 release we should package up... you planning on tackling that RAOF?
<RAOF> Yes.
<Sarvatt> intel is already ready in git
<bryceh> ok, I looked at pulling the -ati rc snapshot, but it needs new mesa iirc so held off.  Looks easy - do you want to do that too or shall I?
<Sarvatt> was really hoping we could avoid libdrm-nouveau1a so I didn't do libdrm yet but ah well
<bryceh> Sarvatt, well I mean the actual release, not the git snapshot
<RAOF> I've done libdrm
<Sarvatt> http://sarvatt.com/downloads/patches/101_select_between_classic_and_gallium_dri.patch
<Sarvatt> refreshed radeon patch for git
<RAOF> We might also want to consider switching to r600g by default, but that can easily wait for a call-for-testing.
<bryceh> yep
<Sarvatt> http://sarvatt.com/downloads/patches/radeonbgnr.patch bgnr patch for radeon that works with xserver 1.10 too
<bryceh> we'll have a few weeks after a2 before FF where we can fiddle with the buttons and switches
<bryceh> Sarvatt, thanks
<bryceh> RAOF, did you run into any other glitchy bits putting 1.10 into edgers that we need to account for?
<RAOF> bryceh: http://cooperteam.net/Packages/ has wacom.
<Sarvatt> wondering what we should version a radeon git checkout, I think 6.13.2+gitfoo might be best
<RAOF> There were a couple of obscure drivers that needed a snapshot; siliconmotion was one.
<bryceh> RAOF, great, got it.  Does that need to wait for 1.10 or can it get uploaded now?
<Sarvatt> siliconmotion doesn't compile in git
<Sarvatt> http://sarvatt.com/downloads/patches/siliconmotion-ABI.patch
<Sarvatt> needs that
<bryceh> ok
<RAOF> Oh, and synaptics.
<bryceh> Sarvatt, looks like that'd be safe to go in now
<RAOF> Synaptics can be uploaded pre-1.10 and rebuilt.
<Sarvatt> we are going to get an insane amount of bugs about synaptics :(
<bryceh> I guess any bits we can upload *before* xserver 1.10, the simpler the transition will be, since everything'd just need a no-change rebuild
<bryceh> Sarvatt, why's that?
<bryceh> is there functionality lost with 1.10?
<Sarvatt> have you used it yet?
<RAOF> I was thinking of uploading post 1.10, but you're right, and buildd time is cheaper than the annoyance.
<Sarvatt> they switched to a new acceleration mechanism that is unusable out of the box on all 5 of my laptops
<bryceh> Sarvatt, just what is in xorg-edgers but didn't notice anything weird
<bryceh> RAOF, yeah esp. for drivers, they don't take long to build
<bryceh> Sarvatt, revertable?
<Sarvatt> haven't figured out how to fix it yet, was reverting it from edgers but needs quite a lot of reverts now
<bryceh> Sarvatt, can you file a bug report about it so we can have something to track and dupe bugs to?
<Sarvatt> http://who-t.blogspot.com/2010/06/new-synaptics-acceleration-mechanism.html
<Sarvatt> sure
<bryceh> sounds like something we could fuss with post-a2
<bryceh> mm, yeah looks like something we might want to turn off until there is a way to configure it
<bryceh> Sarvatt, I think you're right we'd get a lot of bug reports otherwise ;-)
<Sarvatt> I wish it was just slower like the blog post says
<RAOF> We could also mess with the default settings in gnome-settings-daemon.
<Sarvatt> but I cant move the pointer more than 1CM without it stopping
<RAOF> I didn't notice a problem on my netbook when I tried it, but maybe I should try harder.
<bryceh> RAOF, when you feel mesa 7.10 is ready to go in, ping me or send an email with pointer what needs uploaded.
<RAOF> bryceh: Thanks.
<jcristau> bryceh: yuo should stop sponsoring him so he needs to get core-dev privs :)
<jcristau> you, even
<RAOF> My application page is up :)
<Sarvatt> hmm http://git.gnome.org/browse/gnome-control-center/commit/?id=59248ed8ba5ff58248f63c0e208c133de538d046
<bryceh> jcristau, well if we weren't under a deadline ;-)  But actually I suspect he's accumulated enough sponsors to apply now.
<RAOF> Sarvatt: But we can't pull that in, because it depends on gsettings.
<bryceh> RAOF, ok also Sarvatt mentioned debian is in process of pulling 7.10 in there; might be best if we base the natty package on their stuff, or at least on the same source package
<RAOF> Ah, yeah.  Some in-flight duplication :(
<jcristau> RAOF: thanks for getting that osmesa build issue fixed btw
<RAOF> Everytime I have to touch the buildsystem I think âautotools is the worst build system, apart from all the other ones that have been triedâ
<jcristau> +1
<Sarvatt> just in time for talloc to get ripped out of the mesa build system on friday :)
<RAOF> For the dricore patch I even went so far as to look at resurrecting some of the old autotoolification branches, but... urgh.
<RAOF> Sarvatt: What, really?
<jcristau> RAOF: they're in the process of NIHing it
<RAOF> Superb.
<jcristau> because omg lgpl.
<RAOF> I knew that was a source of friction, but seriously?
<RAOF> Gah.
<RAOF> Ah, yes.  There it is.
<Sarvatt> hmm looks like we need git synaptics instead of 1.3.0 too?
<bryceh> RAOF, btw you can probably close out https://blueprints.launchpad.net/ubuntu/+spec/desktop-maverick-xorg-in-mm
<RAOF> Done.
 * bryceh rolls eyes at #wayland
<Sarvatt> bryceh: http://www.listshow.net/201101/kernel-team/45590-removing-debugfs.html ....
<bryceh> ouch
<albert23> hmm, isn't ureadahead using that too?
<Sarvatt> yeah
<jcristau> Sarvatt: as long as they keep it enabled for non-release kernels maybe it's not too bad.
<RAOF> Ok.  What's changed that makes GM45 system lock so dependably.
<Sarvatt> between which versions?
<bryceh> jcristau, I'd agree
<RAOF> Betwee yesterday and today.
<RAOF> So last night's -intel upgrade is a good candidate!
<RAOF> Ah, there we go.  dmesg finally has something interesting in it.
<RAOF> Survey says: deadlock in gem!
<Sarvatt> RAOF: no change between 0122 and 0124 intel uploads
<Sarvatt> haven't updated mesa because it needs a new libglapi package
<RAOF> Master does, yeah.
<Sarvatt> uploading intel with that latest commit just incase
<RAOF> This is not with edgers, it's with natty.
<Sarvatt> ohhh
<Dr_Jakob> Sarvatt: You don't need to do the libglapi thingy.
<Dr_Jakob> Sarvatt: also libglapi is not seperate from libGL and you need to update them in lockstep.
<RAOF> If you want to support gles without gl then you ned libglapi, right?
<RAOF> Packaging can handle the update in lockstep; we'll just have =version as the dependency.
<Dr_Jakob> no, if you want to run GL and GLES in the same applictaion you would need libglapi.
<jcristau> i think we want libglapi
<jcristau> the update in lockstep part is fine.
<Amaranth> ooh, I am intrigued
<Amaranth> Why would you have GL and GLES in the same app though?
<bryceh> RAOF, Sarvatt, tjaalton, et al: kinda rough but here's a todo list from our earlier discussion - https://wiki.ubuntu.com/X/Roadmap/Natty - take a gander and see if anything's missing or needs clarification
 * bryceh re-foods.  bbiab
<jcristau> Amaranth: olv says it's a legitimate use of egl
<jcristau> i'm inclined to believe him.
<Dr_Jakob> it is..
<Amaranth> Well, I suppose it is
<Amaranth> I mean, if you can share between OpenGL ES and OpenVG I suppose OpenGL and OpenGL ES is possible but I can't imagine a reason for doing so
<Sarvatt> Amaranth: http://lists.freedesktop.org/archives/mesa-dev/2010-December/004550.html
<Dr_Jakob> the actual use case was to detect of one of the implementation where software I think.
<Amaranth> ah, that makes sense
<Amaranth> But how do you link to both? Or do you just link to libglapi?
<Dr_Jakob> It doesn't look like those changes when into 7.10 so its all unrealesed stuff.
<Amaranth> Oh, I see, you'd link to libglapi instead?
<Sarvatt> yeah this is going in a PPA that I try to update from git daily, but the past few weeks have brought major changes weekly so its been fun :)
<Amaranth> A guy in my team is actually implementing something like this too, a sort of gl proxy library
<Amaranth> If ARM vendors provided mesa-based drivers it seems we wouldn't need it :/
<Amaranth> oh, he commented on the thread :)
<Dr_Jakob> Amaranth: team beeing?
<Amaranth> Dr_Jakob: linaro graphics working group
 * Dr_Jakob <-- Jakob Bornecrantz
<Dr_Jakob> Was in one or two meetings.
<Amaranth> dunno, I just started this month :)
<jcristau> Amaranth: one case olv mentioned was an app using gles and a toolkit, and the toolkit using desktop gl
<Amaranth> jcristau: Oh, yeah
<Dr_Jakob> if you are using a toolkit you really should be using what the toolkit provides
<jcristau> sometimes people don't, though.
<RAOF> Gah.  Not plymouth.
<Dr_Jakob> are you guys going to run r300g by default btw?
<RAOF> We have for essentially all of Natty.
<Dr_Jakob> ok
<RAOF> We'll consider r600g by default after some testing with 7.10, too.
#ubuntu-x 2011-01-25
<RAOF> Hm.  Maybe it's libdrm conspiring with firefox that's at fault.
<RAOF> Yes, that seems like it may well be it.
<RAOF> Has anyone else seen problems with libdrm 2.4.23 & firefox?
<RAOF> (On intel)
 * RAOF starts a quick libdrm bisect.
<RAOF> Nope, not libdrm.  And it's no longer reproducible.  GAH!
<bryceh> RAOF, Sarvatt:  x11proto-randr, x11proto-xext, and -wacom now uploaded to natty
<RAOF> Funky!
<RAOF> Test-building the mesa merge with kibi's redone experimental mesa-7.10.
<bryceh> -siliconmotion abi patch uploaded
<Sarvatt> doh
<RAOF> ?
<Sarvatt> x11proto-randr (1.4.0+git20101207.0d32bb07-0ubuntu1) natty; urgency=low
<Sarvatt> sorry if I did that + :(
<bryceh> Sarvatt, what?
<RAOF> It's 1.3.2+git... the release will be 1.4.0
<Sarvatt> there hasn't been a 1.4.0 release yet
<bryceh> ah rats, didn't doublecheck that, just reused the -edgers version number
 * RAOF should have picked that up when auditing the xorg-edgers packages before saying âyesâ
<bryceh> maybe there'll be a 1.4.1 ;-)
<Sarvatt> I use + more than I should in there because ~ is hell for versioned deps and it's automated, if you have 1.4.0~git build deps on 1.4.0 dont get fufilled
<RAOF> Sarvatt: That's why you have build-deps on 1.4.0~
<RAOF> bryceh: Worst case we have 1.4.0+really1.4.0 :)
<Sarvatt> yeah but then 10 packages build dep on 1.4.0 and need manual adjustment to 1.4.0~git every day
<Sarvatt> gets out of control fast
<Sarvatt> will be more careful about it
<bryceh> Sarvatt, aha, bug #557023 fixed and sru'd... one more down for solving the usb livecd issues
<ubot4> Launchpad bug 557023 in usb-creator (Ubuntu Natty) (and 7 other projects) "update-initramfs: deferring update (trigger activated) / cp: cannot stat `/vmlinuz': No such file or directory (affects: 479) (dups: 391) (heat: 3161)" [High,Invalid] https://launchpad.net/bugs/557023
<Sarvatt> sweet! and holy crap look at the dupe list
<RAOF> Ah, that's the proprietary-drivers on livecd bug?
<RAOF> bryceh: libdrm is ready in git and on http://cooperteam.net/Packages
<Sarvatt> Amaranth: so it looks like vesafb + macbook = massive fail? color me surprised :)
<Sarvatt> Amaranth: tried booting with vesafb.sucks=1?
<Sarvatt> \o/ the same gcc bug that was making plymouth look like crap when compiled with -O2 was what was making the pixman test suite fail on natty!
<RAOF> :)
<RAOF> Shouldn't the macbook be using efifb anyway?
<Sarvatt> i think we're unconditionally using vesafb now but yeah
<RAOF> And there's mesa done.
<bryceh> dpkg-source: info: extracting libdrm in libdrm-2.4.23
<bryceh> dpkg-source: info: unpacking libdrm_2.4.23.orig.tar.gz
<bryceh> dpkg-source: info: applying libdrm_2.4.23-1ubuntu1.diff.gz
<bryceh> dpkg-source: info: upstream files that have been modified: 
<bryceh>  libdrm-2.4.23/ChangeLog
<bryceh>  libdrm-2.4.23/RELEASING
<bryceh>  libdrm-2.4.23/autogen.sh
<bryceh>  libdrm-2.4.23/tests/auth.c
<bryceh>  libdrm-2.4.23/tests/lock.c
<bryceh>  libdrm-2.4.23/xf86mm.h
<bryceh> RAOF, those supposed to be changed?
<bryceh> hmm, appears those were changed by debian
<tjaalton> bryceh: yeah I should have a crude script that downloads the drivers that have no ubuntu changes, increments the changelog with 'buildN' and then uploads it
<tjaalton> ..without any fault tolerance ;)
<tjaalton> speaking of which; when do we start dropping drivers that are essentially unmaintained? (10.10?)
<tjaalton> there are a number of them that don't even have any bugs filed, which is a good indication that no-one uses them :)
<tjaalton> the first step would be to not include them in video/input-all
<tjaalton> that would also save some cd space
<bryceh> tjaalton, re:script - awesome!
<bryceh> re: dropping drivers, I'm all for being aggressive
<bryceh> fewer drivers == less space on cd, fewer bugs to have to worry about, etc.
<tjaalton> and I meant 11.10 of course
<tjaalton> (still living the 10.04 bliss :)
<tjaalton> but for natty we could drop them from video-all
<tjaalton> and input-all, they'd still be available from the archive
<tjaalton> but for 11.10 (and wheezy?) we could discuss about dropping them completely
<bryceh> tjaalton, yeah dropping them to universe is a suitable first step
<bryceh> tjaalton, do you have a list of drivers you're thinking we should look at leaving behind?
<tjaalton> the old cra^H^H^Hgreat hardware would then get vesa, and be basically just as fast in 2d as with the native driver & xaa
<bryceh> heh, true dat
<tjaalton> yeah I had a look at the driver list the other day..
<RAOF> Although with possibly worse modesetting.  Although given the hardware is ancient, they may even have cared about VESA modes.
<tjaalton> (and filed archive removal bugs for -sun*, which are sparc only=
<tjaalton> )
<tjaalton> RAOF: right, some might still have used weird panels on laptops etc
<tjaalton> but.. we'll ses
<tjaalton> see
<bryceh> and people can rely on Debian if they really have to run that hardware (assuming the drivers don't bitrot away entirely)
<RAOF> Or we could have the drivers in Universe; the livecd would get vesa.
<tjaalton> well I think debian(-x) wants those removed as well
<RAOF> Man.  Hardware so ancient even *Debian* doesn't support it :)
<tjaalton> and upstream is mulling over it as well
<bryceh> well, if debian plans to drop them too, then that makes the decision pretty obvious
<RAOF> Yes.
<tjaalton> right
<tjaalton> but dropping from the metapackages is 'cheap'
<bryceh> *nod*
<tjaalton> so.. video drivers that have no bugs are: apm, ark, chips, (dummy), glide, i740, tseng, voodoo
<tjaalton> voodoo has seen some kms love lately, and dummy could be useful for other purposes (servers?)
<RAOF> Is chips used in virtualised enviromnents?
<RAOF> i740 can DIAF, though
<tjaalton> cirrus IIRC
<tjaalton> kvm uses that
<RAOF> Oh, yeah.  The other "c" driver.
<tjaalton> cirrus I mean
<RAOF> You know, if we were really hurting for CD space we could get away with just -intel, -ati-, -nouveau, and -vesa.
<tjaalton> hmm a bunch of input drivers were purged when xserver 1.5(ish) was released
<tjaalton> right
<RAOF> The other drivers aren't particularly big, especially with dricore, so they're cheap to keep on there, but we could probably save a couple of MB.
<Amaranth> Sarvatt: disabling vesafb got rid of the hang
<RAOF> Well, there's a surprise :)
<Amaranth> Now if only I knew how to make it use efifb instead
<RAOF> video=efifb:something?
<bryceh> tjaalton, yeah none of those drivers seem to come up much.
<bryceh> tjaalton, shall we remove them from -video-all for a2 and see if anyone complains?
<tjaalton> and then there are drivers like i128, glint, neomagic, s3* that are pretty rare
<tjaalton> bryceh: that would be one way to find out :)
<bryceh> one of the s3 variants is used as a virtualized driver for something
<tjaalton> ah, right
<bryceh> libdrm 2.4.23 uploaded
<bryceh> I'll tackle the mesa upload in the morning when I'm fresh
<RAOF> Oh.  It's a public holiday tomorrow in .au.  Is the Eastern Edition actually going to take place, I wonder?
<bryceh> oh wow
<bryceh> if y'all are out, and jason's out, it's just gonna be me!
<bryceh> could be short!
<RAOF> Ok.  Synaptics is done locally.  I can't push to git yet because I've made a bit of a mess of the history.
<RAOF> bryceh, Sarvatt: I'll push a 1.10-buildable synaptics to git sometime tomorrow, or Thursday if the public holiday goes well :)
<Sarvatt> libdrm got uploaded before mesa/nouveau/etc were ready and RAOF is on holiday now??
<tseliot> Sarvatt: need a hand with uploads or what?
<Sarvatt> tseliot: looks like RAOF got a mesa ready before he left that needs an upload http://cooperteam.net/Packages/
<Sarvatt> its in git too http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=shortlog;h=refs/heads/ubuntu
<tseliot> Sarvatt: ok, I can upload that. Have you tried to build it?
<Sarvatt> nope I haven't, need to fix up my schroot since libdrm-dev isn't installable with xserver-xorg-video-all at the moment. he said he did before he uploaded it there last night looking at the log
<tseliot> ok, I'll see if it builds in my chroot, just in case
<Sarvatt> great, libdrm-dev depends not satisfiable in pbuilder
<Sarvatt> The following packages have unmet dependencies:
<Sarvatt>   libdrm-nouveau1a: Conflicts: libdrm-nouveau1 but 2.4.22-2ubuntu1 is installed.
<Sarvatt> hmm, what am I missing here, this supposedly works in debian :)
<jcristau> you have packages depending on libdrm-nouveau1?
<jcristau> like plymouth and nouveau and stuff
<Sarvatt> its a brand new buildd variant pbuilder
<Sarvatt> ahh yeah plymouth is the problem
<jcristau> pbuilder shouldn't have plymouth installed
<tseliot> Sarvatt: I was about to mention this little problem when doing a build-dep in my pbuilder chroot: libdrm-dev : Depends: libdrm-nouveau1a (= 2.4.23-1ubuntu1) but it is not going to be installed
<Sarvatt> it's installed in there, and fun it reqires libdrm-dev to install which wont upgrade :)
<Sarvatt> err libdrm-dev to build I Meant
 * tseliot is wondering what's the difference between libdrm-nouveau1a and  libdrm-nouveau1...
<jcristau> tseliot: incompatible ABI
<tseliot> hmm...
<jcristau> but plymouth in a build chroot makes no sense to me
<tseliot> +1000
<tseliot> Sarvatt: we should rebuild plymouth against the new libdrm anyway
<Sarvatt> yeah, but it still works without a rebuild and how do we do it with libdrm-dev not being installable? I've got a libdrm-nouveau1a rename back to libdrm-nouveau1 ready if nothing else
<tseliot> Sarvatt: is that because the binaries ended up in NEW?
<jcristau> Sarvatt: what's pulling plymouth in your build env?
<tseliot> I guess not, otherwise they wouldn't show up in my chroot
 * tseliot is sleep deprived...
<Sarvatt> i   mountall Depends plymouth
<jcristau> lolz.
<tseliot> yes, to show fsck checks in plymouth
<tseliot> :/
<jcristau> so libdrm-nouveau1 is essential?  well played there.
<Sarvatt> tseliot: http://sarvatt.com/downloads/merges/libdrm-natty/
 * tseliot has a look
<jcristau> Sarvatt: that's a bad idea.
<tseliot> how so?
<jcristau> there's a reason the package was renamed.
<Sarvatt> we can make sure everything is rebuilt the way we have been and dont have 2 pockets to support with different abi's, struggling to see another way around this mess
<Sarvatt> transitional libdrm-nouveau1 package maybe?
<Sarvatt> <cjwatson> ok, using Conflicts for this is against current policy, which may be part of why it broke
<Sarvatt> <cjwatson> the correct package relationships would have been:
<Sarvatt> <cjwatson> Breaks: libdrm-nouveau1
<Sarvatt> <cjwatson> Replaces: libdrm-nouveau1
<Sarvatt> <cjwatson> I suspect that if you do that then it will be happier
<Sarvatt> jcristau: ^
<jcristau> can't see how that would help, seeing how plymouth is still essential and depends on libdrm-nouveau1
<Sarvatt> looks like we're going to end up temporarily removing the breaks to bootstrap a plymouth build
<Sarvatt> tseliot: so new libdrm upload just changing Conflicts: libdrm-nouveau1 to Replaces: libdrm-nouveau1 until plymouth is rebuilt sounds like the plan then, would ya be willing to upload that?
<jcristau> yeah that sounds like easiest way out
<Sarvatt> got it prepared here if ya want, http://sarvatt.com/downloads/merges/libdrm-natty-2/
<tseliot> Sarvatt: sure, let me have a look
<Sarvatt> tseliot: pitti already got it
<Sarvatt> sorry about that
<tseliot> Sarvatt: no, that's better, I can't think think clearly today ;)
<tseliot> Sarvatt: I'll hold the upload of mesa (which I can probably do tomorrow)
<tseliot> or whoever can upload it first
<tseliot> can do it tomorrow
<Sarvatt> argh, I forgot -dbg but thats ok since its just temporary for the rebuild, fixing it up for the real release in git
<Sarvatt> ok new upload ready in git for whenever plymouth is done http://git.debian.org/?p=pkg-xorg/lib/libdrm.git;a=shortlog;h=refs/heads/ubuntu
<tseliot> good
<killtill> Anyone had problems after Friday updates ? -killed my gdm 
<tseliot> Sarvatt: if needed, you can remind me tomorrow about the upload
<Sarvatt> mesa needs to go in ASAP after plymouth is done because the archive is still busted until then, bryce should be around by then though
<tseliot> oh
<Sarvatt> plymouth hasnt been uploaded yet
<tseliot> Sarvatt: who is supposed to upload plymouth?
<Sarvatt> cjwatson said he'd get it, libdrm just finished a few minutes ago
<tseliot> ok
<Sarvatt> we need a new nouveau too, guess its time to figure out how the heck raof does it in git
<shadeslayer> ok so drm is now fixed and uploaded?
<Sarvatt> not exactly, the libdrm uploaded now will allow plymouth to be rebuilt
<Sarvatt> plymouth needs to be rebuilt for mesa to be uploaded and built
<shadeslayer> ah ok :)
<Sarvatt> lots of things that need libdrm-dev also need mesa dev packages and are waiting for that
<shadeslayer> Sarvatt: kipi-plugins in KDE too
<Sarvatt> sorry for the trouble shadeslayer, I'm guessing it'll be ~2 hours or so until its fixed in the archive depending on when plymouth gets uploaded
<shadeslayer> Sarvatt: sure no problem :)
<Sarvatt> looks like the switch to keyboard-config screwed up my keyboard :) XKBMODEL="a4techKB21" XKBLAYOUT="us,af"
<tormod> anyone willing to wave bug 675622 through?
<ubot4> Launchpad bug 675622 in glew (Ubuntu) "Merge sync glew 1.5.7-1 from Debian experimental (main) (affects: 5) (dups: 1) (heat: 36)" [Undecided,New] https://launchpad.net/bugs/675622
<Sarvatt> hey tormod! how the heck have ya been man?
<tormod> hi sarvatt!
<bryceh> heya tormod
<bryceh> tormod, I generally don't process sync requests but I've added my +1 in case that helps move it along
<tormod> bryceh, thanks, also for correcting the title :)
<Sarvatt> sync requests are processed amazingly fast these days
<Sarvatt> oh bryce acked it, theres something else to do after that, looking it up
<Sarvatt> set it to triaged and subscribe someone else and unsub review team
<Sarvatt> darn where's that wiki
<Sarvatt> ah there it is, https://wiki.ubuntu.com/SyncRequestProcess -- looks like subscribing ubuntu-archive is the next step
<kva> hello, anyone here?
<Sarvatt> RAOF: if you happen to pop on can you update nouveau? I'm not sure how you do it with gbp
<Sarvatt> if anyone's using edgers on natty, I apologize in advance that things are going to be broken a bit with libdrm-nouveau1a, got some super important work that needs my attention and not sure how to fix it best in there yet
<bryceh> I've subbed ubuntu-archive
<bryceh> Sarvatt, I'll pop a note to ubuntu-x
<bryceh> popped
<Sarvatt> bryceh: thank you so much for that
<Sarvatt> bryceh: ugh, I see what you're talking about now, inbox full of bugzilla status update spam
#ubuntu-x 2011-01-26
<bryceh> alrighty, time for a reboot.  bbiab
<RAOF> bryceh: Sorry about the libdrm snafu.  It didn't occur to me that plymouth was installed in the buildds :(
<bryceh> Sarvatt had it pretty much all squared away by the time I arrived on scene
<bryceh> lesson learned for me is to not upload right before heading to bed... wait 'til morning
<RAOF> :)
<bryceh> on a better note, so far no reports of troubles from the mesa upgrade
<bryceh> btw x11proto-xext failed to build, which I'm poking at currently
<bryceh> looks like just packaging stuff for missing docs needing updated
<RAOF> Oh, dear lord.  Nouveau, why do you need a *newer* libdrm *again* ?
<bjsnider> wouldn't it be better to have each x driver use its own direct rendering manager?
<bjsnider> like the nvidia blob?
<theprep> I need help configuring Compiz on a G5 with Radeon 9600, Terminal is saying multiple errors when checkng xorg 
<bjsnider> a g5?
<theprep> Mac PPC G5 IMac
<theprep> was referred here by the Ubuntu PPC IRC
<bjsnider> i thought those had already been retired
<theprep> I have 10.10 running, just video issues
<theprep> any suggestions on how to troublesoot?
<RAOF> bjsnider: Perhaps if you had an extra 200 full-time developers to throw at each of the drivers.
<bjsnider> RAOF, i'll hire them but they'll be paid with monopoly money
<RAOF> theprep: Generally, /var/log/Xorg.0.log, dmesg, and whatever errors you get when running âcompiz --replaceâ are the cost of entry into the troubleshooting club.
<theprep> yes indeed. My first on the PPC platform
<theprep> I've found some relevant topics, just how to input to get the issue resolved
<bjsnider> theprep, are you unsatisfied with osx?
<theprep> for 12 years, until i worked for Apple
<theprep> I've always been a closet opensource fan. Apple is jaded me. 
<bjsnider> what has apple done to jade you?
<theprep> becoming the new Microsoft, controlling everything. Paying me $11hr no commission when I sold $100K a week 
<bjsnider> you sold one hundred thousand a week?
<theprep> it's a cult, and EVERYBODY wants in. use to be creative, niche art types. Now everybody HAS to have it and they have no clue why. yes, $100K 
<bjsnider> "has to have it and no clue way" == marketing
<bjsnider> microsoft would love to be as good at vendor lock-in as apple. they're just so incompetent that they can't ever be
<theprep> damn right, ruined a good thing, and infantiled new users
<theprep> So i am very pro opensource
<bjsnider> but on very old hardware
<RAOF> Woot.  One xserver-xorg-video-nouveau buildable against current Natty and 1.10.
<bryceh> RAOF, when you're back on official time would be nice to address doko's complaint on the mailing list
<apw> RAOF, Sarvatt, bryceh, i think one of you pointed me to a writable EDID patch, i seem to have lost the reference and worse google cannot find it... do you happen to recall it, still have it, remember this and i am not going mad?
<Sarvatt> apw: just forwarded the mail to ya
<apw> Sarvatt, thanks that great
<Sarvatt> http://permalink.gmane.org/gmane.comp.video.dri.devel/46289
<apw> Sarvatt, thanks a lot ... thats somewhat stealthed as a reply to another patch ... no wonder noone did 'owt with it
 * apw opens his window, yep that is tangerine i can hear howling
<tseliot> Sarvatt: are things ok with libdrm/mesa now? Do you still need someone to upload your packages?
<Sarvatt> tseliot: looks like plymouth was rebuilt so http://sarvatt.com/downloads/merges/libdrm-natty-3/ needs an upload, other than that there is http://sarvatt.com/downloads/merges/intel-natty/
<tseliot> Sarvatt: ok, I'll take care of them
<Sarvatt> thanks! just rebuilt and tested the intel again with current natty and its looking fine here, uploaded the build log
<tseliot> ah, very good. I'm trying to build libdrm here so as to see if my chroot is still screwed up
<tseliot> it seems to be ok
<theprep> Morning gentlemen. I am having some issues configuring 3D/Compiz on my iMac PPC G5. Any aboard have experience with ATI video cards?
<Sarvatt> theprep: #radeon might be a better place to ask, there are a few devs in there who actually use the ATI/PPC combo
<bjsnider> fglrx doesn't support that old card anymore
<theprep> whats the IRC?
<Sarvatt> theprep: this server, #radeon
<theprep> thank you
<Sarvatt> I havent used my ibook with ati/ppc since karmic, things have changed a *lot* since then :( you may want to try disabling KMS as a first step though
<bjsnider> i think the gallium driver for those old cards is working very well
<theprep> I I followed some step on xorg, rebooted, ,y log in panel turned to just a black page, asking for login credentials, which it will not accept mine
<theprep> I got this pingback on #radeon : Cannot send to channel: #radeon
<jcristau> you need to identify to nickserv
<theprep> I did I thought, signed in as I did here
<theprep> Can I safely delete in OSX yaboot and Ubuntu from Disk Utility manager?
<jcristau> probably not the best place to ask that question.
<theprep> where might that be?
<tseliot> Sarvatt: libdrm hasn't been built for amd64 yet. In theory the build should start in 10 minutes. After that I think I can upload intel
<mfraz74> i have just upgraded to KDE 4.6 on Kubuntu 10.10 and I'm getting the error:Xsession: unable to launch "" X session --- "" not found; falling back to default session.
<bryceh> huh, interesting that cairo is now considered part of the Intel graphics package http://intellinuxgraphics.org/2010Q4.html
<ilmari> I guess it has lots of intel people working on it?
<bryceh> ilmari, at least one ;-)
<ilmari> the linked release announcement was posted by ickle, at least
<jcristau> he was working on cairo before he was intel.
<Amaranth> bryceh: ppa-purge fell over when I tried to remove xorg-edgers
<Amaranth> I believe due to the nouveau change
<bryceh> Amaranth, argh, that sucks
<Amaranth> I only remember the xchat-gnome bug happening with edgers though, I downgraded once before for mipmap issues and that bug went away too
<bryceh> Amaranth, can you pastebin the error spew?
<Amaranth> bryceh: http://paste.ubuntu.com/558678/
<bryceh> thanks
<Amaranth> It goes on suggest either removing all GL support or not downgrading most things
<bryceh> hmm, maybe try removing libdrm-nouveau1a first before downgrading?
<bryceh> Sarvatt, ^^ ideas?
<Sarvatt> it's the breaks
<Amaranth> bryceh: I don't have libdrm-nouveau1a, I have libdrm-nouveau1
<Amaranth> If I try to remove that it installs the 1a version but also removes all GL/GLES support
<Sarvatt> guess i'll have to backport the plymouth change to lucid-natty and start doing libdrm-nouveau1a on all those too and rebuild everything
<Sarvatt> nevermind the fact edgers libdrm-nouveau1a isn't compatible with natty libdrm-nouveau1a anyway, such a pain in the butt
<Amaranth> I suppose I can let it remove all this stuff then put it back
<bryceh> Sarvatt, what's the way to work around it manually?  just rm it all and then install the gl bits again?
<bryceh> Sarvatt, maybe just document that on the xorg-edgers page until you get some spare cycles to do that?
<Sarvatt> huh
<Sarvatt>   libdrm-nouveau1a: Breaks: libdrm-nouveau1 but 2.4.22-2ubuntu1 is to be installed.
<Sarvatt> might be xserver-xorg-video-nouveau which hasn't been updated to libdrm-nouveau1a yet in the archive
<Sarvatt> yeah, uploading the libdrm with breaks: libdrm-nouveau1 is causing it
<Sarvatt> it was just replacing libdrm-nouveau1 before and both were installed so nouveau deps were satisfied
<Sarvatt> i thought RAOF uploaded that last night, crap
<Sarvatt> Amaranth: remove xserver-xorg-video-all and xserver-xorg-video-nouveau and it should work for now
<Sarvatt> and just reinstall xserver-xorg-video-nouveau in a few hours
<Sarvatt> from the logs RAOF got a nouveau ready but its not in git, he should be on soon though
<Sarvatt> what the heck is going on with keyboard-configuration.. I get like 4 identical keyboard setup prompts just about every dist-upgrade and it still doesn't use the values I pick
<bryceh> Sarvatt, I've made some further changes to the -intel package (changelog entries for -2ubuntu[2,3], patch 107, drop 'linux-any' qualifier for libudev-dev so it pbuilds for me, add python-dev recommends for the apport py script
<Sarvatt> bryceh: your pbuilder doesn't work with linux-any? I thought that got fixed in october or november
<bryceh> Sarvatt, I can still list the overall change as coming from you if you're ok with these changes
<Sarvatt> bryceh: ohh thanks for doing that, I missed that more intels got uploaded that weren't in git
<bryceh> yeah I hadn't realized we were maintaining -intel in git (or had forgotten)
<bryceh> I'm mystified by the linux-any issue.  But my pbuilder was ignoring libudev-dev and failing because it was missing
<Sarvatt> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=600823
<ubot4> Debian bug 600823 in pbuilder "[pbuilder] Doesnt support "any" wildcards in debian/control" [Important,Open]
<bryceh> hah
<BUGabundo_noX> evening
<BUGabundo_noX> need tips on how to recover X in natty
<BUGabundo_noX> nvidia with nouvea
<BUGabundo_noX> AFAIK i havent removed any packages
<Amaranth> Sarvatt: Nope, after removing -nouveau ppa-purge still ends up wanting to remove my GL stuff
<Amaranth> I'll just remove and reinstall
<bryceh> [ubuntu/natty] xserver-xorg-video-intel 2:2.14.0-1ubuntu1 (Accepted)
<BUGabundo_noX> it would seem even PPA isnt upgrading clearly 
<Amaranth> ok, got everything put back together, time to reboot and see what happens
<BUGabundo_noX> Amaranth: ahah
<BUGabundo_noX> i'm in the same situation 
<BUGabundo_noX> brb
<Amaranth> bryceh: My memory was correct :)
<Amaranth> No issues with xchat-gnome and 2.13.901
<bryceh> Amaranth, excellent thanks
<Amaranth> neat, a crash in libdricore
<Amaranth> oh, my bad
<RAOF>  Good morning all.
<bryceh> morning RAOF
<RAOF> I don't seem to have broken the world again overnight? :/
<bryceh> only a little
<bryceh> Sarvatt was mentioning that your new nouveau package is needed to solve some breakage
<RAOF> To keep xserver-xorg-video-all installable?
<bryceh> RAOF, he mentioned you'd done a package but hadn't yet gotten it into git?
<RAOF> I got as far as checking that it built before I was called away.
<RAOF> I'm now testing that it actually *runs*, then I'll push to git.
<bryceh> anyway, no major emergencies.  Some folks having trouble downgrading out of xorg-edgers due to the nouveau abi change, not sure that's been figured out
<Sarvatt> its keeping libdrm-nouveau1 installed which the latest libdrm breaks, and nouveau isn't working until it goes in.
<Sarvatt>  woohoo thanks RAOF!
<bryceh> ok fixed x11proto-xext uploaded
<RAOF> Sarvatt: I've also documented how to update nouveau in README.source :)
<RAOF> Bah.  Sometimes I hate my router.
<RAOF> Give me a damned DHCP lease!
<bryceh> [ubuntu/natty] x11proto-xext 7.1.99.0~git20110111.9df8b776-0ubuntu2
<bryceh>         (Accepted)
<bryceh> https://wiki.ubuntu.com/X/Roadmap/Natty looking good
<bryceh> RAOF, yesterday did you mention some other bits needing uploaded?
<RAOF> Synaptics, wacom.
<RAOF> Synaptics needed a bit of patch-surgery to get the quirking re-applied, and I need to unmunge the git history before pushing it.
<bryceh> RAOF, got .dscs or are they in git?
<RAOF> Oh, hey! You uploaded wacom on Tuesday :)
<RAOF> So, synaptics.  No, I need to clean it up before the packaging's done.
<bryceh> alrighty, ping me when it's ready.
<bryceh> meanwhile I'll tackle a couple xkeyboard-config sru's
<bryceh> actually... meh don't feel like that.  Will work on release notes instead.  Mmm
<RAOF> Excellent.  nouveau not only builds, but it also actually works.
<bjsnider> Amaranth, isn't xchat-gnome the one that hasn't worked in years?
<Amaranth> bjsnider: Eh? It works great for me
<Amaranth> I don't think it has been updated in a few years though
<bjsnider> or is it the other one? i don't even know which one i'm using right now
<Amaranth> I've been tempted to put some work in to it, it has poor tab handling and the little icon it shows when someone joins/parts is annoying
<Amaranth> I actually patched the tab handling from regular xchat in to it at some point but it was a big hack
<bjsnider> have you used the other one?
<Amaranth> Regular xchat? It's full of stuff I don't need, works a little differently, and doesn't really integrate with the desktop
<RAOF> bryceh: nouveau now ready on http://cooperteam.net/Packages
<bryceh> RAOF, got it
<bryceh> [ubuntu/natty] xserver-xorg-video-nouveau
<bryceh>         1:0.0.16+git20110107+b795ca6e-0ubuntu1 (Accepted)
#ubuntu-x 2011-01-27
<RAOF> Has anyone else noticed -intel 2.4.14-0ubuntu1 being broken?
<RAOF> Oh, and that's why!
<Chelsea> Hi all, i'm trying askubuntu for the first time, and have a question. I'm trying to post a comment to a question, without answering the question. Is this possible with 1 reputation?
<RAOF> I don't think it is, no.
<Chelsea> ok.. thanks
<RAOF> bryceh: Still around to sponsor an -intel update, so it actually works?
<RAOF> bryceh: No need for sponsoring; StevenK got it.
<bryceh> RAOF, what was wrong with it?
<bryceh> ah bad canDoBGNoneRoot in patches.
<RAOF> bryceh: No, it used intel_batchbuffer_wait_last, which didn't exist, so it didn't load.
<bryceh> hrm, not good that we missed that
<RAOF> I just took the opportunity to make BGNoneRoot safe for 1.10 at the same time.
<RAOF> Did anyone test the 1ubuntu1 -intel upload before uploading it?
<bryceh> RAOF, I had assumed sarvatt had, but sounds like we need to be more explicit about the testing
<Amaranth> wait, so edgers went through 2 DDX ABI changes?
<bryceh> I'm wondering if we need some sort of staging ppa in addition to edgers, where the actual uploadable packages can age a bit
<RAOF> Amaranth: Yes, because X went through a post-RC1 ABI change.
<Amaranth> There was one when the packages all got the ABI updated and another where you just did a rebuild (and I spent half a day with no X :/)
<Amaranth> ah, ok
<RAOF> bryceh: What would the staging PPA pick up?
 * Amaranth waits patiently for intel 1ubuntu2
<RAOF> Yeah.  Don't log out before then :)
<RAOF> Actually, I think I've heard ubuntu+1-proposed being proposed before.  This PPA would essentially be that.
<RAOF> Alternatively, it could be a mirror of the sid/testing Debian split.
<bryceh> RAOF, yeah... basically a place for us all to dput things ready for being uploaded to the archive, for final review/testing before actual upload
<bryceh> but dunno, maybe that'd just be extra bureaucracy
<RAOF> It would block uploads on PPA builder availability.
<RAOF> Possibly just being more explicit about testing would do.
 * bryceh nods
<RAOF> Speaking of testing... time for synaptics.
<bjsnider> Amaranth, i'm using xchat-gnome right now and i don't see how it's more fully integrated with gnome than xchat. can you enlighten me?
<Amaranth> bjsnider: perhaps xchat has cleaned up since I last used it
<Amaranth> It used to look ugly and you had to manually configure what browser to open links with and such
<Amaranth> and proxies
<bjsnider> well i don't have issues with either of those
<Amaranth> not that anyone uses a proxy with IRC :)
<bjsnider> maybe you should try xchat?
<bjsnider> they both use the same settings directory
<Amaranth> bjsnider: btw, does xchat do spell checking?
<bjsnider> yup
<bjsnider> it do indeed
<bjsnider> come to think of it having used both i'm not sure there's a need for an "xchat-gnome" anymore
<RAOF> cnd: We need to update to a new evdev for xserver 1.10.  Do you have any wishes while we're at it?
<ripps> well, the 2.6.38 kernel is still to unstable. Keep getting ati pageflipping errors in dmesg and the desktop seems to freeze occasionally.
<seb128> hello there
<seb128> so xchat-gnome started showing refresh issues
<seb128> is that a known issue?
<Amaranth> seb128: I already filed that bug :)
<Amaranth> seb128: It's a regression from -intel 2.13.901 to 2.14.0
<seb128> ok, weird
 * Amaranth has been living with it for some time on xorg-edgers, figured it would go away after a couple days
<seb128> doesn't happen anymore after a session restart
<Amaranth> seb128: scroll up
<seb128> well I restart my IRC so up is the 2 lines you just wrote
<Amaranth> For me it sometimes goes away until I start scrolling
<seb128> oh you are right
<seb128> do you have the bug number handy?
<Amaranth> bug 707236
<ubot4> Launchpad bug 707236 in xserver-xorg-video-intel (Ubuntu) "corruption in xchat-gnome window (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/707236
<Amaranth> I knew I wasn't the only xchat-gnome user left :)
<seb128> dholbach complained about it as well
<Amaranth> Should have filed that bug sooner :/
<jcristau> if it's still in intel master you should file it at fdo
<Amaranth> Just figured it was edgers, things break and fix all the time, until I realized the same stuff was about to hit natty
<seb128> it did now
<Amaranth> jcristau: Apparently edgers has a git snapshot from 3 days ago so I guess I'll file upstream
<Azelphur> Anyone got a GTX 570 here? I'm having X freeze issues with mine :(
<apw> bryceh, is there an equivalent of intel_reg_dumper for ati and/or nvidia cards?
<Azelphur> it's weird, it'll lock up for like 60 seconds, then return to normal as if nothing happened.
<Azelphur> (most of the time, sometimes it doesn't come back)
<apw> Azelphur, get any errors in dmesg associated with that?
<Azelphur> apw http://pastebin.com/qPP9KuYy not sure
<Azelphur> I did just have a total freeze and had to kill X
<Azelphur> so there should be something near the bottom - if there is anything
<Azelphur> it's definitely after line 1059
<Azelphur> that Disabled privacy extensions thing might be something to do with it?
<apw> Azelphur, so no nothing there ... the lo: bits are networking
<Azelphur> ok
<apw> nice to see its not just me who has flash pooping self all over the place
<Azelphur> haha yea, flash crashes continually, I heard that's a bug in compiz that'll be fixed soon
<apw> yeah right, all bugs in compiz are going to be fixed soon.  i am still waiting for my menus to appear above the background relaibly
<Azelphur> :D
<apw> Sarvatt, ROAF, is there an equivalent of intel_reg_dumper for ati and/or nvidia cards?
<Azelphur> oh I should state this early, I'm running quad screen (2 separate X screens both running twinview) card 1 is GTX 570, card 2 is 8800GT :p
<Azelphur> figure I'll state my weirdness to start with :)
<Azelphur> apw: http://pastebin.com/mtDvzLbB
<Azelphur> that's interesting, at the bottom
<apw> Azelphur, is this with the binary drivers ?
<Azelphur> yes
<apw> phew
<Azelphur> I had this problem with the version available in the repositories, so I tried building a new package and upgrading to the latest driver, but I still get the problem
<bryceh> apw, no there isn't an exact equivalent but I do have leads on a couple tools.
<bryceh> apw, what I'm really curious about is if the kernel can emit a signal in these cases like with intel, so we can hook apport to it
<apw> bryceh, hangs you mean?  yeah i am more interested in them for 'black screen
<apw> on boot' cases i am seeing
<bryceh> aha
<bryceh> apw, ok, for nouveau there is a pgtest tool mentioned here - https://bugs.freedesktop.org//show_bug.cgi?id=26980#c7
<bryceh> dunno if it'd be useful in this case but might be worth checking out
<ubot4> Freedesktop bug 26980 in Driver/nouveau "NVA3 / NVA5 / NVA8 / NVAF (GT2xx/GT3xx) with nouveau: random GPU lockups" [Normal,New]
<apw> bryceh, know anything about "Nvidia graphics driver, obtained directly from Nvidia", any idea how its packaged, is it dkms ?
<bryceh> apw, pretty sure they have their own installer
<bryceh> apw, generally if a user installs nvidia from the nvidia site, they're on their own
<apw> bryceh, that was my feeling, that he has installed it, got a new kernle and ended up in a mess, and thats what i'd expect "here keep both pieces"
<jcristau> apw: http://cgit.freedesktop.org/~airlied/radeontool/
<bryceh> tjaalton, hey can you shoot me a copy of that driver rebuild script?
<RAOF> apt-get source $(apt-cache show xserver-xorg-input-all | grep Depends: | sed s/Depends://g | sed s/,//g)
<RAOF> followed by for I in * ; do [ -d $I ] && (cd $I && dch --build "Rebuild against Xserver 1.10" && dpkg-buildpackage -S) ; done
<RAOF> ? :)
<RAOF> bryceh: Also, good morning :)
<jcristau> you mean evening.
<jcristau> damn aussies have everything reversed!
<jcristau> :)
<jcristau> RAOF: pretty useful thing to have scripted for server abi bumps.
<RAOF> jcristau: Yeah.  That shell will also pick up x11-common, so it could do with a little bit more love :)
<bryceh> RAOF, heya!
<RAOF> bryceh: Was Sarvatt going to do the -ati update?
#ubuntu-x 2011-01-28
<bryceh> RAOF, not sure, but I can take care of it if you want to tackle xserver
<RAOF> xserver is pretty much done, but RC2 should be out today, I think, so it might be nice to wait for that tarball.
<RAOF> My rebuild tests have the list of updates needed at vmmouse, evdev, fbdev, chips, ati.
<bryceh> it might be nice to get the current one in just to get a jump on the abi rebuilds
<RAOF> Fair enough.
<jcristau> i thought rc2 was supposed to have more randr stuff, but i haven't seen that posted?
<RAOF> It'll be RC1+enough git to be practically RC2 anyway, since we don't want to silently bump ABI in the archive.
<RAOF> jcristau: I thought all of keith's randr 1.4 was already in?
<jcristau> RAOF: maybe i'm just confused
<RAOF> jcristau: Certainly his *last* randr patches landed just after RC1 was meant to be released 
<RAOF> Maybe that's what you're thinking of?
<pcjc2> hi there
<pcjc2> anyone on natty complaining about broken hotkeys?
<pcjc2> Fix is recompile udev against a non-broken kernel
<RAOF> Which kernel's broken?
<bryceh> pcjc2, raise it with the kernel guys?
<pcjc2> commit is fixed
<pcjc2> sorry - kernel is fixed
<pcjc2> just need to identify which versions to build against - have filed a bug against udev to request the rebuid
<pcjc2> https://bugs.launchpad.net/ubuntu/+source/udev/+bug/708962
<ubot4> Launchpad bug 708962 in udev (Ubuntu) "[NATTY]: Rebuild against newer kernel required due to IOCTL breakage (affects: 1) (heat: 8)" [Undecided,New]
<pcjc2> 2.6.37 has the fix
<pcjc2> Something after v2.6.36-rc1 broke it
<jcristau> RAOF: ah, found it.  keithp said on jan 3 he had more randr proto changes.
<jcristau> dunno if that'll affect driver abi though
<pcjc2> so RE: Udev - basically, don't build against kernel headers from the 2.6.36 series
<pcjc2> Commit was introduced somewhere before refs/tags/Ubuntu-2.6.36-2.8
<RAOF> Then I think that's fixed in natty already, as I think udev's been built against the 2.6.37 tree.
<pcjc2> not fixed until refs/tags/Ubuntu-2.6.37-11.25 or afterwards
<RAOF> I seem to recall a recent udev buildâ¦ yeah, there we go.  9 hours ago.
<RAOF> So that should be fixed then.
<pcjc2> looks like the recent build will have fixed it
<pcjc2> _JUST_ got the right version number for the libc stuff
<pcjc2> irritating to think how long I just spent tracking that down, given if I'd not bothered - it would have fixed its self by tomorrow :(
<RAOF> What hotkeys were you seeing not work?
<pcjc2> Brightness etc..
<RAOF> It obviously only affects a subset of users (a subset which excludes me âº), then.
<pcjc21> On Intel here, running xorg-edgers
<pcjc2> better
<pcjc2> As I was saying.. On Intel here, running xorg-edgers, so there is currently some breakage thanks to 2.6.38
<pcjc2> and you have to apply some patches from Matthiew Garret and recompile the 2D driver to list "intel_backlight" as a backlight driver
<RAOF> Ah.
<pcjc2> various other little niggles too, but that is probably a userspace issue with a backlight brightness prop which goes from 0 to lots
<pcjc2> 	BACKLIGHT: 1637355 (0x0018fbeb)	range:  (0,3274965)
<pcjc2> 	Backlight: 818642 (0x000c7dd2)	range:  (0,3274965)
<pcjc2> (wiring up the keymap was half the battle though)
<RAOF> cnd: You wouldn't happen to have a refreshed gestures patch for evdev?
<RAOF> Oh, man.  ext4, I had forgotten how awesome it was for dpkg to be fast.
<RAOF> cnd: Oh, also: refreshed gesture extension patch against the Xserver?
<RAOF> âdrm/nvc0: implement irq handler for whatever's at 0x14xxxxâ.  Aaah, reverse engineeringâ¦
<Amaranth__> o_O
<bryceh> [ubuntu/natty] xserver-xorg-video-ati
<bryceh>         1:6.13.2+git20110124.fadee040-0ubuntu1 (Accepted)
<RAOF> Woot!
<RAOF> bryceh: Have you updated unity today, and if so, are you able to interact with it using the mouse?
<RAOF> I don't *think* my problem stems from the evdev update, but I'd like to be sure :)
<tjaalton> bryceh: what RAOF said, basically :)
 * RAOF finally groks the context.
<tjaalton> hehe
<bryceh> RAOF, unfortunately it's just been giving me "your hardware ain't good enough" errors
<RAOF> Heh.
<bryceh> on an r7xx
<RAOF> It seems to have been molified by a reboot for me.
<bryceh> I'm going to try to do the xkeyboard-config merge tomorrow.  I see Debian did an update for experimental (first in long time).  We've got a bunch of patches against it I need to go through.
<bryceh> RAOF, I'm going to be working downtown tomorrow with the rest of the Portland crew so will be a little constrained but I think I can upload xserver if it's ready to go by then
<RAOF> Ok.
<bryceh> RAOF, or if you do want to wait until the next rc release, we can tackle it monday
<RAOF> I'll see if I can get it done this evening.
<RAOF> The final piece is the gestures patch, which I may get cnd to weigh in on.
<RAOF> (And a a couple of drivers - chips, fbdev, evdev, vmmouse - that need cleaning, then sponsoring)
<RAOF> And we need to fix up nvidia-graphics-drivers and fglrx so that they properly depend on the video ABI(s) they support, so we don't upgrade the xserver under them and crash.
<Sarvatt> Amaranth_: can you run compiz under valgrind while you run xchat-gnome for ickle? I upstreamed that bug report of yours
<Amaranth_> Sarvatt: I just commented on the upstream report, it's not a compiz display issue as the bug looks even worse without compiz running
<Sarvatt> Amaranth_: oh sorry, just saw you responded already there too
<Sarvatt> is it just xchat-gnome?
<Sarvatt> I sure as heck can't reproduce it on gen3
<Amaranth_> xchat-gnome is the only app I've seen it with
<Amaranth_> What is gen3?
<Sarvatt> 915-945-g33-3150
<Amaranth> ah
<Amaranth> That's confusing, the 3100 is gen4 but the 3150 is gen3?
<Sarvatt> heh
<Sarvatt> 3100 is gen3 too
<Sarvatt> x3100 is gen4
<Sarvatt> yeah it's really crazy
<Amaranth> oh, ok
<Amaranth> I guess I must have the x3100 then *shrug*
<Amaranth> I just say 965
<Amaranth> All of that is still less confusing than the new HD stuff
<Amaranth> People always think I'm talking about radeon
<bryceh_> [ubuntu/natty] libx11 2:1.3.3-3ubuntu3 (Accepted)
<Sarvatt> bryceh: 1.4.1 is waiting around to be uploaded if you ever do another libx11, I kept meaning to mention that the last 2 :)
<Sarvatt> http://sarvatt.com/git/cgit.cgi/mesa-packaging/commit/?id=26a3f7f992032bd3f42ea4744d020231dd3e7799 I guess that'll work for now for a libglapi placeholder.. need a better description
<Sarvatt> libglapi-mesa: package-name-doesnt-match-sonames libglapi0
<Sarvatt> ah libglapi0-mesa?
<bryceh_> or libglapi-mesa0?
<bryceh_> Sarvatt, yeah if you want to post a .dsc somewhere for that I'll sponsor
<pcjc2> GM45, with Mjg59's backlight patches, udev rebuilt... brightness collapses to almost zero when you try and adjust with the hot-keys
<pcjc2> one-line patch required to remove a val >> 1; in the kernel
<pcjc2> Have prodded upstream about it, but feel free to give me a shout if anyone bumps against this issue and we need to patch sooner rather than later
<bryceh_> ][ubuntu/natty] xserver-xorg-video-chips 1:1.2.3-2ubuntu1 (Accepted)
<bryceh_> [ubuntu/natty] xserver-xorg-video-fbdev 1:0.4.2-3ubuntu1 (Accepted)
<bryceh_> [ubuntu/natty] xserver-xorg-input-evdev 1:2.6.0-1ubuntu1 (Accepted)
<kva> hello, all
<kva> that's nothing to do with ubuntu cause I am running debian, but I got horisontal stripes on screen in firefox and skype on intel video driver
<kva> any suggestions where I can fix it?
#ubuntu-x 2011-01-29
<kva> only some sites and some skype windows, not all
<cup> bryceh, have you ever heard of an x session with excessive color banding? everything looks 16-bit or 65k color
<LLStarks> stupid net
<ari-tczew> hi folks
<ari-tczew> is xorg 7.6 going to be in natty ?
<jcristau> it's already there.
<ari-tczew> jcristau: how? 1:7.5+6ubuntu8
<jcristau> that's an empty package
<ari-tczew> jcristau: could you point me to right package and explain why xorg source is empty?
<jcristau> there's over 100 packages in the X.Org X11 distribution.
<jcristau> xorg source is empty because it only builds metapackages
<ari-tczew> jcristau: so merging with experimental doesn't make sense?
<jcristau> what's your actual question?
<ari-tczew> jcristau: [15:58] <ari-tczew> jcristau: so merging with experimental doesn't make sense?
<jcristau> i don't understand your question
<jcristau> merging what?
<Quintasan|Droid> Hiya, after upgrading natty I get segfaults on X, the last X releated stuff I upgraded was xserver-xorg-video-(fbdev,chips,ati,radeon) xs-xo-input-evdev.
<bigon> could someone have a look at https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/709746 ?
<ubot4> bigon: Error: Bug #709746 is private.
<Quintasan|Droid> I pinpoited the culprit
<Quintasan|Droid> Its evdev,  makes something nasty which makes X crash
<LLStarks> grrr. why is dropping to tty broken?
<LLStarks> can't boot into recovery console and tty1/tty2 don't offer a console
<cup> so, uh. 24-bit gradients are broken on natty intel drivers.
<LLStarks> yo sarvatt, do you have any idea as to why xsession-wide color banding would occur on certain kernels? it happens on all sessions for .37 and .38, but not .35
<LLStarks> *some sessions on .37
<kva> hello all
<ari-tczew> jcristau: around?
#ubuntu-x 2011-01-30
<Spicemaster> hi Alexia_Death 
<Alexia_Death> hi
<LLStarks> bryceh, i think synaptic is busted. did the new evdev or anything else in the new stack break stuff? touchpad clicks are broken. minimal pointer accuracy. jumping cursor.
<LLStarks> usb mice seem to be fine
<LLStarks> anyone?
<RAOF> LLStarks: Oh, really?  BAh.
<RAOF> LLStarks: Are you actually *using* synaptics, or evdev?
<LLStarks> synaptics according to xorg logs
<RAOF> So, there is a new synaptics, and it pretty drastically changed the acceleration infrastructure.
<RAOF> Although, for the touchpads *I* tested on, it resulted in subjectively better behaviour.
<RAOF> Touchpad clicks work for me; Xorg.0.log might possibly be useful.
<LLStarks> http://pastebin.com/C5KV22fJ
<LLStarks> synaptics is terrible right now. the point can't even stay stationary if your finger is.
<LLStarks> *pointer
<LLStarks> raof, is the previous version abi compatible with the new stack?
<RAOF> That's because you appear to be using evdev, rather than synaptics.
<LLStarks> oh, am i?
<RAOF> Yes: SynPS/2 Synaptics TouchPad: Applying InputClass "evdev touchpad catchall"
<RAOF> Do you have the synaptics driver installed? :)
<LLStarks> yes.
<LLStarks> 1.3.99+git20110116.0e27ce3a-0ubuntu1
<RAOF> Well, that's rather disappointing.
<LLStarks> how do i force synaptics and why isn't it being used?
<LLStarks> i don't mind using my mx510, but i'd rather not drag it everywhere
<LLStarks> <_<
<RAOF> The server doesn't appear to be even loading the synaptics module.
<RAOF> Can you pastebin the contents of /usr/share/X11/xorg.conf.d ?
<LLStarks> eric@kingfisher:/usr/share/X11/xorg.conf.d$ dir
<LLStarks> 10-evdev.conf	   50-vmmouse.conf	     60-magictrackpad.conf
<LLStarks> 50-synaptics.conf  51-synaptics-quirks.conf
<LLStarks> i didn't even know evdev were a fallback for touchpads
<LLStarks> i thought they used -mouse
<LLStarks> does alps use evdev?
<RAOF> No.
<RAOF> Touchpads use synaptics, everything else* uses evdev
<RAOF> * Barring special things like wacom.
<LLStarks> ah
<RAOF> Well, and the magic trackpad, which gets evdev because that's where gesture support is.
<LLStarks> x gesture support is so confusing. there's utouch and then there's the gesture extension.
<LLStarks> i dun get it
<RAOF> Utouch is the userspace component.
<RAOF> The gesture extension is a (temporary, it turns out) server-side support for it.
<LLStarks> i see
<LLStarks> any insight on the evdev-over-synaptics?
<RAOF> Not really.
<RAOF> Perhaps the udev log would be helpful?
<RAOF> Because synaptics *should* be picking up your touchpad as a touchpad.
<LLStarks> what file?
<RAOF> udevadm --query=all --name /dev/input/event8
<LLStarks> can't query all
<LLStarks> grr. all options are unrecognized.
<RAOF> Does âudevadm --query=all --name=/dev/input/event8â work?
<RAOF> Bah! âudevadm info --query=all --name=/dev/input/event8â work?
<LLStarks> yar
<LLStarks> http://pastebin.com/hA8G3jmR
<RAOF> And can you pastebin /usr/share/X11/xorg.conf.d/50-synaptics.conf ?
<LLStarks> http://pastebin.com/yndbtBwS
<RAOF> Ok.  I'm now officially confused.
<RAOF> I don't see why that shouldn't match your touchpad.
#ubuntu-x 2012-01-23
<broder> RAOF: hey - how hard is it to tell from GPU hang data whether it's a bug that's been fixed already?
<RAOF> I think it depends.
<RAOF> And in what way hard?  Automated hard?  Dude looking at it hard?
<broder> Either. I have an apport report from a Natty machine, and I'm wondering whether this is a "cherry-pick one patch and move on" or "cry in a corner" grade of problem. http://web.mit.edu/broder/Public/xserver-xorg-video-intel.2012-01-21.crash if you have a second
<RAOF> Certainly some bugs are easy to tell; there's an obviously-bad value in the command stream.  And by âobviouslyâ I mean âobvious to someone who fixed the bugâ :)
<broder> I seem to be able to reproduce it with some amount of consistency by going from either an extended or cloned monitor layout to just the external being enabled. Symptomatically the screen is all black
<broder> Actually...I wonder if this is connected to the issue where GnomeRR screws up the CRTC config on the external display
<RAOF> It looks to me like that gpu dump isn't useful; it seems to have fallen off the end.
<broder> :-/
<RAOF> I suspect that might have picked up the post-reset hardware state.
<broder> I forget - how much of the relevant data is gathered when I run apport-collect/ubuntu-bug as opposed to when the hang actually occurs?
<RAOF> The most useful information - the gpu dump - is collected when the hang occurs.
<broder> Hmm, ok. Phrased differently, given that I can reproduce the issue without too much difficulty, is there something else I can do to get better debugging output?
<RAOF> drm.debug=0x4 might spew something interesting into dmesg; and a newer kernel has better gpu hang reporting.  But that latter thing's not very useful for you :)
<broder> I can try to drop in a newer kernel. I suppose the risk is that it fixes the bug as a side-effect :)
<RAOF> Right :)
<cnd> RAOF, are we pushing X today?
<RAOF> cnd: I'm not sure.  There's the Xorg metapackage left to go - tjaalton was on that - and an intel upload.  Things got delayed by the PPA running out of room.  It's now got 4GiB of space, and so that's resolved.
<cnd> ok
 * cnd is getting anxious :)
<RAOF> :)
<RAOF> By the way, is there an obvious place to get the unclamped input history of a master device anywhere?
<RAOF> (ie: not clamped to the screen)
<cnd> RAOF, raw events?
<RAOF> Yeah, I guess so.
<RAOF> And maintain my own history.
<cnd> the only way to get history that I'm aware of is the XI 1.x motion history
<RAOF> Or, rather, pull stuff out of valuators[0] and [1].
<cnd> and that is only the history of the normal events
<RAOF> Yeah.
<cnd> though I'm not sure if master devices spit out raw events
<cnd> I bet they do, but you'd want to double check
<RAOF> Since I'm actually in the server I can just pull stuff out of the DeviceIntPtr
<cnd> RAOF, and maintain the history yourself?
<RAOF> Yup.  I only need this, this-1 anyway.
<cnd> ahh, ok
<RAOF> tjaalton: You're doing the Xorg metapackage?
<RAOF> cnd: If I want the valuator in screen coordinates I'll need to rescale it, right?
<cnd> hmmm
<cnd> it potentially depends :)
<RAOF> :)
<RAOF> I'll follow stuff through, then.
<cnd> I would imagine the coordinates are stored in screen coords already
<cnd> that's my best educated guess without looking at the code
<RAOF> I think they are for master devices.
<cnd> and it's still my sunday night, so...
<cnd> :)
<cnd> RAOF, that sounds familiar
<RAOF> Yeah, certainly.  Just picking your brains while you're here :)
<cnd> like for master devices the device int ptr holds screen coords while for slaves it holds device coords
<cnd> I think there's a comment to that effect
<RAOF> Good, that concords with my understanding.  I'll also check that I get sane values out, but that should work nicely.
<RAOF> Oh, whoops.  Need to cherry-pick an additional patch for the xserver.
<tjaalton> RAOF: it's basically done on git, maybe just needs another pair of eyes to check it through
<RAOF> Ok, cool.
<tjaalton> maybe I'll just upload it to the ppa
<tjaalton> now that there's room
<RAOF> I can give it a look over if you like, but you could just upload.
<tjaalton> i'll just do that
<tjaalton> done
<tjaalton> now off to feed the kids :) ->
<RAOF> :)
<broder> RAOF: if i drop precise's kernel on top of natty to test this GPU lockup, do you know off the top of your head if natty's detection/state dump tools still work?
<RAOF> Yes, they should.
<broder> Cool
<tjaalton> hmm uploaded xorg to a non-existing ppa first, should be ok now
<tjaalton> RAOF: wacom works
<tjaalton> hum, I'll merge xkb-data
<tjaalton> RAOF: would you agree that we can drop the dvorak-intl -> dvorak-alt-intl rename in xkb-data, now that oneiric is out?
<tjaalton> hmm no, after precise
<Milos_SD> hello
<Milos_SD> will xorg-edgers ppa have xserver 1.12 for oneiric?
<cnd> tjaalton, do you know where we stand on the x upload?
<tjaalton> cnd: not really, xorg metapackage is on the ppa so maybe we are good to go and waiting for RAOF to hit the big red button
<cnd> ok
<FernandoMiguel> evening
<cnd> RAOF, let me know when you're on so we can discuss the X upload
<tjaalton> speaking of which, could we sneak in the new stable release rc?
<tjaalton> i'll try merging with debian
<ricotz> tjaalton, yeah, having this ctrl+alt+* thing patched would be nice too
<tjaalton> ricotz: hm? that's xkb-data
<tjaalton> no need for xserver patches
<ricotz> oh, but debian has a xserver patch for it
<tjaalton> cnd: looks like merging from the upstream stable branch doesn't work without reverting some stuff
<ricotz> http://anonscm.debian.org/gitweb/?p=pkg-xorg/xserver/xorg-server.git;a=commit;h=663e92e660a15548f68a764479d7d59ed5c9af64
<tjaalton> ricotz: applied before a new xkb-data was available
<cnd> tjaalton, there's been a new 1.11 stable release?
<tjaalton> cnd: rc's
<tjaalton> debian has 1.11.3.901, .902 was released on saturday
<cnd> tjaalton, it's a pain to merge because of the frankenserver
<cnd> I'd suggest that if we are ready to push as is, we do so and then update
<tjaalton> yeah
<tjaalton> we can merge later
<albert23> Hmm, somehow I still have the screensaver bug, with xkb-data 2.3-1ubuntu3 from canonical-x/x-staging
<albert23> [  2185.106] Ungrabbing all devices and killing their owners; grabs listed below:
<ricotz> tjaalton, ^
<ricotz> by any chance, has someone tested fglrx 8.920 or 8.930 with xserver 1.12?
<albert23> arg, ubuntu-bug fails, not an official ubuntu package
<tjaalton> albert23: i can't reproduce it
<tjaalton> running the same repo
<albert23> Tjaalton: I am using a laptop, using numlock so the P becomes *. Could that make a difference?
<tjaalton> ah me too, tried the wrong key :)
<tjaalton> let's see..
<albert23> xev says that's XF86ClearGrab, no underscore
<albert23> the package diff says XF86_ClearGrab, with underscore
<tjaalton> yep, still happens
<jcristau> look at xkbcomp output
<albert23> jcristau: which input file should I use for xkbcomp?
<jcristau> your X server
<albert23> xkbcomp :0 gives no output
<jcristau> xkbcomp :0 -
<albert23> lists XF86ClearGrab with KP_Multiply
<jcristau> sure.
<jcristau> that's not an issue tho
<jcristau> you want to check if there's an associated action
<tjaalton> action= Private(type=0x86,data[0]=0x43,data[1]=0x6c,data[2]=0x73,data[3]=0x47,data[4]=0x72,data[5]=0x62,data[6]=0x00);
<albert23> same here
<jcristau> on a server started after xkb-data was upgraded?
<albert23> indeed
<tjaalton> need to check
<tjaalton> I did upgrade earlier today and booted the new kernel
<jcristau> that doesn't make a lot of sense...
<tjaalton> hm the package was updated three days ago, so yes
<albert23> could "XKB: reuse xkmfile /var/lib/xkb/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm" be related? That file is dated 8 December for me
<jcristau> albert23: yes
<tjaalton> haha
<jcristau> very much so.
<tjaalton> mine is dated 5min after the package update
<tjaalton> after a reboot
<tjaalton> hm
<tjaalton> though it could use an older one..
<tjaalton> why of course
<tjaalton> from september
<tjaalton> i'm winning.. ;)
<jcristau> yay moblin patches
<albert23> I have multiple too, but youngest is 4 days ago
<albert23> So it doesn't seem to rebuild with an update
<tjaalton> not necessarily no
<tjaalton> and the server picks a seemingly random one
<albert23> it even tries multiple, according to x log
<tjaalton> eh
<tjaalton> quality crap
<albert23> interesting: it only tries the 3 oldest, dated 8 December, not the youngest
<tjaalton> ricotz: why bother testing fglrx, it won't work
<cnd> albert23, so you needed to delete the old xkmfiles to fix the security bug?
<albert23> cnd, didn't do that yet
<cnd> xkm cache files can cause other issues, as I found out a few months ago :)
<cnd> bryce, RAOF, you guys thought about adding a script or hook somewhere to clean those out
<jcristau> but, faster boot!
<cnd> any news on that?
<bryce> cnd, thought about but no plans
<jcristau> you could make them live in /run so they go away on their own
<cnd> jcristau, that would defeat the purpose :)
<jcristau> not really
<cnd> they are cached to make subsequent X server starts faster
<jcristau> you'd run xkbcomp once instead of 3 times per device
<cnd> or so I've been told
<jcristau> (ok, maybe not 3, but still)
<jcristau> i suppose rm them in xkb-data.postinst would make sense too
<cnd> that's what I'm thinking
<jcristau> to invalidate the cache
<ricotz> tjaalton, still hoping, i can't play with fglrx here though, but nvidia has a driver built against 1.12
<jcristau> nvidia != fglrx
<tjaalton> ricotz: built? as in package doesn't conflict?
<ricotz> jcristau, i dont have a radeon card so i never used it
<ricotz> tjaalton, as in binary built against the 1.12 video abi
<tjaalton> which version is that?
<jcristau> ricotz: me neither.  but from experience nvidia works with an xserver release as soon as that exists.  fglrx waits until the next one is almost there.
<ricotz> tjaalton, no public release though, 295.10
<tjaalton> ok
<ricotz> jcristau, right, but as the nvidia binaries tend to work with never servers, i was hoping kind of the same with fglrx
<tjaalton> not surprising though, since aaronp got upset recently when the abi was going to be broken again
<ricotz> jcristau, 290.10 kind of works with 1.12
<jcristau> ricotz: as i said..
<jcristau> nvidia != fglrx
<ricotz> right
<albert23> ok, moved the xkm's away and restarted X. Now I have fresh xkm's and xkbcomp does not show XF86ClearGrab with action anymore.
<albert23> screensaver works fine now
<tjaalton> hm, the staging upload was not in git
<tjaalton>   if dpkg --compare-versions "$2" lt-nl 2.5; then
<tjaalton>     rm -f /var/lib/xkb/*.xkm
<tjaalton>   fi
<tjaalton> I'll try that..
<jcristau> tjaalton: tbh i don't think that should be version-specific
<tjaalton> yeah
<tjaalton> true
<RAOF> cnd: Yo!
<cnd> RAOF, holla!
<tjaalton> RAOF: hang on, I've got a xkb-data update under testing ;)
<RAOF> tjaalton: Merged from Debian?  Cool.
<cnd> tjaalton, with the postinst change to delete the cache?
<tjaalton> cnd: yes
<cnd> tjaalton, cool
<tjaalton> RAOF: read the recent backlog
<RAOF> Yay xkb cache?
<tjaalton> that
<cnd> RAOF, so once tjaalton has the xkb cache issue resolved, are we ready to push?
<RAOF> I believe so, yes.
<cnd> cool
<cnd> mdeslaur, ping
<mdeslaur> cnd: yes?
<cnd> so we want to push the latest X bits to precise today
<mdeslaur> cnd: ok
<cnd> with a fix that tjaalton is readying for xkb-data, we believe we have addressed the security hole
<mdeslaur> cnd: ok, great
<cnd> is there anything we need to do at this point?
<cnd> or did you just need to check that we had things fixed before pushing?
<mdeslaur> cnd: I just wanted to make sure the fix went in before it got pushed
<cnd> ok
<cnd> thanks for following the issue :)
<mdeslaur> cnd: thanks for fixing it!
<cnd> np (though tjaalton and RAOF deserve the credit :)
<tjaalton> and albert23 for the heads up :)
<mdeslaur> thanks tjaalton and RAOF too
<RAOF> :)
<mdeslaur> and albert23
<albert23> np
<tjaalton> pushed the commit, fixed it here
<tjaalton> so it removes the cache files every time postinst is run
<tjaalton> ok, pushing it to the ppa
<tjaalton> or, to the archive?
<tjaalton> does it matter?
<cnd> tjaalton, I think this can go to the archive
<tjaalton> yeah
<cnd> hmm
<cnd> actually, RAOF pushed it to the ppa last time
<cnd> you could probably do either, unless xkb-config has an interdependency with the X server
<RAOF> I did, but there's no reason for this to not go to the archive.
<RAOF> I pushed it to the PPA since it only fixed a bug found in the PPA; a new upstream version is more widely usefu.
<tjaalton> pushed to precise
<tjaalton> RAOF: you have the keys now ;)
<RAOF> tjaalton: Ok.  I'll find out how to turn them :)
<tjaalton> yeah, noticed :)
<cnd> \o/
#ubuntu-x 2012-01-24
<RAOF> cnd: Whoops!  I didn't notice before, but your xserver-xorg-input-synaptics upload is a native package.  Generally when we take upstream snapshots we âmake distâ a tarball to get an orig.tar.gz.
<cnd> RAOF, ahh yes, I didn't think to do that :(
<cnd> RAOF, have you already uploaded?
<RAOF> Yup, we're pending publication.
<cnd> well, we can upload a fix
<RAOF> Yeah.
<cnd> it's not a show stopper I wouldn't think
<RAOF> Just next time we touch it.
<cnd> ok
<RAOF> It's not.  It's a bit annoying, but nothing terrible.
<cnd> RAOF, it's alive!
<cnd> we now have multitouch, upstream, and in ubuntu!
<RAOF> :)
 * cnd is so happy!
<RAOF> Rock on!
<Prf_Jakob> Cool
<RAOF> cnd: You've failed to add 0004-xi22-ubuntu.patch to git :)
<cnd> gah...
<RAOF> Oh, to xserver-xorg-input-evdev git.
<cnd> RAOF, I'll fix it up
<RAOF> Ta.
<cnd> RAOF, synced up
<RAOF> Thanks muchly.
<RAOF> Um, that fails to apply in configure.ac?
<cnd> grr.
<RAOF> You appear to have a copy-number mutation in the patch :)
<cnd> how did this build before?
<RAOF> Dunno.
<RAOF> I can push the fixed patch if you like.
<cnd> I'll figure it out
<cnd> hmmm, something is pretty wrong in the patch I added
<cnd> looks like it does the same thing twice for some reason
<RAOF> It's duplicated.
<RAOF> You've probably >>ed the patch to itself at some point, or something.
<cnd> yeah
<RAOF> Now to hit up my new xserver
<cnd> RAOF, evdev should be all fixed up
<cnd> it builds properly once again
<RAOF> Woot
<RAOF> Oh, man.  I'm awesome like the fox.
<bryce> nice, congrats on the landing guys
<bryce> hmm, X starts but doesn't render anything.  odd
 * cnd is glad he doesn't do graphics :)
<RAOF> bryce: What GPU?
<bryce> 945
<bryce> RAOF, its the little netbook I was using during the rally
<bryce> RAOF, startx works to boot it into 2d mode
<bryce> odd, and now it's working fine again
<bryce> just wanted another reboot
<RAOF> Huh.
<tjaalton> bryce: check out the old logfile..
<tjaalton> though I doubt it has anything to do with purging the xkb cache..
<RAOF> Huh.  For those playing at home, sqrt(dx*dx) isn't actually the quickest way of doing what I was after :)
<RAOF> Oh, balls.  Pointer movement can be restricted by multiple barriers.  Arse.
<tjaalton> huh, did some defaults change or why is git mergetool failing/refusing to merge anything
<tjaalton> have to pull every change one by one, at least when using meld..
<tjaalton> RAOF: still around? looks like we ship libwayland-egl in libegl1-mesa, and debian in libegl1-mesa-drivers. maybe ok to go with debian?
<tjaalton> also, I don't think there's much point in providing the classic radeon drivers in -dri-experimental
<tjaalton> if they even build
<tjaalton> hmm dricore is apparently upstream?
<tjaalton> galliumcore needs further work, and wayland needs an update
<tjaalton> kibi said he'd take care of the latter tomorrow
<Sarvatt> tjaalton: what's wrong with galliumcore?
<tjaalton> Sarvatt: building dri/swrast fails, since -lgallium is everywhere
<tjaalton> didn't look closer, need to run now :)
<tjaalton> it's in git, have a look
<Sarvatt> yeah got it building now
<Sarvatt> +        DRI_LIB_DEPS='-L$(TOP)/$(LIB_DIR) -Wl,-R$(DRI_DRIVER_INSTALL_DIR) -lgallium -ldricore -lglsl'
<Sarvatt> could probably even ditch galliumcore with all the space gained from dropping dri1 drivers
<Sarvatt> ricotz: damn, almost there
<Sarvatt> *** Warning: Linking the executable i965_symbols_test against the loadable module
<Sarvatt> *** i965_dri.so is not portable!
<Sarvatt> ./.libs/i965_dri.so: undefined reference to `vbo_get_minmax_indices'
<Sarvatt> down to 1 undefined reference on mesa master instead of pages full of them
<ricotz> Sarvatt, hi, nice and yeah these fuzzing patches could do some harm
<Sarvatt> ricotz: tempted to upload an 8.0 branch snapshot for now since mesa master hasn't built since jan 10th
<Sarvatt> oh yeah master needs to be 8.0+ now too
<ricotz> Sarvatt, i see, since the current version number permits that it should be fine
<ricotz> to do a 8.0 branch snapshot
<ricotz> but if you are this close ;)
<hallyn> hi - I was wondering whether anyone might be willing to upload a change to xserver-xorg-video-qxl for bug 913314
<ubot4`> Launchpad bug 913314 in xserver-xorg-video-qxl (Debian) (and 3 other projects) "Corrupted display with Spice (affects: 2) (dups: 2) (heat: 23)" [Unknown,New] https://launchpad.net/bugs/913314
<tjaalton> hallyn: is the fix in upstream master or some release?
<hallyn> the fix is upstream
<hallyn> it's a straight cherrypick
<tjaalton> I could push that to debian
<hallyn> that'd be great
<tjaalton> looks like there is no new release available since 0.16
<tjaalton> ..which is seven months old
<tjaalton> no, six
<tjaalton> hallyn: btw, there is ddebs.u.c which has -dbgsym packages for the drivers. not that discoverable though
<hallyn> d'oh.  i thought that was obsolete :)
<tjaalton> :)
<tjaalton> Sarvatt: d'oh, how did I skip those patches
<tjaalton> and why
<Sarvatt> tjaalton: can ya pastebin ls -al /usr/lib/x86_64-linux-gnu/dri/ ?
<Sarvatt> curious to see the size difference without libgallium
<tjaalton> http://paste.ubuntu.com/815632/
<Sarvatt> think libdrm's build-dep should be bumped to 2.4.30?
<Sarvatt> libdrm-intel requires it
<tjaalton> ok
<tjaalton> bad upstream :)
<Sarvatt> LIBDRM_REQUIRED=2.4.24
<Sarvatt> LIBDRM_RADEON_REQUIRED=2.4.24
<Sarvatt> LIBDRM_INTEL_REQUIRED=2.4.30
<tjaalton> oh ok
<Sarvatt> i'm unsure because intel isn't built on all arches and those dont need 2.4.30
<tjaalton> could build-deps have 'libdrm-dev (>= 2.4.30) [amd64 i386]'?
<tjaalton> and kfreebsd-*
<tjaalton> i mean two lines for libdrm-dev
<tjaalton> maybe it doesn't matter
<tjaalton> just bump it :)
<tjaalton> most of them have .30
<tjaalton> just hppa, powerpcspe, avr32 behind
<Sarvatt> 7th mesa build of the day, poor macbook air
<jcristau> hallyn: get upstream to release it?
<tjaalton> that would be optimal
<Sarvatt> argh, forgot mesa 8.0 branch doesn't compile against newer wayland
<tjaalton> sounds great
<Sarvatt> only bug i've seen so far against the newer x https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-173/+bug/921023
<ubot4`> Launchpad bug 921023 in nvidia-graphics-drivers-173 (Ubuntu) "Crash at startup (affects: 1) (heat: 6)" [Undecided,New]
<tjaalton> is there a newer version even available?
<Sarvatt> .31 but doesn't say it has 1.11 support
<tjaalton> right
<Sarvatt> might need to add IgnoreABI via jockey again for that package
<Sarvatt> if it even works
<tjaalton> whee, so we get to drop all the legacy ones :)
<Sarvatt> cnd: might be a synaptics problem after the updates - https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/921082
<ubot4`> Launchpad bug 921082 in xorg (Ubuntu) "after touchpad movement and stop, pointer continues in same direction at a steady pace (affects: 1) (heat: 6)" [Undecided,New]
<cnd> hmm
<cnd> it sounds like the intended behavior if it's near the edge of the touchpad
<cnd> though it may be new in the latest synaptics version
<bryce> uploaded intel-gpu-tools 1.1 just now
<RAOF> tjaalton: We've got the go-ahead from the techboard for --enable-texture-float, by the way.  Please feel free to flip that switch.
<tjaalton> RAOF: it's flipped already :)
<tjaalton> on the debian branch
<RAOF> Superb
<tjaalton> but good to know that it's ok for them, was about to ask around what the situation was
<tjaalton> Sarvatt: how's the dri size comparison doing, got any results?
<RAOF> How hard is refreshing galliumcore?  That was a ~10MB win, likely to be more now that llvmpipe is default swrast.
<Sarvatt> tjaalton: nope, hit the wayland problem then got poked about some hotkey bugs
 * Sarvatt has edgers installed atm and downgrading away from it takes about 30 minutes worth of manual apt-get crap
<tjaalton> ah, ok
<Sarvatt> oh scratch that, mesa doesn't explicitly depend on the exact version anymore!
<Sarvatt> downgraded and got it building again now
<tjaalton> RAOF: well, my branch had all sort of fuzzy patches applied, so could be that me "fixing" the patch to apply might've actually broken it further
<tjaalton> are we going to use the dri-alternates path anymore, now that the classic drivers are gone?
<Sarvatt> i915g would be the only consumer
<tjaalton> so it seems
<RAOF> And we're not exactly lining up to support i915g :)
<Sarvatt> :)
<Sarvatt> tjaalton: oh hell
<RAOF> We can drop it; it doesn't prevent us from shipping i915g in -experimental if we want to.
<Sarvatt> soo it doesn't build with the wayland in precise, and it doesn't build with wayland from git
<Sarvatt> going to need to make a special wayland checkout just for mesa 8.0 :(
<tjaalton> Sarvatt: yep..
<tjaalton> RAOF: ok, I'll clean up rules a bit
<Sarvatt> well theres a weird input bug https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/921236
<ubot4`> Launchpad bug 921236 in xorg (Ubuntu) "[12.04 Xorg] Dual monitor, after entering passoword, mouse pointer stuck on LHS of screen, no desktop. (affects: 1) (heat: 6)" [Critical,New]
<Sarvatt> [    20.232] (II) intel(0): Allocated new frame buffer 3840x1080 stride 15360, tiled
<Sarvatt> [    20.436] BUG: triggered 'if (dev->valuator->numAxes < 2)'
<Sarvatt> BUG: ../../dix/getevents.c:848 in scale_to_desktop()
<RAOF> Awesome.
<RAOF> I wonder how you can get there without an at least two-axis valuator.
<Sarvatt> already fixed in evdev git
<Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/commit/?id=5c5b2c8db851df7921cedd888222a6630a007fd8
<Sarvatt> anyone mind sponsoring http://sarvatt.com/downloads/merges/evdev-precise/ ? it's been confirmed to fix it by the bug reporter
<Sarvatt> (and is in git)
<RAOF> Looking
<Prf_Jakob> Hello Ubuntu peeps!
<Prf_Jakob> How goes the mesa packageing?
<RAOF> Prf_Jakob: tjaalton's on it; it sounds like there's significant progress.
<tjaalton> missing pieces are getting the wayland bits building, and then adding libxatracker etc
<Prf_Jakob> Cool
<tjaalton> kibi from debian wants to do the wayland stuff
<Prf_Jakob> You need to redo the video-vmware package as well, to pick up xatracker.
<tjaalton> not just a rebuild with a suitable option?
<Prf_Jakob> That should do it.
<tjaalton> ok good
<tjaalton> I'll play with it tomorrow..
<Prf_Jakob> cool
<tjaalton> but the wayland situation is a tricky one, Sarvatt says 8.0 doesn't build with wayland git due to this http://cgit.freedesktop.org/wayland/wayland/commit/?id=151ca457b4384c385c0062716b55595e22fef7ea
<Sarvatt> and it doesn't build with our current wayland checkout either
<tjaalton> right
<Sarvatt> looks like nvidia-graphics-drivers-updates and fglrx-updates didn't get updated
#ubuntu-x 2012-01-25
<Sarvatt> RAOF: thanks a bunch!
<RAOF> Sarvatt: No problem; thanks for the fix.
<tjaalton> huh, xa can't find any headers
<tjaalton> namely the bits/ include dir
<tjaalton> /usr/bin/makedepend: warning:  xa_tracker.c (reading /usr/include/features.h, li
<tjaalton> ne 323): cannot find include file "bits/predefs.h" not in /usr/lib/gcc/x86_64-linux-gnu/4.6/include/bits/predefs.h not in /usr/lib/gcc/x86_64-linux-gnu/4.6/include-fixed/bits/predefs.h
<tjaalton> etc
<tjaalton> there, libxatracker & vmwgfx built
<jcristau> bryce: abort() is raise(SIGABRT), not SIGSEGV
<Sarvatt> so https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/921384 is ~2 months away from making it into a fglrx public release, something to keep an eye on and dupe to that bug because i'm sure we'll get a ton of dupes
<ubot4`> Launchpad bug 921384 in fglrx-installer (Ubuntu) "Xorg crashes when trying to play a video (affects: 1) (heat: 6)" [High,Confirmed]
<jcristau> Sarvatt: it takes them that much time to fix an embarrassing crasher? oh my.
<seb128> hey
<seb128> is that a known issue?
<seb128> ==18430== Conditional jump or move depends on uninitialised value(s)
<seb128> ==18430==    at 0x522379B: sse2_combine_over_u (pixman-sse2.c:558)
<seb128> ==18430==    by 0xFC3FDC3: ???
<seb128> it's making nearly impossible to valgrind nautilus
<seb128> I was wondering if that's a known bug or if there is a known workaround
<Sarvatt> holy crap -rw-r--r-- 1 sarvatt sarvatt 28M Jan 25 11:03 ../libgl1-mesa-dri_8.0~rc1-1_i386.deb vs 2.7mb with dricore and galliumcore, that prettyy much maps 1:1 with livecd space used
<Sarvatt> tjaalton: so you said xatracker needs gcc-multilib on amd64? not having any problems compiling it on i386 straight from debian-experimental with http://sarvatt.com/downloads/patches/0001-Add-libxatracker-packaging.patch
<tjaalton> Sarvatt: can't check the link, but it might just be some issue on my box
<tjaalton> will have a closer look tomorrow
<Milos_SD> Guys, if anyone had problems with Intel+Ati hybrid graphics in Ubuntu, try new version of AMD drivers 12.1 :D
<Milos_SD> they worked for me on HP ProBook 4530s with Sandy Bridge + AMD 6490
<FernandoMiguel> evening
<bryce> Sarvatt, can you add a comment to 921384 about that?  (At least mention AMD is already aware of it and has plans for a fix)
<stgraber> hey there, I'm doing some tests with friendly recovery and noticed that when resuming from it, my X server starts with vesa, no intel driver
<stgraber> this is apparently caused by a missing /dev/fb0 which is apparently linked to the recovery mode using "nomodeset"
<stgraber> did we loose UMS support recently for intel and now absolutely need KMS?
<Sarvatt> stgraber: lucid was the last release that supported UMS, yeah :(
<Sarvatt> same situation on nouveau
<stgraber> ok, I'll investigate why we added that to start with and will remove the nomodeset if that won't break recovery mode for some people (which I'm really quite worried about)
<stgraber> Sarvatt, bryce: How bad would it be for you if the recovery mode was to use KMS too? Do you know if people currently use it to debug X/video drivers issue with mode setting?
<Sarvatt> from my perspective making it use KMS would be really bad, the situations I use it in are ones where the video driver is borked and I need something that just works to recover, UMS/vesa works great there
<bryce> stgraber, why do you ask?
<stgraber> bryce: because one of the option of friendly-recovery is to "resume" the boot and currently that's broken as X will start with vesa instead of the usual driver as we boot with nomodeset
<bryce> true
<bryce> well, I suppose we could have two recovery modes, one friendly-recovery with KMS, the other grumpy-recovery with VESA
<bryce> in fact the latter probably could slot in well with failsafe-x mode
<Sarvatt> the alternative is someone booting an intel machine with eDP where KMS doesn't work (happens quite often..) and having to figure out kernel command line options to pass to grub to even get the system up
<stgraber> yeah, might end up doing that then, I don't particularly like adding entries to grub but well...
<bryce> sounds good
<bryce> while not adding stuff to grub is important, unfortunately toggling between UMS and KMS can only effectively be done in grub, and due to the nature of the failures has to be done pre-boot.
<bryce> and unfortunately this class of bugs that requires it is still not quite rare enough that we can ignore it
<stgraber> yeah, just talked a bit with slangasek about it, we really don't want to add an entry so what we'll do instead is start in UMS as we always did and show a warning to the user when he askes to continue the boot, telling him he may need to reboot to get the right screen resolution
<bryce> stgraber, ok, what will display that warning?
<stgraber> friendly-recovery
<bryce> stgraber, thanks
<Sarvatt> pixman bug we'll probably run across https://bugs.freedesktop.org/show_bug.cgi?id=45009
<ubot4`> Freedesktop bug 45009 in libpixman "minor graphical glitches" [Normal,New: ]
#ubuntu-x 2012-01-26
<ogra_> hey, are there any known probs with the new X abi and themeing ? 
<ogra_> i'm using an nvidia tegra driver over here, according to nvidia it should work fine with ABI 11 but i see a lot of small issues in firefox, with the overlay toolbars and general themes
<tjaalton> ogra_: probably a driver bug then
<Sarvatt> ogra_: try downgrading to https://launchpad.net/ubuntu/+source/pixman/0.24.0-1 ?
<ogra_> Sarvatt, ah, thanks, will try that later today 
 * ogra_ has meetings all over the day
<tjaalton> oh right, that got updated
<Sarvatt> ogra_: I'm not sure what kind of corruption you're getting, but there is a bug in the newer pixman
<Sarvatt> https://bugs.freedesktop.org/attachment.cgi?id=55873
<Sarvatt> instead of https://bugs.freedesktop.org/attachment.cgi?id=55872 with 0.24.0
<Sarvatt> oh got updated?
<Sarvatt> ah got my hopes up they already released a revert of what broke it :)
<tjaalton> nah meant that I synced 0.24.2
<jcristau> ssp posted a revert patch for that one aiui?
<Sarvatt> yeah http://mid.gmane.org/ye8ehunr1fm.fsf@llama16.cs.au.dk http://mid.gmane.org/ye8y5sv8s46.fsf@llama16.cs.au.dk
<orated> Hello!
<orated> I need some help with Dell XPS 15 dual graphics card. I used  - https://wiki.ubuntu.com/HardwareSupport/Machines/Laptops/Dell/XPS/15#Optimus_.2BAC8_Graphics_cards - and followed - echo OFF > /sys/kernel/debug/vgaswitcheroo/switch  - command to turn off the card but it gives error of -  # ls -l /sys/kernel/debug/vgaswitcheroo/switch  ls: cannot access /sys/kernel/debug/vgaswitcheroo/switch: No such file or directory - As per lspci, 
<orated> there there is Nvidia card detected but I'm not able to switch if off. How to fix this?
<tjaalton> it's not possible to select from bios?
<orated> No, I don't see any option in BIOS to disable second graphics card
<orated> tjaalton: But howcome switch directory is not present in my system?
<tjaalton> orated: no idea..
<tjaalton> using the distro kernel and not your own?
<orated> Well, the instruction in the same wiki to completely disable the Nvidia card works though
<ogra_> Sarvatt, hmm, now i had time to read the bug, i think my issues are worse than just badly rendered triangles
<orated> 3.0.0-15-generic 
<tjaalton> yeah blacklisting nouveau makes sense
<orated> But I'm not sure if its completely disabled
<tjaalton> check the power usage
<orated> yes before blacklisting I remember the number but not the unit.. I remember 159 (unit) and after blacklisting, now it says - grep rate /proc/acpi/battery/BAT0/state - around 3000 mA
<orated> which changes to 1mA to at times unknown
<orated> on battery
<orated> power in watts but the command listed in wiki gives current
<orated> cat /proc/acpi/battery/BAT0/state gives no value for power here
<tjaalton> use powertop-1.13
<orated> tjaalton: I don't think its possible to get power rating with a software tool. I tried powertop.. It gives Summary: 1008.9 wakeups/second,  0.0 GPU ops/second and 0.0 VFS ops/sec and table, nothing in watts
<tjaalton> that's why I said powertop-1.13
<orated> ok installed 1.13 now
<orated> and pinned it
<tjaalton> it's a separate package, no need to pin
<orated> ok
<orated> I used http://packages.ubuntu.com/natty/powertop
<orated> and locked the version*
<tjaalton> the archive has both versions
<orated> ah
<orated> Well, I will use from the archive later then. Now after running powertop, is the number within brackets under Top causes for wakeups in mW ?
<orated> I see Wakeups-from-idle per second : 138.1    interval: 15.0s no ACPI power usage estimate available
<tjaalton> run powertop-1
<tjaalton> hmm
<jcristau> orated: on battery, or ac?
<orated> ah
<jcristau> the acpi power usage estimate thing only works on battery afaik
<tjaalton> right
<orated> ok on battery - Power usage (ACPI estimate): 38.9W (2.7 hours)
<tjaalton> wow :)
<tjaalton> my t420s takes ~9
<orated> Now, what does - 888.0 represent in Top causes for wakeups:  53.0% (888.0)   [Rescheduling interrupts] <kernel IPI> ?
<jcristau> it represents 888 wakeups
<orated> I'm not sure how does it conform if the secondary GPU is disabled
<orated> probably not
<tjaalton> right, sounds like it's still powered on
<orated> any other suggestion then?
<tjaalton> not really..
<orated> It says now - Power usage (ACPI estimate): 31.4W (3.2 hours) (long term: 100.1W,/1.0h)
<orated> Ok
<tjaalton> this thinkpad is the only hybrid gfx machine I've had
<tjaalton> and it has a bios option to choose
<orated> thinkpad allows to disable secondary gfx card in bios, yes
<orated> anyway thanks tjaalton jcristau
<bryceh> cnd, for bug 754000 the branch is in the patch pilot queue for upload sponsorship, but it's a bit ambiguous whether it should go in
<ubot4`> Launchpad bug 754000 in xserver-xorg-input-synaptics (Ubuntu) (and 4 other projects) "Running Unity disables Xorg's 3-finger click support (middle click) (affects: 55) (dups: 4) (heat: 245)" [Low,In progress] https://launchpad.net/bugs/754000
<bryceh> cnd, should I upload it, or should I put the branch back to work in progress to remove it from the sponsor queue?
<bryceh> (I've checked that it builds and written a changelog entry)
<bryceh> cnd, I don't have touch hardware I can test it on, but am wondering maybe just toss the patch in and see if anyone complains?
<cnd> bryceh, the patch doesn't apply to precise anymore
<cnd> and I worry that it could have regressions if applied as an SRU
<cnd> unfortunately, I haven't had enough time to test it
<cnd> but it modifies a moderately complex area of the code
<bryceh> cnd, ok sounds like you would be against it, so I will unmark it for sponsorship
<cnd> bryceh, I can leave a comment if you are busy
<bryceh> I'm patch piloting today, so it's what I'm supposed to do
<cnd> ok
<bryceh> cnd, ok it's dropped from the sponsor queue
#ubuntu-x 2012-01-27
<RAOF> I'm uploading the pointer-barrier work.  It works everywhere I've tested it, and I'll check in here in the morning.
<tjaalton> cool
<tjaalton> push the branches too :)
<RAOF> Thanks for the reminder.
<RAOF> Thar ya go.
<tjaalton> thanks
<Prf_Jakob> tjaalton: Howdy?
<Prf_Jakob> s/?/!/ :)
<tjaalton> Prf_Jakob: mesa still blocked on wayland update
<Prf_Jakob> ok
<Prf_Jakob> thanks for the update
<Sarvatt> RAOF: http://paste.ubuntu.com/819028/
<Sarvatt> RAOF: nevermind, it was an easy fix. thanks coccinelle
<Sarvatt> RAOF: http://kernel.ubuntu.com/~sarvatt/patches/500_pointer_barrier_thresholds.diff
<Sarvatt> (for xserver master)
<bryce> we don't care about powerpc for x-staging do we?
<RAOF> Sarvatt: Oh - the version I sent to xorg-devel@ should have been the version that applies against master; as you've noticed, there are some small changes required to backport it to 1.11 :)
#ubuntu-x 2012-01-28
<Sarvatt> RAOF: oh I didn't see them because they were attached and in response to the protocol, bah
<Sarvatt> no biggie took all of 2 minutes to fix
<broder> RAOF: if you have a chance to look, i was able to reproduce my GPU hang with natty userspace + oneiric kernel + drm.debug=0x4 - http://web.mit.edu/broder/Public/xserver-xorg-video-intel-oneiric-kernel.crash
<tjaalton> syncing xcb-proto, libxcb 1.8 on hold until finished some testing
<Sarvatt> RAOF: did you have any xcb patches for the xfixes stuff?
<Sarvatt> tjaalton: i can't reproduce the libxcb/alsamixer problem from debian in precise at least
<Sarvatt> tried 4 systems when i saw that bug come in, only 1 i386 though
<jcristau> i don't know how ld.so thinks it should resolve shutdown@GLIBC_2.2.5 to the one in alsamixer
<jcristau> then again i don't know much about ld.so
#ubuntu-x 2012-01-29
<RAOF> Sarvatt: Yes, I have xcb patches*
<RAOF> *: However, xcb doesn't have fixesproto v5 yet, and due to some problem somewhere the xcb-generated bindings send a non-empty Devices array, running into the unfinished parts of fixes v5, and so creating a barrier always generates BadImplementation.
<FernandoMiguel> guud afternoon
<mdeslaur> wow, the nvidia binary driver sure is borked in precise
<ricotz> mdeslaur, how?
<mdeslaur> ricotz: switching between users gives screen corruption, suspend and resume is flaky, I either get a blank screen with a flashing cursor, or the unity launcher is corrupted, etc.
<ricotz> mdeslaur, yeah, it is like switching ttys ;), dont do it
<ricotz> :P
<mdeslaur> hehe
<metasansana> Is it possible to drag windows across separate X screens?
<RAOF> It depends on what you mean by separate X screens.
<jcristau> if he means separate X screens, then no it's not.
<metasansana> I have to separate nvidia gf cards
<metasansana> on board and pci
<metasansana> I can select Seperate X screen in the NVIDIA X Server settings
<RAOF> And, in order to use both, you need to set them up as âSeparate X screensâ.  I *believe* that this will set up a Xinerama configuration, which will allow you to move windows between your displays.
<metasansana> RAOF: they just mirror each other
<RAOF> Then set them to not mirror.
<metasansana> I tried setting Clone "0" but in the ServerLayout but they still mirror
<RAOF> Unless that's what you want, of course :)
<metasansana> Its definitely not what I want
<RAOF> nvidia-settings should be able to set it up how you want, but I've not played with those settings.
<metasansana> :(
<metasansana> thanks RAOF 
<RAOF> It *should* be possible to do what you want, but I've not done it myself.
<metasansana> I found some more info on nvidia's website
#ubuntu-x 2013-01-21
<mlankhorst> morning
<tjaalton> uploaded -intel 2.20.19 with sna
<mlankhorst> weird, so libradeonsi.a is suddenly 27mb, but each individual object summed together is much smaller
<mlankhorst> oh, links to libradeon
<tjaalton> we're going to drop it from raring anyway, would it be uncool to drop from quantal too?
<mlankhorst> what do you mean?
<tjaalton> radeonsi is disabled in my mesa snapshot
<tjaalton> because the llvm backend was moved to llvm, and will be released with 3.3
<mlankhorst> oh that
<mlankhorst> I'd rather keep the quantal lts stack's support identical to quantal. I was thinking of trying to move everything in drivers/* to libgallium, to see if it reduces the object size some. I wonder if llvm's static libs are duplicated multiple times..
<tjaalton> sure
<mlankhorst> hm doesn't look easy, I'll try an evil hack
<mlankhorst> just building llvm shared from the static files it has
<mlankhorst> didn't seem to affect size much, though :(
<tjaalton> hrm
<mlankhorst> I guess everything would already be pulled in from -lLLVM-3.1
<mlankhorst> also reduces the possibility of making it even smaller :(
<tjaalton> so, now I actually uploaded -intel..
<mlankhorst> phew, didn't do a reboot in my chroot this time, almost did though :P
#ubuntu-x 2013-01-22
<mlankhorst> morning
<rye> Hello, I am suffering from https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1100360/ starting from raring - is there anything I (or other people in the bug report) can do to debug this?
<ubottu> Ubuntu bug 1100360 in xserver-xorg-video-intel (Ubuntu) "[raring][sandybridge-m-gt2+] GPU lockup IPEHR: 0x0b160001 IPEHR: 0x0b140001" [Undecided,Confirmed]
<tjaalton> rye: the other bug has a pointer to the upstream bug..
<tjaalton> rye: echo 0 > /sys/modules/i915/parameters/semaphores
<tjaalton> try if that helps
<mlankhorst> tjaalton: are you planning to do a sru of mesa9 to quantal?
<tjaalton> mlankhorst: at some point yes, 9.0.1 would be nice to have
<tjaalton> although it's possible that it regressed intel, bug 1100970
<ubottu> bug 1100970 in xserver-xorg-video-intel (Ubuntu) "transparent dash background flickers on intel graphics" [Undecided,Incomplete] https://launchpad.net/bugs/1100970
<mlankhorst> yeah personally I want 9.0.2, i pulled a bunch of nouveau fixes :)
<tjaalton> is it released?
<mlankhorst> dno
<tjaalton> doesn't seem like it
<mlankhorst> I did a bunch of nouveau cherry picks after 9.0.1 release
<mlankhorst> maybe I should do some more now :)
<tjaalton> go for it
<mlankhorst> hm, did you build llvm-3.2 with the radeon additions yet?
<tjaalton> no, and not going to
<mlankhorst> ah, why?
<tjaalton> doko won't like the idea
<tjaalton> *doesn't
<tjaalton> just drop radeonsi
<mlankhorst> :/
<mlankhorst> will llvm-3.3 be released in time?
<tjaalton> in time for what? raring? no
<tjaalton> upstream says radeonsi isn't useful anyway
<f4bs> when will 310/313 come to quantal?
<f4bs> quantal still has 304.64
<tjaalton> -experimental-310 is there
<tjaalton> tseliot: that package probably should be removed from raring?
<tjaalton> tseliot: -experimental-310
<mlankhorst> yeah but still you'll get people that want to try it :/
<tjaalton> and maybe backport -310..
<tjaalton> raring has -310 already
<tjaalton> nvidia-graphics-drivers-310 which has the latest version, and -experimental-310 which is an older one :)
<f4bs> well i think i switch to xorg-edgers
<tseliot> tjaalton: yes, we should remove -experimental-310 
<bryce> I see debian-experimental is merged into the ubuntu git tree as of a couple weeks ago, yet that version isn't uploaded to raring?
<bryce> I need to put a patch into xserver (for nexus7).  Should I roll back what's in git to match whats in the archive?
<tjaalton> sorry
<tjaalton> huh
<bryce> it looks like we've pushed a bunch of our changes up to debian, which is good, but it's not released there
<tjaalton> there's some clash again
<tjaalton> oh..
<tjaalton> mlankhorst: you merged xserver master to ubuntu, not ubuntu+1
<bryce> ah
<tjaalton> I thought my tree wasn't pushed, but it was
<bryce> guess we need a branch ubuntu+1-1 ?  ;-)
<tjaalton> heh
<tjaalton> nah I guess it could be reset back to 56953a24f021a67
<bryce> tjaalton, are you aware of any ABI breakage so far in 1.14?
<tjaalton> or just use ubuntu+1 which has the same
<tjaalton> bryce: both video & input abi's have been bumped
<bryce> tjaalton, thanks
<tjaalton> so it's the usual dance again
<bryce> tjaalton, so yeah we're gonna want to hold off on pulling this 1.3.99 stuff in until nvidia's had a chance to update the arm drivers I guess
<tjaalton> nvidia has added support in the latest releases, doubt we have those yet though
<bryce> (+ -nvidia and -fglrx)
<tjaalton> right tegra will be a problem I think
<bryce> been emailing ogra & co about that
<bryce> someone will chase it down
<tjaalton> what's the patch btw?
<bryce> the one to fix touch movement with the screen rotated
<bryce> 237_dix_save_touchpoint_last_coords_before_transform.patch
<bryce> commit 3b9f1c701787965246638c1a6fd99fb2b6078114
<bryce> I've verified raring+nexus7 still needs it, and is fixed once it's applied
<tjaalton> ah, it's in the latest pull request for 1.13.x
<tjaalton> huh, I dropped it
<tjaalton> way to go
<bryce> so... do I not need to patch it in?
<tjaalton> yeah you do, it's not in upstream 1.13.x yet.. dunno why I dropped it, probably failed to apply for some reason
<bryce> there were two patches; the one that was posted to the ML originally that you pointed me at, and one from after peter's review comments - which is the one that was accepted
<bryce> both patches still apply to our xserver, but the former was the one we had in the quantal staging, so perhaps you were looking at that and dropped it because you knew the newer one was available?
<tjaalton> no idea :)
<tjaalton> strong work nevertheless
<bryce> yeah, anyway, do you want to reset the tree back or shall I have a go?
<tjaalton> hmm
<tjaalton> let's see
<tjaalton> guess there aren't that many consumers of the ubuntu branch that an innocent git reset matters much :)
<tjaalton> pushed ubuntu+1 with what was there
<tjaalton> and forced ubuntu
<tjaalton> bryce: so it should be set now, ubuntu has what raring has now, ubuntu+1 has the staged stuff by mlankhorst
<bryce> tjaalton, push?
<bryce> $ git pull
<bryce> From ssh://git.debian.org/git/pkg-xorg/xserver/xorg-server
<bryce>  + 6efcd5b...56953a2 ubuntu     -> origin/ubuntu  (forced update)
<bryce>    9e211da..6efcd5b  ubuntu+1   -> origin/ubuntu+1
<bryce> Already up-to-date.
<tjaalton> bryce: git fetch origin; git checkout ubuntu; git reset --hard origin/ubuntu
<tjaalton> your local tree is "newer" than origin
<tjaalton> need to reset it
<bryce> ok got it.  I just deleted the branch and repulled it
<bryce> tjaalton, thanks!
<tjaalton> np, sorry for dropping the patch :)
<tjaalton> some brainf... there
<bryce> wtf?  gcc: error trying to exec 'as': execvp: No such file or directory
<mlankhorst> well the input abi bump got in for the xserver, so I guess it' s just waiting for rc2 now
<bryce> weird, 2nd pbuilder of xserver passed.  huh.
<mlankhorst> bryce: did it fail on xvfb?
<mlankhorst> sometimes the debian/tmp/main/usr/bin/xvfb-run test hangs :/
<bryce> mlankhorst, maybe, although the error was that gcc/as error I pasted so dunno
<bryce> we'll see how it builds in the archive...
<bryce> Sarvatt, had to play 10 min of Dungeons of Dredmor to get my son to take a nap; Dutch wanted to see my "Mustache friend kill the bad guys" before he'd settle down
#ubuntu-x 2013-01-23
<agrestringere> exit
<tjaalton> hmm, wonder if the new -modesetting release would fix bug 1098639
<ubottu> bug 1098639 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT" [Medium,New] https://launchpad.net/bugs/1098639
<mlankhorst> to the buildmobile!
<tjaalton> mlankhorst: just checking; you noticed that I reset the xorg-server branches?-)
<mlankhorst> yes
<tjaalton> good
<mlankhorst> I'm waiting for rc2 release before I start on it again
<tjaalton> and then to the staging ppa?
<mlankhorst> yes
<tjaalton> great
<tjaalton> erm, the bug -modesetting might fix is actually bug 1065288
<ubottu> bug 1065288 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in OsAbort()" [Medium,Confirmed] https://launchpad.net/bugs/1065288
<Chipaca> hi guys. Today my intel-ironlake-driven 1920x1200 displayport monitor doesn't get any signal nine times out of ten i change something with xrandr. Is that a known issue, or should I file a new bug?
<tjaalton> Chipaca: and worked perfectly yesterday?
<Chipaca> tjaalton: well. it failed less often; i've had to drop to console and frob xrandr before now
<Chipaca> but it would just take the once, or very rarely the second time
<Chipaca> and i'd be able to come back into x, turn off eDP1 and carry on using DP2 happily
<tjaalton> so what changed?
<Chipaca> today the only time (out of ~10) i got it working on the console, came back to X, turned off eDP1, and lost DP2 again
<Chipaca> to be clear, X thinks it's working, the monitor drops into "no signal so power save" mode
<Chipaca> tjaalton: you tell me; it's raring :)
<tjaalton> bad cable?
<tjaalton> well it's hard to guess what you've done to your system..
<Chipaca> tjaalton: what do you mean?
<Chipaca> I haven't done anything to it other than update it
<tjaalton> exaclty
<tjaalton> so what changed?
<Chipaca> tjaalton: x, the kernel, libc, python, compiz, dbus? maybe
<Chipaca> not sure about x either, but i think so
<Chipaca> tjaalton: you seriously expect me to keep track?
<mlankhorst> you expect us to keep track what changes on your system? :p
<tjaalton> Chipaca: check dpkg.log..
<tjaalton> the xserver hasn't changed, -intel driver has seen minor updates, kernel otoh..
<Chipaca> mlankhorst: if you change something in the distribution that breaks my system, hell yes i do :)
<mlankhorst> unfortunately the software we work on can change one very hardware combination
<mlankhorst> so quite impossible :P
<tjaalton> you can be running an obsolete raring, and then get a months worth of updates one day
<mlankhorst> could you try an older kernel perhaps?
<Chipaca> http://paste.ubuntu.com/1562150/
<Chipaca> that's dpkg.log
<Chipaca> last known working with this monitor was the 21st
<mlankhorst> i it was a software thing, it was probably either xserver-xorg-video-intel, or linux-image, so check those ;P
<mlankhorst> that site seems to cause my poor firefox to hang
<tjaalton> downgrade -intel
<bryce> Chipaca, see /topic
<mlankhorst> so many libdrm dupes about 2.4.39-0ubuntu1 :/
 * mlankhorst eyes Sarvatt suspiciously
<tjaalton> what dupes?
<mlankhorst> about failing to upgrade because xorg-edgers had a libdrm with the same version as quantal
<mlankhorst>  * [new tag]         mesa-9.0.2 -> mesa-9.0.2
<mlankhorst> \o/
<tjaalton> oh that
<tjaalton> whee
<mlankhorst> tjaalton: are you still working on mesa-master for raring, or should we upload that version to raring first with the size reduction patches I did for the lts-stack enabled?
<tjaalton> mlankhorst: I'm ok with uploading 9.0.2 first
<tjaalton> no immediate rush to get master there
<mlankhorst> ok
<mlankhorst> tjaalton: btw you can just override LLVM_CONFIG with ./configure ac_cv_path_LLVM_CONFIG=llvm-config-3.2
<tjaalton> so no need to patch it?
<tjaalton> sounds good
<mlankhorst> it grabs whatever you put after ./configure and puts it in environment, so you end up with this (I force ignored build-deps because I'm on precise backport stack)
<mlankhorst> checking for llvm-config... (cached) llvm-config-3.2
<mlankhorst> ./configure: line 22091: llvm-config-3.2: command not found
<tjaalton> ok
<mlankhorst> it's almost the same as doing ac_cv_path_LLVM_CONFIG=llvm-config-3.2 ./configure, but when you reconfigure it will remember to pass it again :)
<mlankhorst> configure: error: LLVM 3.1 is required to build the radeonsi driver.
<tjaalton> right
<tjaalton> you need to force it for now
<tjaalton> with master it doesn't matter
<tjaalton> since the backend got removed
<mlankhorst> yeah sadly
<mlankhorst> is there no way to convince the llvm maintainer to take on the radeonsi patches?
<tjaalton> tstellar is on it
<tjaalton> don't think it's ready for llvm yet
<tjaalton> and we won't get a snapshot anyway
<tjaalton> unless it's a separate one-off package for raring
<mlankhorst> we should
<mlankhorst> I would rather not remove support for recent cards that worked before
<tjaalton> fsvo worked
<mlankhorst> indeed but still better than llvmpipe :P
<mlankhorst> weird
<mlankhorst> I have a diff to src/gallium/auxiliary/Makefile that according to git doesn't exist..
#ubuntu-x 2013-01-24
<bryce> I'll be afk tomorrow morning; reviewing son's preschool.
<tjaalton> don't be too hard on them ;)
<tjaalton> bryce: btw, looks like the workqueue bug search doesn't show bugs that have other packages listed as affected
<tjaalton> was wondering why some -intel bugs don't show up on the list, no matter what the bug status is
<tjaalton> hmm not that simple
<mlankhorst> tjaalton: but we have a MRE for mesa? \o/
<mlankhorst> oh still need to run piglit for that.. yikes
<tjaalton> provisional mre, but I guess we could apply for a standing one
<tjaalton> how's 9.0.2 shaping up?
<xnox> mlankhorst: have you seen the mini-mailing-list bug #993187 ?
<ubottu> bug 993187 in plymouth-theme-int2mil-ubuntu-11.04 (Ubuntu Precise) "ubuntu 12.04 completely freezes frequently." [Undecided,Fix released] https://launchpad.net/bugs/993187
<xnox> (never mind the bogus plymouth package in it)
<mlankhorst> tjaalton: uploaded to raring
<xnox> it's a linux/x bug with a lot of angy people in it.
<xnox> Maybe somebody from X team can respond saying what users can try to resolve their issues or like point them to the quantal enablement stack.
<xnox> ?
<mlankhorst> what's stopping you from recommending to install xserver-xorg-lts-quantal to test? :P
<mlankhorst> sounds more like this 1. either has nothing to do with x, 2. has been overloaded to all kinds of hang bugs that may have the same symptons but different underlying causes..
<tjaalton> xnox: yeah that bug is just hopeless..
<xnox> mlankhorst: tjaalton: yeah it is hopeless, i am naive enough to think experts can redirect useless rants into useful bug reports =)
<tjaalton> I tried to bang some sense to it earlier, but it didn't help
<mlankhorst> now you know!
<tjaalton> hmm what if it's marked private? :)
<mlankhorst> don't bother
<tjaalton> would that stop the useless comments?
<mlankhorst> best you can do is let it die out..
<tjaalton> it doesn't seem to :)
<mlankhorst> then leave it active and ignore, any effort on it is wasted..
<tjaalton> well, a pointer to the backport stack and then mark it private :)
<mlankhorst> they'll just find another place to vent..
<xnox> i don't think marking it private will help.
<xnox> just another spark of "hiding _gasp_ critical bugs"
<tjaalton> mlankhorst: what is the "correct" way to enable the backport stack btw, install the kernel & xserver manually?
<mlankhorst> install xserver-xorg-lts-quantal (and maybe libgl1-mesa-dri-lts-quantal:i386 if you're on 64-bit to help out apt)
<tjaalton> does the xserver pull the new kernel too?
<mlankhorst> yeah it has a recommends on it
<tjaalton> ok
<tjaalton> but folks with dkms modules need the new headers too, unless it recommends linux-generic-lts-...
<tjaalton> ?
<mlankhorst> yeah but that's probably a kernel problem :P
<tjaalton> not really
<mlankhorst> I guess when you load from the cd it will install those too
<tjaalton> yes
<tjaalton> so whenever someone suggests the backport stack, it should be linux-generic-lts-.. + the xserver
<mlankhorst> Package: linux-generic-lts-quantal
<mlankhorst> Depends: linux-image-generic-lts-quantal, linux-headers-generic-lts-quantal
<tjaalton> ah
<tjaalton> that's fine then :)
<tjaalton> didn't bother checking myself :)
<tjaalton> i guess someone would've complained already..
 * mlankhorst fighting piglit
<mlankhorst> surprisingly, no lockup yet
<mlankhorst> bryceh: I'm not getting any lockup on piglit atm on mesa-master with my fermi, though some traps  so it's probably not completely correct, but still :)
<stgraber> hey there, anyone who has some time to help me debug some DisplayPort problems on Intel graphics? :)
 * mlankhorst points at topic
<stgraber> fine, I'll do that, not that you'll find anything interesting in the logs (otherwise I'd have fixed the problem myself)
<stgraber> (the problem is that DisplayPort daisy-chaining doesn't appear to work at all, to the point where the second display doesn't show up anywhere on the system)
<stgraber> bug 1104230
<ubottu> bug 1104230 in xorg (Ubuntu) "DisplayPort 1.2 MST support seems to be broken in the Intel driver" [Undecided,New] https://launchpad.net/bugs/1104230
<mlankhorst> could try to bug the intel devs in #intel-gfx, see what they think :)
<stgraber> mlankhorst: I'll do that in a bit. Just waiting for a friend with the same laptop but running Windows to confirm that my setup works fine on Windows :)
<tjaalton> also try this kernel for fun http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/current/
<Sarvatt> stgraber: in order to do triple head on ivybridge 2 of the monitors need to be identical and use the same type of connection, you might want to try disabling the internal display
 * Sarvatt has to run for a bit
<stgraber> I'm starting to suspect that the DP cable I got today is bad as Windows doesn't see anything more than Linux and plugging the DP-DP cable in my laptop (with a DP to mini-DP adapter) doesn't find anything (using a mini-DP to DP to that screen works though)
<stgraber> so I marked my bug as incomplete for now. I was expecting another DP cable next week anyway, so I'll retest then
<stgraber> (I know I'll need to turn off the LVDS to have the two others work, but DP2 should at least show up before that ;))
<stgraber> it's really weird how difficult it's to find a standard DP-to-DP cable these days, seems like people just want DP-to-anything-else...
<chiluk> not sure if this is the right place, but I love the new unity dash icon in raring that was pushed in recently whoever did it kudos.
<tjaalton> someone in #ubuntu-unity perhaps
<chiluk> thanks tjaalton 
#ubuntu-x 2013-01-25
<Sarvatt> hmm, unity dash is much slower in mesa 9.1 than 9.0 on ivybridge
<agrestringere> Can anyone look at a bug and give me guidance on how to proceed triaging?  https://bugs.launchpad.net/xubuntu-desktop/+bug/1015297
<ubottu> Ubuntu bug 1015297 in Xubuntu "Screen partially darkened after suspend and resume in Xubuntu" [Undecided,Confirmed]
<GeoffCh> Just a heads-up:  after yesterday's upgrade of libdrm-intel1, libdrm-nouveau1a, libdrm-radeon1 and  libdrm2 to 2.4.39-0ubuntu0.1 on 12.10, my Arrandale GPU has started to hang randomly.  Here's a trace from syslog:  http://pastie.org/5860453 ... Since I'm using drm_kms_helper to override EDID, I'm not sure this will affect others.
<GeoffCh> Oops, I meant on 12.04
<tjaalton> GeoffCh: please file a bug
<tjaalton> ubuntu-bug libdrm should do the trick
<GeoffCh> OK.  Not sure if it would be a dup of this:  https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1081009
<ubottu> Ubuntu bug 1081009 in xserver-xorg-video-intel (Ubuntu) "[arrandale] GPU lockup IPEHR: 0x02000022" [High,Fix released]
<tjaalton> that was a kernel bug
<GeoffCh> Thanks tjaalton ... bug report is in.
<wrouesnel> so kernel 3.5.0.22 is breaking multi-monitor setups with the radeon driver. I'm not entirely sure where to file this.
#ubuntu-x 2014-01-20
<plasmasolutions> Hi guys, I got a really big problem here, maybe you got an idea - my latin has come to an end...
<plasmasolutions> https://bugs.launchpad.net/ubuntu/+source/x264/+bug/1270655
<ubottu> Ubuntu bug 1270655 in x264 (Ubuntu) "System freeze (kernel panic) while decoding H264 files" [Undecided,New]
<plasmasolutions> I don't know where to look, so any ideas are helpful
<tjaalton> so you filed a bug against an encoder?
<tjaalton> the nvidia driver is a better bet
<plasmasolutions> tjaalton: Hi Timo! I just added you to the bug - ubuntu-gnome was telling me to do that..
<plasmasolutions> Great to see you "personal" here ;)
<plasmasolutions> tjaalton: So you mean I should try to get the bleeding edge nvidia?
<plasmasolutions> tjaalton: Atm I'm not using the nvidia cards (got all cards removed) and am on the internal chip...but still freezing - do you still think that could be the nvidia driver?
<plasmasolutions> Didn't purge it
<tjaalton> and I removed myself :)
<tjaalton> dunno then
<tjaalton> if it freezes with intel too
<tjaalton> wait, blender just crashes?
<plasmasolutions> Yes, it just crashes
<tjaalton> so blame blender then
<plasmasolutions> But "crashes" in the meaning of freezing the whole system
<tjaalton> ok
<plasmasolutions> It's exactly the same issue as with the thumbnailer
<plasmasolutions> And as I am a blender developer I would never blame me :D
<plasmasolutions> tjaalton: no, I think the problem lies deeper on the ground: As that are all h264 vids and the cpu got decoder units for that I assume that the mobo and the cpu are not talking nicely to each other... (corrupting memory)
<plasmasolutions> tjaalton: Maybe you know who could take a look at the bug? I really like to help investigate it
<tjaalton> the cpu doesn't, but the gpu
<tjaalton> check your ram
<tjaalton> try newer kernels
<tjaalton> or older
<plasmasolutions> tjaalton: Did a one day check...no issues
<plasmasolutions> and tried the 3.13 kernel, no problem
<plasmasolutions> ups same problem
<plasmasolutions> didn't try older ones though
<plasmasolutions> am off now, tjaalton thanks for your help!
#ubuntu-x 2014-01-24
<sinean> installed fglrx and fglrx-amdcccle, driver is fine but no catalyst control center (from xorg edgers ppa) linux mint 16 cinnamon x64 stock kernel
<tjaalton> we don't support mint
<tjaalton> go ask the mint folks
<sinean> k
<tjaalton> edgers folks tend to hang here though, on and off
<21WAB8FNS> there are new patches now that enable opengl on radeonsi cards, any idea when new mesa is pushed forward?
<tjaalton> trusty has 10.1
<tjaalton> opengl is already "enabled"
<21WAB8FNS> well the patches are posted t oday
<21WAB8FNS> today
<tjaalton> so hope that 10.2 will have them
<ricotz> tjaalton, trusty has 10.0.1 ;), 10.1 is git master
<tjaalton> hah, true
<tjaalton> silly versions
#ubuntu-x 2014-01-26
<Sarvatt> ricotz: dri3 needs to be disabled in mesa for steam/playonlinux to work, dunno if you've seen the latest update in edgers. heads up if you update it again
#ubuntu-x 2015-01-19
<jderose> does anyone know where the VCS branch is for 346.35? this is still at 346.22 - https://github.com/tseliot/nvidia-graphics-drivers/tree/346/debian
<jderose> (i'm looking for the debian/ VCS for the 346.35 packages here https://launchpad.net/~xorg-edgers/+archive/ubuntu/ppa)
#ubuntu-x 2015-01-22
<soee> hi, why *ubuntu recommends some old version of nvidia drivers - not the newest stable ?
<ricotz> soee, 331 is still the best working one, and newer drivers are also dropping support for quite an amount of older graphics cards -- https://devtalk.nvidia.com/default/topic/533434/linux/current-graphics-driver-releases/post/3751724/#3751724
#ubuntu-x 2015-01-25
<ricotz_> Sarvatt, hey :), i hope you can run an update of intel ddx
<Sarvatt> ricotz: sure thing, up there now.
<Sarvatt> question is, do i upgrade to it right before getting on a plane? :D
#ubuntu-x 2016-01-26
<mamarley> ricotz: 352.79 is out and I am working on it.
<mamarley> tseliot: How close are you to being ready with the prime EGL stuff?
<tseliot> mamarley: I have the code, I'm testing it today
 * tseliot -> lunch
<mamarley> Great!
<ricotz> mamarley, great, thanks ( you are not giving much of a chance to do it ;) )
 * mamarley is trying to prove that he can actually do this without committing hundreds of mistakes each time. :)
<mamarley> ricotz: All the 352 builds (including nvidia-settings 352 for Precise) are now in https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages.
<mamarley> I also have an update for 361.18 for all the distro versions.  For everything but Xenial, it removes the nvidia EGL alternative since that is only going to be supported on Xenial.  For Xenial, it has an update to the Prime ld.so.conf that is necessary to make tseliot's upcoming changes work properly.
<tseliot> mamarley: it looks like nvidia-361 dropped support for my GPU? [    24.767] (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found)
<tseliot> that happens after (II) NVIDIA GLX Module  361.18  Sat Jan  9 20:41:31 PST 2016
<tseliot> which means my hybrid system is kind of useless now
<tseliot> sigh
<tseliot> except 1140 is listed as supported
<tseliot> mamarley: I'll take that back, there must be something wrong with gpu-manager
<tseliot> mamarley: everything seems to work now :) . I'll test it more tomorrow.
#ubuntu-x 2016-01-28
<tseliot> mamarley: I'm about to upload nvidia-prime and u-d-c in xenial
<mamarley> Cool, thanks!
<mamarley> ricotz: Do you mind if I go ahead and copy all those prime-EGL-supporting drivers (and the 352.79 update) to the main PPA?
<tseliot> done
<ricotz> mamarley, just copied 352
<mamarley> OK
<ricotz> mamarley, try to avoid cluttering the changelog, it is fine to summon your further changes in one entry
<ricotz> I left out the xenial prime-related updates
<mamarley> ricotz: Why did you leave out the Xenial Prime changes?  tseliot just uploaded the new versions of nvidia-prime and ubuntu-drivers-common that will make that work.
<mamarley> ricotz: Oh sorry, nevermind, you left it in for Xenial.  I was looking at the wrong version.
<mamarley> soee: Your issue with sddm not working while using the Intel graphics should now be fixed if you update from the graphics-drivers PPA.
<mamarley> soee: Your issue with sddm not working while using the Intel graphics should now be fixed if you update from the graphics-drivers PPA.
<soee> mamarley: i had system settings and prime updates - id it few minutes ago
<soee> and switched fine from intel to nvidia with relogin only
<soee> :)
<mamarley> Great!
<soee> mamarley: what was the issue ?
<mamarley> The issue was that the EGL library alternatives were not being switched when switching between cards.
<mamarley> (Which is why I asked you to remove the NVIDIA version of said alternative to work around the problem.)
<soee> and now alernatives are updated when switching profile ?
<mamarley> Yep.  Don't thank me though.  Thank tseliot, he is the one who fixed it.
<ricotz> soee, which nvidia driver series are you using?
<soee> ricotz: i always test latest :D
<soee> 361.18 atm
<ricotz> ok
<mamarley> ricotz: The 346.96 upload failures confuse me.  It is saying that the uploaded version (346.96-0ubuntu1.1~gpu16.04.2) is less than 352.63-0ubuntu1, which is an entirely different series.
<ricotz> mamarley, that is fine, 346 is obsolete for xenial anyway
<mamarley> OK.  Yeah, that's right, 352 supports all the same cards.
<ricotz> since the archive constains transitional packages it isn't easy/possible to install them
<mamarley> Should we delete the 346 packages then?
<mamarley> (For Xenial only, that is.)
<ricotz> no, they can be overridden when a new 352 release arrives while keeping the transitionals like done with 331 to 340
<ricotz> already done for xenial
<mamarley> OK
<ricotz> mamarley, jfyi, instead of 340.96-0ubuntu1.1~gpu16.04.X using 340.96-0ubuntu1+gpu16.04.X is better
<mamarley> OK, got it.  Sorry.
<ricotz> aka safer
<ricotz> mamarley, it isn't a problem just a minor note
<ricotz> mamarley, you understood my issue with your changelogs?
<mamarley> Yes, from now on I will put all the changes under the same version.
<ricotz> right, thanks
#ubuntu-x 2016-01-29
<furkan> is this troubleshooting page up to date? https://wiki.ubuntu.com/Hotkeys/Troubleshooting
<furkan> i upgraded to Ubuntu 16.04 alpha and i'm having intermittent problems with media keys (rebooting seems to fix the problem) so i was trying to find out how i could narrow down the regression
<furkan> those instructions say to kill gnome-settings-daemon before running xev, but i don't seem to have that running on my system
<furkan> well it looks like there is a unity-settings-daemon, i could try killing that
<furkan> so any thoughts about debugging my media key issue?
<furkan> i seem unable to kill unity-settings-daemon
<furkan> acpi_listener doesn't show me anything, and neither does xev (when the media keys are in their working state)
<furkan> so i'm guessing i need to figure out a way to kill unity-settings-daemon to get some output out of xev
#ubuntu-x 2016-01-30
<furkan> ok i managed to kill it, and now xev gives me output for all my special keys except for play/pause, mute, and vol up/down
<furkan> turns out if i run evtest in the background, xev can capture my volume keys
#ubuntu-x 2017-01-29
<mamarley> ricotz: I am starting to test a patch allowing the 378.09 driver to be compiled against Linux 4.10, but sadly the driver's CPU hotplug support is broken with 4.10 and no-one has figured out how to fix it, so the patch looks like it will cause PAT not to work on systems that use CPU hotplugging.
#ubuntu-x 2018-01-23
<alkisg> Hi, I'm seeing a lot of instability with the -hwe kernel in 16.04, and I'm pondering downgrading all the schools here to 4.4 instead.
<alkisg> Question, will I see severely degraded graphics performance, e.g. on haswell intels? I'm planning to keep the xorg-hwe stack... Or, anything else to worry about while downgrading to 4.4?
<alkisg> (of course I reported all the bugs that I see, both to launchpad and upstream, etc etc)
<tjaalton> no
<alkisg> Thank you tjaalton :)
<tjaalton> what kind of instability?
<alkisg> Immediate reboots, https://bugzilla.kernel.org/show_bug.cgi?id=198529, vbox crashes the HOST, page faults on stress...
<ubottu> bugzilla.kernel.org bug 198529 in x86-64 "Reboot on kernel load due to 92a0f81d" [High,New]
<tjaalton> due to meltdown?
<alkisg> Maybe; that one in bugzilla came right before meltdown
<tjaalton> it's part of the meltdown fix commits
<alkisg> It's one of the "preparation" commits, yeah
<alkisg> Maybe it'll settle down in a few months, but having the whole school not boot is a big deal for them...
<alkisg> And unfortunately "press shift for grub to appear, then boot with the previous kernel" isn't something that comes to everyone's mind...
