#ubuntu-x 2007-02-26
<Ubugtu> New bug: #87888 in xorg (main) "Correct resolution detected, but impossible to use" [Undecided,Needs info]  https://launchpad.net/bugs/87888
<Ubugtu> New bug: #46697 in xserver-xorg-video-mga (main) "I could not test out LiveCD at all" [Medium,Needs info]  https://launchpad.net/bugs/46697
<seb128> tepsipakki: hi
<tepsipakki> so, what patch have you found?
<seb128> tepsipakki: 42_build_int10_submodules.diff that you didn't apply for 'causes "some regression"' reason breaks the int10 module (undefined symbol and doesn't load)
<tepsipakki> oh yes
<seb128> what was the regression you found with it?
<tepsipakki> there was some discussion on debian-x I think
<tepsipakki> let me check
<seb128> they do apply it
<seb128> ok
<tepsipakki> could be that I just misunderstood something
<seb128> "dlopen: /usr/lib/xorg/modules//libint10.so: undefined symbol: Int10Current"
<seb128> that's the error without the patch
<tepsipakki> ok, so apply it
<tepsipakki> can't find any regression-talk about it :/
<seb128> k
<seb128> have you seen the changes I made for xorg before upload?
<Ubugtu> New bug: #87973 in xserver-xorg-video-s3 (main) "Broken legacy S3 xorg driver in feisty (Fix included)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87973
<tepsipakki> ah that
<tepsipakki> whatever works ;)
<seb128> yeah
<seb128> ok, back to the server
<seb128> update on http://people.ubuntu.com/~seb128/xorg-server/ for the source package, I'll upload deb soon for people who want to try it
<tepsipakki> upload to the archive?
<seb128> no, on the same people place
<seb128> I'll upload to the archive only when I'm confident it doesn't break for half of the world :p
<tepsipakki> yep, sure
<tepsipakki> I might try the EXA-thing on my radeon
<seb128> that's not a blocker I think
<seb128> I just had EXA enabled and I though the server was broken with radeon cards maybe
<seb128> which it was not, it works fine without EXA
<tepsipakki> so i810 doesn't work right?
<tepsipakki> we could put a new driver release for that, and see if they work together
<seb128> for dholbach
<seb128> yeah, would be nice
<seb128> the EXA problem might be https://bugs.freedesktop.org/show_bug.cgi?id=10070
<Ubugtu> Freedesktop bug 10070 in Acceleration/XAA "EXA & XAA RGB core line text performance regression" [Normal,New]  
<Treenaks> 'core line text performance'.. is that the 'gnome-terminal is slow' thing?
<seb128> no, the gnome-terminal is slow is likely to be vte because people said than drowngrading to the edgy version fixes it
<seb128> that would be nice to have somebody getting to problem looking at it
<seb128> because it's not slow on my box or not enough to be annoying
<Treenaks> seb128: I only have it on fglrx.. not my nvidia-box at work
<seb128> I use the ati driver, not evil binary one :p
<Treenaks> (also, it's the X server eating 100%, not vte/gnome-term)
<seb128> not a lot we can do on fglrx
<Treenaks> seb128: I would, if someone would fix bug 20283 :P
<Ubugtu> Malone bug 20283 in xserver-xorg-video-ati "[fgl v5000]  really bad sync" [Medium,Needs info]  https://launchpad.net/bugs/20283
<Treenaks> (but it probably depends on a rewrite of the ATOM bios parser, which is planned for Radeon/Randr1.2 work anyway)
<tepsipakki> fglrx doesn't support xorg7.2 yet
<Treenaks> tepsipakki: no, but radeon is badly broken on my hardware (see that bug)
<tepsipakki> yep, saw that
<seb128> tepsipakki: http://cvs.fedora.redhat.com/viewcvs/rpms/xorg-x11-server/devel/xorg-x11-server-1.2.0-enable-composite.patch?rev=1.1&view=markup
<seb128> what do you think about that?
<seb128> do you know why that's not the default upstream?
<seb128> tepsipakki: the previous Ubuntu package had a 019_ubuntu_enable_composite.diff
<seb128> tepsipakki: any reason you dropped it?
<tepsipakki> seb128: no.. must be a mistake :/
<seb128> tepsipakki: you dropped a lot of useful patch
<seb128> I've undropped 4 of them
<seb128> and I'm looking at others now
<tepsipakki> maybe they were lost during rename&re-merge
<seb128> tepsipakki: dunno, 7 patches dropped by mistake already though
<tepsipakki> arf
<seb128> not really fun :/
<tepsipakki> no, and it took this long to find out :I
<tepsipakki> but.. without COMPOSITE I shouldn't be able to run compiz?
<seb128> $ compiz --replace gconf
<seb128> /usr/bin/compiz.real: No composite extension
<tepsipakki> ok, so they were lost between -2ubuntu1/-3ubuntu1
<tepsipakki> damnit
<seb128> hum, in fact there might be some patches not required
<seb128> the composite one is required though
<tepsipakki> yes
<seb128> hum
<seb128> tepsipakki: ok, I got pretty confused by your renaming
<tepsipakki> oh!
<tepsipakki> ? rather
<seb128> it made harder to compare the list of patches
<seb128> well, I looked at the patches from previous packages and they were not there to the new package
<seb128> like 38_Fix-pDRIPriv_NULL_deref.patch
<seb128> it was not obvious that 124_fix-pdripriv_null_deref.patch was the same one
<tepsipakki> hmm, ok
<seb128> well, by readin the name it makes sense, from a quick look to the patches lsit no
<tepsipakki> true
<seb128> the only changes I made over your packages for the moment are to enable the 42_build_int10_submodules.diff
<seb128> and undrop the enable composite one
<tepsipakki> I'll check the others
<tepsipakki> for validity
<seb128> thank you
<tepsipakki> no, thank you ;)
<seb128> I think we should be mostly good one we have composite again
<seb128> s/one/once
<tepsipakki> yep
<tepsipakki> seb128: patches 005, 011, 012 are applied upstream
<tepsipakki> 009 is at least partly upstream, and not anymore in fedoras package
<seb128> k
<tepsipakki> 013 doesn't seem to be necessary anymore (and doesn't apply as-is)
<tepsipakki> 015, 016, 017 upstream
<seb128> I think that the update is ready for upload
<seb128> we got some people who tested it
<seb128> Debian has the package as well and not world breakage
<tepsipakki> 018 the same as with 013, not needed anymore
<tepsipakki> seb128: ok, rock
<tepsipakki> so, 019 was the only dropped patch by mistake, phew
<seb128> would have made the bling addicts not happy ;)
<seb128> I'll try the server on my laptop (i810) and upload after lunch if nobody has an objection
<tepsipakki> actually there was someone on the meta-bug who commented that compiz didn't work anymore..
<tepsipakki> but that didn't wake me up
<tepsipakki> seb128: I wonder if we should take some patches from fedora (which are fixes from upstream)
<seb128> I've looked at them
<seb128> I want to get xorg-server uploaded today
<seb128> I'll do bug fixing, and you are welcome to participate, then
<tepsipakki> yep, those can be added later
<seb128> would be nice to look at drivers updates now
<seb128> do you know if debian-x is working on those?
<seb128> maybe we can start with simple ones (not i810, ati or nvidia)
<tepsipakki> yes
<tepsipakki> I mean, yes we can start with those :)
<tepsipakki> experimental hasn't had an upload against 7.2 yet
<seb128> do you know where are upstream tarballs for those?
<tepsipakki> http://ftp.x.org/pub/individual/driver/
<tepsipakki> for instance
<seb128> there is no drivers update for 7.2 then?
<seb128> only i810, vmware and wsfb have tarballs from 2007 
<tepsipakki> that's right
<seb128> ok, so once the server is uploaded we are basically done with xorg 7.2 update? ;)
<tepsipakki> well, maybe the input-drivers?
<tepsipakki> sorry
<tepsipakki> no updates there either..
<tepsipakki> need to look more closely..
<tepsipakki> there are some updates, like -input-mouse and -keyboard
<tepsipakki> also some of the drivers have minor updates since our current versions
<seb128> ok, let's look at those then
<seb128> there is a xserver-xorg-input-mouse 1.2.1 upstream and fedora has it for some time
<seb128> we have 1.1.1
<seb128> do you have any idea of why Debian didn't update it?
<seb128> there is an 1.1.2 also
<tepsipakki> no idea..
<tepsipakki> jcristau: ping?
<seb128> tepsipakki: I'm looking at the input mouse update
<tepsipakki> seb128: ok, I'll take a look at evdev
<seb128> cool
<seb128> xserver-xorg-input-mouse has almost no change
<tepsipakki> 1.1.1 vs 1.1.2 or 1.2.0?
<seb128> 1.1.1 against 1.2.1
<seb128> diffstat has 30 lines of code changes
<tepsipakki> pretty mild :P
<seb128> http://paste.ubuntu-nl.org/7638/
<seb128> do you know when the ABI_XINPUT_VERSION changed?
<seb128> hw/xfree86/common/xf86Module.h:#define ABI_XINPUT_VERSION       SET_ABI_VERSION(0, 7)
<tepsipakki> no I don't ..
<tepsipakki> so it hasn't changed yet?
<seb128> doesn't really mater, the source do an else if for that
<Ubugtu> New bug: #87954 in xorg (main) "Edgy glxgears error - libGL warning: 3D driver claims to not support visual 0x4b" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87954
<tepsipakki> what a lovely bugreport
<tepsipakki> tons of output and of course not in attachments
<tepsipakki> besides a bogus one
<tepsipakki> +being
<seb128> tepsipakki: ok, BTW, do you know why the package doesn't ship utils like 
<seb128> dh_install: debian/tmp/usr/bin/pcitweak exists in debian/tmp but is not installed to anywhere
<seb128> dh_install: debian/tmp/usr/bin/scanpci exists in debian/tmp but is not installed to anywhere
<seb128> dh_install: debian/tmp/usr/bin/xorgconfig exists in debian/tmp but is not installed to anywhere
<seb128> it used to ship scanpci
<tepsipakki> xorg-server?
<seb128> tepsipakki: yep
<seb128> tepsipakki: http://paste.ubuntu-nl.org/7643/
<seb128> most are probably not useful, scanpci could be though, no?
<tepsipakki> maybe so
<tepsipakki>   * Ship again ioport, gtf, pcitweak and scanpci.
<tepsipakki>  -- Fabio M. Di Nitto <fabbione@ubuntu.com>  Tue, 04 Apr 2006 16:33:00 +0200
<seb128> ah
<seb128> I'll modify the package to ship them then
<tepsipakki> maybe that has been dropped some time
<tepsipakki> by accident or so
<seb128> well, dropped by your merge
<tepsipakki> really?
<tepsipakki> hrm
<seb128> $ debdiff /var/cache/apt/archives/xserver-xorg-core_1%3a1.1.1-0ubuntu14_i386.deb xserver-xorg-core_1.2.0-3ubuntu1_i386.deb
<seb128> ...
<seb128> Files in first .deb but not in second
<seb128> -------------------------------------
<seb128> ...
<seb128> -rwxr-xr-x  root/root   /usr/bin/gtf
<seb128> -rwxr-xr-x  root/root   /usr/bin/ioport
<seb128> -rwxr-xr-x  root/root   /usr/bin/pcitweak
<seb128> -rwxr-xr-x  root/root   /usr/bin/scanpci
<tepsipakki> right..
<tepsipakki> sigh, I'll make another check for xorg-server and see if there is anything else missing
<tepsipakki> eh, 381000 lines in the debdiff
<tepsipakki> ok maybe I'll just filter anything _not_ in debian/ :I
<seb128> tepsipakki: don't bother, I think we are fine now
<seb128> you checked the patches already
<seb128> and a debdiff and dh_install --list-missing caught those
<seb128> I'll upload rsn
<tepsipakki> ok, thanks
<tepsipakki> no word from Mithrandir yet, though?
<seb128> no
<seb128> I'll upload anyway if he doesn't reply
<seb128> the new build is done
<seb128> rebooting, if that works I'll upload
<seb128> hum
<seb128> the server upgrade broke xorg on my laptop
<tepsipakki> oh..
<seb128> /usr/share/X11/fonts was existing and a real directoru
<seb128> directory
<seb128> from january 2006
<tepsipakki> ah
<tepsipakki> what package made it?
<seb128> I might have changed things by hand for an xorg problem or something
<tepsipakki> ok :)
<seb128> none, there was nothing own by a package there
<seb128> only font caches and the dir
<seb128> but since the new server doesn't look to /usr/share/fonts/X11
<seb128> it was failing on the "doesn't find fixed font" problem
<seb128> anyway nobody else complained about that
<tepsipakki> there should be a symlink made by xorg
<tepsipakki> -update
<seb128> the symlink didn't work because there was a real dir
<tepsipakki> true
<seb128> I'll upload anyway, I might have changed things by hand
<seb128> and if that's not the case we can track it
<tepsipakki> though it's silly that the server doesn't look there by default
<seb128> it worked for the other people who tried
<seb128> maybe we should patch it for that?
<tepsipakki> yes maybe
<seb128> anyway going to upload the server now if nobody is against it, we need to get that done
<tepsipakki> go ahead
<tepsipakki> hah, --with-default-font-path doesn't have the path for fixed
<tepsipakki> rest is there
<tepsipakki> maybe there's a reason, dunno
<tepsipakki> actually, we used to have --with-fontdir=/usr/share/fonts/X11
<tepsipakki> and Debian changed that some time ago
<seb128> tepsipakki: what do you think about http://cvs.fedora.redhat.com/viewcvs/rpms/xorg-x11-server/devel/xorg-x11-server-1.1.1-builtin-fonts.patch?rev=1.1&view=log ?
<Ubugtu> New bug: #22373 in linux-restricted-modules-2.6.15 (restricted) "cant run fgl_glxgears" [Medium,Unconfirmed]  https://launchpad.net/bugs/22373
<tepsipakki> --enable-kdrive is set, and so should KDRIVESERVER be as well
<tepsipakki> but maybe I'm missing something
<tepsipakki> ah, maybe it is set for kdrive and _only_ kdrive
<tepsipakki> so using that patch uses the fallback for all servers
<seb128> I'll try if that fixes the "xorg doesn't start when the symlink is not made" problem
<tepsipakki> cool
<tepsipakki> seems that fedora has used it for quite a while
<seb128> and then I'll upload
<tepsipakki> ok, I'm going to sauna now.. maybe that'll beat this frigging flu as well :P
<tepsipakki> I'll come back later ->
<seb128> tepsipakki: doesn't fix the login without the correct font directory, I'm uploading without that
<tepsipakki> seb128: ok
<seb128> tepsipakki: I uploaded like half an hour ago but not sign of the upload, I probably screwed something, dunno what I didn't get mail yet
<tepsipakki> heh
<tepsipakki> seb128: fedora has "--with-default-font-path="unix/:7100,built-ins", so maybe that's why the patch (alone) didn't work 
<seb128> ah, probably
<seb128> xorg-server upload accepted BTW
<tepsipakki> whee
<seb128> the first one was rejected because the email was not correct
<seb128> "Ubuntu Core Developers <ubuntu-devel-discuss at lists.ubuntu.com>: no @ found in email address part."
<tepsipakki> ah, that again :/
<tepsipakki> had the same problem with xorg
<tepsipakki> there were some xgettext problems because of that :)
<tepsipakki> I copied those from some feisty-changes post, so no wonder it didn't work
<seb128> it's fixed anyway
<seb128> I'm away for ~2 hours
<seb128> time for the server to build and be available
<tepsipakki> yeah
<tepsipakki> thanks
<seb128> I'll look at bugs and breakages reported then
<tepsipakki> I'll monitor them as well
<seb128> bbl
<seb128> cool, thank you
<jcristau> tepsipakki: pong
<jcristau> (just got back from brussels)
<tepsipakki> hi.. I've already forgot what it was :)
<tepsipakki> but when I remember, I'll ping you again :)
<jcristau> ok :)
<tepsipakki> oh yes, the 42_build_int10_submodules.diff.. IIRC you said once that it causes some regression, but I can't find anything related on debian-x list
<Ubugtu> New bug: #88093 in xorg (main) "strange colors all over the screen" [Undecided,Needs info]  https://launchpad.net/bugs/88093
<jcristau> tepsipakki: #410879
<seb128> jcristau: hi
<jcristau> hi seb128 
<seb128> jcristau: without it the int10 module can't be used (missing symbol)
<jcristau> seb128: did you autoreconf?
<seb128> no, just the package update made by tepsipakki dropped the patch
<seb128> I made the package use it again
<seb128> jcristau: and any opinion on http://cvs.fedora.redhat.com/viewcvs/rpms/xorg-x11-server/devel/xorg-x11-server-1.1.1-builtin-fonts.patch?rev=1.1&view=markup ? 
<jcristau> not really
<seb128> the font path changes and if for whatever reason the new path is not made available xorg doesn't start, would be nice to get it robust to that problem
<jcristau> fair enough
<seb128> did Debian change from /usr/share/fonts/X11 to /usr/share/X11/fonts also or is that Ubuntu specific?
<tepsipakki> seb128: other way around
<seb128> tepsipakki: hum
<tepsipakki>  /usr/share/fonts/X11 is what we use now ;)
<seb128> why do we need the /usr/share/X11/fonts symlink then?
<jcristau> debian sarge has /usr/lib/X11/fonts, or /usr/X11R6/lib/something, IIRC
<jcristau> so we never released with /usr/share/X11/fonts
<tepsipakki> seb128: the old configs have that
<seb128> ah right, for configs not update
<seb128> updated
<seb128> makes sense yep
<tepsipakki> but I guess adding fixed to "--with-default-font-path" would solve this as well
<tepsipakki> jcristau: do you know why debian changed --with-fontdir to --with-default-font-path ?
<jcristau> no
<tepsipakki> fedora uses both \o/
<tepsipakki> umm
<tepsipakki> --with-default-font-path="/usr/share/fonts/X11/misc,/usr/X11R6/lib/X11/fon
<tepsipakki> ts/misc,/usr/share/fonts/X11/cyrillic,/usr/share/fonts/X11/100dpi/:unscaled,/usr/share/font
<tepsipakki> s/X11/75dpi/:unscaled,/usr/share/fonts/X11/Type1,/usr/X11R6/lib/  X11/fonts/Type1,
<tepsipakki> damn
<tepsipakki> the point was that there is whitespace between "/usr/X11R6/lib/" and "X11/fonts/Type1"
<tepsipakki> wonder why
<Ubugtu> New bug: #51775 in xserver-xorg-input-mouse (main) "Logitech usb mouse random freezes" [Undecided,Needs info]  https://launchpad.net/bugs/51775
#ubuntu-x 2007-02-27
<Ubugtu> New bug: #87729 in xorg-server (main) "ATI 9800 XT - screen resolutions above 1280x1024 are distorted" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87729
<Ubugtu> New bug: #87750 in xorg (main) "Live CD 6.10 Resolution-change problem" [Undecided,Needs info]  https://launchpad.net/bugs/87750
<Ubugtu> New bug: #83706 in xorg (main) "The video dual head on VGA port not work in notebook sony vaio" [Undecided,Needs info]  https://launchpad.net/bugs/83706
<Ubugtu> New bug: #88240 in libx11 (main) "/usr/lib/libX11.a: could not read symbols: Malformed archive" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88240
<Ubugtu> New bug: #50042 in xorg (main) "X-server crashes on login" [Undecided,Needs info]  https://launchpad.net/bugs/50042
<Ubugtu> New bug: #88254 in xorg (main) "xserver fails to start with ATI Radeon Xpress 200M (since XOrg 7.2 update?)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88254
<tepsipakki> seb128: good morning ;)
<seb128> hi
<tepsipakki> bug 88254
<Ubugtu> Malone bug 88254 in xorg "xserver fails to start with ATI Radeon Xpress 200M (since XOrg 7.2 update?)" [Undecided,Confirmed]  https://launchpad.net/bugs/88254
<tepsipakki> the description is not right, but we'll get those more, I guess
<tepsipakki> ie. missing "FontPath /usr/share/fonts/X11/misc" from xorg.conf
<Ubugtu> New bug: #88311 in xorg-server (main) "upgrade to 1.2.0-3ubuntu1 killed X" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88311
<tepsipakki> and that's a dupe
<seb128> I commented on the dup already
<tepsipakki> oops
<seb128> https://bugs.beta.launchpad.net/ubuntu/+source/libx11/+bug/88240
<Ubugtu> Malone bug 88240 in libx11 "/usr/lib/libX11.a: could not read symbols: Malformed archive" [Undecided,Unconfirmed]  
<seb128> interesting one
<tepsipakki> ah that
<Ubugtu> New bug: #22995 in xorg (main) "xserver-xorg fails on ATI Radeon X700" [Medium,Fix released]  https://launchpad.net/bugs/22995
<Ubugtu> New bug: #88318 in xorg (main) "could not open default font 'fixed'" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88318
<Ubugtu> New bug: #40021 in xserver-xorg-input-synaptics (main) "Synaptics side scroll is disable by default on Dell Inspiron6400" [Medium,Needs info]  https://launchpad.net/bugs/40021
<tepsipakki> woohoo, the "debian_always_use_default_fontpath" -patch did the trick
<tepsipakki> in the logs I can see the entries specified in --with-default-font-path after the ones from the config
<Ubugtu> New bug: #25097 in libx11 (main) "Mathematica does not work (doesn't find XKeysymDB, X11 locales)" [Medium,Rejected]  https://launchpad.net/bugs/25097
<Ubugtu> New bug: #21829 in xfonts-core (main) "X server fails to start: "could not open default font 'fixed'"" [High,Fix released]  https://launchpad.net/bugs/21829
<Ubugtu> New bug: #42385 in xserver-xorg-video-ati (main) "Driver hangs my laptop (Mobility Radeon 7000 IGP) (dup-of: 15219)" [Medium,Unconfirmed]  https://launchpad.net/bugs/42385
<Ubugtu> New bug: #88340 in Ubuntu "[feisty]  x server wont start after upgrade (dup-of: 21829)" [Undecided,Needs info]  https://launchpad.net/bugs/88340
<Ubugtu> New bug: #54412 in linux-restricted-modules-2.6.15 (restricted) "Screen stretched vertically to double size, only top half visible in TV out." [Undecided,Unconfirmed]  https://launchpad.net/bugs/54412
<Ubugtu> New bug: #55570 in xserver-xorg-video-ati (main) "ThinkPad X32 freezes often after upgrading to dapper" [Undecided,Unconfirmed]  https://launchpad.net/bugs/55570
<tepsipakki> seb128: oh you did the -input-mouse merge? I have -input-evdev ready and -kbd almost there
<tepsipakki> ok, input-drivers should be done
<tepsipakki> elographics can be synced
<seb128> tepsipakki: do you have your merges at the usual place?
<tepsipakki> yes
<tepsipakki> evdev would be syncable as well if 1.1.5 was in experimental
<tepsipakki> keyboard has that one patch for korean layouts
<tepsipakki> I guess many of the video-drivers can be synced as well
<seb128> did you look at new version or only synced with Debian?
<tepsipakki> looking at the MoM
<seb128> ok
<seb128> I'll look at those tonight
<tepsipakki> ok
<tepsipakki> oh crap, the drivers can't be synced, since there is Conflicts:/Replaces: xserver-xorg-driver-$DRIVER in every one of them
<tepsipakki> although, maybe that can be dropped
<seb128> probably not
<seb128> dapper use that naming
<seb128> and we want upgrade from dapper working
<tepsipakki> well, maybe after the next LTS version :)
<Ubugtu> New bug: #57803 in xpdf "fonts do not diplay when run in X" [Undecided,Unconfirmed]  https://launchpad.net/bugs/57803
<Ubugtu> New bug: #88482 in xorg (main) "Xserver-xorg doesn't recognize my ATI card anymore" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88482
<Ubugtu> New bug: #54191 in xorg (main) "Mouse button click delayed" [Undecided,Unconfirmed]  https://launchpad.net/bugs/54191
<Ubugtu> New bug: #88505 in xorg (main) "[feisty]  xorg 7.2 doesn't work with fglrx" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88505
<Ubugtu> New bug: #88522 in xorg-server (main) "Font error causes xorg server to crash (xorg 7.2 Feisty)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88522
#ubuntu-x 2007-02-28
<Ubugtu> New bug: #88552 in linux-restricted-modules-2.6.15 (restricted) "fcpci module cannot be loaded" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88552
<Ubugtu> New bug: #88568 in xorg (main) "regression: firefox, liferea, epiphany cause xorg to peg CPU usage (ati)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88568
<Ubugtu> New bug: #88585 in xf86dga (main) "dga corrupts its pagetable" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88585
<seb128> tepsipakki: evdev 1.1.5, not sure that's a good idea
<seb128> "Merge branch 'input-hotplug'"
<tepsipakki> well.. we could do 1.4.1 which was for 7.2 IIRC
<seb128> 1.1.4 you mean?
<tepsipakki> oh
<tepsipakki> yes
<seb128> FC current has 1.1.2
<tepsipakki> they're just lazy
<tepsipakki> :P
<seb128> I think we shouldok
<seb128> looks like they merged input-hotplug for 1.1.4
<seb128> maybe 1.1.3 is for 7.2
<tepsipakki> uh, no.. 1.1.2 is
<seb128> where do you see that?
<tepsipakki> http://ftp.x.org/pub/X11R7.2/src/driver/
<seb128> ok, let's sync from Debian there
<seb128> I mean merge with Debian
<tepsipakki> yes
<seb128> there have 1.1.2 also with some patches
<tepsipakki> yes, I'll merge it
<tepsipakki> it's pretty trivial
<seb128> thank you
<seb128> same for keyboard, 1.2.0 has lot of changes
<seb128> and 7.2 tarballs list has 1.1.1
<seb128> we should better stick to that one
<tepsipakki> mind if I rename that "enable-composite" patch so that our patches all are 1xx?
<tepsipakki> I'm doing the debdiff now
<tepsipakki> seems that debian could be enabling it themselves soon
<seb128> not at all
<seb128> we should probably have all of the Ubuntu patches with a different numbering
<seb128> to make easy to know which one come from Debian or Ubuntu
<seb128> BTW http://xorg.freedesktop.org/wiki/ModuleVersionsInXorgReleases
<seb128> evdev 1.1.5 is listed for 7.2
<tepsipakki> oh
<tepsipakki> damn them ;)
<tepsipakki> for confusing poor little integrators
<tepsipakki> btw, most of the patches already are numbered correctly, the 001_something is also in debian, so I've left it alone
<seb128> ah ok
<seb128> I'm sorting that evdev question with daniels
<tepsipakki> there. a plea to accept the enable-composite-patch sent to debian-x
<tepsipakki> and not to mess with xorg.conf
<seb128> how mess with xorg.conf?
<tepsipakki> in the postinst..
<tepsipakki> debian bug #412069
<Ubugtu> Debian bug 412069 in xserver-xorg "patch for beryl support" [Wishlist,Open]  http://bugs.debian.org/412069
* Starting logfile irclogs/ubuntu-x.log
<tepsipakki> -input-keyboard merge done
<seb128> k
<tepsipakki> the only change compared to 1.1.1 is in the patch from debian
<Ubugtu> New bug: #88424 in xorg (main) "Geforce Go 7950 GTX SLI is not detected properly." [Undecided,Needs info]  https://launchpad.net/bugs/88424
<Ubugtu> New bug: #88639 in xresprobe (main) "refresh rates not set for Thinkpad A21p" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88639
<tepsipakki> I merged video-ati
<seb128> rock on ;)
<Ubugtu> New bug: #88644 in xserver-xorg-video-vmware (main) "Upgrade to 10.15 for significant performance increase." [Undecided,Unconfirmed]  https://launchpad.net/bugs/88644
<Ubugtu> New bug: #51552 in xorg (main) "Can't set mouse speed (only acceleration and treshold)" [Undecided,Confirmed]  https://launchpad.net/bugs/51552
<seb128> tepsipakki: do we need to keep the previous debian/changelog Ubuntu entries?
<Treenaks> tepsipakki: about the fglrx / X 7.2 thing.. does this mean fglrx won't work for feisty?
<seb128> Treenaks: it doesn't work for you?
<seb128> tepsipakki: xserver-xorg-input-keyboard uploaded
<Treenaks> seb128: I haven't tried, but I keep reading 'fglrx doesn't work with X7.2!' everywhere (blogs, news posts)
<tepsipakki> seb128: no we don't, I just used grab-merge for siplicity
<seb128> Treenaks: it works for me
<seb128> I tried before updating the server
<Treenaks> seb128: ok.. I'll stop worrying :)
<tepsipakki> maybe ATI will release a new driver soonish that is "certified" for 7.2
<seb128> we got bug #88505 about that though
<Ubugtu> Malone bug 88505 in linux-restricted-modules-2.6.20 "[feisty]  xorg 7.2 doesn't work with fglrx" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88505
<tepsipakki> maybe that's with legacy
<tepsipakki> isn't the version 8.3x.x now?
<seb128> dunno
<tepsipakki> check what you have :)
<seb128> 8.33.6
<tepsipakki> there you go
<tepsipakki> either he is doing something silly, or runnin fglrx-legacy which doesn't work with 7.2 and never will
<seb128> fglrx-legacy? you mean binaries from upstream?
<tepsipakki> yes
<seb128> let me restart with fglrx to make sure it works fine
<Treenaks> *insert sound of seb128 cursing X*
<Treenaks> *in French*
<tepsipakki> "sacr bleu!"
<seb128> ok, works fine
<tepsipakki> good
<seb128> hum, another lock problem: bug #88657
<Ubugtu> Malone bug 88657 in mesa "[apport]  compiz.real crashed with SIGSEGV in savageGetLock()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88657
<seb128> to mesa that time
<Ubugtu> New bug: #88657 in mesa (main) "[apport]  compiz.real crashed with SIGSEGV in savageGetLock()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88657
<seb128> ok, that one is not new
<seb128> was happening with libx11 1.0.3 already
<tepsipakki> good :)
<Ubugtu> New bug: #81889 in mesa (main) "[apport]  compiz.real crashed with SIGSEGV in savageGetLock()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81889
<Ubugtu> New bug: #88659 in compiz (main) "[apport]  compiz.real crashed with SIGSEGV in savageGetLock() (dup-of: 81889)" [Medium,Rejected]  https://launchpad.net/bugs/88659
<Ubugtu> New bug: #88670 in xorg-server (main) "graphics card has wrong resolution and no acceleration" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88670
<Ubugtu> New bug: #88678 in xorg (main) "New tab crashes both gnome-terminal and xfce4-terminal" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88678
<Ubugtu> New bug: #88691 in xorg (main) "Dim LCD backlight on boot" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88691
<Ubugtu> New bug: #88692 in xorg (main) "Touchpad not fully functional" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88692
<Ubugtu> New bug: #88696 in xorg-server (main) "EXA broken" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88696
<Ubugtu> New bug: #88707 in xorg (main) "[feisty]  xorg fails to start with composite enabled" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88707
<Ubugtu> New bug: #88708 in mesa (main) "feisty: Assertion `c->xlib.lock' failed for all gl apps" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88708
<borg_> help :)
<borg_> my x doesnt start
<borg_> it say /dev/wacom not found
<borg_> (feisty)
<borg_> ok
<borg_> the last update fixed it ;)
<Ubugtu> New bug: #88741 in xorg-server (main) "mergedfb doesn't work with xserver-xorg-core 2:1.2.0-3ubuntu1 (or newer)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88741
<Ubugtu> New bug: #88589 in compiz (main) "gtk-window-decorator does not display borders" [Undecided,Confirmed]  https://launchpad.net/bugs/88589
<Ubugtu> New bug: #88763 in xserver-xorg-input-evdev (main) "evdev manual page is nonsensical" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88763
<tepsipakki> seb128: how about adding these to the ati-driver http://lists.freedesktop.org/archives/xorg/2007-February/022148.html
<seb128> tepsipakki: looks like a good idea
<tepsipakki> there are lots of bugs about dropping to vesa when the driver should support the device just fine..
<seb128> what do you mean?
<seb128> what drop to vesa?
<tepsipakki> hmm
<tepsipakki> nevermind
<tepsipakki> oh
<tepsipakki> right
<tepsipakki> I mean that the server doesn't find a suitable driver for it.. but that's a bug in discover, really
<tepsipakki> there are gray areas regarding the configuration phase ;)
<Ubugtu> New bug: #88772 in xorg (main) "X/radeon in feisty breaks ppc/ati external dvi/vga output" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88772
#ubuntu-x 2007-03-01
<Ubugtu> New bug: #49138 in xorg (main) "Dell GX620 + ATI Radeon X600 SE" [Medium,Confirmed]  https://launchpad.net/bugs/49138
<Ubugtu> New bug: #88815 in xorg-server (main) "Sluggish rendering since xorg 7.2 update" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88815
<tepsipakki> seb128: morning, I'm continuing the driver merges.. apm, ark, chips, cirrus now done
<seb128> tepsipakki: hi
<seb128> tepsipakki: ups :/
<tepsipakki> you've done them?-)
<seb128> tepsipakki: I did apm and ark yesterday, they are uploaded and blocked by freeze
<tepsipakki> oh, that's ok, they are trivial
<seb128> right
<seb128> they just have the Conflicts, Replaces for Ubuntu and the Maintainer change
<tepsipakki> yep
<seb128> looking at chips
<tepsipakki> it's not in the-usual-place yet
<seb128> ah ok
<tepsipakki> did you change the Provides: -field (s/-1.0//)?
<tepsipakki> I guess now could be a chance to get rid of that delta if we are going to upload all the drivers anyway
<tepsipakki> ie. drivers provide xserver-xorg-video-1.0 (=ABIVER), and the server depends on xserver-xorg-video-1.0
<seb128> no I didn't
<seb128> do we need to?
<tepsipakki> if we didn't upload them all at once and keep the debian versioning, yes
<tepsipakki> but imho we should go with debian ;)
<seb128> well, what is that Provides useful for atm?
<tepsipakki> xserver-xorg-core Depends on xserver-xorg-video
<seb128> no, it doesn't
<tepsipakki> well, something does :)
<tepsipakki> can't check now
<seb128> Depends: x11-common (>= 1:7.0.0), libc6 (>= 2.5-0ubuntu1), libdrm2 (>= 2.3.0), libfontenc1, libgcc1 (>= 1:4.1.2), libxau6, libxdmcp6, libxfont1, xserver-xorg
<tepsipakki> xserver-xorg maybe
<seb128> before update
<seb128> Depends: x11-common (>= 1:7.0.0), xserver-xorg-video-all | xserver-xorg-video, xserver-xorg-input-all | xserver-xorg-input, libc6 (>= 2.4-1), libfontenc1, libgcc1 (>= 1:4.1.1-12), libxau6, libxdmcp6, libxfont1, zlib1g (>= 1:1.2.1)
<seb128> did you drop that on purpose?
<tepsipakki> is that from xserver-xorg-core?
<seb128> yep
<tepsipakki> hmm
<tepsipakki> I'll check
<seb128> that's xserver-xorg
<seb128> Depends: xserver-xorg-core, xserver-xorg-video-all | xserver-xorg-video, xserver-xorg-input-all | xserver-xorg-input, debconf (>= 0.5) | debconf-2.0, xkb-data | xkb-data-legacy, xbase-clients
<tepsipakki> ok, so that covers it
<seb128> we install xserver-xorg-video-all anyway
<seb128> so we update all the drivers to provide xserver-xorg-video-1.0 and update xserver-xorg then?
<tepsipakki> yes
<tepsipakki> then we should be ok
<seb128> maybe we can use xserver-xorg-video-all | xserver-xorg-video | xserver-xorg-video-1.0
<tepsipakki> that would work during the transitional phase
<tepsipakki> then we wouldn't need to upload all the drivers at the same time
<seb128> right
<tepsipakki> the old ati-driver had a Replaces/Conflicts with xserver-xorg-driver-atimisc which has never been in Ubuntu AFAICT
<tepsipakki> so I dropped that delta
<tepsipakki> nor was there any mention in the changelog about it
<seb128> ok
<Ubugtu> New bug: #48773 in linux-source-2.6.17 (main) "Mouse doesn't get turned off on system shutdown" [Medium,Unconfirmed]  https://launchpad.net/bugs/48773
<Ubugtu> New bug: #88918 in xserver-xorg-video-i810 (main) "Request: sync new agpgart & drm modules for 50% DRI performance boost with Intel users" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88918
<Ubugtu> New bug: #5801 in xserver-xorg-video-nv (main) "(NVidia only) Wrong default and maximum resolution on widescreen monitor (stretched 1024x768) on GeForce 6200" [Medium,Needs info]  https://launchpad.net/bugs/5801
<Ubugtu> New bug: #20168 in xorg (main) "[radeon/rv280]  crash at startup" [Medium,Confirmed]  https://launchpad.net/bugs/20168
<Ubugtu> New bug: #88955 in xorg (main) "S3 trio 3D/2X video problems" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88955
<tepsipakki> ok nv done, that makes 16 drivers..
<tepsipakki> 21 to go
<seb128> you did merge 16 of them already?
<tepsipakki> yes
<tepsipakki> and some updates
<tepsipakki> like i810, nv
<crimsun> tepsipakki: we should reject the mesa portion of 88918, no?
<tepsipakki> bug 88918
<Ubugtu> Malone bug 88918 in linux-source-2.6.20 "Request: sync new agpgart & drm modules for 50% DRI performance boost with Intel users" [Wishlist,Confirmed]  https://launchpad.net/bugs/88918
<crimsun> I'm not sure why -i810's there, either
<tepsipakki> yes, I think we just need the kernel to have newer drivers
<crimsun> (unless it's for an UVFe for -i810?)
<tepsipakki> I don't think UVF
<tepsipakki> 's are needed
<tepsipakki> ;)
<tepsipakki> not quite yet anyway
<crimsun> right, I thought it was a special case anyhow
<crimsun> ok, rejected the mesa and -i810 tasks
<tepsipakki> thanks
<tepsipakki> ok, drivers up to and including sunffb done
<tepsipakki> ten remains
<tepsipakki> now home ->
<seb128> they are at the usual place?
<Ubugtu> New bug: #27508 in xorg (main) "Only 60 Hz display refresh available" [Low,Needs info]  https://launchpad.net/bugs/27508
<tepsipakki> seb128: not yet, I need to copy them there first
<Ubugtu> New bug: #88998 in xserver-xorg-video-ati (main) "Please upgrade to xorg 7.2 versions" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88998
<tepsipakki> I'll put the drivers available tomorrow all at once
<tepsipakki> need to make sure they are ok first
<seb128_> ok
<seb128_> archive is frozen anyway
<kylem> tepsipakki, ping me, i can help review if colin says it's ok.
<cjwatson> kylem: please do
<kylem> ok.
<tepsipakki> manpower is needed, since there are 41 drivers ;)
<tepsipakki> most of them are trivial
<tepsipakki> should be synced if we could
<kylem> i imagine very few of them changed
<tepsipakki> true, but I've merged them all with debian
<seb128_> yeah, most of them are syncs from Debian with no new version for xorg 7.2, just Conflicts,Replaces for Ubuntu
<tepsipakki> some minor updater here and there
<kylem> that's fine
<tepsipakki> updates
#ubuntu-x 2007-03-02
<Ubugtu> New bug: #11743 in linux-restricted-modules-2.6.15 (restricted) "nvidia-glx-config suggests invalid command" [Undecided,Unconfirmed]  https://launchpad.net/bugs/11743
<Ubugtu> New bug: #89024 in xorg (main) "glxinfo error. ati 9600pro" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89024
<Ubugtu> New bug: #88938 in xorg (main) "Dell Dimension fan always at full speed" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88938
<tepsipakki> ok, drivers done
<tepsipakki> need to put them on display
<tepsipakki> there
<tepsipakki> http://users.tkk.fi/~tjaalton/xorg72/new
<tepsipakki> as usual..
<Ubugtu> New bug: #89171 in xorg-server (main) "[apport]  Xorg crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89171
<tepsipakki> seb128: howdy, now all the drivers are at the usual place
<seb128> hi tepsipakki, good
<seb128> tepsipakki: have you seen than Debian did upload a lot of drivers package this morning and did update some to new version?
<tepsipakki> yes
<seb128> ok
<tepsipakki> doesn't matter much
<tepsipakki> I had most of these ready, so.. :)
<seb128> cool
<tepsipakki> and updated some
<seb128> did kylem work on some of them?
<seb128> like upload
<tepsipakki> for instance debian has 10.14.1 of vmware, I did 10.15 which should have better performance
<seb128> or I can pick anything to upload?
<tepsipakki> not yet
<seb128> ok, no conflict then
<tepsipakki> nope
<tepsipakki> debian has a snapshot of ati-driver, but versioned as 6.6.3 when in reality it is something like 6.6.90
<tepsipakki> after these are uploaded we can cherry pick fixes from upstream if there are any
<seb128> right
<seb128> I've planned to do a round of "what patches FC is shipping and would be nice to have" when we are uptodate ;)
<tepsipakki> yes
<tepsipakki> oh, forgot to say about the drivers.. I didn't build them, so those that had a new upstream release might need some work
<tepsipakki> saw a bugreport on debian-x about -vmware which could need some builddeps
<seb128> tepsipakki: ok, that means those got no testing yet and it could be a good idea to test new ati driver on some boxes before uploading for example? ;)
<tepsipakki> yes
<tepsipakki> well, it's the same version in debian now, but we have some patches they don't
<tepsipakki> in experimental is the snapshot version
<tepsipakki> I merged with unstable
<seb128> ok
<tepsipakki> glad I did, since the upload to experimental was broken
<seb128> will have a look now on your updates and let you know when I update something
<seb128> oh?
<tepsipakki> they used the wrong ABIVER ;)
<seb128> BTW did you spoke with them about using the Conflicts,Rename we need for Ubuntu?
<tepsipakki> -1.1 not -1.0
<tepsipakki> I mentioned it, but haven't asked for including it there
<seb128> ok
<tepsipakki> maybe that warrants an email to debian-x
<seb128> because with it we could probably just sync most of drivers from Debian
<tepsipakki> yes, current situation is so bad it makes me sick :)
<tepsipakki> otherwise we'd need to keep them until the next LTS version
<seb128> right
<seb128> which is at least one other year
<tepsipakki> and I hope exactly one year ;)
<seb128> we will see ;)
<tepsipakki> two years between LTS's would be good
<tepsipakki> thinking of the schools etc in northern hemisphere
<tepsipakki> summer is good time to do upgrades :)
<tepsipakki> mid-term is not
<Treenaks> tepsipakki: tell that to the admins of my old schools :P
<tepsipakki> Treenaks: heh
<Treenaks> (ok, that was 10 years ago.. but still :))
<tepsipakki> some just don't get it ;)
<seb128> looking the xserver-xorg-video-chips update now
<seb128> uploaded
<seb128> cirrus update uploaded
<seb128> cyrix update uploaded
<tepsipakki> whee ;)
<seb128> dummy update uploaded
<kylem> seb128, want me to start from the other end of the drivers?
<seb128> kylem: feel free to pick any you want and announce on the chan or start in the other direction, as you prefer
<seb128> I'm looking a fbdev atm
<kylem> ok
<kylem> i'll take -vmware.
<seb128> cool
<seb128> an useful one ;)
<tepsipakki> kylem: try to build it as well
<tepsipakki> it might lack builddeps
<kylem> ok.
<seb128> looking at glint
<seb128> fbdev update uploaded
<seb128> glint update uploaded
<seb128> looking at i128
<seb128> ah
<seb128> tepsipakki: i128, Debian has updated to 1.2.1 the xog 7.2 version, I'm syncing on them, or there is a reason you didn't update the version?
<kylem> seb128, you just looking/testing then debsigning?
<kylem> or are you regenerating src packages
<tepsipakki> seb128: I think I checked that there were no real code changes between them
<kylem> tepsipakki, -vmware needs xinerama proto, added, (i'll leave your changes entry tho)
<seb128> kylem: yes, looking, building to be sure it doesn't ftbfs and then signing and uploading the version downloaded
<kylem> ok.
<seb128> kylem: you can dch -r, it'll add you name for the entry and 
<seb128> [ name from entry before dch ] 
<seb128> * changes corresponding
<kylem> seb128, ah, yeah, forgot about that. thanks.
<seb128> np
<tepsipakki> heh, I had to get a newer i810 so that Lenovo TC M55 could get X up.. it works :)
<tepsipakki> meaning that I just built i810 and it seems to work at least on that hardware
<tepsipakki> seb128: experimental seems to be a bit mixed up now with the abiver-hassles
<kylem> we should really rename that to -intel, but it's probably too late for that for feisty.
<kylem> since they renamed it upstream.
<tepsipakki> kylem: yes, with modesetting-branch
<seb128> tepsipakki: yeah, I'll not grab those changes
<tepsipakki> I think it can still be done
<kylem> they released modesetting?
<tepsipakki> but later
<tepsipakki> don't know
<kylem> warning, `debian/xserver-xorg-video-vmware/DEBIAN/control' contains user-defined field `Original-Maintainer'
<tepsipakki> kylem: ^^
<kylem> fixed that too.
<tepsipakki> hah
<kylem> oh.
<kylem> you already did.
<tepsipakki> bad copypaste
<kylem> uhh.
<seb128> that's not an error, is it?
<seb128> that's the new XSBC-Original-Maintainer thing, no?
<tepsipakki> maybe so
<tepsipakki> I tried to be careful but there could be errors such as that
<kylem> seb128, i don't recall seeing a warning for having it.
<seb128> I think I've seen that on several builds, I though that was normal
<seb128> let me know if you find anything wrong though ;)
<kylem> seb128, this is a dumb question i should already know, is it normal to have to specify -sa?
<seb128> kylem: if it's ubuntu versionned yes
<kylem> ok
<seb128> we should probably patch the magic to include source for -0ubuntu1
<seb128> as it does for -1
<kylem> vmware uploaded
<kylem> working on via
* kylem needs a local mirror. hehe.
<seb128> i128 uploaded
<seb128> looking at i740
* kylem spanks tepsipakki.
<kylem> UploadError escaped upload.process: Unable to find distrorelease: unstable
<seb128> arg
* seb128 fixes uploads
<seb128> I didn't check that
<kylem> reuploading vmware
<seb128> BTW if you rebuild the source to change that use -v on the debian version we synced previously
<seb128> so the .changes has the debian changes we are syncing
<kylem> ok
<seb128> i128 reuploaded
<kylem> via uploaded
<kylem> vga now
<seb128> i740 uploaded
<seb128> skeeping i810 for now, doing easy ones first
<seb128> looking at imstt
<kylem> what do we call the "unstable;" thing in the changes line? pocket?
<kylem> vga uploadd
<kylem> vesa now
<kylem> vesa uploading
<seb128> kylem: I don't think pocket is correct
<seb128> distribution?
<kylem> i just put "dist"
<kylem> i recall being told that wasn't the modern parlance though.
<seb128> if people understand what you mean that's enough ;)
<seb128> imstt uploaded
<kylem> tseng uploaded
<kylem> god, i need pbuilder... using debfoster/build-dep to do chroot maintenance manually is super boring. :)
<seb128> tepsipakki: mga has a 1.4.6.1, updating your 1.4.4 to that
<kylem> seb128, i'm a muppet, i've been rebuilding src packages, will start copying the originals and not rebuilding...
<seb128> you can do it either way, no real difference ;)
<cjwatson> distribution is the traditional name for that element of the changelog
<cjwatson> katie calls it a suite
<kylem> tdfx.
<cjwatson> soyuz calls it a pocket of a distrorelease
<cjwatson> distrorelease => edgy, pocket => UPDATES
<cjwatson> or RELEASE
<cjwatson> or whatever
<kylem> ah
<seb128> mga update uploaded
<kylem> should i just ignore the sparc-only drivers?
<Ubugtu> New bug: #89248 in xorg (main) "screen resolution !" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89248
<kylem> i guess there's little chance they actually changed between 7.1 and 7.2
<kylem> ok, i've got it on good authority they haven't changed in forever.
<seb128> kylem: if the update is ready you can upload it, doesn't cost much
<kylem> i've looked over all of them, they should be fine.
<kylem> i'll take care of any build failures that result
<kylem> sun* done.
<kylem> sisusb now.
<seb128> neomagic update uploaded
<kylem> sisusb uploaded
<seb128> looking at newport
<kylem> sis uploaded
<Ubugtu> New bug: #44499 in xserver-xorg-video-mga (main) "mga-driver KDE startup icons" [Medium,Unconfirmed]  https://launchpad.net/bugs/44499
<kylem> siliconmotion uploaded.
<seb128> newport update uploaded
<seb128> now ;)
<kylem> s3virge uploaded
<seb128> looking at nsc
<kylem> s3 uploaded
<kylem> looking at rendition
<kylem> rendition uploaded
<kylem> seb128, i'll take nv, you take i810?
<seb128> works for me
<seb128> I've an i810 card on my laptop and an ati card on desktop, no nv handy to play with
<kylem> i suspect both will take more effort.
<seb128> that an ati
* kylem has an nv he can test.
* kylem yawns and reboots to test on amd64.
<kylem> works. uploading nv.
<kylem> looking at ati
<kylem> won't upload until i find a tester.
<kylem> did -amd not get released with 7.2?
<kylem> http://people.ubuntu.com/~kyle/xserver-xorg-video-ati_6.6.3-2ubuntu1_i386.deb
<seb128> kylem: http://xorg.freedesktop.org/wiki/ModuleVersionsInXorgReleases
<kylem> seb128, bookmarked, thanks.
<seb128> np
<seb128> kylem: testing that deb now, my desktop has a radeon card
<kylem> ok, cool
<kylem> hmm, i could try it on parisc.
<kylem> my c8000 has a firegl somethingorother.
<tepsipakki> I can test ati
<tepsipakki> radeon8500 on my box
<kylem> ok
<kylem> thanks!
<tepsipakki> kylem: heh, seems that I forgot to run another check for "unstable" ;)
<kylem> :)
<kylem> it happens
<tepsipakki> yeah
<kylem> i've uploaded shit to debian by accident.
<tepsipakki> hah
<kylem> by forgetting "ubuntu" on dput
<tepsipakki> ati works
<kylem> cool
<seb128> np
<seb128> no
<seb128> wait
<seb128> /usr/bin/compiz.real: GLX_EXT_texture_from_pixmap is missing
<tepsipakki> seb128: ati?
<seb128> compiz doesn't start with the ati update
<seb128> tepsipakki: yep
<tepsipakki> hmm, works for me
<tepsipakki> strange
<kylem> are you up to date with everything else?
<seb128> gra
<seb128> I've installed fglrx some days ago to test a bug
<seb128> it divers mesa and create that I think
<tepsipakki> heh
<kylem> ah.
<tepsipakki> they really should be able to coexist..
<kylem> seb128, i'll wait for you to confirm before i upload
<seb128> going to take me a min, brb
<tepsipakki> and I'll upgrade first
<kylem> ok.
<tepsipakki> slow network, so it'll take a while
<tepsipakki> shouldn't be that many updates though
<seb128> ok
<seb128> works now ;)
<tepsipakki> heh
<tepsipakki> kylem: go for it
<seb128> tepsipakki: "that many updates" for what?
<tepsipakki> for my box
<kylem> blam.
<tepsipakki> upgraded it on wednesday I think
<Ubugtu> New bug: #89275 in xorg-server (main) "Xorg crashes after dist-upgrade (nvidia)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89275
<Treenaks> I restarted my (nvidia, amd64) X this afternoon, no problems
<tepsipakki> I reinstalled my work-powerhouse with feisty.. almost no problems
<tepsipakki> once on reboot something went wrong and the display was corrupted, had to reboot when everything was fine again
<tepsipakki> and I don't see any slowdowns with metacity-animations or with compiz
* kylem has "interesting" issues with nv, so is using nvidia for now.
<kylem> mostly because my LCD can't do DDC worth a shit.
<kylem> display is fucked at 50hz, 60hz, works fine at 57hz. :)
<kylem> (according to xrandr -r)
<tepsipakki> I have problems getting nv above 1280x1024
<tepsipakki> so I don't use it..
<kylem> yeah.. this is 1680x1050
<Treenaks> my work machine is dual-head, so it needs nvidia
<tepsipakki> I had Dell 24" and now HP 30" so they were a no-no for nv ;)
<kylem> at 50hz, the picture is right but fuzzy, at 60hz, the picture is utterly wrong.
<Treenaks> kylem: http://foodfight.org/zut/ati-breakage.ogg <-- that's what 'ati' does to my laptop :)
<tepsipakki> it still does?
<Treenaks> tepsipakki: yes..
<Treenaks> tepsipakki: that's 20283
<tepsipakki> remember seeing that
<kylem> hmm, i haven't got any more accepted mails
* kylem suddenly moderately concerned he /did/ end up uploading to debian
<kylem> hmm, nope
<Ubugtu> New bug: #48318 in linux-restricted-modules-2.6.15 (restricted) "ati xpress 200 black screen freeze when xorg is killed" [Medium,Unconfirmed]  https://launchpad.net/bugs/48318
<Ubugtu> New bug: #89289 in xorg (main) "Wrong resolution on initial install - Radeon 9600 Laptop LCD" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89289
<tepsipakki> kylem: are you still around?
<kylem> yessir.
<tepsipakki> ok, there was a patch in ati which got dropped because it was applied directly to the code.. (by Tollef :)
<tepsipakki> I'll roll a new version now
<kylem> ok.
<tepsipakki> kylem: alright, it's here: http://users.tkk.fi/~tjaalton/xorg72/new/ati.debdiff
<tepsipakki> the author noticed it :)
<kylem> k
#ubuntu-x 2007-03-03
<kylem> uploaded.
<tepsipakki> nice, thanks
<kylem> np.
<Ubugtu> New bug: #74056 in xorg (main) "Viewing certain binary data cause the xorg server to die a horrible, flaming death" [Undecided,Unconfirmed]  https://launchpad.net/bugs/74056
<pochu> tepsipakki: still around?
<pochu> tepsipakki: I'm not sure where to get the modesetting driver
<pochu> I've downloaded last git checkout from git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel
<pochu> but I can't find there the modesetting branch
<pochu> am I doing something bad?
* netjoined: irc.freenode.net -> anthony.freenode.net
<pochu> tepsipakki, anybody else: I'm here again, if you know the answer to my previous question, I will test the modesetting driver :)
<Ubugtu> New bug: #52489 in xresprobe (main) "Dapper autodetection fails with Matrox mga and Dell monitor." [Undecided,Unconfirmed]  https://launchpad.net/bugs/52489
<Ubugtu> New bug: #40297 in xserver-xorg-video-mga (main) "X completely corrupts VesaFB Virtual Terminals' image (also Dapper)" [Medium,Needs info]  https://launchpad.net/bugs/40297
<Ubugtu> New bug: #47250 in xserver-xorg-video-mga (main) "Screensaver locks keyboard and mouse G550" [Medium,Needs info]  https://launchpad.net/bugs/47250
<Ubugtu> New bug: #43793 in xserver-xorg-video-mga (main) "REGRESSION: X crashes after the last breezy update" [Medium,Fix released]  https://launchpad.net/bugs/43793
<Ubugtu> New bug: #24103 in xserver-xorg-video-ati (main) "dragging glxgears locks the server" [Medium,Needs info]  https://launchpad.net/bugs/24103
<tepsipakki> ok, I'll test xorg-server-1.3 branch how it does with EXA
<Ubugtu> New bug: #31830 in Ubuntu "Incorrect screen resolution in Dapper LiveCD" [Medium,Confirmed]  https://launchpad.net/bugs/31830
<Ubugtu> New bug: #40808 in xserver-xorg-video-ati "open lid -> wrong resolution" [Medium,Unconfirmed]  https://launchpad.net/bugs/40808
<Ubugtu> New bug: #32853 in linux-restricted-modules-2.6.15 (restricted) "installing NVIDIA non-free binary package requires manual configuration" [Medium,Unconfirmed]  https://launchpad.net/bugs/32853
<Ubugtu> New bug: #42871 in linux-restricted-modules-2.6.15 (restricted) "the ati fireglcontrol icon appears in root menu" [Medium,Unconfirmed]  https://launchpad.net/bugs/42871
<Ubugtu> New bug: #89424 in xrgb (main) "file "owned" by x11-common included" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89424
<Ubugtu> New bug: #89425 in xorg (main) "Failed to install, conflicting files in xrgb" [Medium,Needs info]  https://launchpad.net/bugs/89425
<tepsipakki> could we sync x11proto-randr-1.2.1 from experimental?
<Ubugtu> New bug: #89434 in xorg (main) "Wrong display resolution" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89434
<Ubugtu> New bug: #54813 in xorg (main) "X server failure dialogue garbled (UTF-8 problem)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/54813
<Ubugtu> New bug: #89430 in compiz (main) "[apport]  compiz.real crashed with SIGSEGV in savageGetLock() (dup-of: 81889)" [Medium,Rejected]  https://launchpad.net/bugs/89430
<Ubugtu> New bug: #35632 in mesa (main) "no gl manpages available" [Medium,Needs info]  https://launchpad.net/bugs/35632
<Ubugtu> New bug: #89498 in mesa (main) "[apport]  glxinfo crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89498
<Ubugtu> New bug: #89517 in xserver-xorg-input-synaptics (main) "Synaptics touchpad isnt detected" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89517
<kylem> tepsipakki, what's new in randr-1.2.1?
<tepsipakki> kylem: it's needed for xorg-server-1.3 :)
<tepsipakki> I built it for testing, had to take the version in experimental to make it compile
<tepsipakki> protos are just headers
<kylem> hrm.
<tepsipakki> hum, I thought input-evdev was uploaded already
* kylem notes i810 7.2 is running nicely on his i965.
<tepsipakki> need to merge it again since I purged them all
<tepsipakki> xorg-server-1.3 snapshot is running fine as well ;)
<kylem> i'm available to upload/review all day today.
<kylem> and likely tomorrow.
<tepsipakki> ok, maybe I'll redo it now
<kylem> or monday. whenever you feel ready, just ping me.
<tepsipakki> yeah
<tepsipakki> btw, EXA-slowness is gone if I run just 'xcompmgr -a'
<kylem> EXA is in server 1.3?
<tepsipakki> and I was told that it isn't meant for a "regular" desktop anyway..
<tepsipakki> no, EXA has been here for a while
<kylem> ah.
<tepsipakki> meant for composite and the "new" stuff
<kylem> cool
<tepsipakki> just that there's a bug (with dupes) that EXA is "broken"
<kylem> hrm.
<tepsipakki> I remember seb128 having some opinions on evdev, so I'll leave it for Monday
<kylem> ok.
<kylem> no problemo :)
<Ubugtu> New bug: #73471 in xserver-xorg-video-i810 "missing some refresh when playing a video" [Undecided,Confirmed]  https://launchpad.net/bugs/73471
<Ubugtu> New bug: #40307 in mesa (main) "ATI radeon with blender corrupts screen" [Medium,Confirmed]  https://launchpad.net/bugs/40307
#ubuntu-x 2007-03-04
<Ubugtu> New bug: #89581 in xserver-xorg-video-tdfx (main) "Undefined symbol in Xorg tdfx server" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89581
<Ubugtu> New bug: #82999 in xorg (main) "Some windows are empty" [Undecided,Confirmed]  https://launchpad.net/bugs/82999
<Ubugtu> New bug: #88423 in xserver-xorg-video-via (main) "[apport]  compiz.real crashed with SIGSEGV in viaGetLock()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88423
<Ubugtu> New bug: #43944 in linux-restricted-modules-2.6.15 (restricted) "Resuming (from suspended state) hangs X / keyboard" [Medium,Needs info]  https://launchpad.net/bugs/43944
<Ubugtu> New bug: #47217 in linux-restricted-modules-2.6.15 (restricted) "Installation of nvidia-glx-legacy causes hang on reboot" [Medium,Needs info]  https://launchpad.net/bugs/47217
<Ubugtu> New bug: #89632 in xorg (main) "moving windows jumps xorg cpu usage + fan" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89632
<Ubugtu> New bug: #20359 in xorg (main) "Loads gdm. Freezes while logging in" [Medium,Rejected]  https://launchpad.net/bugs/20359
<Ubugtu> New bug: #89653 in xserver-xorg-input-mouse (main) "Horizontal scrolling not working for Logitech LX5 mouse" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89653
<Ubugtu> New bug: #89659 in libx11 (main) "X11 locale data misconfiguration after upgrade to feisty." [Undecided,Unconfirmed]  https://launchpad.net/bugs/89659
<Ubugtu> New bug: #39050 in gst-plugins-base0.10 "gstreamer crashes due to BadAlloc response from xv" [Undecided,Confirmed]  https://launchpad.net/bugs/39050
<Ubugtu> New bug: #89727 in xorg (main) "Touchpad horizontal scrolling seems to be disable by default" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89727
<Ubugtu> New bug: #53664 in xorg (main) "Wrong resolution detected for Dell 2405 monitor" [Undecided,Unconfirmed]  https://launchpad.net/bugs/53664
#ubuntu-x 2008-02-25
<ubotu> New bug: #195238 in firefox-3.0 (main) "Firefox 3.3 renders websites very poorly (dup-of: 186186)" [Undecided,New] https://launchpad.net/bugs/195238
<Ng> tjaalton: have you seen any crashes when exiting X on -intel?
<Ng> it's not every time, but a fair percentage of the time, my laptop completely hangs
<tjaalton> Ng: no, works fine with 965
<Ng> hrm
<Ng> I don't seem to get any log entries, it just hangs solid :(
<tjaalton> try the new kernel, it has a number of drm changes
<Ng> ooh, new kernel you say :)
<Ng> newer than 2.6.24-8?
<tjaalton> -10
<tjaalton> metapackages not updated yet
<Ng> ah
<bryce> Ng, I've not seen that either on my intel boxes
<Ng> any 855s?
<bryce> nope
<bryce> night
<ubotu> New bug: #195363 in xorg-server (main) "Xorg crashed with SIGSEGV in XkbEnableDisableControls() (dup-of: 157881)" [Medium,New] https://launchpad.net/bugs/195363
<asac> hey ... how can i get the DPI used for fonts?
<asac> (using api, not cmd line)
<jcristau> asac: using Display{Height,Width}{,MM}() i think
<ubotu> New bug: #195424 in xserver-xorg-video-intel (main) "new upstream version" [Undecided,New] https://launchpad.net/bugs/195424
<ubotu> New bug: #194987 in xserver-xorg-video-ati (main) "Totem quits on startup due to X Window System error" [Undecided,New] https://launchpad.net/bugs/194987
<asac> jcristau: thats display ... i want font (which can be out of sync)
<asac> but i think thats just out of sync for GtkSettings enabled applications ... no idea though; thats why i ask ;)
<seb128> asac: well, the xsetting should not be gtk specific
<jcristau> no idea what xft does
<asac> seb128: ok i think i will look into code ... e.g. what xft settings returns and if there are corner cases where this doesn't return anything sane. is that in pure Gtk Source?
<seb128> asac: no clue about fonts, xft, etc
<ubotu> New bug: #195219 in xserver-xorg-video-intel (main) "Graph intel 855 does not work " [Undecided,Incomplete] https://launchpad.net/bugs/195219
<Ng> tjaalton: are we gonna get the new upstream -intel? :)
 * Ng looks at that bug report. there seems to be way too much variation of behaviour for 855s ;)
<ubotu> New bug: #194343 in xorg (main) "Keyboard goes suddenly bananas (dup-of: 194214)" [Undecided,New] https://launchpad.net/bugs/194343
<ubotu> New bug: #195412 in xserver-xorg-input-synaptics "laptop touchpad not recognised" [Medium,Incomplete] https://launchpad.net/bugs/195412
<tjaalton> Ng: of course, tomorrow at the latest
<Ng> awesome :)
<Ng> does this have a standing exception? ;)
<tjaalton> heh, I'm not sure, but I guess that we can upload bugfix releases without too much paperwork
<tjaalton> there's also a new mesa release candidate
<seb128> bryce_: current comment on bug #32963 seems to indicate the issue is an xorg one
<ubotu> Launchpad bug 32963 in xserver-xorg-video-intel "totem overrides XV_CONSTRAST to wrong default value (Xv movies on i810/i945 have horrible colour/gamma)" [Medium,Confirmed] https://launchpad.net/bugs/32963
<Ng> ooh interesting, I have a 945 at home running hardy and movies have indeed been looking awful
<ubotu> New bug: #195470 in xserver-xorg-video-nv (main) "xserver crashes while window minimizing" [Undecided,Incomplete] https://launchpad.net/bugs/195470
<mvo> Ng: with compiz or everytime?
<mvo> Ng: (movies looking ugly)
<Ng> mvo: I'm not actually sure, my 945 box is hooked up to my TV and I mostly just use it for watching movies. I'll check
<Ng> it's quite likely using compiz
<Ng> but it definitely seems like a gamma thing - the image is clear, but bright areas are ridiculously bright
 * mvo nods
<mvo> I'm just curious if it has something to do with compiz or not
<bryce> seb128: I have updated the gnome-desktop and gnome-settings-daemon packages:  http://people.ubuntu.com/~bryce/Testing/XrandrGui/
<seb128> bryce: thanks
<ubotu> New bug: #190370 in xorg (main) "privilege escalation when canceling the low-graphics warning prompt" [Undecided,New] https://launchpad.net/bugs/190370
#ubuntu-x 2008-02-26
<ubotu> New bug: #195636 in wacom-tools "/dev/input/wacom device missing for Bamboo Fun" [Undecided,New] https://launchpad.net/bugs/195636
<superm1> hey bryce_ you around?
<bryce> heya superm1
<superm1> good evenin.  
<superm1> did you by chance see that patch that I attached to a mesa bug?
<bryce> hey I have a question for you (maybe a bit philosophical)
<superm1> sure shoot
<bryce> hmm, not sure (been looking at a lot of patches lately tho)
<superm1> bug 189580
<ubotu> Launchpad bug 189580 in mesa "mythfrontend.real crashed with SIGSEGV in glXMakeCurrentReadSGI()" [Undecided,In progress] https://launchpad.net/bugs/189580
<bryce> well, with mythtv I'm wondering how you think things will work once analog is turned off next year, and cable companies are using DRM-laced digital feeds.
<superm1> well analog is only turned off OTA
<bryce> do you think there'll be a solution, or is that going to be more or less the end of mythtv as a television recording tool?
<superm1> that's a big selling point to cable companies right now
<superm1> that you can "use your old tv"
<superm1> still
<bryce> hmm, yet the analog channel sets that the two cable companies in my area provide are a small subset of the available channels
<bryce> (essentially just what's provided OTA already)
<superm1> wow it's that bad by you?
<superm1> i get ~80 analog stations on my cable here
<bryce> I mean, for the digital packages
<superm1> well the cable company can approach the issue from two sides
<bryce> for "regular" cable I still get ~80 channels too, however I think they'll be ending that
<superm1> 1) either keep the analog stations around, and "transition" people over to their cable packages to use their old tvs - only to eventually plug that loop hole
<superm1> 2) deter people because they need a digital tuner for cable, satellite, or OTA
<superm1> i personally think most cable companies are going to approach it from (1)
<bryce> the issue we've run into is that comcast has been gradually dropping channels from the analog service
<bryce> quite irritating
<superm1> well look at it from a lamen's consumer perspective
<superm1> people are going to complain that they are missing all these channels 
<superm1> the more that go
<superm1> and so cable companies either deal with that influx of complaints, or eventually open up the "basic" digital packages or keep analog around
<bryce> hmm, that could be
<superm1> so, in other words my own belief is that some way or another it will be sorted out - either keeping analog around longer, or cable co's being forced to de-drm there stations
<superm1> and very worst comes to worst - there is always svid capture
<superm1> and ir blaster/serial changer/firewire changer
<bryce> of course it sort of presumes the absence of monopolies or collusion
 * superm1 shrugs
<superm1> if only our capitalist society didn't allow for such things
<superm1> in the event of either of those though, you do need to remember how often the ability to sue gets abused
<tjaalton> morning guys
<superm1> morning tjaalton 
<bryce> heya tjaalton
<tjaalton> at least you guys have widespread HD?-)
<bryce> hmm, well I guess if worse comes to worst, someone will come up with some clever mythtv/bittorrent thingee that bypasses the networks entirely
<pwnguin> we've got about 80 channels here as well ;)
<tjaalton> we only have a handful of crappy paytv-channels
<tjaalton> ..that are HD
<pwnguin> err
<pwnguin> i mean, 80 analog cable TV channels
<superm1> bryce, you also have to remember too - once everything is all digital, hackers will pop up looking for a way to circumvent security measures
<bryce> yup
<superm1> its always a cat and mouse game
<tjaalton> this is the last week that cable companies are allowed to broadcast analog
<tjaalton> in Finland
<pwnguin> we just got a junkmail from our cable company bragging about how you can still use analog with their stuff
<superm1> tjaalton, so what is happening with digital stuff then, drm free?
<tjaalton> superm1: remains to be seen, so far it is drm free
<tjaalton> meaning that you are able to record stuff
<superm1> well that's nice :)
<bryce> superm1: what was the mesa patch you wanted me to look at?  I can take a look at it in a little while tonight
<superm1> bryce, bug 189580
<ubotu> Launchpad bug 189580 in mesa "mythfrontend.real crashed with SIGSEGV in glXMakeCurrentReadSGI()" [Undecided,In progress] https://launchpad.net/bugs/189580
<tjaalton> bryce: if it looks good, I can merge it with the new mesa from debian
<bryce> tjaalton: ok
<tjaalton> superm1: have you sent it upstream?
<superm1> i'm not sure if upstream mesa has already absorbed such a thing, but it resolves issues for myself and a handful of other folks that have ran into the issue using free drivers
<tjaalton> would be nice to get some feedback from upstream :)
<superm1> tjaalton, not yet, i was hoping to find someone with a good relationship with x.org to forward it on up
<superm1> i'm not the original author of it, just a messenger :)
<tjaalton> ok :)
<tjaalton> it's easy to forward it, but the author should then subscribe to the upstream bug
<superm1> tjaalton, i'll be glad to link the appropriate bug trackers if you can send it for feedback
<bryce> superm1: ok I've given a thumbs up on the bug.  Patch looks pretty simple
<superm1> bryce, great thanks.  
<bryce> not certain what side-effects might come of it though
<superm1> i dont have core dev powers, so if you could sponsor it too, that'd be good :)
<superm1> bryce, well given the description of it, i wouldn't expect anything harsh, but i dont know for sure
<tjaalton> there's a new release candidate in debian that needs merging anyway
<bryce> I'm still a hair away from having core dev powers myself, so will leave to tjaalton
<tjaalton> :)
<bryce> superm1: well, since it's opening a dynamic library, there's a fairly limitless number of things that could happen in theory; in practice I'm betting it'll be fine
<bryce> ok, bbiab
<superm1> bryce, wow, surprised you don't have the core-dev prowess already :)
<tjaalton> ok, forwarded as freedesktop bug 14675
<ubotu> Freedesktop bug 14675 in GLX "mythfrontend crashes in glXMakeCurrentReadSGI()" [Normal,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=14675
<superm1> tjaalton, okay thanks, i'll get the person who wrote the patch subscribed
<tjaalton> cool
<bryce> superm1: you're not the first to say that
<superm1> bryce, well then i'm sure you won't have trouble once you apply for it
<ubotu> New bug: #195707 in linux-restricted-modules-2.6.22 "Please upgrade Nvidia binary driver to 169.09" [Undecided,New] https://launchpad.net/bugs/195707
<tjaalton> superm1: seems that the mesa problem is already fixed in master, and if the backported commits work with 7.0, they could be added to the stable branch
<ubotu> New bug: #194249 in linux-restricted-modules-2.6.24 (restricted) "atieventsd crashed with SIGSEGV in _XSend()" [Undecided,New] https://launchpad.net/bugs/194249
<ubotu> New bug: #187421 in limewire (universe) "c->xlib.lock failed (dup-of: 87947)" [Undecided,New] https://launchpad.net/bugs/187421
<ubotu> New bug: #187947 in azureus (universe) "azureus crashes (dup-of: 87947)" [Undecided,New] https://launchpad.net/bugs/187947
<ubotu> New bug: #194846 in netbeans (universe) "[hardy] Assertion `c->xlib.lock' failed (dup-of: 87947)" [Undecided,New] https://launchpad.net/bugs/194846
<ubotu> New bug: #188412 in ubuntu "jvm error (dup-of: 87947)" [Undecided,New] https://launchpad.net/bugs/188412
<ubotu> New bug: #189064 in j2se1.4-i586 (multiverse) "cannot view java applet on konqueror (dup-of: 87947)" [Undecided,New] https://launchpad.net/bugs/189064
<ubotu> New bug: #192761 in sun-java6 (multiverse) "Java JVM 6 Swing Crashes  (dup-of: 87947)" [Undecided,Fix committed] https://launchpad.net/bugs/192761
<ubotu> New bug: #193061 in ubuntu "java: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.  (dup-of: 87947)" [Undecided,New] https://launchpad.net/bugs/193061
<ubotu> New bug: #193103 in sun-java6 (multiverse) "sun java6 firefox plugin crashing (dup-of: 87947)" [Undecided,New] https://launchpad.net/bugs/193103
<ubotu> New bug: #195767 in xorg-server (main) "Xorg crashed with SIGSEGV in free()" [Medium,New] https://launchpad.net/bugs/195767
<Ng> tjaalton: woo, thanks for the upload. the little fix I was testing got included upstream, right?
<tjaalton> it already was
<Ng> ah, I've had mine on hold for a little while ;)
<Ng> I'll unhold it and upgrade :D
<tjaalton> cool
<tjaalton> sigh, need to add ServerLayout back to make synaptics work
<superm1> tjaalton, yeah i got an email from the author.  his fix went in in November :)
<tjaalton> superm1: heh, ok. It's uploaded now, so please test when it's built
<superm1> tjaalton, alright thanks
<jcristau> tjaalton: why do you need serverlayout?
<tjaalton> jcristau: people need it for synaptics
<tjaalton> I can't test it, so I trust them :)
<tjaalton> otherwise the synaptics section is not used by the server, I guess
<jcristau> hrm
<tjaalton> there's also a strange bug where enabling the SL section the keymap is different..
<bryce> tjaalton: It may help having it back to reduce displayconfig-gtk breakage (which I think we still need for bulletproof-x mode)
<seb128> bryce: speaking about bulletproof-x, was there any discussion about a boot option to start in vesa mode 800x600 or similar?
<bryce> I vaguely remember something like that
<bryce> I don't recall if there were any decisions
<tjaalton> bryce: ah, indeed
<bryce> seb128: have you had a chance to look at the gnome-desktop and gnome-settings-daemon changes?  I think they're ready to go up.
<ubotu> New bug: #195843 in xserver-xorg-video-intel (main) "INTEL_BATCH=1 should be enabled per default for Intel graphic hardware" [Undecided,New] https://launchpad.net/bugs/195843
<seb128> bryce: no, new GNOME weeks are crazy, lool looked at the patches I think
<bryce> seb128: gnome-control-center is also building correctly and should be ready to go up soon (I just want to do additional testing first)
<seb128> he's slightly concerned about the API additions or changes
<seb128> and he said the patches are not really clean
<ubotu> New bug: #195846 in xserver-xorg-video-amd (main) "xserver-xorg-video-amd  2.7.7.6-1ubuntu2 fails at DDC module on Flat Panel" [Undecided,New] https://launchpad.net/bugs/195846
<bryce> seb128: I hope that either you two will be able to fix the issues, or provide me with detailed feedback so I can fix it.
<seb128> bryce: right, will do, I've just been busy, but I'm almost done with this week updates and I'll look at those again
<seb128> I'm away for dinner, be back later
<bryce> seb128: having got things to this point, I would really like to just focus on gnome-control-center and it's remaining xrandr issues, and leave gnome-desktop and gnome-system-daemon to you guys.  I've taken care of most of the work with them, so hopefully between the two of you the remaining integration work should be straightforward.
<seb128> bryce: right, should be alright
<bryce> seb128: great
<seb128> I'll ping you back about those later today or tomorrow, I have to go now
<bryce> ok
<ubotu> New bug: #29897 in xserver-xorg-input-mouse (main) "USB mouse not working after booting with mouse plugged in" [Medium,Invalid] https://launchpad.net/bugs/29897
<ubotu> New bug: #195901 in linux-restricted-modules-2.6.24 (restricted) "please sync nvidia-glx-new to new release 169.12" [Undecided,New] https://launchpad.net/bugs/195901
<ubotu> New bug: #195912 in linux-restricted-modules-2.6.24 (restricted) "linux-restricted-modules-2.6.24-10-generic broken after latest updates [Ubuntu 8.04 Alpha 5]" [Undecided,New] https://launchpad.net/bugs/195912
<ubotu> New bug: #195953 in wacom-tools (main) "Tablet input resolution tied to display resolution" [Undecided,New] https://launchpad.net/bugs/195953
<ubotu> New bug: #195952 in xserver-xorg-video-intel (universe) "gstreamer-properties default video out should be X Window System (No Xv)" [Undecided,Fix released] https://launchpad.net/bugs/195952
#ubuntu-x 2008-02-27
<ubotu> New bug: #172296 in xorg (main) "Openoffice is sometimes extremely slow" [Undecided,New] https://launchpad.net/bugs/172296
<ubotu> New bug: #163941 in xorg (main) "openoffice slow scrolling with antialiasing" [Undecided,Incomplete] https://launchpad.net/bugs/163941
<ubotu> New bug: #196038 in linux-restricted-modules-2.6.24 (restricted) "nvidia-settings missing from nvidia-glx-new" [Undecided,New] https://launchpad.net/bugs/196038
<bryce> tjaalton: here's a synaptics patch that looks like it'd be worth uploading - https://bugs.launchpad.net/ubuntu/+source/xfree86-driver-synaptics/+bug/184398
<ubotu> Launchpad bug 184398 in xfree86-driver-synaptics "[PATCH] Increase touchpad polling value to decrease number of wakeups per second" [Medium,In progress] 
<tjaalton> bryce: ok
<bryce> tjaalton: oh btw, I've now got the xrandr gui ready to go -- http://people.ubuntu.com/~bryce/Testing/XrandrGui/
<bryce> there's debs there if you'd like to test it
<bryce> pending review from seb128, and maybe some minor code cleanups, I think it's ready for upload
<tjaalton> bryce: cool, I'll try on my laptop
<bryce> save your work before you test ;-)
<seb128> bryce: btw the gtk changes don't seem to be required, right?
<bryce> right
<bryce> night
<ubotu> New bug: #196073 in libpciaccess (universe) "Please sync from libpciaccess from Debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/196073
<ubotu> New bug: #196027 in ubuntu "2.6.24-10 linux-restricted-modules missing (dup-of: 195912)" [Undecided,New] https://launchpad.net/bugs/196027
<ubotu> New bug: #196065 in xserver-xorg-driver-i810 "Cannot start Kubuntu or Ubuntu" [Undecided,New] https://launchpad.net/bugs/196065
<ubotu> New bug: #196100 in xserver-xorg-video-trident (main) "Please sync a new version from Debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/196100
<ubotu> New bug: #196103 in xserver-xorg-input-acecad (universe) "Please sync a new version from Debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/196103
<ubotu> New bug: #192331 in ubuntu "keyrepeat problem (dup-of: 194214)" [Undecided,New] https://launchpad.net/bugs/192331
<ubotu> New bug: #196109 in linux-restricted-modules-2.6.24 (restricted) "fglrx - 3D acceleration totally messed up when this driver is active" [Undecided,New] https://launchpad.net/bugs/196109
<ubotu> New bug: #179744 in xorg "'Lost connection' to X server when staying in the console and Rhythmbox change to a new song" [Undecided,Incomplete] https://launchpad.net/bugs/179744
<ubotu> New bug: #194048 in mesa (main) "missing package for 3D acceleration" [Undecided,New] https://launchpad.net/bugs/194048
<ubotu> New bug: #196153 in xkeyboard-config (main) "Some corrections for /usr/share/X11/xkb/symbols/it," [Undecided,New] https://launchpad.net/bugs/196153
<ubotu> New bug: #196169 in linux-restricted-modules-2.6.24 (restricted) "Opengl corruption using fglrx" [Undecided,New] https://launchpad.net/bugs/196169
 * jcristau laughs at fglrx
<tjaalton> :)
<ubotu> New bug: #195837 in linux-restricted-modules-2.6.24 (restricted) "fglrx 8.02 corrupts kdm login screen on Radeon X300SE" [Undecided,New] https://launchpad.net/bugs/195837
<Ng> tjaalton: just updated to new kernels and X drivers and all seems well :)
<tjaalton> Ng: nice :)
<bryce> heya, morning!
<tjaalton> morning bryce 
<ubotu> New bug: #196215 in xorg (main) "Hardy live cd displays strange things with geforce 7900 & acer AL1916W screen" [Undecided,New] https://launchpad.net/bugs/196215
<ubotu> New bug: #195918 in linux-restricted-modules-2.6.24 (restricted) "ATI prop.driver on Hardy 64bit result in no screen output" [Undecided,New] https://launchpad.net/bugs/195918
<ubotu> New bug: #196220 in xserver-xorg-video-intel (main) "xserver-xorg-video-intel (2:2.2.1-1ubuntu2) doesn't works" [Undecided,New] https://launchpad.net/bugs/196220
<ubotu> New bug: #196242 in xorg (main) "[Hardy] bulletproof xorg fails completely with mbp rev3" [Undecided,New] https://launchpad.net/bugs/196242
<bryce> hi seb128
<seb128> hey bryce
<seb128> bryce: the gnome-desktop changes are not trivial 
<seb128> I'm wondering if that really makes sense to have there or if we should have a new lib
<bryce> perhaps longer term, but I'm not sure there is time to do that right now
<seb128> I'm not sure we should have that many changes there now
<seb128> is the new capplet something really useful?
<bryce> hmm, well if you have time for setting up a new library and getting it into main, ok
<bryce> yes, for configuring multiple monitors
<seb128> is that a common usecase?
<seb128> I would tend to be conservative and delay that to next cycle
<bryce> there is very strong interest in this by users, and we have tons of bug reports against xorg and displayconfig-gtk that they cannot do this already using displayconfig-gtk
<seb128> having a new lib would be harder and those changes are likely to land upstream somewhere so that could create conflicts
<jcristau> seb128: everyone uses two monitors these days :)
<seb128> jcristau: I'm not everyone apparently ;-)
<seb128> I'm not a luser and have several boxes
<seb128> but I've no dual screen config
<bryce> it's also used for laptop + projector use cases
<seb128> and I don't know of anybody out of work who has
<seb128> bryce: ok, I'll test the changes and upload if there is no issue on the basis that's something we want and that fedora guys likely know what they are doing
<seb128> and we can drop those if required
<bryce> ok thanks
<seb128> you are welcome
<pwnguin> every computer in our linux lab has dual monitors
<pwnguin> of course, they run gentoo ;)
<tormod> anyone want to help debug bug #101943? I have gdb attached to compiz.real and Xorg and they're both exploding in RAM in some kind of ping-pong.
<ubotu> Launchpad bug 101943 in xserver-xorg-video-intel "braid screensaver crashes system with compiz activated" [High,Confirmed] https://launchpad.net/bugs/101943
<ubotu> New bug: #196299 in linux-restricted-modules-2.6.24 (restricted) "nvidia-glx-new doesn't remember 1280x800 resolution" [Undecided,New] https://launchpad.net/bugs/196299
<ubotu> New bug: #190232 in linux-restricted-modules-2.6.24 (restricted) "compiz.real crashed with SIGSEGV in _nv000069gl()" [Medium,Incomplete] https://launchpad.net/bugs/190232
#ubuntu-x 2008-02-28
<ubotu> New bug: #196318 in xorg (main) "small screens end up only allowing small external display resolutions" [Undecided,New] https://launchpad.net/bugs/196318
<ubotu> New bug: #194929 in xserver-xorg-video-intel (main) "hardy alpha5, i810 fuzzy/choppy problems" [Undecided,New] https://launchpad.net/bugs/194929
<ubotu> New bug: #196349 in xserver-xorg-video-unichrome (universe) "xserver-xorg-video-unichrome broken in hardy." [Undecided,New] https://launchpad.net/bugs/196349
<tjaalton> hmm, i965 doesn't start a session with vesa.. x-window-manager/compiz gets stuck
<tjaalton> bryce: what's your opinion about vmmouse? the current method of using vmmouse_detect doesn't work, and just defaulting to it instead would fall back to mouse when the (driver internal) check fails
<tjaalton> mvo: what do you think of bug 67996, you said that /usr/X11R6/bin could be moved aside instead of failing the upgrade?
<ubotu> Launchpad bug 67996 in xorg "x11-common preinst script fails (was: aborts /usr/X11R6/bin not empty)" [High,Confirmed] https://launchpad.net/bugs/67996
<tjaalton> hm, my session doesn't work with intel either
<Ng> erk
<Ng> my laptop just suspended and on resume X was broken and green :(
<jcristau> some suspend/resume problems on intel are fixed in .25-rc3
<Ng> hmm
<Ng> testing it again and I saw the same green screen flash right after it powered up, but then it was redrawn with the proper X stuff
<tjaalton> the current kernel in hardy has the drm bits backported
<tjaalton> but maybe rc3 has more
<mvo> tjaalton: yes, I think it is wrong to fail here, I think what it should do is to warn the user via debconf about it but then move /usr/X11R6/bin to /usr/X11R6/bin.move_on_upgrade or something like this
<tjaalton> mvo: ok, I'll change it and modify the message too
<mvo> tjaalton: great, thanks
<jcristau> are there that many problems left with that?  i don't remember many reports of broken upgrade after etch release
<tjaalton> jcristau: shouldn't be, but..
<tjaalton> there was at least a broken opera
<tjaalton> this change can go right after hardy is released
<jcristau> not from a deb then?
<tjaalton> yes, official opera deb
<tjaalton> upstream crap :)
<jcristau> x11-common conflicts with opera
<tjaalton> well, that was an example.. don't know if there are others
<tjaalton> maybe I should just ask
<Ng> mvo: http://bugzilla.gnome.org/show_bug.cgi?id=482354 was the firefox/wm thing I mentioned
<ubotu> Gnome bug 482354 in general "gtk_window_present() causes full applications to move workspaces" [Normal,Unconfirmed] 
<Ng> and a simple testcase for the weird borderless bug doesn't expose it, so maybe I have a bug ;(
 * mvo checks
<jcristau> tjaalton: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/67996/comments/13 eg has nothing to do with that bug afaics
<ubotu> Launchpad bug 67996 in xorg "x11-common preinst script fails (was: aborts /usr/X11R6/bin not empty)" [High,Incomplete] 
<jcristau> and the rest of the failure reports are old
<tjaalton> yeah, era is complaining about xli
<tjaalton> I'll hold off that change for now and upload what I have now
<tjaalton> nownow
<ubotu> New bug: #196560 in xorg (main) "[gutsy] X crash (low graphics mode) when logging out and in several times consecutively" [Undecided,New] https://launchpad.net/bugs/196560
<tjaalton> jcristau: yep, you were right.. era didn't have the problem anymore, so I closed it. thanks for the push ;)
<bdmurray> Wasn't nvidia-glx-config removed recently?
<mario_limonciell> bryce, are you around momentarily?
<bryce> hi mario_limonciell
<mario_limonciell> hey bryce
<mario_limonciell> had a few questions regarding how fn-f8 was "supposed" to be handled on intel cards
<mario_limonciell> is acpid supposed to be catching the events for them, or all within the intel video driver?
<jcristau> the driver doesn't deal with that afaik
<jcristau> probably a bios thing
<bryce> mario_limonciell: in theory acpi should be handling it all
<mario_limonciell> bryce, so in the event that /var/log/acpid isn't showing any of these events being caught, who to start pointing fingers at likely?
<bryce> well, I wouldn't point fingers, but mjg59 is the best guy to answer questions about it
<bryce> sometimes the issue goes down as far as the kernel
<mario_limonciell> okay, well on this morning's call, rtg had mentioned to poke you on it first
<mario_limonciell> well let me put it this way though - it seems that something gets intercepted by the keypress. FN-F8 issues a whole bunch of events to xev, but nothing with the randr change on the displays
<mario_limonciell> which was why I was thinking to point it at xserver-xorg-video-intel
<bryce> hang on, I have a bug report about this...
<jcristau> mario_limonciell: the driver shouldn't be involved in this at all. if you get a keypress event, then you can configure your desktop env to act on it
<mario_limonciell> no keypress event is caught, let me get a pastebin showing you what events actually are caught by xev
<jcristau> (seems to send XF86Display here)
<mario_limonciell> http://paste.ubuntu.com/5106/
<bryce> bug #144225, #133568
<ubotu> Launchpad bug 144225 in xrandr "Fn + F8 doesn't work on Dell Inspiron 6400 to switch display to another monitor" [Low,Triaged] https://launchpad.net/bugs/144225
<ubotu> Launchpad bug 133568 in xserver-xorg-video-intel "fn+f8 (crt/lcd switch) does nothing" [Medium,Confirmed] https://launchpad.net/bugs/133568
<jcristau> hmm. maybe i'm wrong. the driver seems to listen to acpi stuff
<bryce> both of those are misfiled; it's not xrandr and like jcristau it's not a video driver thing
<mario_limonciell> they're also dated back some time - as i'd imagine behavior has changed on hardy
<bryce> yeah could be
<bryce> that latter one seems to not be about it not working, but not working they way they expect
<bryce> hmm, it sounds like we need something better than just mapping to xrandr --auto
<mario_limonciell> well but in this case, xrandr --auto isn't even being called 
<bryce> it needs to be a toggle type thing that switches between that and xrandr --output FOO --off
<bryce> yeah, I'm just saying in general ;-)
<mario_limonciell> yeah, i'll agree there, but that framework for querying the driver other than xrandr | grep BLAH would probably be nicer to have first before that
<mario_limonciell> well for now i'll mark the bug with xserver-xorg-video-intel pending more information
<ubotu> New bug: #196176 in dell "FN-F8 doesn't switch displays on M1330" [Medium,Confirmed] https://launchpad.net/bugs/196176
<mario_limonciell> well it would appear that after a lot of presses an XF86Display key is caught by xev, but X doesn't react on that keyevent
<jcristau> mario_limonciell: X *sends* the key event
<jcristau> so that you can do whatever you want client-side with it
<mario_limonciell> jcristau, well I think i've narrowed it down further.  gnome-settings-daemon is crashing
<mario_limonciell> at when FN-F8 is pressed
<jcristau> ah :)
<mario_limonciell> so perhaps it wasn't ported to xrandr 1.2
<mario_limonciell> off to CVS to look around :)
<mario_limonciell> too bad apport doesn't catch it though
<asac> tjaalton: hey. i have "enemy territory QW" and it plays fine with -generic fglrx, but i get rendering errors + worse: quick system crashes when using -rt. any idea?
<tjaalton> asac: hmm, sorry no idea.. maybe abogani might know, he should be the -rt master
<mario_limonciell> whew okay after tracking that all down, here's my update on it - g-s-d doesn't support switching displays (yet).  2.24 is the target
<mario_limonciell> that crash that i was encountering is indeed a bug with g-s-d 
<bryce> ahh interesting
<mario_limonciell> so perhaps we need a more local fix until 2.24
<bryce> mario_limonciell: do we have those bugs in launchpad against gsd?
<mario_limonciell> bryce, i just got them an unoptimized backtrace upstream
<mario_limonciell> at bugs.gnome.org
<mario_limonciell> i'll link a launchpad bug once i find the most appropriate one
<bryce> great, thanks
<mario_limonciell> so for a more local fix, i'd propose just binding fn-f8 to xrandr --auto
<mario_limonciell> at least until it's properly implemented upstream
<bryce> hmm, I thought we already had fn+f8 bound to xrandr --auto though?
<bryce> hi seb128
<mario_limonciell> maybe at one point
<mario_limonciell> but i'm not sure where that would sit now
<bryce> yeah me either
<mario_limonciell> do you know when the last time that was present?
<bryce> mario_limonciell: seb128 or mjg59 might know the details
<mario_limonciell> seb128, well if you are aware, do you know if/when/how fn+f8 was bound to xrandr --auto?
<bryce> mario_limonciell: I am fairly certain it was there in gutsy; I've seen bug reports referring to side effects when it's hit
<seb128> mario_limonciell: it's a gnome-control-center shortcut, I think it was dropped in hardy on the way and I will add it back when I do the next gnome-control-center upload
<seb128> hey bryce
<mario_limonciell> seb128, ah that would make more sense then :)
<bryce> mario_limonciell: btw I have another mythtv question
<mario_limonciell> go ahead shoot
<bryce> mario_limonciell: I installed mythfrontend on one of my laptops (which I use for a variety of things, and just sometimes mythtv), but now on each boot it's prompting me for mythtv settings, and then autologging me into mythtv
<bryce> so I guess a two parter question
<bryce> a) how do I get it to not prompt for the same info, and b) how do I turn off the auto-loging?
<bryce> oh, if it matters, the front end is Hardy, the back end Gutsy
<mario_limonciell> bryce, likely gnome is starting it up
<mario_limonciell> er wait
<mario_limonciell> its autologging from gdm?
<bryce> right
<mario_limonciell> remove the package ubuntu-mythtv-frontend
<mario_limonciell> it creates that autologin session.  perhaps its worthwhile ditching that package to avoid confusion
<bryce> hmm
<bryce> maybe it's just a gdm setting?  *poking around*
<mario_limonciell> well that package provides an override gdm config
<mario_limonciell> so yes in a sense it is a gdm setting
<bryce> aha, there's flags in /etc/gdm/gdm-cdd.conf for automatic and timed logins
<bryce> awesome, thanks
<mario_limonciell> if you aren't using the autlogin feature, just remove the package
<mario_limonciell> that's the only useful thing it provides :)
<bryce> oh interesting
<bryce> it sounds so official ;-)
<mario_limonciell> yeah hence why i think i should just nuke the package from debian/control
<mario_limonciell> it causes confusion :)
<bryce> btw, I checked through your mythbuntu.org site last night - great work on it, lots of really useful info :-)
<bryce> finally I learned how to shut off the screensaver ;-)
<mario_limonciell> thanks :)
<mario_limonciell> ugh upstream nailed the bug -
<mario_limonciell> its because of one of our gsd patches
<mario_limonciell> seb128, 19_extra_keybindings.patch shouldn't be present
<mario_limonciell> its not complete
<mario_limonciell> or at least it should be modifying a little bit mroe
<seb128> mario_limonciell: ?
<mario_limonciell> seb128, gnome bug 518637
<ubotu> Gnome bug 518637 in plugins "crash in media keys on resume?" [Critical,Resolved: notgnome] http://bugzilla.gnome.org/show_bug.cgi?id=518637
<mario_limonciell> that was caused by 19_extra_keybindings
<mario_limonciell> because of not having a callback to the XRANDR key
<seb128> mario_limonciell: right, as said I'll fix the xrandr thing in the next upload
<mario_limonciell> seb128, okay just wanted to point out its in gsd not gnome-control-center then
<seb128> mario_limonciell: thanks
<mario_limonciell> are you aware of where the changes need to be made?  I can summarize what i've discovered here in the last 2 hours in a bug to save you some trouble if you'd like
<seb128> I think using what we had in gutsy should do the trick
<seb128> mario_limonciell: no?
<mario_limonciell> seb128,  i'm not aware of exactly what was in that patch.  the necessary change is pretty small to 19_extra_keybindings.  give me a few minutes and i'll test what i believe is necessary, and then pastebin it.  should hopefully solve things
<seb128> mario_limonciell: http://paste.ubuntu.com/5119/
<seb128> mario_limonciell: so basically the schemas and the code case
<mario_limonciell> seb128, it's very similar to that yes.  i just tested it and it works
<seb128> very similar? what is wrong in the version I copied?
<mario_limonciell> execute() is no longer used
<seb128> ok, will adapt to the current code style
<seb128> but that's the idea, right?
<mario_limonciell> yeah.  i've got the patch together.  don't worry about it.  i'll track down the bugs and put together a debdiff
<mario_limonciell> i've been tracking this down the better part of the afternoon, it will feel good to have fixed it :)
<seb128> what patch?
<seb128> I'm about to do the upload with that change and a svn fix, should I wait on something elsE?
<mario_limonciell> to update 19_extra_keybindings
<seb128> no need to bother
<mario_limonciell> okay, well here: http://paste.ubuntu.com/5120/  
<mario_limonciell> that's the current syntax +                execute (manager, "xrandr --auto", FALSE, FALSE);
<seb128> mario_limonciell: is there a bug on launchpad?
<mario_limonciell> yes
<mario_limonciell> bug 179444
<ubotu> Launchpad bug 179444 in gnome-control-center "gnome-settings-daemon crashed with signal 5" [Medium,New] https://launchpad.net/bugs/179444
<seb128> mario_limonciell: can you attach the patch there?
<mario_limonciell> sure
<seb128> I'll use your version since you worked on it that's fair I think ;-)
<seb128> feel free to ping before starting working next time
<seb128> somebody pointed this one some times ago and I knew what to change
<mario_limonciell> well i didn't realize it'd be this involved, but yeah next time i will :)
<seb128> mario_limonciell: gsd update uploaded, thanks
<mario_limonciell> thanks a bunch
<seb128> thank you for looking in the issue
<seb128> to the issue
<seb128> rather ;-)
<ubotu> New bug: #196802 in xserver-xorg-video-unichrome (universe) "Unichrome setup problems" [Undecided,New] https://launchpad.net/bugs/196802
#ubuntu-x 2008-02-29
<ubotu> New bug: #196823 in mesa (main) "libgl1-mesa-glx" [Undecided,New] https://launchpad.net/bugs/196823
<ubotu> New bug: #196711 in xserver-xorg-input-mouse (main) "single click is considered as double click" [Undecided,Confirmed] https://launchpad.net/bugs/196711
<tjaalton> hmm, should we just drop -unichrome..
<bryce> have we converted over to openchrome as the default?  or are we still using via?
<bryce> I think -unichrome could be dropped to universe for Intrepid
<tjaalton> it is already in universe, and openchrome is the default
<tjaalton> it's just that there are no unichrome releases, the current one is a git checkout from a year ago
<bryce> hmm
<bryce> well I would leave it for hardy and drop it starting with intrepid
<tjaalton> why wait?
<tjaalton> it's just collecting bugs, albeit not that many users apparently, given that it's not even installable currently :)
<bryce> oh, if it's not even installable, I guess there'd be limited value in keeping it
<tjaalton> it's simple to fix though, just change the Provides
<bryce> I'm just thinking that if people have been using it in the past, dropping it entirely for hardy might be a bit too drastic since hardy is supposed to be an lts
<bryce> however if it's not installable, and hasn't that many users, it probably won't matter
<tjaalton> the driver uses "via" name anyway, so on upgrade the users will end up using openchrome
<tjaalton> umm
<tjaalton> or maybe not
<tjaalton> openchrome sucks in modesetting though
<tjaalton> poor via users, nobody cares :)
<bryce> hehe
<tjaalton> bdmurray: nvidia-xconfig is still there, but maybe it should be dropped
<tjaalton> but not before jockey has a cmdline option
<ubotu> New bug: #196900 in linux-restricted-modules-2.6.24 (restricted) "Ati x1600Pro White screen on active desktop fx" [Undecided,New] https://launchpad.net/bugs/196900
<bryce> night
<tjaalton> night
<Ng> is bryce's xrandr stuff going to replace the Screens and Graphics tool?
<tjaalton> I think so
<tjaalton> although they server different purpose
<tjaalton> -r
<Ng> I was playing with the latter last night at home and it does some strange stuff. I tell it my monitor is an LCD Panel that can do 1920x1080 and the highest resolution it offers is 1680x1050
<Ng> tjaalton: yeah, that's what I wondered
<Ng> the strange and wonderful thing is that X actually figures everything out itself if I remove the xorg.conf. pops straight into 1920 :)
<tjaalton> guidance trying to be clever or something
<pwnguin> man, that tool really kicked my ass when i set up our mythbox
<ubotu> New bug: #196789 in xorg (main) "while playing different games the screen field either shrinks to 1/8  screen size or is sucked into the desktop and vanishes" [Undecided,New] https://launchpad.net/bugs/196789
<ubotu> New bug: #117480 in openoffice.org (main) "OpenOffice 2.2 crashes the machine with File->Open (dup-of: 113679)" [Undecided,Confirmed] https://launchpad.net/bugs/117480
<ubotu> New bug: #189380 in sun-java5 (multiverse) "[Hardy] Can't make any java package work (dup-of: 87947)" [Undecided,New] https://launchpad.net/bugs/189380
<ubotu> New bug: #196979 in xorg (main) "laptop crashes when closing the lid" [Undecided,New] https://launchpad.net/bugs/196979
<ubotu> New bug: #98594 in xubuntu-meta (universe) "Xubuntu - Bad fonts size: Firefox, OpenOffice, interfaz user, etc (dup-of: 112514)" [Undecided,Invalid] https://launchpad.net/bugs/98594
<seb128> bryce: I officially don't like those gnome-desktop changes
<Q-FUNK> :)
<Q-FUNK> seb128: which ones?
<seb128> Q-FUNK: the xrand changes
<Q-FUNK> hmm... such as?
<Q-FUNK> here, I'm mostly worried that Hardy will be released withthe absolute piece of crap known as Firefox 3.
<tjaalton> ff3 rocks
<Q-FUNK> it's as slow as molasses and polutes the notification tray with crap.
<Q-FUNK> "upgrading" to ff3b3 that is currently in hardy made me fele like someone had removed all the RAM out of my workstation. the difference of speed was that drastic.
<tjaalton> hmm? fast as hell and my notification tray is empty :)
<Q-FUNK> tjaalton: i really wonder how you do that.  here, access speed is down to half what it was and the UI has become extremely unresponsive.
<tjaalton> uses less memory too
<Q-FUNK> not here
<tjaalton> try a new profile
<Q-FUNK> you mean they still haven't gotten rid of profiles either?
<tjaalton> eh
<Q-FUNK> hard to tell with a new profile.  it fails to import my bookmarks or my session form the other profile
<bryce> seb128: what do you not like?
<seb128> bryce: it add a lot of functions to the public api
<seb128> bryce: I think I would like better to ship copy of the code in gnome-settings-daemon and gnome-control-center if possible
<seb128> bryce: another issue is that those functions don't use a gnome_ namespace and they should
<seb128> those symbols could conflict with other libs, etc
<seb128> soren said he would accept a patch to use a correct namespace
<bryce> by 'ship copy of the code' what do you mean?
<seb128> the functions which are added to gnome-desktop
<seb128> have this code in gnome-control-center
<seb128> and gnome-settings-daemon
<seb128> so they would not be in any public library
<seb128> just code in the binaries
<bryce> ah, ok anything else?
<seb128> no
<seb128> sorry about that, but I think it's a better solution
<seb128> this way we don't provide a non stable api
<seb128> and we will not break the lib compatibility when upstream does something similar
<seb128> I mean some function names might change etc when that's upstreamed next cycle
<bryce> ok, shall I make these changes or are you planning to?
<seb128> which means the ubuntu libgnome-desktop abi would break compatibility
<seb128> I'll not do those today most likely
<seb128> you are welcome to look at those
<seb128> I'm sorry I had a very busy week
<seb128> what we can do if you want to get the things some testing is to upload the changes now as you did them
<seb128> and switch to the copies later
<bryce> yes, that would be great
<seb128> ok, I'll do that then
<bryce> I'll work on the changes today
<seb128> thanks
<soren> seb128: I said that I'd accept a patch to use a correct namespace for what?
<seb128> soren: not you, the soren from redhat who is writting the code we are speaking about
<soren> seb128: Oh, sorry. :)
<seb128> soren: sorry about the confusing with your nickname ;-)
<soren> seb128: No worries :)
<seb128> bryce: gnome-desktop changes uploaded
<bryce> seb128: thanks
<bryce> seb128: you'll be uploading g-c-c and g-s-d as well?
<seb128> bryce: looking at the gnome-settings-daemon changes
<seb128> there is no setting migration, right?
<seb128> which means user will be back to whatever xorg uses rather than what he had configured, right?
<bryce> no, it detects and starts from the current settings
<bryce> so if they achieved that via xorg.conf, it uses that; if they did it through the current screen resolution tool, it uses that.
<ubotu> New bug: #197049 in xorg (main) "[hardy] shift and caps lock keys not working" [Undecided,New] https://launchpad.net/bugs/197049
<seb128> bryce: how does that work? the user settings are written to gconf and applied on startup right now, the code applying those gconf key is replaced to use the libgnomedesktop one apparently
<ubotu> New bug: #197053 in linux-restricted-modules-2.6.24 (restricted) "package nvidia-glx None failed to install/upgrade: el subproceso post-removal script devolviÃ³ el cÃ³digo de salida de error 2" [Undecided,New] https://launchpad.net/bugs/197053
<seb128> bryce: gsd uploaded now
<bryce> what gnomedesktop does is store the configuration layout in an xml file in the user's home dir
<bryce> so (if I understand correctly) the first time it's run, it will store whatever the user has set up
<bryce> I tested on a system with dual monitors set up via a .xprofile setting, and it picked up and handled that.  If it handles that ok, it should handle most anything
<bryce> I also tested with laptops in a few different configurations and it picked up the existing settings correctly
<seb128> bryce: well, the question was whether it'll pick the setting written by the old capplet on gutsy and stored in gconf when you first log in hardy
<seb128> bryce: because I've seen no code reading those gconf keys and written a new .xprofile with the values
<seb128> bryce: which is not really an issue but could be nice to fix
<bryce> right, it does not read those gconf keys directly, just indirectly by taking them from what has been booted up (which in some ways is better)
<seb128> I fail to see how that can work
<seb128> let me take an example
<seb128> xorg default is 1024x768, user is on gutsy, he picks 800x600, the value is written to gconf
<seb128> he logs in on gutsy, gnome-settings-daemon read the gconf key, apply it and he gets 800x600
<seb128> he update the hardy, reboot
<seb128> he logs in, nothing read the key, nothing apply those, he gets 1024x768 which is the xorg config
<seb128> no?
<seb128> since gnome-settings-daemon in hardy doesn't read those keys
<bryce> hmm
<bryce> yeah I guess that's true
<seb128> ok, not a big issue but might be worth considering migration code before hardy
<seb128> should be easy to have something reading the gconf keys and writting those to xprofile on first hardy login
<seb128> bryce: looking to the capplet changes now, the patches are mostly redhat work, right?
<seb128> bryce: just wanting to give some credit where it's due in the changelog if that's the case ;-)
<bryce> the first (main) patch is from redhat, the auto* changes I did, and there's a patch I did to clean up the ui a little
<seb128> ok
<bryce> the hard part was getting the changes into the gnomedesktop lib such that everything linked to it properly
<seb128> bryce: your new capplet seems to be working but I just broke my session using it :-p
<seb128> I did rotate the screen
<bryce> I've found it certainly offers a good way to test for xrandr bugs ;-)
<seb128> but now it doesn't take any click or keyboard event
<bryce> sounds like a known xrandr bug
<bryce> fwiw, rotation worked 100% on all of the systems I tested on.
<seb128> lucky you :-p
<bryce> one system has problems when scaling up or down
<bryce> maybe we should include a note on the dialog, "Um, maybe save your work first?"
<seb128> rather "backup your disk"
<seb128> because restarting xorg doesn't fix the issue
<seb128> I've no a broken session and no way out of the command line to fix it
<bryce> the issue I ran into required a reboot
<seb128> that's not good
<seb128> well, it's applying the rotation on login
<seb128> which seems to be an issue
<bryce> hrm yeah
<seb128> where is the config file?
<bryce> ~/.gnome2/monitors.xml
<seb128> thanks
<seb128> fixed
<bryce> there should be a confirmation dialog like displayconfig-gtk has
<seb128> I've to go for diner but I've g-c-c ready for upload
<seb128> will upload later
<bryce> ok
<seb128> having what the previous capplet had would be nice
<bryce> I'll look into that next week
<seb128> a counter which reverts if you don't ack
<seb128> cool
<bryce> yeah displayconfig-gtk had that as well
<seb128> otherwise good work, it looks cool ;-)
<bryce> great
<bryce> did it get your monitor name correct?
<ubotu> New bug: #197069 in xserver-xorg-video-amd (main) "xserver-xorg-video-amd: wide resolutions don't work" [Undecided,New] https://launchpad.net/bugs/197069
<seb128_> re
<seb128_> bryce: still around?
<bryce> yup
<seb128_> I uploaded gnome-control-center
<bryce> yay!
<seb128_> xrand is really buggy on my dell laptop though
<seb128_> rotation breaks xorg in a way I've to switch to a vt and edit the xml by hand to get xorg working again
<bryce> aside from the rotation, are you seeing other issues?
<seb128_> and changing resolution corrupts part of the screen
<bryce> seb128I will put a note in the dialog on how to restore
<seb128_> yes, changing to 800x600 worked correctly, switching back to 1440x900 doesn't
<seb128_> I get what looks like a working 800x600 area
<bryce> right, that is one of the bugs I ran into on one of my systems that I mentioned
<seb128_> and a corrupted border on right and bottom which is not usuable
<seb128_> I expect intel to be not too buggy ;-)
<bryce> and you can move the mouse into those areas, and interact with buttons located there
<seb128_> expect intel not too by too buggy rather
<seb128_> yes
<seb128_> but I can't move things there
<bryce> yup, that's the same bug I found - jdub also reported it earlier, but identified it as a metacity bug
<bryce> he tried running a different window manager and it worked correctly
<seb128_> compiz consider the corruption border as the viewport limit and will switch to next one
<seb128_> I'm using compiz
<bryce> yeah mine was with compiz as well. 
<seb128_> ok
<seb128_> I think I've done my part for this week now that those packages are uploaded
<seb128_> I'll let you figure the xrandr issues ;-)
<bryce> so maybe check if the same thing happens with metacity - if not, then it may be a compiz bug
<bryce> yup
<seb128_> let me know if you need debug informations
<seb128_> well, you said jdub had the issue using it
<bryce> sure, thanks, yep I'm working on the xrandr issues
<seb128_> cool, thanks
<seb128_> and again, nice work ;-)
<seb128_> out of the xrandr bugs the capplet looks great
<bryce> the rotation one is well known; this other one I've not seen reported but I can reproduce it easily, so...
<bryce> good to hear
<bryce> still needs a few more features, but good enough for hardy.  Much better than what we've had
<seb128_> right
<bryce> tjaalton: btw I have a new patch to extend the "greedy" fix to all intel chipsets here - http://people.ubuntu.com/~bryce/Uploads/
<seb128_> bryce: btw you come you don't use a ppa for your uploads?
<bryce> tjaalton: but I'm not certain yet if it's appropriate to do that, or if it would cause more issues
<bryce> seb128_: I should start using that, I just have my workflow set up for doing local builds mostly
<seb128_> well,; you copy those on rookery apparently though
<seb128_> so you could as easily dput them on launchpad ;-)
<bryce> yep
<bryce> can you delete things from a ppa?
<mvo> tjaalton: hm, what happend to the nvidia-settings that used to be part of nvidia-glx (-new) ? is that now all folded into the nvidia-settings package?
<keescook> bryce: yeah, it's on the left side, 2nd action down, IIRC.
<tjaalton> mvo: yep
<mario_limonciell> tjaalton, why did that happen?
<tjaalton> bryce: ok, maybe after the weekend?
<tjaalton> mario_limonciell: because it has source
<mario_limonciell> oh fair enough :)
<bryce> tjaalton: sure
<bryce> tjaalton: I may have more user reports on it by then
<tjaalton> mario_limonciell: but now that the default xorg.conf has a ServerLayout section again, it's not a problem anymore.. without that it would just crash
<bryce> heya keescook
<tjaalton> man, I'd love to see fglrx banished from the archive when r5/6xx has 3D support
<mario_limonciell> tjaalton, there are similar problems with aticonfig not liking the default xorg.conf (when trying aticonfig --initial)
<mario_limonciell> i've reported them to the beta team
<tjaalton> mario_limonciell: yep
<tjaalton> well, jockey should have a cmdline interface, then every doc should mention that aticonfig/nvidia-xconfig are Evil
<mvo> tjaalton: hm, I use it in compiz to detect the available video ram, any chance to get it back ?
<mario_limonciell> well there features of the AMD driver that are not exposed via any other public interface
<tjaalton> mvo: maybe by depending on it
<mvo> tjaalton: its universe currently, but that shouldn't be too much of an issue - but let me dig a bit into it, maybe there is a different way to get the video ram
<keescook> heya bryce :) I just happened to catch your question :)
<tjaalton> mvo: btw, jockey still disables composite for fglrx, but apparently composite still has some issues..
<mvo> tjaalton: I can give it a try early next week - I can't wait to see fglrx go
<bryce> tjaalton: do you seriously think we may be able to drop fglrx?  that'd be rather stunning.  I hadn't realized things had progressed that far already
<tjaalton> mvo, bryce: no, we are not there yet :)
<tjaalton> unfortunately
<mvo> tjaalton: the "ati" driver works quite well with the r500 now in 2d, randr, suspsend all of this is good for me
<mvo> (well, radeon)
<tjaalton> 3D support is still very much a work in progress..
<tjaalton> maybe intrepid+1..
<tjaalton> r5xx docs are out, so maybe intrepid will have a mesa which supports it
<tjaalton> bryce: the archive has 2.2.1-1ubuntu2 ;)
<bryce> ah, hmm
<bryce> tjaalton: I'll rework the patches then.  I also have another quirk to add
<tjaalton> bryce: yep, saw that one
<bryce> http://bryceharrington.org/drupal/display-config-1
<tjaalton> looks nice
#ubuntu-x 2008-03-01
<bryce> tjaalton: http://ppa.launchpad.net/bryceharrington/ubuntu/pool/main/x/xserver-xorg-video-intel/
<bryce> also at http://people.ubuntu.com/~bryce/Uploads/
<bryce> hrm, I wonder how you'd post debdiffs into the ppa?
<ubotu> New bug: #197147 in xorg (main) "No gnome desktop after password" [Undecided,Incomplete] https://launchpad.net/bugs/197147
<ubotu> New bug: #197158 in xorg (main) "should not have to manually do sudo dpkg-reconfigure -phigh xserver-xorg after upgrade" [Undecided,New] https://launchpad.net/bugs/197158
<ubotu> New bug: #197163 in xorg (main) "mathematica 6.0.1 in Hardy" [Undecided,New] https://launchpad.net/bugs/197163
<ubotu> New bug: #197182 in linux-restricted-modules-2.6.24 (restricted) "Please upgrade nvidia to 169.12" [Undecided,New] https://launchpad.net/bugs/197182
<ubotu> New bug: #197209 in linux-restricted-modules-2.6.24 (restricted) "fglrx + compiz fusion won't resume" [Undecided,New] https://launchpad.net/bugs/197209
<ubotu> New bug: #196970 in xorg (main) "keyboard partially fails [Hardy Regression]" [Undecided,Confirmed] https://launchpad.net/bugs/196970
<ubotu> New bug: #197198 in xorg (main) "Totem crashes when trying to play anything" [Undecided,Incomplete] https://launchpad.net/bugs/197198
<ubotu> New bug: #193559 in linux-restricted-modules-2.6.24 (restricted) "atieventsd crashed with SIGSEGV in XQueryExtension()" [Undecided,Incomplete] https://launchpad.net/bugs/193559
<ubotu> New bug: #193878 in linux-restricted-modules-2.6.24 (restricted) "amdcccle crashed with SIGSEGV" [Undecided,Incomplete] https://launchpad.net/bugs/193878
<ubotu> New bug: #196288 in xserver-xorg-input-mouse (main) "USB Mice do not work on Dell Precision M6300" [Undecided,Incomplete] https://launchpad.net/bugs/196288
<ubotu> New bug: #197242 in xorg (main) "radeon drm locking problem: xorg freezes  with gutsy and radeon 7500" [Undecided,New] https://launchpad.net/bugs/197242
<ubotu> New bug: #197230 in xorg "Ubuntu 8.04 alpha 5 won't boot in qemu 0.9.1" [Undecided,Confirmed] https://launchpad.net/bugs/197230
<ubotu> New bug: #196858 in xorg (main) "Video not detected Hardy KDE 4" [Undecided,Incomplete] https://launchpad.net/bugs/196858
<ubotu> New bug: #197263 in xorg (main) "[hardy] xserver freezes the system" [Undecided,New] https://launchpad.net/bugs/197263
<ubotu> New bug: #188452 in ubuntu "Ubuntu in X-org don't detect serial mouse.. (dup-of: 9068)" [Undecided,New] https://launchpad.net/bugs/188452
<ubotu> New bug: #197291 in xserver-xorg-video-intel (main) "tty broken after last update of xserver-xorg-video-intel" [Undecided,New] https://launchpad.net/bugs/197291
<ubotu> New bug: #196617 in xorg (main) "[Hardy Alpha-5] fglrx log noise if dualhead" [Undecided,New] https://launchpad.net/bugs/196617
<ubotu> New bug: #197269 in xorg-server (main) "Xorg crashed with SIGSEGV in free()" [Undecided,New] https://launchpad.net/bugs/197269
<ubotu> New bug: #196391 in xorg (main) "2d performance is slower after resume  (acpi S3 sleep)" [Undecided,New] https://launchpad.net/bugs/196391
<ubotu> New bug: #196343 in xorg (main) "Selecting nvidia restricted driver kills gnome" [Undecided,New] https://launchpad.net/bugs/196343
<ubotu> New bug: #196341 in xorg (main) "System reboot before login GDM" [Undecided,New] https://launchpad.net/bugs/196341
<ubotu> New bug: #196277 in xorg (main) "[hardy] keyboard layout switching shortcut doesn't work after reboot" [Undecided,Confirmed] https://launchpad.net/bugs/196277
<ubotu> New bug: #196129 in xorg (main) "[hardy] X server does not start on G3 iMac." [Undecided,Confirmed] https://launchpad.net/bugs/196129
<ubotu> New bug: #197337 in xorg (main) "[hardy][wish] vmmouse should be default driver on kvm/qemu" [Undecided,Confirmed] https://launchpad.net/bugs/197337
<ubotu> New bug: #197339 in xserver-xorg-video-intel (main) "No detection of my S-Video output" [Undecided,New] https://launchpad.net/bugs/197339
<ubotu> New bug: #57415 in xorg-server (main) "Inconsistent cut-and-paste behaviour (dup-of: 11334)" [Undecided,Invalid] https://launchpad.net/bugs/57415
<ubotu> New bug: #197414 in xorg (main) "Bulgarian phonetic keyboard layout is not the country standard" [Undecided,New] https://launchpad.net/bugs/197414
<Q-FUNK> odd
<Q-FUNK> they were the ones to invent the phonetic cyrillic keyboard, which is the best thing since sliced bread
<Q-FUNK> http://www.jukie.net/~bart/blog/fixing-x-for-geode-lx
#ubuntu-x 2008-03-02
<ubotu> New bug: #186103 in xorg (main) "Gutsy alternate installer fails to recognize display on Averatec 3280" [Undecided,New] https://launchpad.net/bugs/186103
<ubotu> New bug: #195834 in xorg (main) "[Hardy Alfa 5] Ati fglrx graphic is slow, diagonal lines and slow refreshes" [Undecided,New] https://launchpad.net/bugs/195834
<ubotu> New bug: #197542 in xorg (main) "[hardy] dell d410 Volume keys not working" [Undecided,New] https://launchpad.net/bugs/197542
<ubotu> New bug: #195486 in xorg (main) "mouse cursor not selecting/ deselecting items, boxes ect." [Undecided,New] https://launchpad.net/bugs/195486
<ubotu> New bug: #164793 in xserver-xorg-input-mouse (main) "Logitech MX610 mouse special functions doesn't work" [Undecided,New] https://launchpad.net/bugs/164793
<ubotu> New bug: #197565 in xorg (main) "overscan setting on svideo tv out w/nvidia drivers?" [Undecided,New] https://launchpad.net/bugs/197565
<ubotu> New bug: #148589 in xserver-xorg-input-mouse (main) "usb mouse stops working after a short while" [Undecided,New] https://launchpad.net/bugs/148589
<ubotu> New bug: #197576 in linux-restricted-modules-2.6.24 (restricted) "NVidia freezes with "no video decoder detected"" [Undecided,New] https://launchpad.net/bugs/197576
<ubotu> New bug: #197589 in xserver-xorg-input-keyboard (main) "hardy numeric keys problem" [Undecided,Incomplete] https://launchpad.net/bugs/197589
<ubotu> New bug: #197612 in xorg (main) "Default keyboard layout for Kurdish is wrong" [Undecided,New] https://launchpad.net/bugs/197612
<Q-FUNK> hm
<Q-FUNK> is kernel -10 known to break -intel?
<ubotu> New bug: #197620 in xserver-xorg-video-intel (main) "Make the intel driver available of the fujitsu-laptop /sys interface" [Undecided,New] https://launchpad.net/bugs/197620
<ubotu> New bug: #197626 in libxi (main) "[hardy] xinput hotplug buggy" [Undecided,New] https://launchpad.net/bugs/197626
<ubotu> New bug: #197651 in xserver-xorg-driver-ati "Compiz doesn't work with an ATI rv100 board by default, while it could" [Undecided,New] https://launchpad.net/bugs/197651
<ubotu> New bug: #197680 in xserver-xorg-video-ati (main) "rotation doesn't work with this board" [Undecided,New] https://launchpad.net/bugs/197680
<ubotu> New bug: #197722 in xserver-xorg-video-intel (main) "[Hardy, intel-video-driver] X Crashes frecuently and system freezes" [Undecided,New] https://launchpad.net/bugs/197722
<ubotu> New bug: #183913 in xorg (main) "320x240 screen mode not supported" [Undecided,Incomplete] https://launchpad.net/bugs/183913
<superm1> hey bryce i had some follow up info to your original concerns bout whats going to happen if everything gets locked down digital
<superm1> you should take a look through this thread
<superm1> http://www.gossamer-threads.com/lists/mythtv/users/319444
<twb> My VIA Unichrome card is detected wrong by Hardy 8.04a5.  Here's the fix: sed --in-place "/11063344/d" "/usr/share/xserver-xorg/pci/via.ids"
<twb> (That PCI ID is in both via.ids and unichrome.ids, and so xorg uses via, which results in a "no screens found".)
<bryce> superm1: cool thanks
<superm1> bryce, yeah that will be a very exciting time if we really have support for it :)
<superm1> i don't think i'd care it being analog at that point
<tjaalton> twb: the server should always use openchrome..
<tjaalton> twb: oh you mentioned unichrome
<bryce> superm1: hmm, I might be misunderstanding, but this sounds like it's just a PBS HD show, but PBS doesn't encrypt their stuff
<twb> Shrug.
<twb> All I know is that, unmodified, the livecd tries to use via, fails, and then GDM pops up a "pick a drive, chum" dialog using vesa.
<twb> And that blatting that line from via.ids makes it all Just Work, and GNOME comes up straightaway.
<twb> I also note that xorg.conf contains no driver "foo" entry in the Device section, which is different to Gutsy and suchlike.
<tjaalton> yes
<tjaalton> twb: file a bug so it's not forgotten
<twb> Too hard.
<tjaalton> ok then
<twb> I'll maintain my own patches until it shows up in Debian, where I can use reportbug.
<ubotu> New bug: #197764 in xserver-xorg-video-intel (main) "Compiz fails to launch with Intel 965GM on Thinkpad X61s" [Undecided,New] https://launchpad.net/bugs/197764
<superm1> bryce, well that device captures analog HD
<superm1> and encodes it to x264
<superm1> twb, you can use reportbug in Ubuntu
<twb> superm1: last time I checked, it sent mail to a subscriber-only mailing list... ubuntu-users, IIRC.
<superm1> twb, there's also a launchpad email interface
<twb> I know.
<twb> I don't wish to discuss it.
<twb> We'll just end up shouting at one another.
<superm1> er okay
<tjaalton> twb: so you just assume that we'd fix that right away?
<twb> No.
<twb> I'm reporting it here, which is easy for me to do.  Whether you choose to do anything is entirely up to you.
<bryce> twn, sorry, the procedure for X bug reporting is to use Launchpad.  That makes it possible to contact you if more information is needed, and to notify you of fixes to test.  If you choose not to file a bug report, that is your prerogative but it is unlikely your issue will be investigated, as we have ample bug reports that *have* followed the procedure.
<twb> Understood.
<ubotu> New bug: #177786 in xserver-xorg-video-v4l (main) "PWC Webcam (Logitech Quickcam Orbit/Sphere) does not work well in Gutsy but worked in Feisty" [Undecided,New] https://launchpad.net/bugs/177786
<ubotu> New bug: #197681 in xorg (main) "cannot display this video mode" [Undecided,New] https://launchpad.net/bugs/197681
#ubuntu-x 2009-02-23
<Alexia_Death> tseliot: how is your hotplug daemon in C caoming along?
<tseliot> Alexia_Death: fine, it needs an XML parser and (maybe) I'll also expose some dbus methods so that other applications can call them
<Alexia_Death> :)
<Alexia_Death> If you have something to test let me know:)
<tseliot> Alexia_Death: of course I'll give credit to you for the idea and for the Python implementation :-)
<Alexia_Death> :)
<tseliot> of course I'll let you know. I've been quite busy recently which is why I haven't finished the daemon
<Alexia_Death> :) Jaunty is ready for such a thing, even if it comes later than release.
<Alexia_Death> tseliot: you use launchpads bazar for the project?
<tseliot> Alexia_Death: not yet, but I will. And yes, of course it will work on Jaunty too
<Alexia_Death> ok:)
<tseliot> currently it takes only 232kb of RAM
<tseliot> which is good but I'll improve it
<tjaalton> tseliot: I tried the xorg-options-editor, but it fails to configure. you know about it?
<tseliot> tjaalton: what happens exactly?
<tjaalton> tseliot: http://pastebin.ubuntu.com/121863/
<tjaalton> maybe a pycentral update would fix it
<tseliot> tjaalton: it's a packaging issue caused by the changes in pycentral. I know how to fix it
<tseliot> as I had the same problem with dontzap
<tjaalton> tseliot: ok, good
<tseliot> tjaalton: thanks for reporting
<tjaalton> np
<tjaalton> tseliot: hum, it configured fine after a dist-upgrade
<tjaalton> or during one, rather
<tseliot> weird
<tseliot> tjaalton: does it work if you launch it?
<tjaalton> yes
<tseliot> ok, less work for me then ;)
<tjaalton> bryce: a couple of xorg-server commits are missing from git
<tjaalton> +your
<tseliot> tjaalton: do you know if Eric Anholt's commit is included in Jaunty? https://bugs.freedesktop.org/show_bug.cgi?id=19037#c8
<ubottu> Freedesktop bug 19037 in App/xrandr "Some libxrandr 1.2.99.2 requests cause hugely repeated EDID requests" [Major,Resolved: fixed]
<tjaalton> tseliot: yep, it is
<tseliot> tjaalton: weird, it doesn't seem to fix the problem (completely)
<tseliot> federico1: I have fixed a bug in gnome-settings-daemon: http://bugzilla.gnome.org/show_bug.cgi?id=572876
<ubottu> Gnome bug 572876 in plugins "gnome-settings-daemon does not load the saved RandR configuration" [Normal,Unconfirmed]
<bryce> tjaalton: which commits?  My git tree is saying that its committed through -0ubuntu7
<federico1> tseliot: thanks, checking...
<tjaalton> bryce: 0u5 is what I got the server, but maybe I did something wrong :)
<federico1> tseliot: hmm, that doesn't look quite right.  But let me take a shower and I can test this when I come back
<federico1> tseliot: do you have other patches on top of g-s-d that could be affecting that function's behavior?
<tseliot> federico1: let me check
<federico1> brb
<tseliot> federico1: no
<tseliot> federico1: it works. Basically it was calling the goto too early therefore the intended config file was never applied
<tseliot> federico1: and the patch was applied against the svn code
<bryce> tjaalton: 6652c592 is the last commit in my tree
<federico1> tseliot: why did your code enter the "if (!g_error_matches (..., NOENT))" case?
<federico1> tseliot: i.e. can you trace it and see what the error is there?
<federico1> brb now really
 * federico1 goes to shower
<jcristau> bryce: you just pushed that one, right?
<bryce> yes, e924ed511 was the previous one
<tseliot> federico1: are we looking at the same patch??? http://bugzilla.gnome.org/attachment.cgi?id=129350&action=view
<tseliot> aah, I see what you mean
<tseliot> federico1: I don't have a backup file, just the intended file
<tseliot> federico1: which is weird since G_FILE_ERROR_NOENT should catch that
<federico1> hmmm
<federico1> tseliot: can you trace it while only having monitors.xml and not the backup file, and see what happens?
<federico1> I'm 98.73% sure that NOENT works fine on my box
<tseliot> federico1: sure
<tseliot> brb
<tseliot> I'm back
<tseliot> federico1: do you mean, running the daemon with strace?
<tseliot> federico1: I did it but I didn't find anything useful.
<tseliot> federico1: as I said in the bug report, if a backup file is available then the settings in the backup file are applied, otherwise nothing happens
<tseliot> federico1: strace doesn't show that the daemon is trying to open monitors.xml
<Laney> What would be useful for a bug report about xorg hosing the CPU?
<Laney> exciting, a wiki page about it
<Laney> downgrading to Intrepid's version fixes it
<tseliot> federico1: it looks like the Gerror is NULL :-/
<bryce> tjaalton: all squared away with xserver now?
<bryce> heya tseliot
<tseliot> hey bryce
<tjaalton> bryce: yes, looking good now
<bryce> xserver-xorg-input-keyboard cleaned out (down to 1 bug)
#ubuntu-x 2009-02-24
<bryce> xrandr cleaned out (20 -> 0 bugs)
<pwnguin> 20 patches, or 20 "please test again"?
<RAOF> Or 20 "not a bug in xrandr", or 20 "this bug is fixed" :)
<bryce> mostly "not a bug in xrandr", and moved to the more appropriate package
<bryce> http://people.ubuntu.com/~bryce/totals.svg
<bryce_> tjaalton, jcristau: what package handles capslock toggling?  Is that -evdev or the server, or ...?  trying to figure out where bugs like 207960 go... I'm figuring xkeyboard-config probably is not the right place
<tjaalton> bryce_: I guess it's the server. would be nice to know if it works in jaunty though
 * bryce_ nods
<bryce_> ok, seems capslock issues are scattered around, I'll pull them into xorg-server and see if some sense can be made of them
<tjaalton> did you see the list of deprecated input drivers by whot? what do you think if we should drop those, since I think none of them actually build anymore
<tjaalton> or just leave them as is until debian drops them, and fix the build in the meantime if someone needs them
<bryce_> yep, I saw the list.  I've been thinking we should deprecate them for quite some time
<tjaalton> none of them have any bugs filed, which clearly shows that no-one is using them :)
<bryce_> whether to drop them now or wait 'til debian drops them, I'm open.  
<bryce_> what's your opinion?
<tjaalton> I'll ask them first
<bryce_> ok
<tjaalton> IIRC it has been discussed before, so probably that's what will happen
<bryce_> btw, I'm hoping to continue my bug stomping tour through xserver and -intel before the release is out.  Those are biggies though, so dunno that I'll make it through any other packages
<bryce_> if you have any time, it would be great if you could look through -evdev (and maybe -mouse)
<tjaalton> ok, I'll see what I can do
<Alexia_Death> Does x support any sort of per device mouse acceleration setting? I have a touchpad and an USB mouse I hotplug. the mouse is high DPI and generates a lot of jitter. However, truning aceleration down makes my touchpad unusable.
<tjaalton> Alexia_Death: not that I know of
<Alexia_Death> tjaalton: :( that sucks.
<tjaalton> at least xinput doesn't show any properties
<tjaalton> maybe master is better
<bryce> heh, after all that capslock work, turns out I think the main bug I was looking at is already fixed (at least it works for me).
<bryce> anyway, night.
<tjaalton> night :)
<Ng> tjaalton: hrm, it feels like the vblank change didn't really change anything
<tjaalton> Ng: really?
<Ng> tjaalton: workspace switches feel like they get stuck for a fraction of a second and then just redraw the desktop. sometimes it does the smooth swipe, but some/most times it feels like it's jumping
<Ng> it's kinda hard to describe ;)
<tjaalton> sounds familiar
<tjaalton> I need to check it out later
<Ng> I suppose, for fairness, I should reset my compiz settings to the defaults
<tjaalton> please do, or test with a new user :)
<Ng> well that was fun, I switched profile in ccsm and X wedged
<Ng> few of these in dmesg: [  648.929470] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0
<tjaalton> you've rebooted since the new mesa?
<Ng> my last reboot was about 15 minutes ago, my last update was within the last couple of hours
<tjaalton> ok
<Ng> I have mesa 7.3-1ubuntu2
<tjaalton> I'm thinking if the patches that are already applied cause some regressions
<tjaalton> but since we are not going to use vblank those could probably be dropped
<tjaalton> from the kernel
<Ng> even with pretty much default compiz settings I'm still seeing it, I guess I'll try a fresh user later
<mvo_> I'm seening very strange behaviour sometimes with jaunty X, some mouse actions (like clicking on the panel do not work) and some keys (like alt-tab, alt-f1) do not work. buttons in apps (like thunderbird) can not be clicked. its as if something has a grab on the mouse/keyboard and not letting go of it or something. have you seen bugreports like this?
<mvo_> IIRC evan had something similar during the sprint, so I think its not my spooky hardware
<tjaalton> I've not seen that
<tseliot> tjaalton: did you read this? http://www.phoronix.com/scan.php?page=news_item&px=NzA4Ng
<tseliot> weird
<tjaalton> tseliot: the nouveau article?
<tseliot> yep
<tseliot> it looks like they will use it instead of nv
<bryce> mvo_, I've seen some reports of weird grabbing behavior, in xserver-xorg-input-evdev iirc
<tjaalton> tseliot: what's weird about it? :)
<bryce> sounds like very good news to me; we've been needing someone to volunteer to guineapig it, so we can use it in karmic :-)
<tseliot> tjaalton: does it mean that it works better than "nv" already? It would be great news
<mvo> bryce: I have no idea where to even start debugging this, but I get it every now and than, nothing really unusual in the logs AFAICS 
<bryce> tseliot: if it didn't, I'm not sure that would stop fedora ;-)
<tseliot> hehe
<tseliot> right
<tjaalton> tseliot: for some chips it actually works, so
<tseliot> even better
<tseliot> ;)
<bryce> mvo: well, on the theory that it's an -evdev bug, if you have steps to reproduce reliably, an easy start might be to try running an older release of -evdev
<bryce> (assuming this is a regression for you)
<bryce> another possibility is a bug in the xserver, so reverting that back might be the next step, if it's not too difficult
<mvo> bryce: ok, that sounds good. I will start with going back with -evdev . the trouble is that it seems to be not reliable to reporduce (or at least I have no pattern yet)
<bryce> mvo: next two times it happens, check what processes are running to see if there are commonalities
<bryce> it is possible there is something which is triggering the grab.  There is one bug I'm aware of I looked at yesterday, let me find it again
<bryce> tjaalton: thoughts on bug #320632 ?
<ubottu> Launchpad bug 320632 in xfree86-driver-synaptics "tap-to-click and edge-scrolling broken in Jaunty" [Medium,Confirmed] https://launchpad.net/bugs/320632
<tjaalton> bryce: tseliot has been working on it recently, but I think there are some related fixes in 2.6.29
 * tseliot has a look at the bug report
<tseliot> bryce, tjaalton: there are some problems with ALPS touchpads but, since I don't own one yet, there is very little I can do
<tseliot> this might change though ;)
<bryce> ok, tseliot can I put you in touch with SteveA on 320632?  He has reproduced the issue on a recent upgrade and has some questions about it
<tseliot> bryce: ok
<thomasdelbeke> Hi there
<thomasdelbeke> I was referred to here by seb128
<thomasdelbeke> I reported earlier:
<thomasdelbeke> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/323694
<ubottu> Ubuntu bug 323694 in xserver-xorg-input-evdev "xorg + VGA driver + BIOS incompatibility ; Symtom: right keypad does no longer work." [Undecided,New]
<thomasdelbeke> Now I have a new one:
<thomasdelbeke> http://paste.ubuntu.com/122485/
<thomasdelbeke> Is it the same?
<Laney> http://pastebin.com/f6da02497 is this normal? I'm experiencing incredible slowness on my desktop
 * Ng wonders if bug 296167 would be worth an SRU - it's the top bug in a "by number of users affected" search on xorg-xserver, by some margin
<ubottu> Launchpad bug 296167 in ubuntu "X.org will stop responding to mouse clicks on Ibex with Xinerama. Occurs frequently, Fatal Error." [Undecided,Confirmed] https://launchpad.net/bugs/296167
<Ng> I do like that search mode :)
<bryce> Ng: is there a regression-free patch identified?
<Ng> I had a quick poke in the linked fedora bug and it doesn't look like they've linked/attached a patch, just pointed at a cause and a build with it fixed :/
<bryce> heh, I see I asked someone already to locate the patch, and the responses are just "is it fixed yet?"
<bryce> yeah I tried to poke at it myself but couldn't find the patch
<bryce> so no SRU until we have a patch
<Laney> I just filed bug 334066
<ubottu> Launchpad bug 334066 in xorg "xorg is terribly slow after Intrepid -> Jaunty upgrade" [Undecided,New] https://launchpad.net/bugs/334066
<Laney> quite welcome to bisect if someone can assist
<Laney> s/welcome/willing/
<tjaalton> Laney: purge fglrx
<Laney> tjaalton: It happens with -ati too though
<tjaalton> it doesn't support the new xserver, and having the module loaded means that you get no DRI
<Laney> but right, I will do that anyway
<maxb> This is a bit perplexing. Many times today, I have: right clicked the update notifier, chosen "install all updates". Waited. Brought the "Untitled window" of synaptic to the front. At this point compiz crashes.
<maxb> metacity seems to autostart in its place
<maxb> any thoughts on things I could include to make a useful bugreport?
<tjaalton> maxb: more in the -desktop territory
<maxb> ah, fair enough
<Laney> hmm
<Laney> actually that bug isn't right
<Laney> if I disable the metacity compositor it returns to normal speed
<albert23> Ng, bryce: ï»¿296167 seems to be http://bugs.freedesktop.org/show_bug.cgi?id=18668. Steven Harms reports the fix works in Intrepid. 
<ubottu> Freedesktop bug 18668 in Server/general "Mouse buttons sometimes stop responding when moving from one xinerama screen to another" [Critical,Resolved: fixed]
<albert23> Pushed as 9fe9b6e4ef669b192ee349e3290db5d2aeea273c and nominated for 1.6
<bryce> Laney: see wiki.ubuntu.com/X/Troubleshooting  and the bit about fglrx conflicting with ati and how to fix
<bryce> albert23: thanks, can you update the lp bug report?
<albert23> bryce: sure, I will
<Ng> albert23: win :)
<Laney> bryce: It all seems removed (that uninstallation script is nowhere to be found though)
<bryce> Laney: ok, and after rebooting is the issue still present?
<Laney> bryce: With the metacity compositor off it's mostly fine
<Laney> moving/resizing windows is much better
<Laney> but scrolling in applications seems pretty sluggish still
<bryce> Laney: lspci | grep VGA ?
<Laney> 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon X1950 GT
<bryce> hmm, that's a r580
<bryce> in theory that should be well supported by -ati, however the support is relatively new so there could still be bugs
<bryce> Laney: is there anything of interesting note in your Xorg.0.log?  In particular look to see if you're using XAA or EXA acceleration
<bryce> also if you're using EXA, test if XAA makes a difference (or vice versa)
<bryce> beyond that, please file a bug via `ubuntu-bug xserver-xorg-video-ati` and we can follow up on launchpad.
<Laney> roger
<Laney> (II) RADEON(0): XAA Render acceleration unsupported on Radeon 9500/9700 and newer. Please use EXA instead.
<Laney> (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA)
<Laney> is that normal?
<Laney> not supported, using it anyway :(
<Laney> looks like I should wait for 6.12
#ubuntu-x 2009-02-25
<bryce> Laney: https://edge.launchpad.net/~bryceharrington/+archive/ppa - git snapshot of what will be going into 6.12.0
<Laney> I'll give it a test
 * Laney restarts x
<Laney> (did -ati used to support compiz? I think I remember it doing so but maybe I'm wrong)
<bryce> on 5xx and earlier it does
<Laney> hm
<Laney> anyway I think this driver is a bit better
<bryce> I've got it on my ati system right now
<Laney> http://www.nibbledish.com is very choppy when scrolling in FF though
<Laney> and metacity's compositor still brings it to a crawl
<bryce> works fine for me, with compiz
<Laney> I cannot enable compiz
<bryce> oh I see, you still have fglrx installed
<Laney> do I?
<bryce> look at your bug report - https://bugs.edge.launchpad.net/ubuntu/+source/xorg/+bug/334066
<ubottu> Ubuntu bug 334066 in xorg "xorg is terribly slow after Intrepid -> Jaunty upgrade" [Undecided,Invalid]
<bryce> NonfreeKernelModules: fglrx
<bryce> that's your problem
<Laney> I killed it all since then
<Laney> tjaalton already told me this
<bryce> https://wiki.ubuntu.com/X/Troubleshooting/FglrxInteferesWithRadeonDriver
<Laney> yeah
<bryce> ok hmm, not sure.  try the ppa driver I posted once it's finished building.
<Laney> I already built it myself and installed it :)
<bryce> ah gotcha
 * bryce kicks ppa
<Laney> woah, wait a second
<Laney> I don't know what I did, but it's alive now
<Laney> I did a full restart (had done one after killing fglrx but not after installing the PPA version), that must have done the trick
<Laney> thanks for your help bryce \o/
<bryce> Laney: no prob, thanks for testing that
<mvo> bryce: re focus/grab problems I described yesterday. I reverted to the jaunty version of -evdev - the problem has not reappared yet. I keep a eye open
<Ng> tjaalton: somewhat subjectively, it feels like this sluggish X I'm seeing is very much tied to system load - I'm applying the morning round of updates atm and even opening menus is crawling. Obviously load will hurt X, but it feels subjectively much worse than Intrepid
<tjaalton> Ng: you had a G45?
<Ng> tjaalton: that machine isn't jaunty yet, this is on my X3100 laptop
<Ng> GM965, whatever
<Ng> sunbird isn't being wildly gentle with the CPU, but it's not munching all of one core, let alone both, and there don't seem to be an unusual number of interrupts or other vmstat type things
<tjaalton> mine works fine, so I'm not sure what's wrong
<Ng> hmm
<mnemo> intel 2.6.2 is out, that's nice.. i wonder what kind of stuff they fixed in it
<Ng> tjaalton: EXA, right?
<tjaalton> Ng: yes
 * Ng hmms, the log looks normal, it's showing direct rendering
<Ng> out of interest, can I make it use UXA?
<tjaalton> yes
<Ng> I'm not expecting it to be better, but I'm curious to try it
<Ng> http://pastebin.com/f1ecd0032 is my log - the only bits I see that I'm not used to seeing are the dumps of PIPEBSTAT before and after something
<Ng> and dmesg has errors from i915.ko about vblank counts for disabled pipe 0, presumably because I'm using pipe B
<Ng> tjaalton: (would that be with Option "AccelMethod" "UXA" ?)
<tjaalton> Ng: (yes) :)
<Ng> ta
<Ng> I hope I can figure out what's straining X, this is going to be very hard to live with for 6 months ;)
<tjaalton> heh :)
<tjaalton> try a livecd too
<Ng> tjaalton: yeah good plan
<popey> Ng: normal or extra effects in compiz?
<Ng> normal
<Ng> I reset my settings with ccsm yesterday, but I've not tested it with a fresh user or a livecd yet
<popey> if i have extra (on my 945) and banshee is starting up, resizing a terminal window results in one frame of wobbled sides followed by the full screen terminal
<popey> in fact with one core flat out (thanks banshee) i get much the same
<popey> if i close banshee (getting a core back) then it seems to recover somewhat
<popey> still not stellar
<tjaalton> hmm, suspend/resume works again, even with UXA
<tjaalton> bryce: filed bug 334578, could you confirm and subscribe u-a? :)
<ubottu> Launchpad bug 334578 in xserver-xorg-input-dmc "Please remove unmaintained drivers from the archive" [Wishlist,New] https://launchpad.net/bugs/334578
<bryce> tjaalton: sweetness, yes I'll confirm
<bryce> tjaalton: btw will you be merging the xserver 1.6 once alpha-5 freeze is over?
<tjaalton> bryce: sure, it needs some other bits too though
<tjaalton> at least the new libdrm
 * bryce nods
<RAOF> Is bug #328944 or either of your radars?
<ubottu> Launchpad bug 328944 in libdrm "DRM_PROP_NAME_LEN undefined" [Undecided,Confirmed] https://launchpad.net/bugs/328944
<tjaalton> RAOF: yes, will get in together with libdrm 2.4.5
<RAOF> Cool.
<RAOF> I wasn't sure what wanted to happen there, otherwise I would have done it :)
<tjaalton> I never got to uploading it
<RAOF> The version of libdrm with libnouveau-drm patched on?  I noticed :)
<tjaalton> I bet
<RAOF> Eh.  It's not exactly critical.
<RAOF> I wonder if nouveau gallium builds again...
<tjaalton> I know, that's why you haven't been pushing it since ;)
#ubuntu-x 2009-02-26
<bryce> wrote up https://wiki.ubuntu.com/X/Architecture
<bryce> (corrections welcomed)
<pwnguin> you know, I'd kind of expect a maintainer of inkscape to cook up a better diagram than that ;)
<bryce> heh, actually I didn't draw that
<bryce> I may redo it nicely in inkscape next time I have a chunk of time
<bryce> but other than being ugly it's not a bad diagram
<pwnguin> where does the kernel stop / start?
<bryce> in the diagram, the kernel would be the box labeled "Graphics Hardware"
<bryce> everything above that is userspace
<tjaalton> whoever drew that forgot the "DRI driver" box :)
<RAOF> bryce: You seem to have opened a bug task for DRI2 against nouveau.  Any particular reason? :)  The 3d component is (a) not included in Ubuntu, and (b) aggressively unsupported upstream.
<tjaalton> RAOF: I think it's just a tracker
<RAOF> Yeah.  I just think it gives the wrong impression.
<tjaalton> maybe importance could be lower
<RAOF> I don't think it should be on that bug at all - nouveau in Ubuntu doesn't support 3d, so that bug doesn't apply, and by the time upstream stops asking me to not ship the 3d component in any packages whatsoever, it'll be supporting DRI2.
<tjaalton> hmm well I marked it wishlist already
<RAOF> Just as long as it doesn't give users the impression that nouveau does 3d at all. :)
<RAOF> As it currently stands.
<tjaalton> right
<tjaalton> maybe mark it wontfix instead with a note that it can be reopened once there is something to offer?
<RAOF> I'll do so, yes.
<tjaalton> thanks
<tjaalton> hm, dexconf is not run when using the alternate installer
<tjaalton> meaning that xorg.conf is empty
<tjaalton> laptop wedged with UXA.. time to switch back to EXA
<tjaalton> "geez, no ctrl-alt-bspace!".. although the only "key" that works seems to be the rfkill-switch
<ion_> I have an identical problem to http://launchpad.net/bugs/330126. I wonder how to debug?
<ubottu> Ubuntu bug 330126 in xorg-server "Xorg crashed with SIGSEGV in xf86_wrap_crtc_notify()" [Medium,New]
<tjaalton> http://wiki.ubuntu.com/X/BackTracing
<tjaalton> sorry
<tjaalton> http://wiki.ubuntu.com/X/Backtracing
<ion_> The backtrace is in the bug report.
<ion_> Mine was identical.
 * bryce looks
<bryce> ion_: hmm, well the trace isn't showing that it's just a simple null pointer issue, so the next step for this bug is to step through the code in xf86_wrap_crtc_notify() and examine the values to see why it is segfaulting
<bryce> possibly there's memory corruption of the config or scrn data structures
<ion_> Iâll try to do that.
<tjaalton> isn't it a dupe of bug 319210?
<ubottu> Launchpad bug 319210 in xorg-server "[jaunty] segfault during X startup with randr < 1.2 drivers" [High,In progress] https://launchpad.net/bugs/319210
<bryce> mm, maybe.  ion_ it would be helpful if you could test the patch attached to that bug.  It revises how xf86_wrap_crtc_notify works, which may prevent the segfault
<ion_> Will do.
<ion_> bryce: The patch (that is, the result of âgit diff ea309e47457156b60aadbf113f04e5b6851029c8^ ea309e47457156b60aadbf113f04e5b6851029c8â applied to the Ubuntu source packageâs tree) fixed the problem.
<ion_> Thanks
<bryce> ion_: sweet, thanks for testing
<bryce> ion_: can you comment as such on the bug, and assign it to me, and I'll put the patch in when I get a chance
<bryce> oh actually
<ion_> Someone already mentioned it fixes savage in the comments of 319210.
<bryce> 319210 is already assigned to me, so comment your test findings there
<bryce> I'll dupe your other bug to that
<ion_> I already duped it. (It was reported by someone else than me.)
<bryce> ahh, great thanks
<ion_> Should i still add a comment?
<bryce> sure
<bryce> extra confirmations of a fix are always welcome
<ion_> Alright
<tjaalton> bryce: it's already in 1.6, so we'll get it with the merge
<tjaalton> hm, so there's a patch to wacom that adds WcmNewInputDeviceRequest()
<tjaalton> might test that some time
<bryce> tjaalton: oh right, I already mentioned that in the git changelog
<tjaalton> hehe
<bryce> I thought that looked familiar :-)
<bryce> tjaalton: xserver-xorg-video-suncg6 can be sync'd too can't it?
<tjaalton> bryce: I don't think it would build
<tjaalton> 4ubuntu1 unincludes xf86Version.h
<bryce> hmm ok
#ubuntu-x 2009-02-27
<tjaalton> could someone explain why increase in DPI makes the fonts larger?
<tjaalton> when the fontsize isn't changed
<tjaalton> I had to change the size to 9 on all my setups (laptop, 24" monitor, 30" monitor)
<tjaalton> AIUI the fonts should appear _smaller_ when DPI increases
<wgrant> tjaalton: GTK sees the DPI increase, which means something the same pixel-size will appear smaller on the monitor.
<wgrant> Thus it compensates, increasing the pixel-size of the font, for the same pt size.
<superm1> so is something wrong with it's algorithm for compensation then?
<wgrant> I don't think so.
<wgrant> I think we're all just so used to the DPI being forced.
<wgrant> And GNOME fonts are in reality really big by default.
<tjaalton> sigh..
<hyperair> hi. i'm curious about the current status of the intel driver in jaunty. does anybody know?
<hyperair> i just tested a livecd i downloaded two days ago and it seems that there's still the performance regression
<tjaalton> what regression?
<ion_> *Of course* the fontsâ pixel size has to be bigger if the resolution of the screen is higher.
<seb128> tjaalton: has the vblank issue been fixed in jaunty?
<hyperair> tjaalton: from 60fps to 30fps in a game
<tjaalton> seb128: yes
<ion_> Also, if the DPI is calculated wrong, add a DisplaySize line to xorg.conf
<tjaalton> seb128: by not using vblank
<seb128> tjaalton: ok, I should drop the drirc workaround then thanks ;-)
<tjaalton> hyperair: what chip?
<hyperair> tjaalton: it's still playable, just that everything moves extra-slowly
<seb128> tjaalton: I was just wondering if that was the issue some users were complaining about but seems it's not
<hyperair> tjaalton: i965
<tjaalton> hyperair: what game, and compared to what version?
<tjaalton> I've got a i965 and am pleased with it
<hyperair> tjaalton: touhou 07 -- perfect cherry blossom. comparing intrepid fully updated to jaunty
<hyperair> yeah if you don't play games you don't notice anything
<tjaalton> right
<tjaalton> I don't :)
<hyperair> yep
<hyperair> see
<tjaalton> except on my ps3
<hyperair> hahah
<hyperair> for some very strange reason, performance with compiz on/off is the same
<hyperair> =\
<hyperair> i tried running metacity, making sure the compositer is off and everything
<seb128> who plays games under linux anyway
<tjaalton> seb128: I'm not sure if there are regressions jaunty->jaunty, those are what interest the most atm
<hyperair> me damnit! 
<hyperair> tjaalton: uxa doesn't exactly seem to help either
<hyperair> tjaalton: i noticed that DRI2 is disabled with EXA though
<tjaalton> ok
<tjaalton> DRI2 requires UXA
<tjaalton> on intel
<hyperair> but it was running with EXA on the earlier jaunty images =\
<hyperair> UXA wouldn't even start
<tjaalton> it still is
<hyperair> wait what?
<hyperair> DRI2 doesn't run when EXA is running right?
<tjaalton> exa is used by default, not uxa
<hyperair> that's the current situation
<hyperair> correcct?
<tjaalton> uh
<tjaalton> dri2 isn't used
<tjaalton> because uxa isn't used
<hyperair> except when UXA is used
<hyperair> yeah
<hyperair> but i stared at the logs in one of the earlier jaunty builds
<hyperair> it said DRI2 was up
<hyperair> and EXA was up
<tjaalton> can't be
<hyperair> nope, i'm very sure about this
<hyperair> i lost the image though damnit
<hyperair> because i turned on wobbly windows
<hyperair> and moved glxgears around
<hyperair> and LIBGL_ALWAYS_INDIRECT was not set
<tjaalton> (WW) intel(0): DRI2 requires UXA
<hyperair> yaeh now it says that
<hyperair> earlier it didn't
<hyperair> when i turned on UXA via xorg.conf, it gave me artifacts and wouldn't even start
<tjaalton> well, uninteresting at this point
<hyperair> yeah
<tjaalton> if it used dri2 or not
<hyperair> but right now there's still the whole slowdown issue
<tjaalton> I'd say the chances to fix it for jaunty are nil 
<hyperair> sigh
<hyperair> that's pretty sad =\
<hyperair> tjaalton: this is rather interesting. i'm now in a jaunty liveusb
<hyperair> ubuntu@ubuntu:~$ sudo chmod 0666 /dev/dri/card0 && glxgears
<hyperair> 4656 frames in 5.0 seconds = 931.029 FPS
<tjaalton> so?
<hyperair> otherwise it's 100+
<hyperair> which means there's an issue regarding stuff accessing dri isn't it?
 * hyperair pokes tjaalton
<tjaalton> I'm awake
<hyperair> hmm lemme try that game again
<tjaalton> is the livecd used in video group?
<tjaalton> user
<hyperair> nope
<hyperair> it isn't
<tjaalton> there you go
<hyperair> a
<hyperair> h
<hyperair> but why isn't it?
<hyperair> that'll be a bug right?
<tjaalton> dunno
<hyperair> hmm
<hyperair> meh. looks like only glxgears showed any improvement
<Ng> hyperair: so you're on 965 and only seeing slowdown in heavy 3d apps?
<hyperair> Ng: yep
<Ng> hyperair: but not compiz?
<hyperair> Ng: that's right
<hyperair> Ng: compiz looks fine
<Ng> this is all very weird, how can tjaalton have no problems, you only have slowdowns with heavy 3d stuff and my CPU only has to think about doing something and compiz chugs like crazy
<hyperair> Ng: very weird indeed.
<hyperair> Ng: well if compiz chugs when your cpu thinks of doing something, then you're probably not using hardware accel?
<Ng> hyperair: I'm pretty sure I am. every way I know to test for that tells me I am
<hyperair> glxinfo -l | grep render?
<Ng> direct rendering: Yes
<Ng> OpenGL renderer string: Mesa DRI Intel(R) 965GM GEM 20090114 x86/MMX/SSE2
<hyperair> hm strange you've got the x86/MMX/SSE2 string
<hyperair> i guess it doesn't show up on x86_64
<hyperair> are you in the video group?
<Ng> hyperair: yup
<hyperair> Ng: then i have no idea heheh
<hyperair> i think i'll be sitting in intrepid until a suitably fast intel driver comes along
<Ng> good luck with that
<Ng> I reckon we're in for another year of intel pain
<hyperair> ouch
<hyperair> that'll hurt =(
<hyperair> and i got intel so that i wouldn't hvae to experience nvidia/ati pain
<hyperair> sigh
<Ng> they're into bugfixing atm so 9.10 should be good for hardware they care about, but there'll be a flood of old stuff breaking I reckon
<Ng> (this is all my wild speculation)
<hyperair> lo
<hyperair> well i'll just backport stuff i care about from jaunty to intrepid
<hyperair> =p
<Ng> I wish I'd done something like run phoronix's 3d benchmark stuff before I upgraded. It'd be very interesting to see over time how it changes
<Ng> also glxgears is a terrible test ;)
<hyperair> heheh yeah
<hyperair> is there any chance of -intel 2.6.2 getting into jaunty?
<tjaalton> not sure it's compatible
<hyperair> hmm it isn't?
<hyperair> i read in some bug report that all it needs is a newer libdrm
<hyperair> which means two packages upgraded and we'll get it
<tjaalton> yes, but the headers are in the kernel these days
<hyperair> yes, but the user was compiling on ubuntu jaunty =\
<hyperair> i wonder if the user was using a custom kernel or the jaunty one
<tjaalton> maybe it's doable
<hyperair> tjaalton: so there  is a chance of it getting in? =D
<tjaalton> I'd have to check what commits are needed to the headers
<hyperair> hmm i see
<quassel208> is ext4 better then ext3? because i hear my hd sometimes having a hard time
<hyperair> supposedly
<hyperair> i haven't really tried it so i can't tell
<hyperair> but if many others are reaping benefits i probably will reap more, since i've encrypted my whole drive =\
<tjaalton> grim-reaping you say?
<hyperair> lol
<mnemo> tjaalton: what intel driver version will ship with jaunty? 2.6.1 or 2.6.2 ??
<tjaalton> mnemo: I've no idea
<mnemo> ok
<tjaalton> read the scrollback
<hyperair> well if it doesn't, i'll probably stick it in my ppa, hoping against hope that it fixes all the performance regressions
<hyperair> otherwise i'll just sit around in intrepid and moan and groan to myself.
<tjaalton> it most likely won't fix any performance problems
<tjaalton> gone ->
<hyperair> alright, then i'll sit around in intrepid and moan and groan to myself
<hyperair> and maybe backport the features from jaunty i find interesting, like notify-osd
<mnemo> hyperair: what chipset do you have? at least on my G45 UXA works great
<hyperair> mnemo: do you play games?
<mnemo> I play chromium at least but its like a pretty simple game
<hyperair> mnemo: i can't even play one of those scroll-down shooters with a FPS that matches intrepid
<hyperair> mnemo: x3100 i965
<hyperair> both uxa and exa suck
<hyperair> running metacity each time of course
<mnemo> im using compiz+UXA on jaunty and while its not super perfy, its fairly stable (on my chipset, ive heard horror stories on other cards though)
<mnemo> I hope UXA will be rock solid for ubuntu 10.04 at least because I'm most likely going to stay on that for a long time... it's too distracting to be on pre-release all the time, heh
<hyperair> well i generally get on during the beta
<hyperair> because around that time, people start asking me to maintain banshee in a new distro version in the ppa.
#ubuntu-x 2009-03-01
<BUGabundo> have any of your guys eared about probs with the new nvidia driver and hibernate?
<BUGabundo> twice now (on separate times) after Resume, my X spawns a new Session
<BUGabundo> Bug 335465
<ubottu> Launchpad bug 335465 in xorg "resume from hibernation crashed X" [Undecided,New] https://launchpad.net/bugs/335465
<tjaalton> same here
<BUGabundo> ok
<BUGabundo> that's now 5 ppl
<tjaalton> it happens on my intel laptop too
<BUGabundo> not sure all the same bug
<tjaalton> right
<BUGabundo> yes
<BUGabundo> I've seen users on +1 confirming intel too
<BUGabundo> tjaalton: any idea what I can add extra to that bug?
<tjaalton> BUGabundo: try older kernel releases
<tjaalton> I mean -6, -7
<BUGabundo> I think I only have -7
<tjaalton> my nvidia box was upgraded straight to -8, but the laptop should have every jaunty kernel on it
<tjaalton> so I'll test them
<BUGabundo> thanks
<tjaalton> because it was regressed after -6 I think
<BUGabundo> I'll ask users on +1 to test too
<tjaalton> thanks
<BUGabundo> RT bardyr: BUGabundo, i noticed it on -6 and -7, -8 and 2.6.29-rc6
<tjaalton> ok
<tjaalton> everyone on gnome or also with kde?
<tjaalton> because it could be gnome-screensaver which is taking it down
<BUGabundo> can you popup on #ubuntu+1?
<BUGabundo> relaying is going to cause bad comunication
<BUGabundo> lol
<tjaalton> ok
<BUGabundo> thanks
<alex_mayorga1> bryce: ping
<alex_mayorga1> anyone that can check bug 146706 please?
<ubottu> Launchpad bug 146706 in xorg-server "[Intrepid] Live cd graphics fail with nvidia geforce4 440 go " [Unknown,Confirmed] https://launchpad.net/bugs/146706
<alex_mayorga1> !trougbleshoot
<ubottu> Sorry, I don't know anything about trougbleshoot
<alex_mayorga1> !troubleshoot
<ubottu> Sorry, I don't know anything about troubleshoot
<tjaalton> alex_mayorga1: nv is buggy, and upstream doesn't care much
<tjaalton> try nouveau in jaunty
<alex_mayorga1> tjaalton: how?
<alex_mayorga1> tjaalton, so you suggest I dist upgrade? even with currently not functional X?
<superm1> alex_mayorga1, i think you are best off grabbing a jaunty alpha 5 ISO and burning it to a CD or USB key 
<superm1> boot off of that and see how things are lookign 
<alex_mayorga1> will give that a shoot
<superm1> alex_mayorga1, if it doesnt work immediately, choose safe graphics mode in the disk, and then finish your install and you can test with nouveau
<alex_mayorga1> is nouveau on intrepid somehow?
<superm1> not easily
<alex_mayorga1> I'll dist-upgrade as it is see how it fares
<tjaalton> "currently not functional X", when you had the problem since gutsy?
<superm1> alex_mayorga1, just boot off the disk, you generally can't dist-upgrade from a live cd
<alex_mayorga1> yup, it's a laptop that ended up as headless server
<alex_mayorga1> actually the live cd part is no longer current, it's installed and running
<superm1> yeah; what i'm saying to do is to just briefly test from the live cd.  it will attempt to use nv when you boot it without messing up your current install
<superm1> and if things look good, you can do a command line dist upgrade using "sudo do-release-upgrade"
<alex_mayorga1> I'll skip the live cd and see how it goes, not really worried if it messes things up
<alex_mayorga1> weird "No new release found"
<superm1> try: sudo do-release-upgrade -d
<superm1> and if that doesn't work, try sudo do-release-upgrade -d -p
<alex_mayorga1> superm1, -d seems to do the trick, thanks
<ScislaC> I have a friend who want to test Jaunty, but X is failing with: "[17179825.492000] [drm:i810_wait_ring] *ERROR* space: 65520 wanted 65528 [17179825.492000] [drm:i810_wait_ring] *ERROR* lockup"
<ScislaC> that's via the live cd... any thoughts on if it's worth bothering with?
#ubuntu-x 2010-03-01
<RAOF> bryceh: Speaking of plymoth transitions, would you like to sponsor an xserver-xorg-video-nouveau upload with an -nr patch attached?
<bryceh> RAOF, sure
<RAOF> It's in pkg-xorg git, or I could attach a debdiff if you'd prefer.
<bryceh> git's fine
<bryceh> RAOF, looks good, upload sponsored
<RAOF> Thanks.
<bryceh> wow, nvidia.man is way out of date
<bryceh> someday we should update that :-)
<RAOF> Hm.  The intel gpu lockup event code looks like it'd be quite easy to port to nouveau :/
<RAOF> Sarvatt: Do you have that upstream link for the plymouth bug?  I think it's time to actually tell launchpad about it!
<vish> jcristau: hi. :) i had mentioned it to the cairo-dock team to contact you guys , since they had several OpenGL bugs and Sarvatt had mentioned that the mesa devs were not happy with how cairo-dock was doing its stuff.  [i forgot what Sarvatt mentioned exactly ]  hence it might have been a bit confusing to understand what they[fabounet/mattbe] were trying to get at.
<vish> mostly they wanted to get in touch with the mesa devs who knew what the problem was and what the cairo-dock was doing wrong ;)
 * vish hopes #dri-devel was the channel Sarvatt mentioned :)
<vish> Sarvatt: anyone particular the cairo-dock team needs to get in touch with? 
<RAOF> Eep!  Random people filing crazy bugs with nouveau upstream :(.
<bryceh> ?
<RAOF> Oh, just one of our users testing nouveau & filing bugs simultaneously in launchpad and upstream with nouveau.
<RAOF> Filing *bad* bugs simultaneously upstream and in launchpad; basically "my log contains (EE) AIGLX: can't load /usr/lib/dri/nouveau_dri.so".
<bryceh> ah
<RAOF> Also, I'm fixing the xorg apport hooks; there are a couple of problems in the recent upload.
<bryceh> oh?
<RAOF> Things like âlsb_release -c" returning "Codename:\tlucid" rather than "Codename:  lucid", so the hook crashes and doesn't attach the extra information.
<RAOF> Just a couple of small things.
<RAOF> A missing comma in a list.
<bryceh> ahh
<superm1> RAOF, lsb_release -sc instead
<superm1> then you dont need to try to parse whitespace 
<RAOF> Ah, there was one substantial question I wanted to ask about that: how would you like people running âubuntu-bug xserver-xorg-video-nouveauâ handled - reading the GDM logs requires root, and so it will currently (once it's fixed) ask whether to add logs it can't actually add.
<RAOF> superm1: Thanks!  I'll use that instead.
<RAOF> There doesn't seem to be a good way to escalate to root in the apport hook, so we can either (a) only ask that message when run as root, or (b) when not run as root, ask people to re-run ubuntu-bug with root privs.
<bryceh> it can't add the gdm logs?
<bryceh> I think I added in the right code to cause apport to prompt for gksudo, however I haven't tested it
<RAOF> It can't read the logs unless it's run as root.  And people can (and I *did*) run ubuntu-bug as not-root.
<bryceh> right, I *think* apport will prompt for that now.  worth testing
<bryceh> also, regarding how to call ubuntu-bug, I've been recommending people just file them via 'ubuntu-bug xorg'
<RAOF> Well, right now it won't, because the hook crashes a couple of times before getting there.  And when I've fixed that up, I don't think ui.yesno actually escalates to root?
<bryceh> then I have a cronjob on my end that reviews the bug reports and reassigns them to the driver package as appropriate
<RAOF> Ok.  I'll do that in future.  Easier to type :)
<bryceh> yeah, and it turned out users got really confused 
<RAOF> There's a fair scope for users to get confused, yeah.
<bryceh> some would file against xserver-xorg-driver-*, others would file driver bugs against xorg-server, or vice versa
<bryceh> regarding reading gdm.log as root, I'll get that fixed up
<tjaalton> bryceh: check bug 529583, the new apport code is probably a bit too effective :)
<ubottu> Launchpad bug 529583 in xserver-xorg-video-intel "I do not know why his bug" [Undecided,Incomplete] https://launchpad.net/bugs/529583
<bryceh> tjaalton, heh
<RAOF> bryceh: I'll push the other fixes up to pkg-xorg git.
<bryceh> ok, let me know once they're merged
<bryceh> tjaalton, yeah we'll have to decide how to handle these kinds of bugs.  It seems a bad idea to send them upstream if the user is clueless, but freezes are not things we're going to be able to fix ourselves.
<bryceh> RAOF, ok I'll tackle the gdm.log root stuff tomorrow
<RAOF> I've just managed to make it work.
<bryceh> basically the commands just need switched over to use root_command_output()
<RAOF> Yup.
<RAOF> Just writing the commit message.
<bryceh> great
<RAOF> Pushed to pkg-xorg git.
<RAOF> I guess I should write a debian/changelog entry, too, while I'm at it.
<RAOF> There we go.
<bryceh> yep looks good
<RAOF> Well, at least *some* people are finding nouveau nice; here's a bug about gnome-shell not working on the second monitor plugged into the displayport on the macbook!
<bryceh> heh
<apw> bryceh, do i expect my keymaps to get flushed when i VT switch?
<apw> (or indeed anyone)
<apw> also is restoration of CAPS etc LED state on return to X a userspace thing or ?
<radoe> Hello. May someone please have a look at bug 402260? I have a debdiff ready and attached and also an ack from ubuntu-sru for a SRU regarding this bug. How to proceed further with this? Thx.
<ubottu> Launchpad bug 402260 in xorg-server "[Needs SRU] segfault when running Xdmx" [Undecided,Fix released] https://launchpad.net/bugs/402260
<superm1> apw, when a system is triggering the high temperature switch, does the kernel actually call into /sbin/shutdown, or does it arrange for a shutdown a different way?
<apw> superm1, normally the bios takes the machine out without any indication or time to stop it
<apw> there is a bug somewhere in lucid which is breaking the temp sensors on one of my dells, which stops the sensors and fans responding correctly after a suspend/resume ...
<superm1> well the problem i'm looking at is actually in karmic
<superm1> and i'm trying to figure out what is sending a SIGTERM and someother signal to all running apps during a factory install
<superm1> given the machines are in burn racks, i'm starting to wonder if temperature was playing into the problem
<superm1> so if the kernel was actually calling /sbin/shutdown or some other means to send signals like that to everything it sounds like its at least a possible venue for the problem
<hyperair> i don't think the kernel calls /sbin/shutdown when overheating..
<hyperair> it just hangs.
<apw> superm1, right, i'd expect it to just stop dead and turn off, thats what mine does here
<superm1> apw, dang.  back to the drawing board then :(
<apw> well its worth asking cjwatson if there is anything else
<apw> i'd expect that kind of thing if they ran out of battery for example
<Ng> apw: superm1: fwiw, my laptop BIOS sends an ACPI event to linux and the machine shuts down gracefully. I had my laptop wake up for some reason once in my bag, hit 127 degrees C and then log that and shut down :/
<hyperair> mine stopped dead while compiling kernels.
<hyperair> and also compiling codelite
<hyperair> kinda painful when doing testbuilds
<hyperair> have to ^Z every 15 minutes
<hyperair> wait for 15 minutes, then fg
<hyperair> that was until i discovered PHC =D
<superm1> Ng, yeah that's what i was hoping is possible; it definitely coo-berates with the symptoms of this problem
<bryceh> apw, keymap flushing should not happen when VT switching.  However losing keymaps is a common problem when unplugging/replugging the keyboard so perhaps its related to that?
<apw> bryceh, i definaly get reset to UK layout on switch in and out of X
<bryceh> apw, is that a new behavior?
<apw> bryceh, i do it so rarely that i doubt i'd have noticed, i only did it today to test what appears to be a bug in LED handling for capslock and numlock over the same VT switch
<apw> and said i couldn't test caps as i delete the key, and found it had come back!
<bryceh> hmm
<bryceh> can you see any evidence of any devices enabling/disabling through that?
<tjaalton> bryceh: hey, we should probably upload mesa and xserver from git?
<apw> bryceh, the only dmesg i get in that switch and back is this:
<apw> [39732.660911] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
<apw> [39732.821452] Skipping EDID probe due to cached edid
<bryceh> tjaalton, sounds good
<bryceh> tjaalton, now that a3 is out it's a good time to upload
<bryceh> apw, that first one I think might be plymouth
<bryceh> apw, the second is just a kernel info message (in fact that should probably be commented out in the kernel as I've seen some people's logs where it gets pretty spammy)
<apw> yeah that secnd one comes out scarily often
<tjaalton> bryceh: yeah
<apw> bryceh, i get a bunch of this on switch and back in Xorg.log
<apw> (II) "Power Button": Device reopened after 1 attempts.
<apw> and so on for everything that is an input device
<tjaalton> bryceh: I'll upload them later unless you want to do the honors :)
<apw> bryceh, we 
<apw> bryceh, we get any feedback on the backport kernel?
<apw> we have some positive noises from owners of some h/w
<bryceh> tjaalton, go for it
<bryceh> apw, jamie said it didn't fix the issue on his old radeon chip
<apw> bryceh, hell, so no modeset for him then
<bryceh> which is ironic since that's the issue that started us down this whole path, and that airlied said would be fixed if we went to .33
<apw> .33 is much a pile of doings as anything else
<bryceh> aside from that I've seen no negatives
<apw> me either ... so i am angling to make any decision official
<bryceh> great!
<apw> i have an upload todo today, for everything before drm
<apw> and then will push that in a couple of days, if you concur its a better place to be than .32
<bryceh> btw, 'no modeset for him' -> have we a kms per-card blacklist set up?  I'd like to document the steps if so
<apw> bryceh, nope, we don't
<bryceh> yes I concur
<apw> but we hoped to avod it by fixing him, but if it doesn't then a per id list will be needed
<apw> which i will have to go add i suspect
<bryceh> apw, ok well it's orthogonal to the .33 decision, but still would be worth having
<apw> yep.  a generic list in drm is appropriate, as nomodeset is there it should be ok
<apw> bryceh, will we have UMS still for i915 in lucid?
<bryceh> apw, yes
<apw> thats something at least, at least nomodeset will mean something across the board
<bryceh> apw, I think we've more or less convinced ourselves to stick with 2.9.1 and retain UMS as an option on intel
<bryceh> yeah
<apw> bryceh, can i also confirm that to your knowledge there is no way to override the mode selected in KMS as it stands?
<bryceh> someone mentioned some idea of lucid being "the last Ubuntu with UMS" so KMS by default with UMS as an option across the board feels quite right
<bryceh> apw, that's correct to my knowledge - I dug around in the kernel code but didn't find anything
<bryceh> nor have I run into online docs about this
<bryceh> I definitely think it's something we're going to need
<apw> it seems a major oversight that i cannot quite fathom how we have not noticed before
<bryceh> having UMS as a fallback slightly reduces the severity of this issue, but it's not a good long term solution obviously, and is probably more hackery than most people would expect to need to do
<bryceh> apw, other larger issues distracting us maybe?  ;-)
<apw> bryceh, yeah i guess ... arrgllle
<jcristau> setting the mode from the kernel command line doesn't work?
<jcristau> fwiw it looks like debian will be going with the drm .33 backport
<bryceh> jcristau, good to know
#ubuntu-x 2010-03-02
<RAOF> bryceh: For future reference, my surname is âHalse Rogersâ.  This causes no end of fun!
<RAOF> bryceh: Are you waiting for anything before uploading x11-common with the fixed apport hooks?
<radoe> Hello, sorry for asking again, but may someone have a look at bug 402260? I already have a fix, a debdiff and a ack from ubuntu-sru for the SRU in karmic. What to do next?
<ubottu> Launchpad bug 402260 in xorg-server "[Needs SRU] segfault when running Xdmx" [Undecided,Fix released] https://launchpad.net/bugs/402260
<RAOF> Excellent.  This weekend I'll pick up a netbook with switchable nvidia ION/intel graphics.  All sorts of testing possibilities!
<tseliot> ara: can you still reproduce the problem with suspend/resume with nvidia?
<tseliot> (with an updated lucid system)
<ara> tseliot, let me update and I will get back to you
<tseliot> thanks
<ara> tseliot, around?
<tseliot> ara: yep
<ara> tseliot, I tried on Lucid, it is better than before, but still buggy
<tseliot> ara: can you define "buggy" please?
<tseliot> so that I can tell Nvidia about it
<ara> tseliot, when it wakes up from suspend, the X does not come back. If you switch to another tty, and then back to tty7, it comes back, but there are some rendering issues
<ara> tseliot, I will get a screenshot
<tseliot> ara: great, thanks
<tjaalton> there's a bug about that
<tjaalton> happened to me too
<tjaalton> bug 528138
<ubottu> Launchpad bug 528138 in nvidia-graphics-drivers "garbage on screen after suspend" [Medium,Confirmed] https://launchpad.net/bugs/528138
<tseliot> even better
<tseliot> ara ^^
<ara> tjaalton, great
<ara> tjaalton, do you have to switch ttys before getting anything?
<tjaalton> ara: yes
<tjaalton> now running nouveau though, seems solid so far
<ara> tjaalton, :)
<tjaalton> I had some weird problem with the user switcher though, but it only happened once
<tjaalton> the new server failed to open drm
<Sarvatt> vish: it was the whole pbuffer vs fbo thing, looks like fabounet already talked to them over the weekend
<Sarvatt> Ng: 127c means the sensor isnt returning a value usually, i doubt it was actually at 127c (i know that doesn't help your problem)
<Ng> Sarvatt: even if 127 is the value for the first thermal zone's trip point?
<Ng> THM1 has some complex configuration of things around 101-105 I don't immediately understand, but THM0 is 127
<Ng> I'm prepared to believe that's some kind of weird misreading though
<Sarvatt> 127=null yeah
<Sarvatt> what kind of cpu is it?
<Sarvatt> maybe the module (like k8temp if amd64) has problems after resume or something
<Sarvatt> i'm positive it returns 127c if it cant get an actual temp though (like if you query it too fast), had that problem on my machines for many many years and its a bios thing not a linux problem.. the machine should shut off way before 127c since that'd kill the cpu
<Sarvatt> apw: the backport -14 kernel of yours that I tried a few weeks ago hated my intel machine, got 2 gpu hangs after resume that dont happen with mainline kernels for some strange reason. do you have any newer ones to test out?
<tseliot> superm1: any ideas on what's going on here? http://pastebin.ubuntu.com/387063/
<Sarvatt> dh_shlibdeps -l`pwd` -- is that even allowed?
<tseliot> Sarvatt: the code was already there, I only added -l`pwd`/debian/fglrx/usr/lib32/fglrx
<apw> Sarvatt, there is a -15 in my red ppa
<tseliot> it should be the same as $(CURDIR) I guess
<tseliot> Sarvatt, superm1: same result with $(CURDIR): http://pastebin.ubuntu.com/387072/
<tjaalton> there's hardly any need to run dpkg-shlibdeps, right?
<tseliot> we have Depends: ${shlibs:Depends} in the control file
<tseliot> but I did something stupid
<tseliot> as I should have done dh_shlibdeps -l$(CURDIR)/debian/fglrx/usr/lib/fglrx:$(CURDIR)/debian/fglrx/usr/lib32/fglrx
<tseliot> it works now
<superm1> tseliot, cool, so it's solved now :)
<tseliot> superm1: yep, I've just committed the fix. I'll tell Felix about it
<matteo`> hi people
<bryceh> hi matteo`
<matteo> bryceh: that bug is getting me crazy
<matteo> looking a such corrupted screen really leads to headaches
<bryceh> matteo, sorry you'll need to be more specific; I deal with dozens of bugs a day
<matteo> https://bugs.launchpad.net/ubuntu/+bug/378794
<ubottu> Launchpad bug 378794 in xserver-xorg-video-intel "[i945] Intel 945GME screen corruption" [Unknown,Confirmed]
<radoe> bryceh: are you on?
<bryceh> radoe, yeah
<radoe> bryceh: ah, may you please have a look at at bug 402260? I  already have a fix, a debdiff and a ack from ubuntu-sru for the SRU for karmic. What to do next?
<ubottu> Launchpad bug 402260 in xorg-server "[Needs SRU] segfault when running Xdmx" [Undecided,Fix released] https://launchpad.net/bugs/402260
<bryceh> radoe, thanks, it is added to my todo list to look at today.
<radoe> bryceh: well, ok, thx.
<libv> board meeting everyone.
<libv> #xf-bod on irc.oftc.net
<RAOF> Woot!  Reproducibility: I kan haz!
#ubuntu-x 2010-03-03
<RAOF> Ok.  modules.order is a part of the nouveau solution.  Now: how do I get it in there... ;)
<Sarvatt> ugh wife's hdd died and usb-creator on lucid doesn't work.. nouveau is working well on her 10de:0244:103c:30b7 nVidia Corporation C51 [Geforce Go 6150]  out of the box though
<RAOF> Cool, and a tiny bit surprising.
<Sarvatt> got (WW) NOUVEAU(0): Failed to retrieve fbcon fb: id 0 because of the vga16fb module being loaded for fb0 but it didnt seem to hurt anything
<RAOF> And you got plymouth splash as well?
<RAOF> And did VTs work?
<RAOF> These are the things that break for me when vga16fb claims fb0.
<Sarvatt> yeah no plymouth because of the vga16fb, didnt try vt switching
<RAOF> I suspect that also breaks suspend?
<RAOF> Also, can I upgrade the bzr format of the pkg-xorg-tools branch?  I'd like to push some libdrm hooks fixes that got trapped in a 2a repository.
<Sarvatt> i didn't run through any tests, just booted it up so she could get on firefox and saved the logs :D
<RAOF> Ok.
<Sarvatt> sure thing!
<RAOF> I think there's an excellent chance that ensuring vga16fb doesn't claim fb0 will resolve most of the failures on NouveauEvaluation.
<RAOF> Or, at least, most of the more serious failures.
<Sarvatt> yeah i have it blacklisted on my other nvidia laptop and things work fine
<RAOF> I had touched the blacklist files before the module-init-tools upgrade that removed vga16fb from the blacklists; consequently it remained blacklisted here.
<RAOF> Which is why I couldn't reproduce all these failures!
<Sarvatt> ohh lots of libdrm updates today, will have to update that in a bit
<RAOF> In edgers?
<Sarvatt> yeah
<RAOF> It'll be easier after I've pushed the hooks changes :)
<Sarvatt> what'd ya add hooks to do?
<RAOF> Oh, to match the recent Ubuntu libdrm updates.
<Sarvatt> ah patch adjustments?
<RAOF> Oh, and not building the broken libkms.
<RAOF> Updating the symbols file.
<RAOF> That sort of thing.
<RAOF> Actually, I should push that libkms patch upstream.  They'd probably like for it to build against the actual headers in libdrm.
<Sarvatt> ./auto-xorg-git -d origin/ubuntu -g -H hooks -p libdrm -a 0ubuntu0sarvatt -t + is what i use for libdrm
<RAOF> Yup.  That's what I've used.
<RAOF> Except with raof in there.
<RAOF> It should fail without hooks updates, because libdrm now (fails to) builds libkms, and there are symbols updates.
<Sarvatt> and control+z then edit the rules manually during the first pause, have to unconditionally pass INTEL=yes in the rules so it builds on lpia and comment out the header removal
<RAOF> Ok.  Didn't do that :)
<Sarvatt> yeah i build it locally every time, usually symbol updates somewhere
<Sarvatt> and gotta relax the depends on linux-libc-dev in control to just the package name since libdrm-dev provides the headers
<Sarvatt> it depends on >= 2.6.32 so it'd DEPWAIT on karmic
<Sarvatt> if you want to update it just do lucid and i'll grab yours and do the karmic one if you want so you dont have to do all the lpia specific stuff, just comment out the header rm's from debian/rules
<RAOF> Um... is that my laptop harddrive *clicking*?
<RAOF> Oh, dear.
<Sarvatt> my wifes was just doing that and got a ton of errors when I scanned it, SSD time for both of us it sounds like :)
<RAOF> On the other hand, a clicking hard drive has made me start up disc utility.  My, it looks very nice now :)
<Sarvatt> oops its still --enable-radeon-experimental-api in ubuntu libdrm git, its --enable-radeon now
<Sarvatt> at least it defaults to on so it doesnt matter
<RAOF> Heh
<RAOF> Win.  xorg-pkg-tools is now 2a, and contains hooks changes.
<Sarvatt> why not just --disable-libkms from the rules?
<RAOF> I did.
<Sarvatt> oh you're patching in a hook, gotcha
<RAOF> But that was after getting it to build; the patch in there is pretty much for historical interest only, I guess.
<Sarvatt> might want to CHANGES+=("hook: whatever after each one")
<Sarvatt> err CHANGES+=("hook: whatever") after each one :D
<RAOF> Aaah.  That's where those changelog entries come from ;)
<Sarvatt> hope ya dont mind but i already uploaded a new libdrm, was working on that before you updated the hooks
<RAOF> That's fine.
<RAOF> I was updating xorg-edgers/nouveau with clean upstream, and noticed that the hooks as written didn't work.
<Sarvatt> yeah libdrm is the worst, needs lots of manual updating and it changes every month or so so i dont bother updating the hooks usually. tormod is alot better about that than me :)
<Sarvatt> oh ya didnt upload the patches, thats what threw me off
<RAOF> Well, at the moment it'll build with hooks & no manual intervention :)
<Sarvatt> forgot to bzr add?
<RAOF> Oh, annoyance.
<Sarvatt> glxgears speed almost doubled with that libdrm update on intel so I know its doing something :D
<Sarvatt> wow qgears2 -gl GEARS went up to 60 fps from ~35
<Sarvatt> GEARSFANCY is up to 31 from 17
<Sarvatt> xrender and gl backends are at ~4x the speed of jaunty now in all tests :D
<AtomicSpark> Lucid, ATI and X; Will they be friends again?
<tjaalton> never ceased to be
<tjaalton> unless you mean fglrx
<AtomicSpark> Yes I do.
<tjaalton> blobs ftw
<AtomicSpark> It's hard to do QA testing when we dont have a driver. I was told to drop by here to see if there was some testing I can do. ;3
<tjaalton> by whom?
<AtomicSpark> Someone in -quality
<tjaalton> it's pretty well known that there is no driver, so that's a bit surprising
<AtomicSpark> A bit.
<AtomicSpark> Are we waiting on ATI?
<tjaalton> who else?
<AtomicSpark> Well, I haven't read into it. Might of been a bug on our side. :P
<AtomicSpark> At least the free driver works well.
<dholbach> good morning
<dholbach> hi guys
<dholbach> how do I fix my machine with an nvidia card today?
<dholbach> what is broken?
<dholbach> the problem this time is that I don't know it's IP address and can't ssh into it
<dholbach> and removing "splash" does not make it work either
<dholbach> the nouveau kernel module was installed, then I rebooted
<RAOF> vga16fb will probably be loading before lbm_nouveau and claiming fb0; this results in VTs (including plymouth splash) being broken, and it looks like it can mess up X in some cases too.
<RAOF> If you can boot at all, adding âblacklist vga16fbâ to /etc/modprobe.d/blacklist.conf and rebuilding the initramfs should fix it.
<dholbach> RAOF: I don't know how to get to the point of adding something to /etc/modprobe.d/blacklist.conf
<RAOF> Booting into recovery mode fails, too?
<RAOF> Do you have any previous kernels to boot into?
<dholbach> recovery mode fails too
<dholbach> let me try an older kernel
<dholbach> RAOF: -13 (recovery) worked
<dholbach> let's hope blacklisting it will fix things
<RAOF> It should; I plan to talk with apw this evening to bed down what's happening with nouveau.
<dholbach> for somebody who doesn't know to talk to you guys it's a bit painful experience :)
<dholbach> RAOF: alright, I'm back on track again - thanks
<dholbach> RAOF: let me know when I can unblacklist it again :)
<RAOF> It's been complicated by me accidentally have a config that avoided this problem.
<dholbach> oh ok :)
<dholbach> thanks again RAOF
<apw> dholbach, heh yeah ... it is painful indeed.  though we are in alpha still so pain is to be expected and if you buy into alphas you are likely more in the know on how to get help
<dholbach> apw: all those nvidia people who wanted to try out the Ubuntu One Music Store ... all lost along the way :)
<apw> some of us didn't get invites
<dholbach> talk to aquarius!
<apw> dholbach, though i'd be ok as i don't have nvidia either
<dholbach> :)
<tseliot> mvo, superm1: I'm adding nvidia-glx-{190|195} to the list of obsolete packages in nvidia-common so that we can deal with packages installed from PPAs (as karmic has 185) when dist-upgrading to lucid
<bjsnider> cool
<Sarvatt> RAOF: you can add vga16fb.sucks=1 to the kernel command line too and it wont load because of the invalid module parameter :D
<tseliot> hehe
<Sarvatt> RAOF: any ideas on how we should keep nouveau going in edgers with the api bump once the backported drm kernel comes out? maybe add a blacklist in the nouveau packages and keep lbm around?
<Sarvatt> i really need to figure out the ubuntu kernel build system one of these days, i've used kernel-package for years so i'm used to that
<Sarvatt> looks like its these bgnr patches causing the invalid fb drm errors with plymouth, no copyfb patch on intel no errors when shutting down here
<superm1> tseliot, so will that cause people to get nvidia-current, or just purge those old things?
<tseliot> superm1: once update-manager picks up my changes to nvidia-common those users should be transitioned to nvidia-current
<superm1> sweet :)
<mvo> tseliot: I plan to do a upload today, I can wait until its build 
<tseliot> mvo: ah, great
<Sarvatt> ok so it looks like we need another udev rule numbered lower than 69 to catch serial tablets?
<bryceh> ok
<apw> bryceh, what dep does X current have to cause nouveau LBM to be installed
<apw> trying to work out what to replace: ... i am assuming linux-backports-modules-nouveau-lucid 
<bryceh> apw, xserver-xorg-video-nouveau has this in its Depends:
<bryceh>  linux-backports-modules-nouveau-lucid-generic | linux-backports-modules-nouveau-lucid-generic-pae
<apw> cool so the meta packages, if replace: those on the kernel images then the meta packages should uninstall when you install the replacement kernel
<apw> bryceh, will userspace cope?  i believe it does cope with normal or lbm- prefixed names for things yes?
<apw> bryceh, will userspace cope?  i believe it does cope with normal or lbm- prefixed names for things yes?
<bryceh> yes, we'll cope in userspace
<apw> bryceh, crap, i assume if i push out that nouveau dep, that will push out X as well as it has a dep on it?
<bryceh> does 'push out' mean 'update' or 'eliminate'?
<apw> bryceh, trigger the uninstalling of via Replaces:
<bryceh> mm, not sure I totally understand, but I don't think it'll do that
<apw> i am told if i add Replaces: l-b-m-n-l-g to the uploaded kernel then it'll trigger the un-install of that before it installs the new kernel
<apw> but ... if its a dep of X that sounds bad
<jcristau> replaces doesn't cause uninstalling
<apw> what does it do?
<jcristau> tell dpkg that you're overwriting some files from the other package
<apw> ok ... i think i meant to use Breaks: in that description
<bryceh> ah
<apw> sorry getting self confused
<jcristau> that makes more sense :)
<apw> good :)  so i assume that would be bad for X though in this case
<bryceh> I would think we should be able to sort it out in the packaging though
<apw> yeah i am sure we can, just wondering if i can do it all in one go with my package or you need to do somethign first
<bryceh> apw, maybe we just need another OR condition in the Depends?
<jcristau> maybe you can have both Breaks and Provides
<bryceh> what's the new package going to be named?
<jcristau> so you cause uninstalling of the old package, but keep X's dependencies happy
<apw> jcristau, i like that, but how long would i have to provide that, 'forever' to allow for slow upgrading people?
<apw> i worry about us needing to have an lbm nouveau in the future
<jcristau> until X drops the dep i guess.  plus some days.
<apw> so not the end of the world then
<apw> bryceh, this is risky enough that i recon i'll get the kernel uploaded to my red ppa again and then we can try it out, if it works then we can upload it first thing tommorrow to the archive
<bryceh> apw, sounds like a plan
<bryceh> apw, that should give RAOF time to review/digest this and give feedback as well
<apw> yeah sweet ... so i'll make that 'first thing' your time tommorrow
<bryceh> I'm kind of letting him take point on nouveau now, so will defer to his judgment.  But I know his time zone and yours are not overlappy enough
<tjaalton> Sarvatt: how so?
<tjaalton> Sarvatt: those rules belong to 69-xserver-xorg-input-wacom.rules
<RAOF> apw: I don't think the kernel needs to do anything more than Breaks/Replaces linux-backports-modules-nouveau-2.6.32-15-$FLAVOUR, and Provides: linux-backports-modules-nouveau-lucid-$FLAVOUR for this ABI only.
<RAOF> If linux-meta starts to point at a new ABI that we know has the kernel module, we can drop the breaks/replaces/provides and the dependency in xserver-xorg-video-nouveau.
<bryceh> heya RAOF
<RAOF> bryceh: Good morning!
<RAOF> So, I think I'll hold off on the call-for-testing until the new kernel hits the archives.
<bryceh> good idea
<RAOF> Particularly since I'm pretty sure it'll fix a lot of the failures on the evaluation page. :)
<bryceh> yeah I'm thinking that when the new drm comes out, I'll do a mega bug-spam asking bug reporters to do a re-test across the board, for all bugs tagged lucid
<RAOF> That would be worthwhile.
<bryceh> it's been a long time since I did a re-test spam, so hopefully shouldn't be seen as *too* annoying
<RAOF> There really aren't that many bugs filed, so it's not much of a mega bug-spam :)
<bryceh> oh I mean across -intel and -ati too
<bryceh> and maybe even mesa...
<bryceh> possibly xorg-server but I'll have to think about that a bit more
<RAOF> They're all touched.
<RAOF> mesa would be an obvious candidate; I'm not sure about the xorg-server bugs.  I'm not as familiar with them.
<bryceh> mostly they're crash bugs, but a lot of random stuff ends up there
<bryceh> well, probably can't hurt to have them all re-test regardless.
<RAOF> Yeah.
<RAOF> Grr.  I wonder if evolution *really* needs a 1.1GiB resident set. 
<bryceh> mutt ftw
<RAOF> I'm a sucker for a non-terrible GUI, and Evolution has the least terrible UI of the mail clients I've tried.
<bryceh> ah yeah
<bryceh> I'm more a sucker for non-crashing in my mail clients ;-)
<RAOF> As long as they have gracefull crash recovery... :)
<bryceh> bleah
<jcristau> you mean not eating your mail when it crashes counts as a feature now?
<RAOF> I've never seen any message that evolution has eaten ;)
<tjaalton> right, because they were gone already :)
<bryceh> hehe
<RAOF> Sarvatt: For lbm-novueau in xorg-edgers I think we can just blacklist nouveau, in exactly the same way nvidia-current does now.
 * Sarvatt nods
<Sarvatt> question -- there's a *large* number of synaptics bugs where they are basically just complaining about the default settings not being what they want.. mark bug invalid because its not a bug or change to wishlist and reassign to gnome-control-center and change to wishlist?
<Sarvatt> one day I'll speak proper english :)
<Sarvatt> like some people want middle click to be a right top tap button and that was purposefully disabled for a hundredpapercuts bug
<jcristau> Sarvatt: i assume some of those want incompatible default settings
<Sarvatt> yeah theres tons of bugs wanting things one way and tons wanting them the other
<jcristau> in debian i tend to close these things as "we use the upstream default, if you want it changed talk to upstream"
<Sarvatt> there's no gui way to change the options so I can see them being a wishlist against g-c-c or gpointing-device-settings adding the functionality
<Sarvatt> its kinda sketchy since we arent using the upstream default in the first place, we were enabling corner tapping then just removed the right top corner tap middle click setting from it
<Sarvatt> we still have the right bottom right click tap button
<bryceh> Sarvatt, yeah find a g-c-c wishlist bug for enabling an ability to configure it, and dupe them all to that
<bryceh> I've generally not done much triaging on the input driver packages so there's probably a lot of invalid/dupe bugs there
<Sarvatt> go figure launchpad goes down :)
<bryceh> yeah
<bryceh> must be middle of the night in london or something ;-)
<Sarvatt> oh, ubuntu-x-swat isnt subscribed to xserver-xorg-input-synaptics bugs?
<Sarvatt> no wonder i missed all these
<bryceh> guess that means its sandwich time here :-)
<Sarvatt> oh! yeah it is, all these bugs i was messing with were just lost in the noise :)
<bryceh> noise sucks
#ubuntu-x 2010-03-04
<tjaalton> bryceh: there are some "can be synced" tags on the versions_current list, do you think that sync requests should be filed for those?
<tjaalton> https://wiki.ubuntu.com/X/PackageNotes
<tjaalton> hmm, slightly outdated though, there are more
<tjaalton> libxi for instance is very much needed, there are some bugs filed against libxcb that this should fix
<tjaalton> http://bugs.debian.org/400442
<tjaalton> superm1: libvdpau can be synced too, it won't break anything?
<tjaalton> oh and lifeless should merge libx11 ;)
<tjaalton> ok, list updated
<superm1> tjaalton, although it's unlikely to break, it would be better to test it first
<tjaalton> superm1: ok, sure
<tjaalton> left it out from the list
<superm1> tjaalton, when trying to build even: The following packages have unmet dependencies:
<superm1>   pbuilder-satisfydepends-dummy: Depends: x11proto-dri2-dev (>= 2.2) but it is not installable
<superm1> is that not in lucid yet?
<tjaalton> superm1: hah, no. but on the list of syncs
<superm1> tjaalton, okay well after all that's in place i'll try a build and look at it again
<tjaalton> there was a sync request for the proto, confirmed it now so hope that it'll get synced soon
 * RAOF prepares to hang his system by trying to suspend.
<tjaalton> RAOF: nouveau suspend works fine for me
<tjaalton> it's nice how the user-switch is instant
<tjaalton> +also
<RAOF> tjaalton: Yeah; my laptop's just a bit of a problem-child.
<tjaalton> ok, mine is a desktop
<RAOF> It *has* worked with nouveau suspend in the past, but it now goes through the motions and then fails to actually power down in any way.
<RAOF> I think that no_console_suspend is the next step in debugging.
<mvo> can we get ctrl-alt-f2 and friends back when in X-is-in-trouble mode please? the menus are all nice but much less efficient than just going to the terminal
<tjaalton> doesn't change the vt for you?
<mvo> it didn't 
<mvo> but maybe something else was wrong too - is it mean't to work?
<tjaalton> what hw? works for me on intel and nouveau
<tjaalton> of course :)
<mvo> nvidia (very new one)
<mvo> aha .) I though it was removed for "safety" (just like ctrl-alt-backspace)
<mvo> glad that its not :)
<tjaalton> heh, no. looks like it's missing ctrl for some reason?
<mvo> yeah, it looks like my keyboard map is wrong too
<mvo> so that may explain it, I look into it
<mvo> thanks
<tjaalton> np
 * mvo was also missing nouveau-firmware for some reason
<tjaalton> nothing depends on it
<tjaalton> but aiui it won't be needed for long
<RAOF> Indeed; the .33 drm backport kernel also has the voodoo generator backported to it, too.
<mvo> RAOF: nouveau is not working for me, gives me a "module nouveau not found" error - do I just need to wait for a new kernel with the .33 bits backported?
<tjaalton> do you have a -pae kernel?
<RAOF> mvo: You could wait for the kernel, or add-apt-repository ppa:apw/red to get it now, or check that you've got the right linux-backports-modules-nouveau-lucid-FLAVOUR installed.
<mvo> RAOF: odd, modprobe lbm_nouveau gives me the module and X starts but for some reasons its not loading it itself (linux-backports-modules-nouveau-lucid-FLAVOUR)
<RAOF> Hm.  Feel free to throw up your dmesg.
<mvo> [drm] failed to load kernel module "nouveau" in Xorg.0.log - but I can wait for the new kernel to hit the archive, if -backports-nouveau is temporarely anyway its probably not worth spend (too) much time debugging
<mvo> nothing in dmesg releated to nouveau, just [lbm-drm] initialized 1.1.0
<mvo> (amd64)
<RAOF> Yeah.  If you feel like it, check out the apw/red PPA; if that doesn't work, we've got an issue.
 * mvo tries that now
<mvo> the prospect of having free driver finally is just too tempting :)
<mvo> RAOF: I'm much impressed, works like a charm now with the apw/red kernel
<RAOF> Good to hear.
<apw> mvo is that amd64 or i386
<mvo> amd64
<mvo> I can not switch to a vt anymore, but I had a similar problem earlier so it may be unreleated
<mvo> and no compiz for me (G86 I think) - but that is probalby know, the 2d bits are fine though (so far)
<RAOF> mvo: Can you post your dmesg; that sounds annoyingly like a bug I was sure the backport kernel would fix.
<mvo> http://paste.ubuntu.com/388159/
<tseliot> yes, compiz shouldn't work
<mvo> (uname -a http://paste.ubuntu.com/388160/)
<RAOF> Yeah, we don't have the 3D components in the main archive.  You can try the xorg-edgers PPA; lots of people have had compiz-level success with it.
<tseliot> RAOF: my late congratulations on joining Canonical :-)
<RAOF> tseliot: Thanks :)
<RAOF> mvo: Can I have the rest of dmesg?  I think the error in there is plymouth, and unrelated.
<mvo> RAOF: sure, sorry, give me a second
<RAOF> tseliot: Oh, I was looking at some of the nvidia bugs, and bug 530481 sprang up as something you'd know about.
<ubottu> Launchpad bug 530481 in nvidia-graphics-drivers "nvidia-graphics-drivers break libgl horribly if hardware isn't nvidia" [Undecided,Confirmed] https://launchpad.net/bugs/530481
<RAOF> I guess that's the new alternatives system making nvidia no longer *totally* break every other driver.
<mvo> RAOF: mailed
<RAOF> But leaving libgl just broken enough that compiz thinks everything's ok, but is actually horribly broken.
<tseliot> RAOF: yes, right. It looks like mplayer's build-dep should be fixed and there is very little I can do if people install the wrong driver
<tseliot> I could make mesa's libraries have the highest priority (with alternatives) so that this doesn't happen though
<tseliot> and users will get the nvidia libraries only if they switch to them manually (or through jockey)
<tseliot> superm1: thoughts? ^^
<tseliot> note: this may break dist-upgrades
<tjaalton> tseliot: but wasn't it meant to be able to install these side-by-side?
<tjaalton> hmm though in this case nvidia was probably enabled as well
<tseliot> tjaalton: yes but unless you choose the correct alternative automatic mode kicks in
<tseliot> i.e. the alternative with the highest priority wins
<tjaalton> shouldn't the free one have that?
<tjaalton> because there's no way to decide the highest priority among the blobs
<tjaalton> so even if you install the blog, you need to enable it
<tjaalton> that way it doesn't break any setups
<tseliot> tjaalton: that's what I was suggesting but there's a use case we wouldn't cover
<tseliot> think of dist-upgrades
<tseliot> users with nvidia would be left with mesa's libraries
<tseliot> instead of nvidia's
<tseliot> and even if we fixed this in update manager, things would still be broken for dist-upgrades from the command line
<tjaalton> and the hw manager would then suggest to enable the nvidia libs
<tjaalton> isn't that what happens?
<tseliot> yes, if X doesn't crash
<tseliot> nvidia would still be in xorg.conf
<tseliot> but we would have no kernel module or gl libraries for that driver
<tjaalton> the kernel module would be loaded, no? or does the alternatives touch that too?
<tjaalton> the ddx driver loads it
<tjaalton> then X wouldn't crash, just that GL is broken
<tseliot> tjaalton: no, it wouldn't be loaded because of nouveau
<tseliot> the KMS moduel
<tseliot> module
<tjaalton> uh, so how does nvidia make it not load nouveau?
<tseliot> alternatives put a blacklist file in /etc/modprobe.d/
<tseliot> then we update the initramfs
<tjaalton> ok then
<tjaalton> I give up :)
<RAOF> But there wouldn't be any other alternative for the blacklist file, right?
<tseliot> tjaalton: heh :-)
<tseliot> RAOF: no, when you switch to mesa the blacklist file goes away and you (meaning jockey) will have to update the initramfs
<RAOF> mvo: Have you done anything strange to your initramfs hooks?  It takes 26 seconds for nouveau to start to come up, which seems strange as it should be in the initramfs.
<mvo> RAOF: nothing 
<RAOF> What does your computer *do* in the 23 seconds before it starts udev?!
<mvo> RAOF: I don't know, I was making tea - I can start it again and see if its reproducable
<RAOF> I'm not entirely sure how to read that dmesg; could you just make sure that nouveau.ko appears in /lib/modules/2.6.32-16-whatever/modules.order, before vga16fb?
<RAOF> mvo: Ah, well, if you were making tea!
<mvo> RAOF: sure, I can do that
<mvo> RAOF: I just checked, nouveau is way before vga16
<RAOF> mvo: Finally... can you check that the output of âsudo update-initramfs -u -vâ contains /lib/modules/2.6.32-16-generic/kernel/drivers/gpu/drm/nouveau/nouveau.ko
<mvo> RAOF: running that now - it says its running the nouveau_kms hook, but that is it. the module is not mentioned in the output (i can provide the full output if you want)
<RAOF> Yes, please.
<jcristau> 'zcat /boot/initrd.img-$(uname -r)|cpio -t |grep nouveau' maybe
<jcristau> if you want to know whether it's in the initramfs
<RAOF> Yeah, or that. :)
<RAOF> Is -t really a synonym for --list?
<RAOF> Yes it is.  How strange.
<mvo> RAOF: here it is http://pastebin.com/VjqCNVTA
<mvo> RAOF: I need to leave for lunch now, but I will read scrollback
<ara> I am getting a lot of X crashers in a dell mini 9 (with an i945), is it knownÂ¿
<ara> (lucid, of course)
<jcristau> hard to say with 0 details
<RAOF> mvo: Ok.  Now I ask you whether /usr/share/initramfs-tools/hooks/framebuffer exists, is executable, and if it's both of those, to pastebin its contents.
<RAOF> mvo: I will be off to the more extended version of lunch in which I lie in a bed and sleep for 8-odd hours.  I shall also read scrollback  :)
<mvo> RAOF: exists, executable, http://pastebin.com/UrGTFc9b is the content - is that outdated?
<mvo> RAOF: heh :) 
<apw> RAOF, yay i beat the docbook failure
<alkisg> How can I debug 100% xorg usage problems? (lucid, ancient ati)
<apw> strace perhaps?
<alkisg> strace xorg? ugh, any specific functions to look for?
<tjaalton> check with gdb where it's spinning
<tjaalton> or some profiler
<alkisg> I think strace or gdb would be too much for my abilities - could you propose some profiler?
<tjaalton> not really, google around
<alkisg> Thanks
<alkisg> Heh, an update solved my 100% xorg usage problem with ati :)
<apw> bryceh, ok, we have some thumbs up from RAOF for the new kernel, i am getting a whole set together in my red ppa, to make sure the interactions on upgrade work correctly ... so don't test with it till i tell you its all there ... need to get kernel lbm and meta sorted as a group, to make it a proper test
<Sarvatt> apw: * (pre-stable) drm/i915: blacklist lid status: Sony VGN-BX196VP, Dell    Inspiron 700m
<Sarvatt> that's pointless isnt it?
<Sarvatt> theres already a commit in .33 blacklisting all 8xx machines lid status
<Sarvatt> ...if i'm not mistaken, checking
<Sarvatt> http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h=7b9c5abee98c54f85bcc04bd4d7ec8d5094c73f4
<tjaalton> bryceh: expect a yet-another merge clash with xorg, since you didn't push the changes :)
<tjaalton> just the changelog though, as usual
<Sarvatt> so yeah that commit is only in drm-intel-next only, wont make it back to stable until its merged I guess anyway
<superm1> tseliot1, mplayer just needs to be fixed
<superm1> dont worry about adding hacks for the fact that mplayer is doing it wrong
<tseliot1> superm1: that's for sure
<Sarvatt> it wasnt even a PPA version of mplayer that was causing it but one in the archive??
<tseliot1> superm1: right, at this point I would rather not make too many changes. I will only re-enable the nvidia installer
<superm1> i think the problem is it's not just s/nvidia blah dev/libvdpau-dev/ because mplayer FTBFS right now
<superm1> so siretart really needs to fix the FTBFS 
<tseliot1> ah
<Sarvatt> what mplayer package is pulling in nvidia-current? i dont see anything on 2:1.0~rc3+svn20090426-1ubuntu13
<superm1> it's the build-deps that pull it in
<Sarvatt> ahh
<bjsnider> he has to refresh ffmpeg first
<bjsnider> and x264, theora, vorbis, et al.
<bjsnider> and then finally mplayer
<bjsnider> and as far as i know none of this has been started
<bjsnider> every time i ask him about it he gets snippy
<superm1> bjsnider, yeah it's an annoying problem :(
<superm1> i would think since he tries to maintain them in debian and ubuntu it would be stable in debian and more syncable though
<bjsnider> the debian version is in no sense upstream. it's horribly outdated
<bjsnider> the commands listed in his upstream-upgrade file for ffmpeg no longer work because there is no ffmpeg-debian to git pull from
<bjsnider> so i don't know what is going on there
<bjsnider> the ffmpeg 5.1 release happened yesterday i think. i went in to their irc room and asked about it. they said debian/ubuntu wanted them to release it
<bjsnider> even though it's outdated code
<bjsnider> debian/ubuntu i assume refers specifically to siretart i would assume
<bjsnider> said assume twice there
<superm1> well there's more to the debian multimedia team than just him i thought
<bjsnider> that's older code than what is currently in karmic
<bjsnider> well, debian/ubuntu and specifically ffmpeg? who else is there?
<bjsnider> the 5.1 release notes specifically mentioned the linker bug that he fixed
<bjsnider> it's also awfully late in the lucid cycle for a multimedia refresh
<superm1> well if nothing else then, perhaps patching mplayer to not FTBFS
<bjsnider> why not just delete it until it's fixed
<superm1> that sounds like a waste of archive administration resources to me
<tjaalton> hm, need to merge xorg since xorg-dev is uninstallable
<bjsnider> does nvidia-current have a provides: nvidia-libvdpau or something like that?
<tseliot> nope
<bjsnider> are there provides at all?
<bjsnider> dpkg must somehow think nvidia-current is related to nvidia-glx-xxx
<bjsnider> otherwise i don't see why mplayer would pull it in
<tseliot> we have transitional packages for that
<superm1> it pulls in the 185 stuff
<superm1> which is transitional
<bjsnider> oh, right hahahaa
<bjsnider> i forgot about the transitional packages
<bjsnider> those darned things
<bjsnider> what would happen if those didn't exist and someone tried to install mplayer?
<superm1> probably wouldn't work
<bjsnider> it would error out if the dependent packages weren't there i assume
<superm1> but remember they're build-deps and suggests right now
<superm1> not recommends or depends
<bjsnider> i wonder what would happen during upgrades if the transitional packages weren't there
<bjsnider> does nvidia-current have a conflicts: nvidia-glx-xxx?
<bjsnider> without that i guess dpkg would fail due to duplicate files
<tseliot> no, its doesn't conflict with that
<bjsnider> tseliot, if someone manually installs nvidia-current, and does nvidia-xconfig to take care of xorg.conf, (bypassing jockey) are they missing anything?
<bjsnider> it seems to me they're missing the glx part
<tseliot> bjsnider: they will have to update the initramfs
<bjsnider> tseliot, nvidia-current doesn't do that though dkms?
<tseliot> bjsnider: ah, right it does that in the postinst
<superm1> s/dkms/postinst/
<bjsnider> but are they using mesa or are they using nvidia-s glx?
<bryceh> morning
<tseliot> morning bryceh
<tseliot> bjsnider: the alternative provided by nvidia-current already has the highest priority so it should use Nvidia's gl libraries
<bjsnider> ah, so you do not in fact need to use jockey to install the driver
<superm1> nvidia-xconfig is probably writing out a lot of unnecessary content to xorg.conf though
<bjsnider> yes, i agree
<bjsnider> at one point it was writing data that was incompatible with xorg and it was causing the driver to fail to load
<bjsnider> it still writes the mouse/keyboard info to it
<superm1> i almost think it would be better to provide a shim that uses xkit in place of nvidia-xconfig to avoid that
<tseliot> you can use jockey from the command line. That will give you a very minimal xorg.conf
<superm1> that or ship an xorg.conf in nvidia-current as a conffile
<bjsnider> but nvidia-settings will still write that parochial data to it as well
<superm1> i thought it was patched?
<bjsnider> oh, i don't know what's happening in lucid, but all other versions do
<tseliot> I patched nvidia-settings to use policykit, I'm not aware of any other work on it
<bjsnider> yeah, so nvidia-settings will be writing gobbledygook data to xorg.conf
<tseliot> superm1: shipping a conffile can make things ugly
<bjsnider> but it's nvidia's fault
<Sarvatt> hmm, just had an idea.. maybe we could add a pci id check in the nvidia-current postinst that checks for a 10de vendor id before it sets the nvidia alternatives
<superm1> Sarvatt, that doesnt help if you need to master an image with nvidia in it already 
<Sarvatt> hmm, if you did that though it wouldnt use nvidia GL by default in that case and activating it in jockey would end up running the postinst wouldnt it?
<Sarvatt> we should be able to add the fglrx/nvidia to the autoconfiguration list at this point in xserver I imagine also
<Sarvatt> that way we dont need an xorg.conf for nvidia anymore
<superm1> bryceh had some patches for that, but they needed work
<bryceh> hmm?
<bryceh> yeah, tseliot was going to look into improving that but ran out of time
<Sarvatt> yeah I added those :) we can add nvidia to the nouveau patch easily, our problem at the time was that we were shipping a stock xorg.conf with no explicit driver specified so it only used the first device from the autodetection list
<bryceh> it gets complicated though.  for nvidia there are also some xorg.conf settings aside from specifying the driver, like the depth, and autoconfiguring the driver would not set those up automatically
<Sarvatt> only the nologo option, dont really need that
<jcristau> wasn't fglrx the one needing to have Depth set?
<bryceh> maybe it was fglrx
<jcristau> (which is incredibly stupid, but hey)
<Sarvatt> ah nvidia has depth and Load    "glx" in it too but i didnt think they were required
<Sarvatt> i'll test it out in a bit
<bryceh> I seem to remember that at least many cards won't boot if depth is not specified
<bryceh> anyway, I believe with some work it could be hacked around server-side, but makes the size of the effort just beyond what seems easy to do quick
<Sarvatt> building xserver now with nv swapped to nvidia in the nouveau default patch to test it out real quick, will be a few hours though because I'm out of the house with a spotty connection
<Sarvatt> there seems to be an x client leak with chromium/flash/nvidia blob :(
<Sarvatt> rebooting to the new xserver without an xorg.conf now
 * Sarvatt crosses fingers.
<Sarvatt> it worked
<superm1> i thought the problem was if you had an xorg.conf though, it doesn't use the proper fallback logic
<Sarvatt> or not! :D
<Sarvatt> load glx is required
<Sarvatt> http://pastebin.com/0nGXwtDX
<Sarvatt> that was only during the jaunty and early karmic devel stage superm1 where there was a default xorg.conf with no specific driver specified but that was dropped a long time ago
<Sarvatt> so glx is not loading with no xorg.conf but 2D works fine
<Sarvatt> that seems like a win to me, jockey installs the xorg.conf still and it'll still work without 3D if theres no xorg.conf for some reason
<superm1> is there a way to get it to conditionally load glx if it's using nvidia
<Sarvatt> need to dig into that more when I have some time, but this would make things basically work for people who install via a terminal instead of jockey (like me)
<jcristau> the server loads glx unconditionally
<superm1> Sarvatt, you can install via a terminal using jockey, jockey-text -e xorg:nvidia-current
<Sarvatt> nice!
<Sarvatt> is that new?
<superm1> i added it a release or two ago to jockey
<Sarvatt> sweet, thank you for that because I use that machine headless 99% of the time
<Sarvatt> hmm mesa is kind of screwed up now on intel, 4 glx visuals 6 glxfbconfigs and some 3D apps arent working
<Sarvatt> (in edgers not lucid's packages)
<Sarvatt> hmmm
<Sarvatt>   * Add 11_nvidia_suspend.patch: Re-enable chvt quirk for nvidia driver, to repair suspend with the current driver versions. (LP: #488720)
<Sarvatt> I swear I tested that when I was looking into it and it didnt work on my machine
<Sarvatt> yay for a mesa upload at 3KB/second
<Sarvatt> time to test out this drm backport kernel, the -14 drm backport kernel had all kinds of problems on my intel that a .33 kernel didn't have for some reason
<superm1> bjsnider, https://lists.ubuntu.com/archives/lucid-changes/2010-March/007277.html
<Sarvatt> apw: might still want to enable the powersave=0 i915 module parameter default patch on -16, still have the hangs here after resume
<bjsnider> well, siretart has decided to go with a very conservative release
<superm1> mplayer doesn't build-dep on ffmpeg though does it?
<bjsnider> oh yes it does
<bjsnider> it uses dynamic ffmpeg like everything else
<bjsnider> i tried building the 5.1 release yesterday and it still had the vhook stuff in it
<bjsnider> not part of current svn code and hasn't been for a long time
<bjsnider> but whatever. he's the expert
<apw> bryceh, RAOF, finally have gotten what i think is the upgrade packages for drm33.  all in my red PPA
<bryceh> apw, great thanks
<bdrung> will xserver-xorg-video-ati updated to version 6.12.191? this will fix the tearing bug #514845
<ubottu> Launchpad bug 514845 in xserver-xorg-video-ati "videos and window movements tear" [Undecided,Triaged] https://launchpad.net/bugs/514845
<bryceh> bdrung_, 6.13 just came out iirc; probably we'll move to that
<bdrung_> bryceh: great
<bryceh> we'll probably need a ffe though
<bdrung_> bryceh: you can use my bug report for getting it accepted ;)
<bdrung_> bryceh: the current version in the archives hurts my eyes (found no translation for augenkrebs)
<bryceh> bdrung_, no, there's not evidence that you tested the newer version and found it solved the issue, so it won't work as a base for a ffe
<bryceh> I don't know what augenkrebs is
<bdrung_> maybe going cross-eyed (direct translation would be eye cancer, but this is meant metaphorically)
<bdrung_> bryceh: i tested a snapshot from 2010-02-24, but i will explicitly test 6.12.191 or 6.13.
<bdrung_> bryceh: according to http://www.x.org/wiki/radeon 6.13 is not yet released
<Trinity33> hi anyone here?
<Trinity33> knock knock........
<BUGabundo> no
<Trinity33> i just found info somewhere that is i want to help i should come over :) so i got lucid alpha 3 q9000 quadcore ati hd4850 ddr2 4gb so where is that driver i have to test:) the last one i tested from open source included in lucid doesnt work so is there anything a=else i could do?
<Trinity33> any other driver to check ?
<Trinity33> catalyst 10.2 doesnt work in 2.6.32
<Sarvatt> Trinity33: there is no catalyst for lucid to test yet unfortunately
<Sarvatt> I'm kind of doubting there even will be one at this point..
<Trinity33> why doesnt soemone make one? for me? nvidia is working in lucid
<Sarvatt> because its a closed source driver and only ATI can do it
<Trinity33> the driver included in lucid doesnt work with hd4850 too it use to much cpu
<Sarvatt> it stinks because we really need time to work out the packaging issues like we did with the nvidia binary driver
<Sarvatt> Trinity33: try booting with radeon.modeset=0 added to the kernel command line
<Sarvatt> the 2.6.32-16 kernel should hopefully help with that a bit
<Sarvatt> i'm guessing you're complaining about how slow flash is with the radeon drivers? radeon.modeset=0 should help with that alot
<Trinity33> im not that good with drivers and generally linux im beginner :) so if i have to change something u need to speak english or russian i tried open source driver in karmic 2.6.31.14 and it use lot of cpu too the same like in lucid in karmic i have installed catalyst and the cpu usage is between 0 and 2% with open source driver between 30 and 50% cpu
<bryceh> Sarvatt, yes there will be an -fglrx
<bryceh> Sarvatt, they always deliver it in time, but only just.
<johanbr> Does anyone know if it's possible with nouveau to detect a GPU lockup and do a reset (similar to what Intel does) ?
<bryceh> johanbr, not afaik
<bryceh> at least not currently
<johanbr> alright, thank you
<Sarvatt> only 965+ intel you should say :) it doesn't now but i imagine some of the newer hardware will be able to do it at some point because I'm pretty sure I remember the windows drivers doing it. nouveau is reverse engineered though so i wouldnt hold my breath for it to happen anytime soon if the blob doesn't already do it
<RAOF> johanbr: It would actually be pretty easy to implement that.
<johanbr> oh, alright :)
<johanbr> so the nouveau people know how to "hot-reset" the gpu?
<RAOF> In some cases.
<RAOF> Oh, I was thinking more of âwhen you have detected a GPU lock up, tell someone so you can get a good bug reportâ.
<RAOF> I'm not sure that being able to recover from arbitrary GPU lockups is easy.
<RAOF> But GPU lockups are currently detected, various errors are detected, and a subset of them can be resloved.
<johanbr> I get them every few days, but I'm not sure how to get the debug information...
<johanbr> I could ssh in from my phone, I guess
<RAOF> #nouveau is likely to be a better resource for actual debugging.
<johanbr> alright, thanks
#ubuntu-x 2010-03-05
<Sarvatt> has mesa-utils been in universe for a long time?
<Sarvatt> cant enable compiz or KDE desktop effects without glxinfo... was just messing around on a kubuntu livecd
<RAOF> I thought compiz now did its own gl extension detection?
<RAOF> It's quite possible that kwin still calls out to glxinfo; I don't think kwin's been the subject of a ruthless time-to-desktop shaving exercise.
<Sarvatt> kwin for sure needed mesa-utils installed to enable gl compositing, i couldn't activate it until i manually enabled universe and installed it
<Sarvatt> grabbing the compiz source to check but i swear it just had glxinfo calls in it when i looked a few days ago
<RAOF> file $(which compiz): ELF 64-bit LSB executable.
<RAOF> It's no longer a wrapper script that calls glxinfo; I guess it might call out to glxinfo from C code, but that seems less likely.
<Sarvatt> ah yeah it doesn't need glxinfo anymore outside of the apport hook
<Sarvatt> i see the checks in src/screen.c
<RAOF> Sarvatt: Have you updated xorg-edgers with new nouveau stuff?  It seems compiz broke for at least one poor widdle macbook with an update today.
<Sarvatt> nope, it needs to be updated, i haven't had time to mess with it because i've been in bug fixing mode all day and am about to pass out :)
<RAOF> You are most welcome to be in bugfixing mode!
<Sarvatt> RAOF: doesn't UNE call glxinfo to determine if it should run in 2D or 3D mode?
<RAOF> That's a good point!
<AtomicSpark> So I have this little icon in my notification area and it references this blog http://blogs.gnome.org/hughsie/2009/08/17/gnome-power-manager-and-blanking-removal-of-bodges/
<AtomicSpark> It mentions X, so I figured I'd ask about it in here. ;3
<Sarvatt> looks like kde and wine need some extending to work with nouveau 3D (yay...)
<Sarvatt> kwin/compositingprefs.cpp has the gl vendor strings hardcoded and wine does the same
<RAOF> kwin hardcodes vendor strings?  Sucky.
<Sarvatt> (in kdebase-workspace)
<Sarvatt> well its just determining if gl compositing should be used by default by the vendor so its no so bad in KDE
<Sarvatt> wine on the other hand...
<Sarvatt> is it me or does that netbook-launcher glxinfo check not look right in the first place..? its parsing the output for Direct Rendering: Yes when you could have that with swrast? if anything I'd think it should be checking the opengl renderer string for != Software Rasterizer or Mesa DRI || Gallium as well, or heck just put the code in and bypass glxinfo altogether to be faster
<Sarvatt> you're working on netbook-launcher now aren't ya RAOF? only reason I'm bugging you about it :)
<RAOF> Sarvatt: Yeah, I am.  You're welcome to bug me about it, but I'm currently turning f-spot into a fusion-powered rocket ship.
<Sarvatt> well it'd have to be renderer string != Software Rasterizer or contains Mesa || Gallium, OR the opengl version string contains NVIDIA || ATI 
<Sarvatt> silly blob drivers put the card names in the renderer string and the vendor in the version string and swrast has Mesa in the version string too so couldnt use just the version string
<Sarvatt> of course I see netbook-launcher being the most use on arm and who the heck knows what gl info those blob drivers (that arent even packaged in ubuntu) use
<tjaalton> yeah, serial wacom works
<tjaalton> apw, RAOF: so which nouveau API are we getting for lucid? reading through the dri-devel flamefest about this made me realize that if and when there are going to be newer kernels backported to lucid (as I've heard is the plan) nouveau will break
<tjaalton> if we stick to 0.0.15
<apw> tjaalton, they said they would be supporting .33 drm for some time, which api does that have
<jcristau> 15 i think
<tjaalton> apw: yes, but it's still the same problem; harder to run newer kernels with nouveau (needs the newer ddx as well)
<tjaalton> and lidrm
<tjaalton> *libdrm
<apw> but that problem will always exist, upstream does not strive for compatibility
<tjaalton> haven't asked but if nouveau gets out of staging in .34 then they have to
<tjaalton> and do what intel is doing, flagging features and turning them on if the userspace works with them
<tjaalton> or the other way around
<tjaalton> anyway, I'm happy as it is now, having the .33 drm backported :) this was just a heads up to see what kind of problems there will be in the future
<tjaalton> (and speaking as the maintainer of an nvidia-only shop)
<tseliot> :-)
<tseliot> shop?
<tjaalton> "shop"
<tseliot> aren't you working at the university any more?
<tjaalton> yes
<tseliot> ok, I get it now
<tjaalton> good, I can't explain the word :)
<tjaalton> in this context
<tjaalton> "place to work" or so
<tseliot> yes, just wanted to know whether I had to take that literally or not
<tjaalton> hehe
<apw> RAOF, about?  did you manage to test the update to the kernel in my red ppa?
<RAOF> apw: I did; it works.
<apw> RAOF, the versions with the linux-meta and everything
<RAOF> Yes.  It upgraded fine.
<apw> RAOF, that worked here on my mini 10v, as far as i can tell ...
<apw> you were absolutly right abut the replaces etc not being needed
<apw> thats great, can i take it you are happy with that kernel (essentially) going into the archive?
<RAOF> Yup.  the linux-backports-moudles-nouveau-lucid-$FLAVOUR dependency can be currently satisfied by the actual packges, which don't apply to the new kernel ABI, and once those kernel packages are in the archive, published and mirrored we can drop the dependency from xserver-xorg-video-nouveau and make cjwatson happy.
<RAOF> Yes.  I'm happy with that kernel going into the archive.
<tseliot> superm1: I'm setting fglrx's alternative priority to 1000 as having the same priority of nvidia-current can cause unpredictable results when in automatic mode
<RAOF> And tomorrow morning I'll pick up my new intel/nvidia netbook, and see how much nouveau likes switchable graphics.
<apw> RAOF, excellent, i'll get steves and bryceh's ack and then get it in, i suspect a special note to u-k and u-x mailinglists will be appropriate
<RAOF> Would you be able to do that?  I'm off to bed, and I'm not entirely confident I'd be coherent if I tried to write such a note now :)
<apw> RAOF, heh yeah i was assuming i would be in the frame for that, i can get bryceh to help
<RAOF> Thanks.  And with that, I depart.  Like a phantom into the night.
<apw> RAOF, thanks for you testing help
<zniavre> hello i posted bur report for legacy 173.22.14 nvidia driver https://bugs.launchpad.net/ubuntu/+source/nvidia-settings/+bug/523108
<ubottu> Launchpad bug 523108 in nvidia-settings "nvidia x server settings on ubuntu 10.4" [Undecided,New]
<zniavre> this morning i tried them again and i got same worrie
<zniavre> and 173.14.25 solved the problem
<zniavre> but i feel plymouth does not work cause im using this driver from nvidia.com
<zniavre> what can i do ? to make driver from repos working ans plymouth running
<bjsnider> change your bug report so that it is a packaging request for the newer driver
<apw> bryceh, how did your testing go on 'red' ...
<zniavre_> sorry ...
<bjsnider> zniavre_, your bug isn't an nvidia-settings bug it is a packaging request for the newer 173 driver. you need to mark the current one as invalid and create a new one
<zniavre_> ok i ll try that
<bjsnider> http://www.engadget.com/2010/03/05/nvidia-pulls-196-75-driver-amid-reports-its-frying-graphics-car/
<bjsnider> seems the firmware wasn't activating the gpu fan
<Sarvatt> nouveau is worrying me alot at the moment.. I see a whole lot of issues supporting it in a LTS with its current state and the risks by *far* outweigh the positives in my mind
<hyperair> Sarvatt: didn't you foresee this coming?
<Sarvatt> yes but I don't make the decisions and the work that has been done to get it going was a very positive thing in my eyes. I just don't feel its a good idea in its current state with how much it will break things
<Sarvatt> for instance, people wont be able to install backported or mainline kernels on nvidia machines unless they are using the blob. people are pushing for the .34 nouveau api to be a stable one and we'd be using .33 thats incompatable
<hyperair> oh that sucks.
<Sarvatt> the dumps that newer nvidia GPU support was based off of were just recently found to be completely broken
<hyperair> and that sucks even more
<hyperair> i think nv is a better bet for stability purposes then
<Sarvatt> a .33 based nouveau with the old api wont be supported by upstream
<hyperair> meh.
<hyperair> unstable APIs suck
<Sarvatt> this is alot of risk for something that is basically a gateway to install the blob graphically at this point
<jcristau> would be interesting to know whether rhel6 will have nouveau
<hyperair> is it too late to revert?
<Sarvatt> no i can see alot of ways we could safely have nouveau in and just not default like dropping xserver-xorg-video-nouveau from xserver-xorg-video-all and making the ddx optional while still keeping the xserver default nouveau patch, blacklisting the nouveau module by default, un-blacklisting it in a maintainer script in the ddx package
<tjaalton> nouveau works great for me
<tjaalton> eh, -nv is crap
<tjaalton> no need to go back now
<hyperair> tjaalton: no new kernels for you
<tjaalton> hyperair: well there are ways to go around that
<hyperair> tjaalton: like using the blob? =p
<tjaalton> no, backporting libdrm/ddx too
<tjaalton> I'm in favour of pulling the new api, more so _if_ it's marked as 1.0.0 (airlied asked for that on the nouveau list)
<Sarvatt> it works great for me as well but I'm thinking of the average user who's going to be using it without understanding all these intricacies, nvidia has such a large number of users 
<Sarvatt> and i know there are alot of gpu's that dont work properly that haven't been tested,  and functionality thats broken that will be expected to work that we miss
<libv> heh, i just slotted an AIW 9000 into a debian stable: boom.
<libv> luckily i know my way around a graphics driver a bit
<libv> but come on, how can a graphics card that, 3 years ago was probably the best supported out there _not_ work with debian stable.
<libv> nobody tests anything, as nobody has the ability to deploy new code easily
<jcristau> what's aiw 9000? :)
<libv> r250 or so
<libv> all in wonder radeon
<jcristau> ok
<johanbr> Sarvatt, but if, as you say, it's mostly a gateway for installing the blob, broken functionality shouldn't be of too much concern, as long as the basic functionality of bringing up a display is there
<libv> i am not blaming you for this, btw, just the situation as a whole is messed up
<libv> johanbr: i have tried explaining nothing else for the last 5 years
<jcristau> libv: well i have no radeon hw so i'm relying on whatever testing happens in unstable before release.
<libv> johanbr: the mountain of crap i have received for that is hard to measure.
<libv> jcristau: as said, not your fault
<jcristau> libv: if you have a fix for stable, though, i'll gladly take it :)
<libv> jcristau: a return right after variable declarations is hardly a fix :)
<jcristau> heh
<libv> but it did allow me to test the dri driver
<bjsnider> libv, the aiw series of cards hasn't been the best ati had in 8 years or so, not 3 years
<libv> which was a success, as was unichrome
<libv> bjsnider: i am one of the guys who worked with amd to free ati, i was the guy who wrote most of the modesetting code for radeonhd
<libv> bjsnider: this was 2.5ys ago
<libv> bjsnider: 2.5ys ago, r200 had the best 3d support out there
<bjsnider> i know who you are sir
<bjsnider> i listened to that talk you delivered recently at the conference
<libv> only about 2ys ago, dri was becoming better for r300 than for r200
<bjsnider> in which the intel guy took strong exception
<libv> radeon 9000 was one of the later and faster r200s
<libv> bjsnider: that'd be eric anholt; who did this commit: http://cgit.freedesktop.org/mesa/drm/commit/?id=b5495527
<bjsnider> right, anholt
<libv> now r200, at the time, was one of the best supported pieces of hardware out there
<libv> but... it still blew up in my face
<libv> why: because people do not go and test things easily
<libv> people cannot deploy a whole graphics driver stack easily
<bjsnider> but the aiw cards have tv chips on them as well
<libv> bjsnider: which is exactly what exploded
<bjsnider> the tv chip?
<libv> bjsnider: no, the code trying to initialise it
<bjsnider> it never worked very well for me
<bjsnider> even back in the day
<bjsnider> i've got one of those cards sitting around here
<libv> i inherited this hw, as i did an agp r500, from my gamer cousin, i only pulled it out now to test dri drivers
<bjsnider> used to use it in mandrake
<libv> i know that it's early 2000s hw far too well, i recommended this hw to my cousin
<libv> but still, it shows how badly these things get tested; and the reason for that is: nobody does, even though they sometimes want to, because everyone is either forced to change half their distribution, or forced to wait and upgrade their distribution before anything can be tested
<libv> this works for many things, but not for volatile stuff like graphics hw and graphics drivers
<libv> the really strange thing is that, what i suggest doing is actually setting the graphics driver developers free to some extent
<libv> and yet they are against it
<Sarvatt> r100/r200 is pretty much the main reason we're having to backport 2.6.33's drm to 2.6.32 to use KMS :)
<libv> Sarvatt: it's broken on 2.6.32?
<libv> Sarvatt: radeon still has xf86 modesetting
<jcristau> libv: ubuntu wanted kms in lucid
<jcristau> aiui
<Sarvatt> yeah wth KMS, quite alot of fixes in .33 that didnt make it back to .32 in that area but UMS is fine
<libv> Sarvatt: well, now the ratrace is on completely
<libv> kernel, libdrm, xorg and mesa will soon be tied 1-1 completely
<Sarvatt> what's the policy about stable mesa and ddx updates in -updates for a LTS? I really think we need to upgrade mesa point releases post release because almost all of my SRU's were fixes in the stable branches and bringing in whole new stable updates would wipe out big chunks of bugs instead of going through the SRU process for each individual commit
<libv> Sarvatt: where are most of those bugs situated anyway?
<libv> Sarvatt: in the mesa code itself, or in the drivers?
<libv> (that would be a mightily interesting datapoint for me)
<jcristau> my guess would be drivers, but i haven't looked.
<Sarvatt> do you mean the drivers in mesa or the x drivers?
<libv> Sarvatt: we're talking about mesa, so the drivers in mesa :)
<libv> what do you have to patch up most?
<libv> src/mesa/ or src/mesa/drivers/dri/*
<jcristau> (but then i've never had to update mesa in a stable release)
<Sarvatt> its both really but probably moreso the drivers
<libv> Sarvatt: ah, but this is probably seen as "both" because they are one whole right now
<libv> guess what i was testing the aiw 9000 for :)
<Sarvatt> do you count swrast as a driver? :)
<libv> hehe :) in my world, no, as it conflicts with src/mesa/drivers/common/driverfuncs.c
<libv> which all normal drivers do use
<libv> but the line is kind of blurry there
<Sarvatt> they do some sketchy things on the stable branches sometimes which would hinder what I was suggesting I guess, like making the libdrm-radeon1 api changes from 2.4.16 required in 7.6.1
<libv> Sarvatt: even though it's only the radeon/r200/r300/r600 dri and gallium drivers that require that
<Sarvatt> mesa is weird, the vmware people work on the stable branch instead of master and pull fixes into master from there and everyone else works on master and backports to the stablebranch
<libv> it's a mess
<libv> someone asked me recently about how i see the future of mesa, with the tungsten people now part of vmware
<libv> which is an interesting thought :)
<Sarvatt> yeah the vmware people care alot more about windows support even though it seems like linux is by far the platform that uses it the most and its holding back having a sane build system from what I see
<jcristau> having 3 build systems is what prevents it from having a sane one :)
<tjaalton> Sarvatt: the sru process is way too heavy imo, and having point releases would be nice
<tjaalton> why not put the whole point-release as a sru
<tjaalton> and keep it in -proposed for some time
<Sarvatt> for mesa 7.6 in karmic I saw issues with glxinfo segfaulting when not using mesa gl, swrast being broken on big endian platforms, too many intel and radeon fixes to count, and a bunch of memory leak fixes all over the place that were fixed by point release updates post release
<Sarvatt> mesa 7.8 should be branching any day now so hopefully they wont try to backport things that require new libdrm releases to 7.7 :D 7.7 wasn't branched yet when the ati stuff landed in 7.6 branch that needed a newer libdrm
<libv> the intel libdrm bump doesn't promise much good there
<libv> the really cool thing is, main mesa-dri only depends on libdrm 2.3.0
<Sarvatt> thats on 7.8 though, seems like too big of a change to add to 7.7 since its dependant on so much stuff like the dri1 removal if i'm not mistaken
<Sarvatt> trying to work out why nvidia requires glx explicitly enabled in an xorg.conf now
<tjaalton> Sarvatt: did you enable the blob, so that the alternatives are fixed?
<Sarvatt> hmm, you know, I didn't actually check that glx was working normally since I installed everything in a hurry for my wife to use it while I work on her laptop
<Sarvatt> yeah glx is fine, forgot i did check it because i was using compiz
<Sarvatt> looks like the problem is that it uses /usr/lib/xorg/modules/extensions/libglx.so instead of /usr/lib/xorg/extra-modules/libglx.so if you dont load glx via xorg.conf
<Sarvatt> even though -- ModulePath set to "/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules"
<Sarvatt> having an alternative for libglx.so would solve that but yuck
<bryceh> hi Sarvatt
<Sarvatt> http://pastebin.com/0nGXwtDX (no xorg.conf) vs http://pastebin.com/9G9LM0k4 (xorg.conf with glx forcibly loaded)
<Sarvatt> heyo!
<bryceh> Sarvatt, regarding your earlier concerns... I don't think he's made it public yet but RAOF has drafted a stabilization plan for nouveau.  
<bryceh> we had known going into this that there'd be a lot of regressions, and that support was going to be tough, but at the time we decided to go forward with it, we felt it would be worth the risk.  What I've seen so far has not been too far out of bounds from what I expected
<bryceh> RAOF says the next step is we need people to write bug reports on issues with nouveau, so the issues can be tracked and gotten upstream.
<Sarvatt> could be really hacky and change xorg-server/hw/xfree86/common/xf86AutoConfig.c to add a device section with glx enabled always :)
<Sarvatt> err module section I mean
<jcristau> Sarvatt: explicit Load "glx" vs default loading makes a difference?
<jcristau> that sounds like a bug to me...
<Sarvatt> yup, it ignores the ModulePath option for loading modules but loads drivers from ModulePath fine
<Sarvatt> ModulePath set to "/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules"  -- Loading /usr/lib/xorg/modules/extensions/libglx.so with no xorg.conf but it loads from /usr/lib/xorg/extra-modules/ fine with 
<Sarvatt> Section "Module"
<Sarvatt>         Load    "glx"
<jcristau> that's not modules vs driver..
<bjsnider> libv, how is the openchrome driver's 3d/compositing coming along?
<libv> bjsnider: i am the guy who writes unichrome.
<libv> openchrome is the people who forked away from me because i wouldn't accept vbe and was working on real modesetting
<libv> this real modesetting was deemed useless at the time.
<libv> and openchrome is just the xorg driver
<jcristau> how's via kms coming along then? :)
<libv> jcristau: ask via :)
<libv> openchrome is basically a dead project
<libv> there is a guy doing some useful work fixing bugs though
<libv> but that's all it is
<libv> oh, yeah, ivor hewitt pointed IDA at a more recent libddmpeg.so from via and added xvmc support for a few other chipsets too
<libv> his second contribution to free software in a decade
<bjsnider> does the driver you are working on do compositing?
<libv> bjsnider: nope, but sadly unichrome is just turning out to be a playground for future technology
<bjsnider> gee, that's funny
<libv> even though all i try to be as directly useful and immediately deployable and backwards compatible
<libv> turns out that those goals means that i am shaping the future each time :)
<bjsnider> the gnome-shell guys said they had to work on via's driver to help it along so g-s would work with it
<libv> tells one more about the current state of free software graphics than anything else
<libv> bjsnider: yes, VIA's driver.
<libv> bjsnider: VIA now claims it is working with openchrome, but it is not a symbiosis
<bjsnider> i'd say free software graphics are pretty much a disaster at this point
<bjsnider> but whatever
<bjsnider> that's not a friggin' secret
<libv> bjsnider: i know, and i have been working my ass off on changing that, sadly things don't work out too well each time
<libv> they do to some extent, as quite a few things of what i have done have been taken on, usually in a reinvented form
<libv> in any case, unichrome is not a dead project, it's just me.
<libv> openchrome is pretty much a dead project, as only a few bugs are being fixed by one guy, while everyone else there is acting big and are talking loudly about how they are working together with via
<bjsnider> i don't think the g-s guys were helping to develop a closed-source driver, i think it was openchrome
<libv> via is just using the openchrome people, who are trying way too hard to be relevant without doing actual code, to clean up its image while being able to retain their old mode of working
<libv> g-s?
<bjsnider> gnome-shell
<libv> i haven't seen any changes to the exa code on openchrome in the second half of the decade
<bjsnider> jon nettlet
<libv> he talks.
<libv> never acts.
<libv> "the openchrome people, who are trying way too hard to be relevant without doing actual code"
<bjsnider> he seems to be very active to me, although i'm not sure about the openchrome thing
<libv> http://www.openchrome.org/trac/timeline
<bjsnider> he's very active in the gnome-shell project and other gnome-related things
<libv> he is active in talking
<libv> not in doing
<libv> i do not follow gnome development directly, i am following enough already doing graphics drivers :)
<libv> but on the openchrome side, he just talks.
<libv> gang65 is bartosz, the guy who actually works when he finds time, and who fixes bugs
<libv> everyone is just talking out of the wrong ends of their bodies.
<libv> everyone else that is
<bjsnider> everyone's wrong but you...
<libv> bjsnider: not everyone, and not on everything, but quite a few are on many things i whine about
<libv> hence why i whine about them
<bjsnider> that's funny, because i thought everyone was wrong except me
<bjsnider> so i might be wrong about that
<libv> i liked the mark twain on the new ubuntu style notepad
<libv> "The man with a new idea is a crank until the idea succeeds."
<bjsnider> what's happening with the radeonhd driver? is that dead?
<libv> bjsnider: novell fired 20% of devs in nue
<libv> bjsnider: leaving me jobless, and leaving my colleagues unable to handle anything anymore
<libv> amd also stopped formally working on it, as it had severe financial difficulties
<libv> so ATIs plan succeeded
<bjsnider> and what was ati's plan?
<bjsnider> if ATI has ever had any plan for anything, this will be the first i've heard of it
<libv> bjsnider: first it was to stop the free software thing altogether, then they went together with redhat, who liked a bit of publicity, to provide a competing driver
<libv> bjsnider: i can spend many hours explaining what happened and provide many instances that can be deemed "highly curious" behaviour
<libv> i usually hold the same monologue at least once per month
<bjsnider> what competing driver? xf86-video-ati or radeonhd?
<libv> -ati
<bjsnider> that's  really old driver
<libv> bjsnider: r500 support in radeon happened late november
<libv> bjsnider: radeonhd development started late july of the same year
<bjsnider> i see what you're getting at
<libv> bjsnider: it is surprising how little people even know that little fact
<bjsnider> you think it was a redhat vs. novell thiing?
<libv> bjsnider: it's an AMD + SuSE (novell had nothing to do with it, it was suse people, with their long standing relationship with AMD, that existed before novell bought suse) versus ATI + rh
<libv> ATI versuse AMD and redhat versuse SuSE
<libv> versuse :)
<bjsnider> ati and amd are the same thing during this
<libv> bjsnider: if your new mothercompany tells you to opensource your crap and to provide docs and change your hw + software sales model to a hw only model, then you're not happy
<libv> and if your mothercompany then says "fine, you're not doing it, we know some guys who will"
<libv> and who then also succeed.
<libv> because we managed to create a massive and working modesetting driver on a terribly small amount of information
<libv> in a terribly small amount of time too
<libv> no, terribly small is not true
<libv> we got the massive register doc
<libv> and AMD bought us a box full of r500 hw
<bjsnider> hahaha really?
<libv> and ati thought we'd never manage to make the pieces fit together in time
<bjsnider> they sent you hardware?
<libv> bjsnider: they always do
<libv> bjsnider: hw vendors do that to distribution vendors
<bjsnider> news to me
<libv> bjsnider: i am typing to you on a laptop amd gave the radeonhd developers
<libv> as a gift
<libv> for the work we did and to get the support going at the same time (eat your own food)
<bjsnider> if amd had problems changing the ati culture they should have fired them and brought their own people in
<libv> bjsnider: bit hard when you just bought a business for more than your whole company is worth still at that point
<libv> bjsnider: and when you are trying to make money from it
<libv> add some bad management into the mix, and fun things happen
<libv> bjsnider: and about hw vendors giving sw vendors hw, this is normal
<bjsnider> ati's drivers were garbage, total garbage on windows when amd bought ati, and had been for years
<bjsnider> the driver developers were no doubt morons
<libv> but in the r500 case, there was no other option, as part of this hw was created before amd owned ati
<libv> we got preproduction hw after this though
<libv> also, always from amd
<libv> never from ati
<libv> amd made sure it got on our desks
<libv> this was one part of the food chain that ati couldn't choke us on
<libv> s/food/supply/
<bjsnider> i don't see why it would have been hard for amd to fire the driver team and bring in their own people
<bjsnider> fire everybody else too
<libv> bjsnider: the thing is, when people are used to a certain mode of working, especially when they're not that clued technically, a change in that mode of working is extremely threatening
<libv> bjsnider: people cannot admit it when they are wrong, and then fix things, they keep on fighting that, and they will not change their mode of working because that would mean that those wrong things would become apparent
<libv> this is why i am so popular, i go in and poke the sore spots all the time, and this pisses off people who created those sore spots or who would like to ignore those parts where sore spots turn up
<jcristau> bjsnider: because firing a driver team means hiring a new one, get them up to speed on the existing driver (which you can't do because you've fired the guys who knew about it), and so on...
<bjsnider> jcristau, have you used windows xp + ati around 5-10 years ago?
<bjsnider> that wasn't a driver, it was a disaster
<bjsnider> there was nothing to save, nothing to bring the new guys up to speed on
<bjsnider> i had so many little bugs and blue screens that it pushed me to nvidia when i couldn't even afford it
<libv> err, hrm
<libv> bjsnider: you just cannot do that, you can fire some rotten apples, and then tell the others to behave
<bjsnider> and the register docs were there somewhere
<libv> bjsnider: btw, there haven't been any register docs since early 2008
<libv> bjsnider: there were some shader docs, but the latest one was released by a part that at the time was already integrated in AMD
<bjsnider> i wonder why
<jcristau> bjsnider: i've never used windows xp
<libv> AMD created a gpgpu team in 2007, outside of ati
<bjsnider> jcristau, you're a smart man
<libv> and they are solely responsible for the r800 shader ISA docs
<jcristau> haven't used windows in like 8 years
<libv> ATI just put it in with the rest of the public docs, thats their only involvement
<libv> in late 2007 early 2008, we had high hopes for going with the gpgpu guys, but then some key ati guys found out about it and killed our last hope of a clear and free information stream
<bjsnider> sounds like the inmates running the asylum
<bjsnider> the amd guys should have authority over ati
<libv> bjsnider: in late 2008 amd sold its foundries
<libv> bjsnider: because they couldn't renegotiate their debt (noone will tell you this, but it stands to reason)
<libv> bjsnider: at this point, ATI was unbelievably powerful and could do whatever they wish
<libv> bjsnider: some people describe ATI as a trojan horse today
<bjsnider> amd's problems are due to their real or imagined inferiority to intel in their main business line
<bjsnider> not because of ati
<libv> bjsnider: sure, but there is more than just that going on
<libv> bjsnider: there are always sidestories happening all the time, all the way down to the individuals
<cnd> I just got a new pinetrail netbook and I've loaded up lucid on it
<cnd> but it doesn't have direct rendering enabled
<cnd> what do I need for 3d? 2.10.0 intel driver? (lucid currently has 2.9.x)
#ubuntu-x 2010-03-06
<bjsnider> nvidia is now saying the 195 unix blobs are affected by the gpu fan issue in the 196 windows drivers. unfortunately, this is the nvidia-current driver in lucid
<BUGabundo> I noticed
<BUGabundo> my fan is always at max
<BUGabundo> the clock is almost always at 400MHz too
<bjsnider> i don't think it would affect integrated hardware since there's no gpu fan there
<Sarvatt> he doesnt have integrated, and that explains why the battery life is sucking on that machine my wifes using
<bjsnider> who doesn't have integrated?
<BUGabundo> I think I do have
<Sarvatt> BUGabundo had the same 8400M GS I did last I checked?
<BUGabundo> its a 8400 GM
<bjsnider> it's a laptop
<BUGabundo> or better 8400m G
<BUGabundo> right
<BUGabundo> its _just_ a chip there
<bjsnider> unless laptops are using pci-express cards now he's got integrated
<Sarvatt> ah yeah thats got lower clocks than GS but the same thing basically
<BUGabundo> I had it clean, and applied new temp mass a few weeks ago
<Sarvatt> yep they are wired up over PCI-E internally on the board
<BUGabundo> but I do notice much more fan, latelly
<BUGabundo> then again we keep getting new gnome-power-managers in lucid
<BUGabundo> and new kernels
<BUGabundo> so its hard to pin point
<Sarvatt> ya cant adjust the profile BUGabundo?
<Sarvatt> theres a module option you can use to force it but i dont have it off the top of my head
<BUGabundo> Sarvatt: nvidia-settings gives me two choices
<BUGabundo> adaptive and performance
<Sarvatt> oh the RegistryDwords option doesnt work anymore since they added it to nvidia-settings :(
<Sarvatt> yay mesa_7.9.0~git20100305.67277a6d-0ubuntu0sarvatt_source.changes -- up to 7.9 already
<Sarvatt> ugh there's already a bug against apw's -16 kernel where r100 KMS is crashing
<libv> bjsnider: about the openchrome/gnome-shell guy: ohloh doesn't lie: https://www.ohloh.net/p/gnome-shell/contributors/116060753925724
<bjsnider> libv, you mean jon nettlet?
<bjsnider> he does a lot of testing with owen taylor. jon doesn't always do the commit after a problem is fixed
<libv> gnome uses git, author and committer are separate, ohloh checks author
<bjsnider> jon's not here to defend himself
<bjsnider> what would he tell me about you if i were to ask him?
<libv> bjsnider: ask him when he is around, nickname is jnettlet
<bjsnider> yes, i know
<bjsnider> he's not in the gnome-shell channel right now
<libv> bjsnider: but try to match talk to code, it tells a very clear story here, but does require you to look at actual code
<bjsnider> well, any contribution is better than none at all, which would be the case with me
<libv> sure, but the point i was trying to make about the openchrome people is that they're mostly into talking
<libv> (the fact that i am saying instead of coding is slightly ironic, yes)
<bjsnider> jon and who else?
<libv> xavier bachelot and ivor hewitt
<libv> the guy who doesn't talk in the openchrome deal, he's the coder.
<libv> or at least the bugfixer.
<libv> bartosz (gang65)
<bjsnider> the original reason i mentioned this is that jon told me he had to go off and fix that driver so it would work with gnome-shell
<bjsnider> or work on it anyway
<bjsnider> maybe they're caucusing on how to fix it
<bjsnider> but i woudln't actually use the hardware if someone had a .44 magnum to my head
<libv> bjsnider: but did he fix the driver so it would work with gnome-shell?
<bjsnider> hahahaa
<bjsnider> you've got me there
<bjsnider> this was two weeks ago
<bjsnider> in that time he has not fixed it
<libv> bjsnider: via might be an almost dead company, but it is still the 4th x86 graphics hw maker out there
<libv> with a market percentage smaller than the error margin, but still :)
<bjsnider> yeah, it's the most popular, right after all of the others
<libv> VIA was doing something amazing in 2003, when they, almost as an error i think, handed alan cox the code to their xfree86 driver
<bjsnider> is this 2003?
<libv> they claimed that they opensourced their graphics driver, in marketing, 3 times after that, but at that point, marketing totally overlooked that
<bjsnider> libv, why are you working on this driver?
<libv> bjsnider: because i bought this hw in 2003
<bjsnider> on a board or in a laptop?
<libv> board
<bjsnider> i know how you can save yourself a lot of work
<libv> heh.
<bjsnider> you know those massive jet engines on a 747?
<bjsnider> go near one and ask the pilot to crank it up to full throttle
<bjsnider> toss the board into the engine
<bjsnider> problem solved
<libv> *shrug*
<libv> so what do i do with those 24 other boards and laptops/netbooks?
<bjsnider> the pilot will wait until they have all been vaporized
<bjsnider> then buy something made by the nvidia corporation
<bjsnider> it's interesting that nobody's bought via, if they're the 4th largest gpu manufacturer. they must be an almost owrthless property, with only obligations to their customers left at this point
<libv> maybe because it is largely owned and run by one and the same family?
<bjsnider> mac folks cannot play 24/96 flac audio files without vlc
<bjsnider> good thing apple doesn't leech off the open source community
<tjaalton> bryceh: bh.org down again?
<Duke`> Sarvatt, will you package mesa 7.9-devel for Karmic, or stay with 7.8?
<Sarvatt> ok i managed to get plymouth working in the screwed up manner that sends sigquit to X when you press enter on one of my machines to troubleshoot it some more
<BUGabundo> woot
<Sarvatt> and the isig flag IS set on tty7 *sometimes* which is for sure whats sending sigquit when you press enter, I can see it with sudo stty -F /dev/tty7
<Sarvatt> and sudo stty -F /dev/tty7 -isig from another VT fixes it
<Sarvatt> i think this is more prevalent when you aren't using the drm plymouth renderer which is why its hitting nvidia blob drivers more
<Sarvatt> where the heck is the ubuntu plymouth bzr branch at? I just see lp:plymouth
<Sarvatt> Duke`: probably wont do 7.9 for karmic honestly unless someone else decides to do it, at least I know 7.8 will work under karmic for the near future and thats already a huge jump from 7.6.0. why dont you upgrade to lucid already if you like the crack that much? it's not far from release :)
<Sarvatt> things are just so different in lucid vs karmic and i'm already spending most of my free time keeping the ppa up to date
<tjaalton> yeah drop it already
<Sarvatt> Duke`: if you want to help keep karmic up to date in edgers it'd be *much* appreciated
<Sarvatt> i live in development releases from the day they open, though i plan on keeping lucid going for a long time in there
<Sarvatt> i think readding the tty-device-added requirements to the plymouth upstart job might help with this sigquit problem since it screws with the flags when the tty isnt ready at the start, have to test that out when i get some time
<Duke`> well I'm not sure I'll have the time for that, unless a script can do it all in one or two commands (build & upload or something like this)
<chrisccoulson> does anyone know what would cause XF86VidModeSetGamma to throw a BadValue error?
<chrisccoulson> (there's not much documentation for that)
<chrisccoulson> i'm trying to debug a screensaver crash (http://launchpadlibrarian.net/40255454/xtrace-mdeslaur.log) and can't see anything obvious that the screensaver is doing wrong
#ubuntu-x 2010-03-07
<libv> chrisccoulson: check both the vidmode lib and server side code
<libv> chrisccoulson: really easy to debug this when you have the code and gdb ready
<libv> ah, i'd say randr and driver issue.
<Sarvatt> chrisccoulson: any way to force gnome-screensaver to activate from the command line? (-a doesn't work)
<BUGabundo> CAD not good enough?
<BUGabundo> :p
<libv> does xgamma have the same result btw?
<Sarvatt> chrisccoulson: hmm yeah its using FADE_TYPE_GAMMA_NUMBER since it says it doesn't support ramps according to that xtrace, and it goes down to test_number: because it only has a gamma parameter not ramps, res = XF86VidModeGetGamma (GDK_DISPLAY (), screen, &info [screen].vmg); should be failing in his case and making him not use fade at all but its not
<Sarvatt> maybe just add a check if kvm is in use to gs-fade.c and use FADE_TYPE_NONE for it :D
<Sarvatt> try using vesa yourself like the cirrus adapter in kvm is using due to the xserver patch we have and see if it does the same thing maybe?
<Sarvatt> imagine there would be alot more bug reports similar if it happened to everyone using vesa and its something kvm specific
<Sarvatt> oh i was looking at old source, this changed things alot http://git.gnome.org/browse/gnome-screensaver/commit/?id=f423a56d536b4ce19383ed74c1550ebd12f88541
<bryceh> tjaalton, yeah tried doing a hardy->lucid upgrade on my webserver but it crashed and burned so had to do a reinstall
<bryceh> tjaalton, however most of the X content gets generated on another machine and pushed to my webserver, so all that is good to go right now
<bryceh> some of the older scripts like the package version report aren't running yet
<Sarvatt> chrisccoulson: check out hw/xfree86/dixmods/extmod/xf86vmode.c to see why it would return BadValue btw
<bjsnider> bryceh, when you started that upgrade, what did you expect? i mean would success have been a reasonable expectation?
<bjsnider> a lot of lts users are going to be faced with this decision soon
<bryceh> bjsnider, what are you getting at?
<bjsnider> i just wondred if you thought it was going to work, and if so how much confidence you had in it
<bryceh> it would have been nice to see it upgrade cleanly, but I didn't have expectations that it would
<bjsnider> i see
<bryceh> it's barely after alpha-3
<bjsnider> ok, wrong question
<bjsnider> do you think it will be possible to upgrade from hardy to lucid once the final release happens?
<bryceh> yes
<bjsnider> with a high amount of confidence that it will work?
<bryceh> well you're asking entirely the wrong person there ;-)
<bjsnider> are efforts underway to test that scenario?
<bjsnider> i mean other than the one you just went through
<bjsnider> ah, here's the question: is that upgrade officially supported by canonical?
<bryceh> in fact there's people at canonical for whom testing lts->lts upgrades is the primary part of their job
<bryceh> yes it is
<bjsnider> wow, that's a realy tough upgrade though
<bjsnider> that's a lot of deprecated packages, new packages, changes in the xorg/mesa system etc.
<bjsnider> new grub
 * bryceh nods
<bryceh> surprisingly I didn't have too many problems with the X packages, although it did get stuck on the -r128 transition package
<bryceh> system was radeon and came up with kms ok, purple screen and everything
<bryceh> something was bugged in the kernel though
<BUGabundo> bryceh: purple is the new brown
<BUGabundo> it even replaced my gnome-terminal black with _this_ fushia
<bryceh> ew
<bryceh> terminals gotta be white with black text.  anything else is abomination
<bryceh> black with green text is ok if you're old school
<BUGabundo> WHAT?
<BUGabundo> black with white text
<bryceh> *shudder*
<bryceh> next you'll be saying terminals should be transparent
<BUGabundo> ehe
<BUGabundo> err
<BUGabundo> mine is :D
<BUGabundo> 70% opace
<BUGabundo> you know my kind, it seems
<bryceh> ;-)
<BUGabundo> oh that's better 
<BUGabundo> back to 70%
<BUGabundo> this new look theme changed that too
<BUGabundo> was on 90%
<bryceh> bjsnider, I just wish we had a good tool for doing a smart backup of a hardy system 
<BUGabundo> $ dd ?
<bryceh> bjsnider, like for instance instead of just copying the mysql db files, to do sql dumps of them so they can be loaded in the new version
<BUGabundo> etckeeper?
<bjsnider> how do you mean smart? only changed files are backed up and so forth?
<bryceh> no, like backup in a form that can be restored onto lucid
<bjsnider> i solve that problem by mounting my home directory as a separate partition
<bryceh> like for instance my drupal stuff for my blog I backed up but I can't really just copy it back into place, I kind of have to recover it chunk by chunk
<bjsnider> i don't do upgrades, only clean installs
<BUGabundo> ehe
<bryceh> yeah me too.  I was half hoping the upgrade would do all the magic of converting all the files over
<BUGabundo> until my disk died early this year
<bryceh> but forgot to copy some of the drupal themes and modules and stuff
<BUGabundo> I had 3 cycles of upgrades here
<bjsnider> point your webserver stuff at your home directory so it will stick around
<bryceh> well I have /var/www on a raid partition and that's all there fine
<bryceh> it's the stuff that had been under /usr I didn't think to back up
<BUGabundo> bryceh: that's why I started doing clonezilla of my discs prior to format
<BUGabundo> I *always* forget something
<bjsnider> BUGabundo, vloopback.c:676: error: âTASK_INTERRUPTIBLEâ undeclared
<BUGabundo> package missing?
<bjsnider> find where that function is declared and install that package and you'll be fine
<BUGabundo> ahh
<bjsnider> task_interruptible
<bjsnider> and all of the others
<BUGabundo> forum says to use another package
<bjsnider> that's why make is failing
<BUGabundo> cause the one in the tar is too old for this kernel
<bjsnider> yeah, if those functions were removed in the newer kernel, that would cause it too
<BUGabundo> !info vloopback-source
<ubottu> vloopback-source (source: vloopback): vloopback modules for Linux. In component universe, is optional. Version 1.1-1 (karmic), package size 15 kB, installed size 60 kB
<bjsnider> that's what moprons like me have to worry about when making deb packages
<BUGabundo> let me try to get that source package 1st
<bjsnider> BUGabundo, check the vloopback.c file. at the beginning there will be a bunch of #includes statements. make sure it has those files
<BUGabundo> The following NEW packages will be installed:
<BUGabundo>   cvs{a} debhelper{a} gettext{a} html2text{a} intltool-debian{a} libmail-sendmail-perl{a} libsys-hostname-long-perl{a} module-assistant{a} 
<BUGabundo>   po-debconf{a} vloopback-source 
<BUGabundo> my idea didn't help
<BUGabundo> trying yours
<bjsnider> try adding the ppa, then doing an apt-get build-dep flashcam
<BUGabundo> ok
<bjsnider> !find sched.h lucid
<BUGabundo> 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
<BUGabundo> didn't take me no where
<ubottu> File sched.h found in asterisk-dev, dietlibc-dev, fftw-docs, libace-dev, libc6-dev (and 31 others)
<BUGabundo> did I tell you the ppa only has 32bits paclages?
<bjsnider> BUGabundo, try installing libc6-dev
<bjsnider> then do make again
<BUGabundo> already instaled
<BUGabundo> no go
<bjsnider> which files are in the include statements?
<bjsnider> why did he only build i386 packages?
<BUGabundo> http://paste.ubuntu.com/390042/
<BUGabundo> cause that's all he needed for him?
<bjsnider> what a numbskull
<bjsnider> you have the linux-headers package for your kernel installed?
<bjsnider> because almost all of those headers are from the kernel
<BUGabundo> checking
<bjsnider> is this popovetsky the developer of the software?
<BUGabundo> $ dpkg -l | grep linux-headers | pastebinit 
<BUGabundo> http://paste.ubuntu.com/390046/
<bjsnider> what kernel are you currently running?
<BUGabundo> no, this is https://sourceforge.net/users/swift-tools/
<BUGabundo> Linux BluBUG 2.6.32-15-generic #22-Ubuntu SMP Tue Mar 2 02:23:29 UTC 2010 x86_64 GNU/Linux
<BUGabundo> Copyright Â© 2008-2010 Olivier "Swift" Debon
<bjsnider> Kernel compiled with CONFIG_VIDEO_V4L1_COMPAT
<bjsnider> is that the case with the ubuntu kernel?
<BUGabundo> yes, I expected as much
<BUGabundo> since Nol did an heck of a job getting my cam driver upstreamed
<BUGabundo> and since karmic it works OTB
<bjsnider> let me take the current release and throw it into pbuilder to see if it builds
<BUGabundo> okay
<BUGabundo> I'll be asleep before it finishs
<bjsnider> probably not
<BUGabundo> I can already barelly keep my left eye open
<BUGabundo> brb, getting some cookies
<BUGabundo> back
<bjsnider> first pbuilder run failed due to missing build-depends
<bjsnider> doing second run
<BUGabundo> ehe
<BUGabundo> which ones?
<bjsnider> build system missing /lib/modules/2.6.31-20-generic/build directory
<Sarvatt> hmm, we have the cirrus patch to make it work with KVM/qemu, why are we defaulting it to vesa?
<Sarvatt> 100_fedora_libpciaccess.patch in x-x-v-cirrus makes it work for KVM use, 184_virtual_devices_autodetect.patch in xorg-server is defaulting it to vesa
<bjsnider> BUGabundo, just tried running make here and got an error related to that option i mentioned above that the kernel has to have
<bjsnider> i am asking in the kernel channel if it has that option enabled
<BUGabundo> thanks
<bjsnider> i'll bet the 32-bit flash already has full v4l2 support and if you were using the i386 version this wouldn't be an issue
<BUGabundo> :p
<BUGabundo> maybe!
<bjsnider> if it's a usb webcam you could probably try it in a vm
<BUGabundo> its a mounted cam, but uses internal usb
<bjsnider> so you might be able to pass it off to the vm
<BUGabundo> I guess
<BUGabundo> I just don't use windows
<bjsnider> and use it with the native 32-bit flash plugin
<BUGabundo> don't even have a licence around for it
<bjsnider> what does windows have to do with it?
<bjsnider> the 32-bit linux plugin
<bjsnider> it's very different from the 64-bit version
<BUGabundo> ahhh
<BUGabundo> I tried BOTH
<BUGabundo> 64 bits from adobe labs
<BUGabundo> flash player from adobe
<BUGabundo> 32bit
<BUGabundo> and archive 32bits too
<BUGabundo> none seems to work with my webcam
<bjsnider> how do you test that?
<BUGabundo> close all browser, install lib (either in .mozilla/plugins or system), open browser, make sure its in about:plugin, open a site that uses cam
<bjsnider> what site?
<BUGabundo> bambuser.com , ustream,com,  chatroulette.com/
<bjsnider> BUGabundo, not going to do anymore tonight.
<BUGabundo> np
<BUGabundo> thanks for the time
<tjaalton> bryceh: yeah I noticed the stats came online later
<kazade> bryceh, just a quick question. I'm running Lucid + xorg-edgers and I get this with glxgears: "IRQs don't seem to be working correctly" apparently this is fixed in 2.6.33 (according to this chat log: http://bit.ly/dpP7mH) is that something that will be backported?
<tjaalton> already is
<tjaalton> just that the image is not built yet aiui
<kazade> ok cool :)
<knittl> hi guys. my x crashes after wakeup from sleep
<tjaalton> what driver
<Sarvatt> anyone able to make this guy a kernel with the patch i attached included? https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/507196 I tried using the ubuntu debian/ build system and failed a few times, dont think he'd want one of my kernel-package ones without an initrd
<ubottu> Launchpad bug 507196 in linux "[i945gme] Ubuntu falls back on vesa driver (no screens)" [High,Confirmed]
<Sarvatt> not sure how to properly bump the version in the ubuntu build system, making it 2.6.32-15.22+bug507196 or 2.6.32-15.23~bug507196 in the changelog didn't build the package properly
<Sarvatt> i asked upstream if they would consider adding the ignorelid module option to ignore the acpi lid status because i've made 6 bad lid status quirks in the past week for people and it would make it possible to have a usable system until the quirks went upstream (and they could verify they needed the quirk with a module parameter instead of rebuilding a kernel)
<Sarvatt> so many chinese knockoff netbooks with screwed up acpi popping up
<hyperair> Sarvatt: you should try poking people in #ubuntu-kernel
<hyperair> i'd build one, but mine's a kernel-package one as well
<Sarvatt> do ya know how to add the update-initramfs hooks back to the new kernel-package package?
<Sarvatt> the documentation is really confusing about it
<Sarvatt> tempted to make a new package thats 11.017 kernel-package with the updated stuff to work for .33+ kernels since that looks self contained
<hyperair> Sarvatt: --initrd
<hyperair> $ alias buildkernel
<hyperair> alias buildkernel='AUTOBUILD=1 CONCURRENCY_LEVEL=${CONCURRENCY_LEVEL:-2} ionice -c 3 schedtool -D -e make-kpkg --initrd --rootcmd=fakeroot --append-to-version=-hyper${KERNELREV:-1} kernel_{headers,image}'
<Sarvatt> doesn't work, they ripped out the initrd hook scripts
<hyperair> i think there's something in /etc/kernel-pkg.conf
<hyperair> er maybe not
<hyperair> ah /etc/kernel-img.conf
<Sarvatt> you need to copy the hook script from /usr/share/kernel-package/SOMETHING to somewhere in /etc/kernel/ but i couldnt work out where
<hyperair> $ tree /etc/kernel
<hyperair> /etc/kernel
<hyperair> |-- postinst.d
<hyperair> |   `-- dkms
<hyperair> `-- prerm.d
<hyperair>     `-- dkms
<hyperair> nothing.
<Sarvatt> for the --initrd option to work
<hyperair> it's just /etc/kernel-img.conf
<hyperair> just change the line
<Sarvatt> yeah theres nothing there now, you have to manually link it according to the man
<hyperair> i think you need some CONFIG_INITRD or so as well
<hyperair> hey i'm compiling my own kernels, and i've been using initrd
<hyperair> and i've got nothing in that directory!
<hyperair> i'm telling you, it's not necessary
<Sarvatt> ahhhhh here we go /usr/share/kernel-package/examples/etc
<Sarvatt> you're on karmic hyperair
<hyperair> oh.
<hyperair> seriously?
<Sarvatt> 12.x kernel-package is completely different now
 * hyperair facepalms
<Sarvatt> you cant compile .33 kernels with the 11.015 you have in karmic either
<hyperair> oh yes i acn.
<hyperair> $ uname -r
<hyperair> 2.6.33-hyper1
<Sarvatt> hmm what version is kernel-package?
<hyperair> 11.015
<hyperair> i think i know what you're talking bout
<hyperair> i changed some .mk scripts
<Sarvatt> the header location changed alot in .33
<Sarvatt> ah yeah
<Sarvatt> with 12.x you dont need to make-kpkg clean if compiling fails anymore though
<hyperair> /usr/share/kernel-package/ruleset/misc/version_vars.mk                    FAILED
<hyperair> eh that's cool
<Sarvatt> you can keep debian/ around, saves alot of time
<hyperair> yes it does
<hyperair> i've been doing rm -rf conf.vars debian
<hyperair> to keep the compiled objects in place
<hyperair> that saves time
<Sarvatt> Please  note that  unless there are hook scripts in /etc/kernel or added into the hook script parameter of /etc/kernel-img.conf.  no initrd will be created (the bundled in example scripts are just examples -- user action is required before anything happens).
<Sarvatt> i wish http://git.debian.org/?s= worked
<Sarvatt> its either wait 10 minutes hoping that'll work or wait 10 minutes for the whole index of git repos to load with the non-caching gitweb debian is using..
<jcristau> the repo index is supposed to be cached
<Sarvatt> ahhah /usr/share/doc/kernel-package/README.gz has good info on how to add initrd and update-grub hooks to /etc/kernel/
<Sarvatt> maybe its just that gitweb is slow as heck to show that many repos on my machine
<Sarvatt> hmm https://bugs.edge.launchpad.net/ubuntu/+source/xorg/+bug/533418
<ubottu> Launchpad bug 533418 in xorg "[xorg-edgers] ...dri/r600_dri.so: undefined symbol: _glapi_tls_Context" [Undecided,New]
<Sarvatt> anyone else using xorg-edgers on karmic with an r600+ by any chance?
<Sarvatt> i dont know why its using this -- file=/usr/X11R6/lib/modules/dri/r600_dri.so [0]; needed by /usr/lib/libGL.so.1 
<Sarvatt> yeah it looks like he has fglrx crap still hanging around, fglrx installs stuff to /usr/X11R6/lib/modules/dri/
<hyperair> is fglrx getting dropped or something?
<hyperair> isn't it the only decent 3D driver around for ATI?
<jcristau> fglrx drops itself
<jcristau> takes them a year to update to trivial api changes
<Sarvatt> its at the point where I wouldnt even use fglrx at the moment unless I had an R800 anyway even if they didnt take >10 months to adjust to a new xserver video abi, but you really need newer than distro packages to keep up with all the progress
<Sarvatt> should take bets on how long it'll take to support xserver 1.8 :)
<Sarvatt> r600+ really needs a bleeding edge kernel for power management on laptops
<Sarvatt> thats one of the other sucky things about nouveau at the moment too, geforce 8xxx+ is just as reliant on power management support to run at lower clocks and voltages and there isnt any yet
<Sarvatt> people with passively cooled desktop 8xxx+'s are going to be in a sucky situation with lucid's nouveau too :D
<tjaalton> my 8600gt seems fine so far
<Sarvatt> my passively cooled radeon hd2400 pro triggered gpu resets from overheating all the time in windows when I forced it to max clock speed
<tjaalton> so pull more upstream crack for .1 :)
<Sarvatt> +1 is going to have 2.6.35 or .36 anyway, will be alot better by then i'm sure :D
<tjaalton> no I meant 10.04.1
<tjaalton> which is probably late june
<bjsnider> BUGabundo, can the android play all of the files here: http://www.linnrecords.com/linn-downloads-testfiles.aspx
<BUGabundo> ill have to test
<BUGabundo> why do you ask?
<Sarvatt> flac support depends on what rom he's using
<BUGabundo> looking to buy a new super phone?
<Sarvatt> i dont think the stock ones under 2.0 support flac
<BUGabundo> Sarvatt: using CM
<BUGabundo> AFAIK it does have extra codecs support
<BUGabundo> let me ask
<Sarvatt> gave my htc dream to the wife 6 months ago so i havent kept up with android stuff :(
<bjsnider> i'm interested in the 24 bit and studio master 5.1 files
<Sarvatt> on a phone?
<BUGabundo> (2010-03-07 19:45:50) sunjon: BUGabundo: flac support is in afaik, haven't ever used it myself
<BUGabundo> Sarvatt: time to update to the last stable cyanogenmod
<bjsnider> Sarvatt, just want to see what its limitations are
<Sarvatt> one sec i'll point you to the dsp source so ya can see
<BUGabundo> andoid.git.k.o
<Sarvatt> what device are you looking at bjsnider?
<BUGabundo> and http://github.com/cyanogen
<Sarvatt> http://android.git.kernel.org/?p=platform/external/opencore.git;a=summary
<bjsnider> xine and mplayer have trouble with the 5.1 flac, but gstreamer and vlc can play it
<Sarvatt> what type of container do you have the 5.1 flac in?
<bjsnider> flac
<Sarvatt> i put mine in mkv and mplayer doesnt have problems with it
<Sarvatt> i just reencode all my 5.1 flac into ac3 to be passed straight to my receiver over digitial spdif though, dont have one of these fancy hdmi receivers so its reencoding anyway somewhere
<Sarvatt> and ac3 can have tags and stuff in a mka container
<BUGabundo> bjsnider: FYI player plays does samples really fine
<bjsnider> Sarvatt, what version of mplayer are you using?
<Sarvatt> i play that stuff on my htpc which runs windows, was an mplayer i built myself about 1.5 years ago when I last cared enough to mess with anything windows related besides updating my htpc front end :)
<bjsnider> BUGabundo, here's the problem with the flashcam compile: The version of vloopback included with Flashcam is too old for your kernel.
<BUGabundo> I know
<BUGabundo> I told you that yesterday
<Sarvatt> lots of places it could go wrong though, you could have it resampling to a format your speakers cant handle or the audio backend its using is screwing it up or any number of things
<bjsnider> also the developer said that he is updating vloopback soon, or whatever
<bjsnider> Sarvatt, why do you need a windows htpc?
<Sarvatt> because linux video acceleration was years behind windows and i dont care enough to switch it over since it took years to get everything working just the way i wanted it :)
<Sarvatt> and last i looked my tv tuner doesn't even work under linux
<bjsnider> well, those are very good arguments
<Sarvatt> this 2.6.32-16 kernel is using ~2 watts more than -15 :(
<Sarvatt> looks like its all chromium's fault though
<Sarvatt> sheesh, wish i had a touchpad hooked up internally over USB instead of going through the EC, I hate how using the touchpad shoots power usage and wakeups/second through the roof
<Sarvatt> power usage almost doubles and i get an extra 600 wakeups from idle per second if i use the touchpad.. lowering the psmouse module rate option to 30 from 100 makes it a little better
<Sarvatt> closed so many bugs against -synaptics about that since its a hardware limitation, at least we dont get huge cpu usage spikes while using the touchpad like windows :)
<bjsnider> BUGabundo, alright, go it
<bjsnider> BUGabundo, still have your flascham directory?
<BUGabundo> guess so
<bjsnider> head in there
<bjsnider> there is a driectory called vloopback. see it?
<BUGabundo> yes
<bjsnider> blow it away
<BUGabundo> done
<bjsnider> download this tarball to the flashcam directory: http://www.lavrsen.dk/foswiki/pub/Motion/VideoFourLinuxLoopbackDevice/vloopback-1.3.tar.gz
<bjsnider> unpack it. rename the resulting directory to vloopback
<bjsnider> then run make
<BUGabundo> done
<BUGabundo> make on the root dir, right?
<bjsnider> yes
<BUGabundo> its going
<BUGabundo> erros
<bjsnider> which kernel is this?
<BUGabundo> http://paste.ubuntu.com/390582/
<bjsnider> .31 or .32?
<BUGabundo> 2.6.32-15-generic
<bjsnider> this is tested up to .31, but do make clean
<BUGabundo> done
<bjsnider> only run make ont he root dir. do not go into the vlloopback directory and run make
<BUGabundo> ok
<BUGabundo> make again ?
<bjsnider> yes run make
<BUGabundo> http://paste.ubuntu.com/390583/
<bjsnider> well, it looks like vloopback is not compatible with the .32 kernel at this point
<Sarvatt> hmm I think I found this guys r600 dri problem, am I crazy or does it look like xorg-driver-fglrx not remove  /etc/X11/Xsession.d/10fglrx after you remove it?
<bjsnider> it did work here with the karmic kernel
<BUGabundo> thanks bjsnider
<bjsnider> that's the latest version of vloopback but not the latest development code
<bjsnider> oh wait. he says svn trunk will work with .32
<BUGabundo> cool
<bjsnider> what's the subversion command that only downloads the latest code and not the entire history of it?
<Sarvatt> superm1: sorry to bug you, but do you have any idea about that? the 10fglrx Xsession script is exporting the fglrx specific LIBGL_DRIVERS_PATH and I dont see anywhere where it is being removed when the package is removed
 * BUGabundo pulls up git
<BUGabundo> svn ? hummm rev ?
<BUGabundo> or head
<BUGabundo> nooo that's git
<BUGabundo> "rev last" I think
<bjsnider> checkout gets you the whole history
<BUGabundo> google
<BUGabundo> BOO
<BUGabundo> google fails me
<bjsnider> export
<bjsnider> alright, blow away the vloopback directory again
<BUGabundo> ahh
<BUGabundo> done
<bjsnider> then run this: svn export http://www.lavrsen.dk/svn/vloopback/trunk/ vloopback
<bjsnider> then run make
<BUGabundo> Exported revision 22.
<bjsnider> right
<BUGabundo> make clean 1st
<BUGabundo> making now
<BUGabundo> DONE
<bjsnider> it worked?
<bjsnider> it created the executable?
<BUGabundo> http://paste.ubuntu.com/390589/
<BUGabundo> it did
<BUGabundo> Found V4L2 Capture device: /dev/video0. gspca_gl860/USB 2.0 PC Camera. Current Size:  1600x1200 Format: GBRG
<bjsnider> it has the wrong prefix, but it worked
<BUGabundo> ?
<bjsnider> the make run is set to install the files to /usr/local
<BUGabundo> ok, back to MAN
<BUGabundo> and get this working
<BUGabundo> ahh
<BUGabundo> thanks, once again
<bjsnider> no prob
<bjsnider> you can run make install at this point
<BUGabundo> FATAL: Module vloopback not found.
<BUGabundo> PATH?
<BUGabundo> make ; su - ; make install
<BUGabundo> /sbin/modprobe videodev 
<BUGabundo> /sbin/modprobe vloopback
<cheako> oi
<Sarvatt> heyo, thanks because its a distro specific issue most likely and not an upstream radeon one most likely :)
<Sarvatt> does /etc/X11/Xsession.d/10fglrx exist?
<cheako> I'm glad to have found to correct place :)
<cheako> No, neither does this env.
<Sarvatt> darn
<cheako> I do have lots of fglrx stuff floating around, I'm cleaning it up.
<Sarvatt> i'm almost positive thats the issue
<cheako> /usr/share/app-install/desktop/fglrx-driver.desktop /usr/share/apport/package-hooks/source_fglrx-installer.py
<cheako> Well, if env dosen't show it then it's not the variable... I can try and clear it.
<Sarvatt> its looking for r600_dri.so at the location fglrx installs its s
<Sarvatt> err
<Sarvatt> wrong window when i was finishing that sentence :)
<Sarvatt> can you pastebin your /var/log/Xorg.0.log?
<Sarvatt> maybe its loading libdri.so (or libglx.so) from fglrx or something
<cheako> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/533418  <-- xorg.log
<ubottu> Launchpad bug 533418 in xorg "[xorg-edgers] ...dri/r600_dri.so: undefined symbol: _glapi_tls_Context" [Undecided,New]
<cheako> sweet.
<jcristau> Sarvatt: yeah that sounds like a bogus loader
<jcristau> $ objdump -T /usr/lib/xorg/modules/extensions/libglx.so |grep glapi_tls
<jcristau> 00000000 g    D  .tdata 00000004  Base        _glapi_tls_Dispatch
<jcristau> 00000004 g    D  .tbss  00000004  Base        _glapi_tls_Context
<cheako> hmm, I saw that.  I first made a symlink from the old location to the new.  Perhaps that was just the wrong fix. *shaking head*
<BUGabundo> MAUAA
<BUGabundo> bjsnider: so much work for nothing
<BUGabundo> cam still not working
<BUGabundo> Reading device map from '/home/bugabundo/.flashcamrc'
<BUGabundo> Warning: no flash video devices map file found.
<BUGabundo> Scanning Vloopback devices
<superm1> Sarvatt, shouldn't it get removed when you --purge since it's a conffile?
<cheako> I get the same from that objdump.
<cheako> So... I'm looking ofr a file with "X11R6/lib/modules/" in it.
<BUGabundo> wait wait wait..
<BUGabundo> bjsnider: it _may_ just work
<cheako> I've got to go soon ish.
<cheako> May not be back for a few days.
<cheako> /usr/lib/libGL.so.1.5.060500
<Sarvatt> cheako: can ya pastebin that Xorg.0.log so we can look at it? 
<cheako> I fixed it... I found the rough libGL that ldconfig was choosing.
<Sarvatt> oh sheesh, I'm an idiot
<Sarvatt> OpenGL vendor string: Advanced Micro Devices, Inc.
<Sarvatt> didnt even notice that since the next two lines were mesa ones
<Sarvatt> glad ya got it fixed :)
<cheako> There, now I've got compiz stuff flying all over and life is good.
<cheako> hmm, how can I mark thisbug as closed?
<tjaalton> done already
#ubuntu-x 2011-02-28
<RAOF> DAMNIT!  I need something on this screen to say âI know this screen is in front of the keyboard, but typing on that keyboard isn't going to work, it's not driven by that computerâ
<JanC> lol
<RAOF> What's even worse is that computer is *on*, so the keyboard actually does do stuff.  The monitor's got two inputsâ¦
<knittl> quickly tested: nvidia-current does *not* work with 2 monitors at full resolution
<knittl> i don't have time to give further information â maybe tonight or tomorrow
<cnd> bryce_, fyi, pkg-create-dbgsym has been fixed, so when we upload the new evdev with the bug fix for fta we'll have a dbgsym package again
<apparle> hey guys, the natty alpha2 comes with r300g driver for radeon or the old radeon driver?
<bjsnider> knittl, have you discussed this issue with nvidia?
<knittl> bjsnider: in #nvidia?
<knittl> and afk again :D
<bjsnider> no
<bjsnider> on the nvforums site
<knittl> hm no
<knittl> i haven't
<knittl> gotta register there
<tjaalton> apparle: not sure about the alpha2-image, but current natty uses gallium by default for radeon
<apparle> tjaalton: I checked that, it is using gallium.
<bjsnider> knittl, http://www.nvnews.net/vbulletin/showthread.php?t=46678
<apparle> But I get a lot of screen corruption on kde even when all the effects are disabled
<knittl> i'll have a look. laters
<tjaalton> apparle: that's probably just a bug in -ati. fixed upstream if it's the one I'm thinking about..
<apparle> and I just can't enable the effects now. which I was able to on the old radeon driver
<apparle> so where do I report the bug, what is the package called now?
<tjaalton> use x-x-v-ati for now
<apparle> earlier the Kwin effects used to work using the option LIBGL_ALWAYS_INDIRECT, but now it is not working even with that. I just get black screen with only cursor
<bdmurray> bryce_: I'm see some weird video artifacts when clicking drop down boxes that go away as the data is filled in on using radeon
<Amaranth> ah, that bug again
<bryce_> bdmurray, yeah I'm seeing it too
<bryce_> bdmurray, I started noticing it about 4-5 days ago, you?
<bdmurray> today but I've been slow to upgrade
<bryce_> we haven't rolled new -ati afaik but there was a new xserver and other bits
<bryce_> bdmurray, mind filing a bug?  might give me some extra info to compare your logs to mine
<Amaranth> Oh, I thought you were talking about fglrx
<Amaranth> But I guess you couldn't be, it doesn't work :)
<LLStarks> -intel, why must you make me so sad...
<cnd> ugh, feels like I'm so far away from anything more than ppa upload rights...
<cnd> ppu, I mean
<RAOF> cnd ?
<cnd> RAOF, just was in front of the dmb
<cnd> I don't have enough experience for motu even
<cnd> apparently
<cnd> I just don't have much interest in adding tasks to my day just so I can get upload rights
<bdmurray> bryce_: bug 726807
<ubot4> Launchpad bug 726807 in xserver-xorg-video-ati (Ubuntu) "drawing of drop down boxes produces artifacts temporarily (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/726807
<RAOF> Do they expect motu qualification before ppu rights?
<cnd> RAOF, no, I've got ppu rights
<cnd> now for utouch stuff too
<cnd> but I asked about motu rights
<cnd> and I couldn't get anything concrete out of them other than that I need more experience
<RAOF> Maybe we *should* get an X package set.
<tjaalton> cnd: sorry, i forgot to write "hear hear" to your wikipage below bryce's looong comment :P
<cnd> tjaalton, :)
<cnd> np
<cnd> I got the utouch upload rights
<tjaalton> better than nothing then
<cnd> I asked what I needed for motu
<tjaalton> but yeah, ppu rights for the x-swat packages might make sense
<cnd> and one of them said that maybe my motu sponsors could tell me when they thought I was ready
<cnd> and I said, they all do :)
<cnd> so I dunno
<tjaalton> heh
<cnd> the dmb seems like a very nebulous thing
<cnd> I don't like going in front of it
<tjaalton> well, one step at a time I guess
<cnd> I've heard it's gotten harder over the years
<cnd> quite a lot harder
<tjaalton> probably so
<bjsnider> cnd, all of the MOTUs are yale grads and members of skull & bones. coincidence? i think not...
<cnd> heh
<stgraber> cnd: I'm sure you'll become MOTU soon enough, keep up the great work.
<cnd> stgraber, :)
<cnd> it's just hard to muster up any energy to get there
<cnd> and even when I'm there, it's just a stepping stone to what would actually be helpful to me
<cnd> which is core dev
<cnd> so in the end, is it worth it for me to spend the amount of effort to get to core dev, just so I don't have to ping bryce_ or tjaalton or didrocks every time I need something uploaded?
<stgraber> well, you are one of these cases where I would +1 for core-dev but not for MOTU based on your current upload history ;)
<cnd> stgraber, if that's the case, then should I apply for core dev straight?
<stgraber> we usually like to see contributions in universe before giving MOTU, but once you'll have MOTU it'll be super easy for you to become coredev
<stgraber> cnd: the tricky part at the moment is that coredev gives you motu ;) but whenever you apply, try to have some uploads/merges in universe and apply directly for coredev
<cnd> stgraber, I've been collating endorsements here for coredev: https://wiki.ubuntu.com/ChaseDouglas/DeveloperApplication-CoreDev
<cnd> do you think I need more?
<cnd> (I wasn't sure whether to apply just for coredev or not, given my upload history)
<stgraber> that way it'll show you're fine with working with not so well maintained packages in universe and as far as I'm concerned you already showed that you know how to maintain stuff in main
<stgraber> your main upload history is "I think" good enough to apply for coredev, the only point that might be problematic is the lack of work in universe. Mostly meaning we don't see if you know how to do package merges from Debian, work with weird packaging (old debhelper, not so well done cdbs, ...)
<cnd> stgraber, ok
<cnd> stgraber, what's the best way to get that experience?
<cnd> do I need to troll for certain types of bugs?
<cnd> I really don't know how universe stuff works :)
<stgraber> looking at the list of merges early in the 11.10 cycle would probably be the easiest as there'll be plenty of merges to do
<cnd> I mean, I do technically
<cnd> stgraber, what list is this?
<cnd> I can knock out merges in no time
<stgraber> https://merges.ubuntu.com/
<cnd> I used to do tens of them a day in an rpm distro a few years back
<cnd> stgraber, ahh, ok, I'll do that then
<stgraber> https://merges.ubuntu.com/universe.html being the most interesting
<cnd> ok, now that I have a pointer of work to do, I can get cracking :)
<stgraber> as we're past feature freeze, there probably isn't much left to do for merges, maybe some bugfix releases though
<cnd> thanks!
<cnd> yeah
<stgraber> no problem
<cnd> RAOF, bryce_: there's a microsoft dongle that is a wireless receiver that tells the machine that it has every possible key/rel axis/abs axis/etc. all the time
<cnd> and the kernel is actually assigning event codes that don't even exist!
<cnd> this is what fta is seeing
<cnd> I'm trying to figure out how to not make evdev crash on such devices
<RAOF> :)
#ubuntu-x 2011-03-01
<LLStarks> if i'm having vsync issues, do i file against ddx?
<RAOF> Filing against the DDX isn't a terrible idea, but more information might help.
<LLStarks> i've been having x session-wide tearing for about a week
<LLStarks> rather, almost a week
<LLStarks> no edgers drivers or anything
<RAOF> And you're running... nouveau?
<LLStarks> 915
<RAOF> Odd.  The DDX will do; they all collect roughly the same logs, anyway.
<LLStarks> there was a recent vblank patch, wasn't there?
<LLStarks> that was i830...
<RAOF> Heh.
<RAOF> I don't recall a recent vblank patch that we've picked up.  Possibly in the kernel, though.
<LLStarks> 115_quell_vblank_counter_failed.patch
<LLStarks> probably doesn't apply here
<RAOF> Yeah.  That's just not printing out error messages.
<RAOF> Or, rather, printing only the first 5 and discarding the rest.
<LLStarks> ugh. time to bisect.
<RAOF> Want to throw up an Xorg.0.log just to check?
<LLStarks> i didn't see anything suspicious
<LLStarks> http://pastebin.com/XB1tLDfG
<RAOF> Is it only with the spanned monitors?
<LLStarks> raof, eh? single lvds.
<RAOF> LLStarks: That xorg log shows i915 allocating a 2880x900 framebuffer at one point.
<LLStarks> i had my laptop vga'd to my tv
<LLStarks> but that was yesterday.
<LLStarks> did i not power cycle <__<
<RAOF> And vsync woes aren't only when that's happening, I take it :)
<LLStarks> lemme double check
<LLStarks> yeah, spanned too.
<LLStarks> and using tv as single-monitor
<LLStarks> the tearing is quite visible on screenshots.
<RAOF> Visible on *screenshots*?  That's odd.
<LLStarks> yeah
<LLStarks> flash, xv, gl, it doesn't matter
<LLStarks> http://i.imgur.com/J2YWn.jpg
<LLStarks> i'll file a bug
<LLStarks> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/726902
<ubot4> Launchpad bug 726902 in xserver-xorg-video-intel (Ubuntu) "Tearing on i945. Loss of vsync? (affects: 1) (heat: 6)" [Undecided,New]
<LLStarks> raof, can i force vsync on intel?
<LLStarks> let's see if that compiz trick still works
<RAOF> vsync is already enabled by default.  Try glxgears for example; it should be limited to (almost) exactly 60FPS
<LLStarks> yeah, compiz fixes it.
<LLStarks> can't use metacity anymore i guess
<LLStarks> and i'm on classic
<LLStarks> hmmm. i see now.
<LLStarks> whenever metacity/compiz crashes when hooking vga or just in general, i usually reactivate metacity with just plain "metacity"
<LLStarks> instead of --replace
<LLStarks> ugh, maybe idon't get it
<bryce_> cnd, heya sorry the dmb didn't give you more concrete advice, although I do remember when I mentored kirkland it was exactly the same sort of situation; he wanted to know more specifics and just got told "it's obvious when it's obvious" or similar
<bryce_> cnd, and yeah stgraber's advice regarding doing merges is good; when I went for MOTU I devoted half a day a week to doing merges via MOM, until I felt ready (I wanted to make sure I had touched each of the different patching systems, and had done a variety of different types of packaging work)
<RAOF> LLStarks: Oh!  You're using Metacity?  With compositing?  Don't do that :)
<LLStarks> not with compositing
<LLStarks> you can't turn that on unless you explicitly set gconf, right?
<RAOF> LLStarks: Yeah, pretty much.
<RAOF> gconftool-2 --get /apps/metacity/general/compositing_manager will tell you.
<LLStarks> it was only relevant for like a month after beryl fell apart
<RAOF> No, it's still useful; I use it :)
<RAOF> When I'm not using a GL compositor.
<LLStarks> raof, is vga_switcheroo needed at a kernel level?
<RAOF> LLStarks: What do you mean?  It's implemented at the kernel level.
<LLStarks> as of which kernel?
<RAOF> .35?  From memory?
<LLStarks> i'm thinking of grabbing a few optimus notebooks lying around and bruteforcing them acpi calls
<RAOF> From my understanding of optimus, that's not going to be terribly useful, except to possibly turn off the nvidia card.
<LLStarks> dell vostros with optimus don't have a physical connection and bruteforcing worked.
<RAOF> Because, IIUC, optimus is basically the nvidia card rendering to specific piece of vram, and then copying that vram somewhere special, and then having that scanned out.
<LLStarks> https://bbs.archlinux.org/viewtopic.php?pid=882737#p882737
<LLStarks> assuming that acpi_call generates calls that "work", i see little reason why it wouldn't be sufficient.
<LLStarks> yet devs are convinced that acpi is not the solution
<LLStarks> they're looking elsewhere now
<RAOF> It looks like that dell has an ACPI mux, which suggests that the nvidia card *is* connected to the outputs, so it's not quite optimus.
<RAOF> Feel free to try; it's not like we've got specs saying it's impossible :)
<LLStarks> well, the whole point of acpi_call is discover acpi mux methods. most optimus notebooks that i've examined have at least one working method.
<LLStarks> some don't
<LLStarks> most do
<RAOF> My understanding of Optimus is that it didn't use ACPI muxs.  It's entirely possibly my understanding is wrong :)
<RAOF> Although you won't be able to do shared rendering stuff with an acpi mux; you'll have to either use the nvidia card for everything or the intel gpu for everything, which isn't optimal.
<LLStarks> i'd rather lose shared rendering if a simple SB.PCI0.PEG1.GFX0._OFF call can enable the discrete gpu
<RAOF> Well, I meant that systems which use a mux instead of a more funky approach *can't* support shared rendering.
<RAOF> Or, at least, if you've got shared rendering support then there's no reason for you to include a mux as well.
<RAOF> So they're less likely to actually have one :)
<LLStarks> well, a couple of asus notebooks can do cuda and intel simultaneously
<LLStarks> which is confusing to say the least
<LLStarks> *simultaneously on linux
<RAOF> Not tremendously confusing.  The nvidia card doesn't have to be hooked up to any outputs to make that work :)
<LLStarks> howso?
<LLStarks> btw, if not acpi, what approaches are left? nvidia coding an intel driver?
<RAOF> LLStarks: The intel and nvidia drivers cooperating, yes.
<RAOF> LLStarks: That's how it'll (eventually!) work in Linux-land :)
<tjaalton> sigh, this nvidia blob is slow
<RAOF> At 2D?
<tjaalton> yes
<RAOF> Silly blob
<tjaalton> like scrolling in chromium or nautilus
<tjaalton> nouveau was really fast
<tjaalton> huh, classic desktop opens unity now?
<tjaalton> had to disable the compiz plugin manually
<seb128> seems a bug, you are the second to mention it
<tjaalton> ok, good
<seb128> tjaalton, bug #726862
<ubot4> Launchpad bug 726862 in unity (Ubuntu) (and 1 other project) "unity launchs itself on the classic desktop (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/726862
<tjaalton> seb128: thanks
<knittl> "Due to hardware capability constraints, disabling display"
<knittl> oO
<knittl> i think this is related to my "blank screen when using nvidia-current and both screens run at full resolution"
<knittl> [ 89311.337] (WW) NVIDIA(0): Due to hardware capability constraints, disabling display
<knittl> [ 89311.346] (WW) NVIDIA(0):     device Seiko/Epson (DFP-0) in MetaMode
<knittl> [ 89311.346] (WW) NVIDIA(0):     "CRT-0:1920x1080@1920x1080+1920+0,DFP-0:1920x1200@1920x1200+0+0".
<knittl> in my xorg.0.log
<knittl> i think nvidia-current might be detecting hardware limits not correctly
<knittl> nvidia-173 has no problems with 2 screens
<knittl> tseliot: friendly ping :)
<tseliot> knittl: what's up?
<knittl> i was told to talk to you regarding jockey not recognizing the installad driver
<tseliot> that's correct
<knittl> and i wanted to ask if you have a clue about my issue above
<knittl> one monitor blank when using nvidia-current and both on full resolution
<knittl> it works with -173 though
<knittl> so i think -current is somewhat borked in that regard
<knittl> do you have a secret wire to nvidia? :]
<tseliot> knittl: I do but you'll have to file a bug report about it and attach your nvidia-bug-report.log
<knittl> bugreport on launchpad?
<tseliot> yep
<knittl> ok, on it
<tseliot> also what's up with jockey?
<knittl> nvidia bug report is generated already
<tseliot> good
<knittl> tseliot: i install nvidia-current, and jockey tells me 'another version of this driver is in use'
<knittl> after reboot that is
<tseliot> what version of ubuntu/jockey is that?
<knittl> i'm on 32 bit
<knittl> natty
<knittl> but also happened in maverick
<tseliot> what's the output of jockey-text -l ?
<knittl> tseliot: http://www.thehappy.de/neo/jockey-nvidia-current.png
<knittl> a screenshot, coz a picture says more than thousand words ;)
<knittl> $ jockey-text -l
<knittl> xorg:nvidia_current - NVIDIA accelerated graphics driver (Proprietary, Disabled, In use)
<tseliot> I don't see how it can be disabled and in use at the same time. Did you install nvidia-current from Jockey?
<knittl> disabled & in use â¦ funny :D
<knittl> tseliot: yes, i did
<tseliot> can I see 1) your xorg.conf 2) the output of sudo update-alternatives --display gl_conf , please?
<knittl> http://thehappy.de/~neo/xorg.conf
<knittl> and u-a: http://paste2.org/p/1275564
<tseliot> they look good to me. Can you file a bug report about it, please? (with "ubuntu-bug jockey-gtk")
<knittl> yup, currently filing one on nvidia-current
<tseliot> and include the information that you've just shown me in the bug report
<tseliot> thanks
<knittl> tseliot: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/727112
<ubot4> Launchpad bug 727112 in nvidia-graphics-drivers (Ubuntu) "nvdia-current does not detect hardware capabilities (affects: 1) (heat: 6)" [Undecided,New]
<knittl> hm, there's a 'correctly' missing â¦
<tseliot> if you can't add it, I will
<knittl> no, i've added it
<tseliot> ok
<knittl> tseliot: https://bugs.launchpad.net/ubuntu/+source/jockey/+bug/727117
<ubot4> Launchpad bug 727117 in jockey (Ubuntu) "jockey-gtk shows nvidia-current as disabled although it's installed and active (affects: 1) (heat: 6)" [Undecided,New]
<knittl> thanks in advance, i really appreciate your support
<tseliot> knittl: does nvidia-173 still show up in Jockey? Even after an apt-get update?
<tseliot> the log shows that it shouldn't
<knittl> tseliot: currently i only see nvidia-current (not even nouveau)
<tseliot> ok, that makes sense (I don't know about nouveau though)
<knittl> before installing nvidia-current i could see all three: nvidia-173, nvidia-current and "experimental 3d support for nvidia cards"
<knittl> that was libgl-dri-mesa-experimental or something like that
<tseliot> yes, a few things changed in jockey and in the drivers
<knittl> ok
<tseliot> can you also put the output of jockey-text -l in the bug report, please?
<knittl> oh yeah. of course
<knittl> just a sec
<knittl> added
<tseliot> thanks
<knittl> np
<bjsnider> tseliot, to avoid the error message that happens on i386 systems when installing nvidia-current, couldn't the script test for build-arch and then only install the 32-bit vdpau links on amd64?
<tseliot> bjsnider: I'd rather not have the same command twice (one without the 32bit stuff) in the postinst just for that warning
<bjsnider> tseliot, that was the only error or indication of failure in the jockey log from knittl
<bjsnider> his jockey log actually said "error", not "warning"
<tseliot> right, I don't think that's what's causing the problem though
<bjsnider> well, jockey installs the module, sets up the alternatives and then errors out before xorg.conf is created, right at the end
<tseliot> it says error only because it was printed to stderr, not because it was an error
<knittl> yeah, jockey aborts before creating xorg.conf
<knittl> and the error message is confusing
<tseliot> furthermore the error is printed only when installing the driver. The driver is not shown as enabled after a reboot
<tjaalton> does jockey still create the xorg.conf even though xserver autoloads nvidia?
<bjsnider> i guess jockey isn't logging the problem
<tseliot> tjaalton: yep
<tseliot> I don't think we want the Nvidia logo to show up every time, do we?
<bjsnider> yeah, "ubuntu, by nvidia"
<tseliot> the autoloading stuff is supposed to make things work when you install the package manually
<bjsnider> if he tries that, everything works. there's no error
<tjaalton> right, forgot about the logo
<knittl> driver installs fine with apt-get
<bjsnider> knittl, right, but if you use jockey, it errors out, says "check the jockey log" which doesn't include anything helpful
<knittl> bjsnider: yup, exactly
<tseliot> ah, so you got an error too
<knittl> yeah, but bjsnider (i think) told me, it was a false positive
<tseliot> knittl: right but was your xorg.conf written when that happened?
<knittl> no
<bjsnider> the jockey log contains an error that everyone on i386 gets
<tseliot> ok
<knittl> xorg.conf had to be generated with nvidia-xconfig (or manually)
<bjsnider> knittl, why are you on i386?
<knittl> i installed ubuntu back in the time when rumor had it, that not all apps would work with 64 bit OS
<knittl> and since there is no easy way to upgrade 32->64 bit, i'm still with i368
<tseliot> knittl: can I see the original log, please?
<knittl> tseliot: jockey.log?
<tseliot> yep
<tseliot> the one with the error
<knittl> http://thehappy.de/~neo/jockey.log
<knittl> i cleared the file before starting jockey and copied right after the error popped up and i had closed jockey
<bjsnider> the line 4 from the bottom doesn't contain an explanation
<tseliot> I guess KernelModuleHandler.enabled() failed somehow
<bjsnider> is 2.6.38-5-generic-pae the kernel in natty right now?
<knittl> yes
<tseliot> knittl: please attach that log to the bug report
<knittl> hm. i thought i had
<knittl> will do
<bjsnider> maybe the pae kernel is somehow the problem
<tseliot> I think I've found the problem. I need confirmation from pitti though
<tseliot> even though I find it a bit weird
<knittl> jockey.log attached
<tseliot> thanks
<bjsnider> tseliot, is this exclusively a jockey problem?
<tseliot> I think so
<bjsnider> in that case, his external monitor issue is exclusively an nvidia problem
<knittl> bjsnider: yeah, monitor being blank is a driver issue
<knittl> i guess
<knittl> most of the time, my internal monitor is blank though ;)
<bjsnider> actually, it could be a hardware problem, but not something we can fix anyway
<knittl> hardware problem would not explain, why it works with nvidia-173
<knittl> minus the comma
<tseliot> it definitely is s different problem
<bjsnider> in that case it's a regression in the driver
<cnd> bryce_, is it still possible to get a fix in for evdev?
<cnd> due to the alpha 3 release freeze
<tseliot> cnd: maybe we should ask an archive admin? What fix are you referring to?
<cnd> tseliot: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/725202
<ubot4> Launchpad bug 725202 in xserver-xorg-input-evdev (Ubuntu) "X crashes on startup in evdev_drv (affects: 5) (dups: 1) (heat: 32)" [Medium,In progress]
<cnd> some MS dongles are wreaking havoc in the kernal
<cnd> kernel
<cnd> and that's havoc is propagating up to evdev :)
<tseliot> nasty bug, I think we should include it
<tseliot> tjaalton: ^^
<tseliot> cnd: where's the source?
<cnd> tseliot, I just pushed it to git.debian.org
<tseliot> or the patch
<tseliot> cnd: here? http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-input-evdev.git;a=shortlog;h=refs/heads/ubuntu
<cnd> tseliot, yep
<cnd> wait, it's not there...
<tseliot> which is why I asked ;)
<cnd> ahh, pushed to the wrong tree
<cnd> sorry bout that
<cnd> one sec
<cnd> is git.debian.org hard to reach for anyone else?
<cnd> it doesn't resolve to an ip address half the time for me
<cnd> and then it's slow to connect
<cnd> tseliot, it's updated now
<tseliot> I can reach that address without problems here
<cnd> tseliot, it happens intermittently
<tseliot> ok
<tseliot> let me review your changes
<cnd> tseliot, thanks
<tseliot> cnd: any reason why you changed the source instead of adding a patch?
<cnd> tseliot, I didn't change the source
<cnd> I changed one of the patches
<cnd> the patch is my xi 2.1 work
<tseliot> cnd: ok, I guess my eyes are a little tired then ;)
<cnd> tseliot, np :)
<cnd> it's really hard to read
<cnd> I know :(
<tseliot> cnd: I'm asking an admin. If he says it's ok, I'll upload the package
<cnd> tseliot, sounds good to me
<cnd> tseliot, where are you asking?
<tseliot> cnd: private message
<cnd> ok
<tseliot> we're good to go
<tseliot> cnd: uploaded and pushed
<cnd> tseliot, great!
<cnd> thanks!
<tseliot> np
<LLStarks> does xvmc still need to be manually configured in xvmconfig or should it work out of the box?
<alexmayorga> got a hung laptop with bug 553789 Anything to gather or do I just restart?
<ubot4> Launchpad bug 553789 in xserver-xorg-video-nouveau (Ubuntu) (and 2 other projects) "X freeze/crash with nouveau driver (affects: 26) (dups: 5) (heat: 132)" [High,Confirmed] https://launchpad.net/bugs/553789
<alexmayorga> RAOF: ping
<alexmayorga> bryce_: ping
<mdeslaur> Does anyone here have a Lenovo T510 with nvidia optimus in it? is it possible to force usage of the Intel graphics in it?
<Sarvatt> mdeslaur: yep it is luckily
<Sarvatt> you can pick between the 2 GPU's or optimus mode in bios on that
<mdeslaur> Sarvatt: oh sweet...and the Intel card supports the 1920x1080 screens?
<Sarvatt> one of the few optimus laptops that actually work
<Sarvatt> yep
<mdeslaur> Sarvatt: that's good news...I was thinking of replacing my T61, but didn't want an nvidia card this time, but that,s all that is listed on the Lenovo site for the high-res screens
<mdeslaur> Sarvatt: so, thanks!
<Sarvatt> mdeslaur: how long can ya wait? :)
<mdeslaur> Sarvatt: why?
<bjsnider> Sarvatt, how's ath9k doing in natty? is it unusable still?
<Sarvatt> bjsnider: I ditched my ath9k for intel a looong time ago, had all kinds of problems on .37 with it
<Sarvatt> had to rmmod/modprobe it every 10gb transferred or so (very rough estimate)
<Sarvatt> mainly ditched it because it didn't work on the 5ghz band
<knittl> namnÃ¶,bauern sind die sicher nicht
<knittl> mc	nÃ¶, sind eher unbekannt
<knittl> woops. sorry
<bjsnider> Sarvatt, the hardware didn't work on 5gz or the driver?
<Sarvatt> hardware
<bjsnider> what was it?
<bjsnider> i think that means it was only draft n
<Sarvatt> almost all non intel mini pcie cards are only 2.4ghz band :(
<Sarvatt> card says ar5b95
<Amaranth> so, it seems fullscreen flash locks the GPU (or kernel panics in the i915 module) with a macbook pro with intel HD3000 :/
<Amaranth> I don't even know how to get debug info about that since the system seems to entirely die
<Sarvatt> Amaranth: try the drm-intel-next mainline kernel
<Sarvatt> all kinds of sandybridge problems with fixes still not merged in .38 at the moment
<Azelphur> Hi, my X keeps freezing and using 100% CPU, I'd like to take a crack at debugging it, anyone care to help?
<Azelphur> It's frozen and 100%ing now and I'm ssh'd in from my netbook
<Sarvatt> bryce_, RAOF: think I should put a newer mesa 7.10 branch checkout in x-updates/natty? so many juicy sandybridge fixes in the past few days and we're in bad shape in that regard in the archive mesa
<bryce_> Sarvatt, if you have time, that'd be great
<Sarvatt> wont even take 5 minutes to do that, okie
<Azelphur> guess I'll just keep killing and restarting X like I usually do until it works \o/
<Azelphur> looks like it'e the nvidia driver anyway, I managed to attach gdb to it
<Sarvatt> Azelphur: ya read my mind, was just going to ask that.. might want to check http://www.nvnews.net/vbulletin/forumdisplay.php?f=14
<Azelphur> fun, lots of people with problems :p
<Sarvatt> what driver version/desktop environment are you using? watching videos using vdpau and using kwin seem to be common themes with that problem there with the current releases
<bryce_> ugh kwin
<Sarvatt> if you've got flash 10.2 on 32 bit it's using vdpau so might be triggering that just having ads open on web sites
<cnd> RAOF, the libavg guys have a minimal test case for that mesa glx tls issue
<cnd> bug 259219
<ubot4> Launchpad bug 259219 in mesa (Ubuntu) "Broken TLS support in libGL.so (affects: 1) (heat: 12)" [Undecided,Confirmed] https://launchpad.net/bugs/259219
<Sarvatt> go figure, new batch of commits to 7.10 branch right as I was going to upload :)
<bryce_> what?
<bryce_> oh oops was thinking 1.10
<bryce_> and went, "Didn't they *just* release it?"
<bryce_> hmm, bug #720468 seems our most popular gpu lockup today
<ubot4> Launchpad bug 720468 in xserver-xorg-video-intel (Ubuntu) "[i915gm] GPU lockup (ESR: 0x00000001 IPEHR: 0x7f9c002d) (affects: 16) (dups: 13) (heat: 124)" [High,Triaged] https://launchpad.net/bugs/720468
<RAOF> cnd: Ah, sweet.  Test case!
<jcristau> Sarvatt: idr says he wants to do 7.10.1 tomorrow
<Sarvatt> cool!
<Sarvatt> no wonder all the intel fixes are getting cherry picked all the sudden :)
<RAOF> Yeah.  I was expecting that soon and was planning to update to 7.10.1 when it was releaesed.
 * Sarvatt has been REALLY out of the loop
<bryce_> RAOF, are you on x86_65?
<RAOF> Yes.
<RAOF> (Well, this box is; I've got an i386 965 box too)
<bryce_> would you mind grabbing the CoreDump.gz files off bugs 724187 and 723319 and doing gdb /usr/bin/Xorg ; core /tmp/CoreFile ; bt full ?
<ubot4> bryce_: Bug 724187 on http://launchpad.net/bugs/724187 is private
<bryce_> I suspect one of the bugs is just a dupe of the livecd OOM bug, and the other maybe is something to do with vbox
<bryce_> but the retracers couldn't grok them
<cnd> bryce_, lsinput works again!
<cnd> and should forever more!
<RAOF> bryce_: The coredump contained a single resolvable symbol; OsLookupColor at #38 in the stack.  Sorry, no joy.
<Sarvatt> wonderful, it looks like fglrx requires the horizontal resolution to be a multiple of 64 (or else it reports screwed up info to xrandr) to work around a driver bug that was causing corruption in 3D apps when it wasn't
<RAOF> That's totally awesome!
<Sarvatt> RAOF: did ya load the symbols manually? gotta do that for core dumps
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/659205
<ubot4> Launchpad bug 659205 in fglrx-installer (Ubuntu) "[fglrx] fails to detect correct resolution with non-multiple of 64 virtual desktop area (affects: 3) (heat: 29)" [Undecided,New]
<jcristau> hahaha.
<bryce_> cnd, awesome!
<bryce_> RAOF, ok thanks for checking
<RAOF> Sarvatt: I did not know that :).  How does one load symbols manually? :)
<Sarvatt> symbol <path to debug lib> for each lib
<Sarvatt> I think..
<Sarvatt> been awhile, let me check
<RAOF> Oh, and it'll probably work better if I don't have a locally built, patched Xserver, too.
<Sarvatt> sharedlibrary <path to debug lib>?
<Sarvatt> could have sworn it was symbol
<RAOF> I think symbol works.
<RAOF> But, again, symbol resolution will likely work better if I actually have the same symbols :)
<RAOF> Hm.  Now with symbols it seems to be dying in dl-fini, which may be fallout of the gallium fallback patch which I already fixed.
<bryce_> is that bug 724187?  yeah it smells a lot like that other vbox/gallium/x64 bug
<ubot4> bryce_: Bug 724187 on http://launchpad.net/bugs/724187 is private
<RAOF> Yeah, that's the core file I was looking at.
<Sarvatt> btw, nvidia-current works with the 1.10 release as long as IgnoreABI is set, we could just add that via jockey the way we have many times in the past
<bryce_> RAOF, does bug 723319's core give anything beyond ShouldSkipDevice()?
<ubot4> bryce_: Bug 723319 on http://launchpad.net/bugs/723319 is private
<bryce_> I'm 90% sure that's just the OOM bug already fixed now
<Sarvatt> bryce_: fixed? ahh I was sick all weekend and didn't check up on it, was it just reverted or actually fixed?
<Sarvatt> the ubiquity one?
 * Sarvatt digs
<bryce_> Sarvatt, oh sorry you were sick!
<bryce_> Sarvatt, yep, it happened I caught colin just in time as he was prepping a new ubiquity update, and he accepted the patch to revert
<bryce_> mario gave another similar patch which purportedly also helped, and he took that as well
<bryce_> the original cosmetic bug is re-opened, colin agreed it was better to have the OOM solved
<RAOF> 723319 goes up ot ProcXGetDeviceFocus, will an null client.
<bryce_> RAOF, mind pasting the bt onto the bug?  I'll follow up on it from there.
<bryce_> looking at the XorgLogOld.txt I can see it definitely is the same bug
<bryce_> RAOF, thanks that's perfect
<bryce_> bug 718620 appears to be a hybrid-graphics specific issue 
<ubot4> Launchpad bug 718620 in xserver-xorg-video-intel (Ubuntu) "With HybridGraphics Xorg assert failure: X: ../../dix/pixmap.c:118: AllocatePixmap: Assertion `pScreen->totalPixmapSize > 0' failed. (affects: 19) (dups: 25) (heat: 200)" [High,Triaged] https://launchpad.net/bugs/718620
#ubuntu-x 2011-03-02
<RAOF> bryce_: Yeah.  That's the bug report I'm wandering through.
<albert231> fwiw, I got that same assert when I booted my PC without monitor attached
<RAOF> albert231: Hm, interesting.  Evidence for my hypothesis!
<RAOF> Got an Xorg.0.log for that case?
<albert231> I have a stacktrace...
<RAOF> Before I try deliberately breaking my X server? :)
<RAOF> That's useful, but I'd also like the Xorg.0.log if you've got it.
<RAOF> There's some debugging information earlier in startup that I'm interested in.
<albert231> http://pastebin.com/SCaae1JX
<albert231> Xorg log is in the trace
<RAOF> Ta.
<RAOF> Yeah.  In that case we also can't copy the fbcon.
<RAOF> Ah, yeah.  There it is.  It makes no sense!  The scratch pixmap *is* initialised before uxa_realize_glyph_caches is called!
<LLStarks> what releases have the same graphics stack and/or kernel as natty? fedora rawhide?
<LLStarks> or rather maverick.
<RAOF> Man, âset print prettyâ should totally be the default.\
<RAOF> Ok.  I'm obviously crazy.
<RAOF> Alternatively, one of our patches is totally crazy.
<LLStarks> how crazy?
<RAOF> Crazy like an upstream fox, apparently.
<RAOF> Ah, no.  Just subtly broken.
<RAOF> Iiinteresting.  I can make it crash slightly later :)
<LLStarks> xrender broken on fc14 too. guess this needs to go to upstream.
<LLStarks> does everyone else have a working upstream, or does this seem limited to intel/945
<RAOF> VW
<RAOF> What was the test, again?
<RAOF> Hah.  There it is.
<RAOF> I win!
<ScottK> The only way to win is not to play the game.
<LLStarks> i lost the game
<RAOF> No, I both played and one.  Your analysis is incorrect :P
<RAOF> bryce_: Re: 109_dont_reconstruct_glyph_cache_on_rotate.patch - did you cherry-pick this in order to fix a known bug?  IIUC, that fixes a bug introduced in a commit that we don't have in our tree, and causes bug #718620
<ubot4> Launchpad bug 718620 in xserver-xorg-video-intel (Ubuntu) "With HybridGraphics Xorg assert failure: X: ../../dix/pixmap.c:118: AllocatePixmap: Assertion `pScreen->totalPixmapSize > 0' failed. (affects: 19) (dups: 25) (heat: 200)" [High,In progress] https://launchpad.net/bugs/718620
<LLStarks> i'm positive now. as of around a week ago, vsync has been broken with metacity, at least on intel.
<bryce_> RAOF, it can probably be dropped
<RAOF> I'll just check that it dropping it *actually* fixes that bug, but I think it's right.
<RAOF> We could also cherry-pick a commit that one depends on.
<bryce_> I had pulled it in hope that it'd resolve the font corruption issues that people reported right after updating the stack
<bryce_> since it was a relatively recent upstream change after the -intel update it looked like a good candidate
<LLStarks> is the font corruption in the same vein as the scrolling corruption?
<LLStarks> because i've noticed both
<RAOF> Still?
<RAOF> bryce_: If you'd like to keep it, I know how to make it not crash :)
<bryce_> LLStarks, I thought it might be, but it proved not to
<bryce_> I'm scratching my head, but I seem to recall we had 3 different font corruption bugs at the time, and I don't remember if one of them went away after this patch or not
<bryce_> (and it could have gone away for other reasons)
<RAOF> I'll pull in the commit which'll fix the crash, then.
<bryce_> RAOF, okie
<bryce_> good find narrowing it to that patch
<LLStarks> being -intel is suffering
 * RAOF uses it for both his primary and secondary systems.  Although that's gen4.
<RAOF> bryce_: Would you like to upload -intel 1ubuntu12?
<RAOF> Anyone available to sponsor xserver-xorg-video-intel?  http://cooperteam.net/Packages
<bryce_> RAOF, still need sponsoring?  I can do it
<RAOF> bryce_: Luke's offered to do it, but I also decided to pull from Debian, too.  They've got useful changes.
<bryce_> alrighty
<bryce_> I pulled my old synthesizer out of my closet this evening and Dutch went absolutely apeshit over it
<RAOF> Incidentally, can we start cherry-picking from upstream using git into the diff.gz?
<RAOF> :)
 * RAOF has a keyboard on order.  Should be fun!
<bryce_> it's covered in buttons and makes noise and he can sit on it, what more can you ask for as a 1.5 yr old?
<RAOF> Totally awesome!
<bryce_> I don't favor that, but lets talk about it at UDS?
<RAOF> Ok.
<bryce_> one of the reasons for my hesitation is that we've had a few cases of non-X guys making changes outside version control, and I'm leery we could get into an even messier situation if patches are managed via version control.  bzr might be more workable on that count, but it has some troubles too
<bryce_> I also am unsure what the workflow would be for testing disabling patches (which we do from time to time), would they need to be reverted?
<RAOF> That's a good question.  That wouldn't work nicely.
<RAOF> At least I don't think it would.
<RAOF> How many times have we needed to revert an upstream cherry-pick, though?
<RAOF> This would *only* be for cherry-picks from upstream git, and it's nice because (a) we seem to have rather a lot of them, and (b) they naturally go away when we update to a version which contains those commits.
<bryce_> true, that's a good point.  there'd been a time (pre-PPA's) when we were carrying a lot more randomly sourced patches, and used to need people to test disabling them from time to time - which I don't think we could do as easily these days
<bryce_> however with PPAs I find it's easier for me to just roll them a special package than to walk them through building packages ;-)
<bryce_> and heck, half the time they never even bother testing the packages...
<RAOF> And when walking others through patch disablement there's always the question of whether they've built the packages correctlyâ¦
<bryce_> RAOF, anyway it's probably one of those things that once I've done it a few times I'll be more comfortable with it
<RAOF> Yeah.
<RAOF> It's what Debian's doing (and has been doing for a while, although they don't cherry-pick nearly as much as we do).
<bryce_> I've done git cherrypick once or twice, and remember being quite impressed with it
<bryce_> anyway, good uds topic.  I think if we switch to doing that we should do it at the start of a new release
<bryce_> also, we probably should become more consistent about using vcs on all the packages
<bryce_> (another something I've not fancied doing, but there's enough of us it makes sense)
<RAOF> The ones that aren't already in git I tend to feel aren't in git because we're hoping they'll go away :)
<bryce_> however I do think we have an issue in that using git imposes a barrier for ubuntu colleagues who could do bzr but aren't going to be as willing to do git
<RAOF> That is a problem, yes.  Although, really, they can just do what they normally do and upload outside of git and we'll fold the changes in ourselves.
<RAOF> That doesn't scale, but we don't really need it to :)
<bryce_> RAOF, so yeah, even though I don't favor it, I'm open minded to the idea.  Sell me on it at UDS. :-)
<tjaalton> ooh, git-cherrypicks.. interesting
<tjaalton> need to get some breakfast first before reading the backlog :)
<Sarvatt> can't say I'm a fan of the idea.. just a few days ago I was having to send our intel 2.12 patch series from maverick to a guy at intel, a bit easier to see our differences that way than know which commits on the branch were cherry picked and dig through the log full of packaging maintenance but I guess its just me :) we'd have to start tagging releases for sure
<RAOF> Sarvatt: Was the intel guy interested in the things we cherry-picked?
<RAOF> Ahem.  Let's save this for a nice, high-bandwidth discussion at UDS :)
<bryce_> yep
<bryce_> http://vignatti.wordpress.com/2011/02/28/x-census-for-1-10/
<bryce_> http://people.freedesktop.org/~vignatti/xdevelopment/xorg_110_xserver-SHOWING-WHEREIS-CANONICAL.txt
 * RAOF hopes to be more prominent in the 1.11 version of that.
<bryce_> RAOF, I wonder how those stats would look if we included commits to the ubuntu git tree too ;-)
<tjaalton> RAOF: how to solve the problem of wacom & git? ron keeps his own tree, but we should have a place to host the branch(es)
<tjaalton> pkg-xorg isn't it
<lag> Ah, just the people I'm looking for :D
<lag> I'm trying to pull up a desktop on my u8500
<lag> But having lack of success
<lag> Would someone mind seeing if there's a problem here please? https://pastebin.linaro.org/37/
<tjaalton> lag: no access
<lag> tjaalton: Was that a question, or a statement? 
<tjaalton> "You do not currently have access to the pastebin."
<lag> tjaalton: Ah yes, I'll use another
<lag> This should be better: http://paste.ubuntu.com/574353/
<bryce_> fbdev, eh?
<lag> bryce_: Hi Bryce 
<lag> bryce_: Yes, is that wrong?
<apw> lag what are your symtoms
<lag> apw: Black screen
<bryce_> ah, arm - Linux 2.6.31-608-imx51 armv7l Ubuntu 
<lag> bryce_: That's wrong, where did you get that from?
<apw> [    14.264] Build Operating System: Linux 2.6.31-608-imx51 armv7l Ubuntu                                                                                                                                                                                                                                                 
<bryce_> lag, from your pastebin log
<lag> Ah yes, just looked
<bryce_> that's your build OS tho
<lag> It's a generic rootfs that we use for ALL our ARM aboards
<bryce_> 2.6.35-1000-u8500 #2 SMP PREEMPT Tue Mar 1 15:21:38 GMT 2011 armv7l  
<bryce_> that's better, that's what you booted
<lag> I'm using Linux version 2.6.35-1000-u8500
<lag> Yes
<bryce_> anyway, for black screen issues, Xorg.0.log hardly ever provides useful debug info
<lag> bryce_: I'm new to this graphics mallarky - if you could point me in the right direction for decent debug ...
<bryce_> usually the procedure for debugging black screen bugs is to capture a gpu register dump with it black, and another with it not black (e.g. any workaround you've found) and then folks in the know can compare registers to see what's gone wrong
<bryce_> however I'm completely unfamiliar with debugging X issues on arm, so YMMV
<bryce_> also, I have NFI how to get gpu register dumps with fbdev
<lag> Hmmm
<bryce_> but that's how debugging works for -ati, -intel, -nouveau, etc.
<lag> I have proven graphics to work
<lag> I have an application which throws some coloured blocks around
<bryce_> this won't help you but is our stock debug page for this class of issue https://wiki.ubuntu.com/X/Troubleshooting/BlankScreen
<tjaalton> X seems to be up, there's just nothing that draws on it?
<lag> I'll take a look
<lag> tjaalton: What needs to be running to draw on it?
<tjaalton> lag: i dunno, is it a normal distro, ie. gdm should be running?
<lag> root      1239  0.0  0.8  13640  2648 ?        Ssl  08:42   0:00 gdm-binary                                                                                                                                                                                                                                               
<lag> root      1373  0.0  0.9  16060  2924 ?        Sl   08:42   0:00 /usr/lib/gdm/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1                                                                                                                                                                            
<lag> root      1427  0.2  3.7  25720 12028 tty7     Ss+  08:42   0:03 /usr/bin/X :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-gxP3xX/database -nolisten tcp vt7                                                                                                                                                             
<lag> root      1635  0.0  0.7  13860  2296 ?        Sl   08:42   0:00 /usr/lib/gdm/gdm-session-worker 
<tjaalton> does the gdm logfile have something?
<lag> tjaalton: Nothing new
<lag> tjaalton: In fact, it's fairly identical 
<tjaalton> lag: what about dmesg? it's fbdev playing tricks, so more likely a kernel problem aiui
<lag> dmesg | grep -i fb
<lag> Nothing
<lag> I'm fairly sure /dev/fb0 is created by MCDE
<lag> root@localhost:~# fuser -v /dev/fb0                                                                                         
<lag>                      USER        PID ACCESS COMMAND
<lag> /dev/fb0:            root       1473 f...m Xorg 
<lag> So X is running on /dev/fb0 and gdm is also running
<lag> What's in the middle?
<tjaalton> do you see the bootsplash (plymouth)
<tjaalton> while booting
<lag> If I kill X, I can run this: http://paste.ubuntu.com/574364/
<lag> And it displays moving blocks, so /dev/fb0 IS working
<tjaalton> ok
<lag> tjaalton: No, but we never to AFAIK
<lag> s/to/do
<tjaalton> right
<tjaalton> you can hear the drums when gdm is loaded (dunno if the sounds is still used)
<lag> Audio doesn't work
<lag> But I get a console on the serial
<tjaalton> ok
<tjaalton> well, there's no pointer device according to the logfile, but that shouldn't matter
<bryce_> lag, it seems your issue is non-obvious, perhaps the logical next action would be to file a bug report ('ubuntu-bug xorg')
<bryce_> lag, also I suspect ultimately it's going to be a kernel drm issue, so may be worthwhile to speak to apw or other kernel team members about it
<bryce_> tjaalton, any other suggestions for 'next action' on this bug?
 * apw sticks his fingers in his ears
<bryce_> apw, *grin*
<tjaalton> bryce_: no, afaict X is running fine, just that nothing ends up on the screen for some reason
<tjaalton> lag: by filing the bug we'd also see the full dmesg, in case there's something..
<bryce_> tjaalton, any chance it's a phantom output or incorrect output issue?
<lag> I've been speaking to my graphics expert
<jcristau> what's in /proc/fb?
<lag> He says that X expects a single buffered autorefreshed framebuffer
<tjaalton> bryce_: could be
<lag> And we have a doublebuffered fb0 that needs an explicit  "pan" in order to do a refresh
<bryce_> lag, what's this fellow's name?
<lag> He who must not be named 
<bryce_> lol
<lag> Do you want to chat with him?
<bryce_> nah, just curious
<lag> Robert Fecket 
<lag> He's my Graphics Guru on the ST-Ericsson Landing Team
<bryce_> ok cool
<bryce_> lag, that sounds like something which might be particular to fbdev (of which I'm unfortunately not sufficiently experienced with to say much)
<lag> https://wiki.linaro.org/EngineeringTeam#ST-Ericsson
<lag> Robert says fbdev is X11, which he isn't fluent in
<bryce_> hrm
<bryce_> we need to gain someone either on our side or yours who knows fbdev inside and our
<bryce_> out
<lag> bryce_: It's not usually something we deal it, it will have to be a Ubuntuite 
<lag> s/it/in
<tjaalton> is the single/doublebufferness a hardware feature or something you can decide on kernel cmdline?
 * lag checks
<bryce_> lag, rubbing my magic 8-ball I predict it's something you'll be dealing with in the future ;-)
<bryce_> lag, but seriously, fbdev is not a driver we tend to deal with much outside of arm
<bryce_> but still, we'll try to help
<lag> Thanks
<bryce_> lag, on -intel and other drivers, we have tools that produce register dumps.  Could you ask Robert if he can find out if there are any tools for getting GPU dumps on this hardware?
<lag> Sure
<lag> In fact, I can do better than that
<bryce_> thanks.  I *think* that is the direction debugging needs to go for this issue (unless it's something obvious I'm just missing).
<tjaalton> lunch->
<bryce_> yep, 2am for me.  bed->
<apw> night night bryce_ 
<lag> Ah, take care
<RAOF> tjaalton: I'd guess we could just host a bzr branch for wacom on launchpad.  I'd be happy to do that, and bzr builddeb is pretty awesome.
<RAOF> lag: Sounds like you might need something a little smarter than fbdev?  The other arm guys seem to take fbdev and add a little sauce to bend it to their will (omapfb, for example).
<tjaalton> hm, so bzr is said to be easier, but bzr-git has no manpages
<lag> RAOF apw tjaalton bryce_: Cracked it :D
<apw> lag, and?
<lag> -# CONFIG_DISPLAY_GENERIC_DSI_PRIMARY_AUTO_SYNC is not set
<lag> +CONFIG_DISPLAY_GENERIC_DSI_PRIMARY_AUTO_SYNC=y
<tjaalton> ha
<apw> heh
<lag> Apparently turning auto_sync off will dramatically reduce battery life and performance, but I have a desktop!
<apw> well you turned it on, so you are good no?
<lag> I'm happy
<tseliot> cnd: do you know what can be causing the synaptics kernel driver to pass x coordinates = 8176 after touching  the right area of the touchpad (not only the right edge)? I noticed this change when upgrading from Hardy to Lucid. BTW the x-axis range is 1472 - 5472
<cnd> tseliot, no idea
<tseliot> cnd: do you know someone who might know what's going on?
<cnd> there's a few people on linux-input
<cnd> but I think you'd probably need to do some debugging
<tseliot> cnd: that wouldn't be a problem
<johanbr_> What's the current situation with Nouveau and 3d in Natty? Default, possible with bits from PPA, or not at all?
<tjaalton> possible with libgl1-mesa-dri-experimental, but unsupported
<johanbr_> ahh, alright. thank you!
<ara> Hello all!
<ara> I know that there is a bug affecting Lucid that prevents installation in headless desktops 
<ara> anyone remembers the bug #?
<ara> thanks!
<tjaalton> no idea, can't seem to find it either
<bryce_> ara, I fixed it earlier this week, it ended up being a bug in ubiquity, not in X
<bryce_> ara, but #714829
<tjaalton> bryce_: that was on natty
<tjaalton> this apparently still in lucid
<ara> bryce_, that's not the bug I am looking for. The one I am looking for is one in Lucid that makes X freeze during the installation if there is no monitor attached to the desktop
<bryce_> tjaalton, ah didn't read close enough
<bryce_> yeah dunno that one
<RAOF> tjaalton: Hm.  I've never noticed that bzr-git doesn't have any manpages, mainly because (a) it's transparent, and (b) bzr help $FOO is how 
<RAOF> I find bzr help :)
<RAOF> ara was thinking of the bug where X would refuse to start with âno screens foundâ, right?
<LLStarks> bryce_, i'm sending xrender bug upstream. should i file against first known affected version of -intel?
<bryce_> LLStarks, probably doesn't matter but I'd file against the most recently tested version
<bryce_> or just leave it blank
<RAOF> They'll be more interested in the most recently tested version.  If you know the *first* affected version, then there's likely bisection to be done, too.
<LLStarks> well, regression window is 2.9.1-2.12
<bryce_> man, going through bug reports is such a slog
<Milos_SD> Hi
<Milos_SD> Is there a way to get XServer 1.10 on Maverick?
<RAOF> It might be in xorg-edgers?
<Milos_SD> RAOF, it is not. Only 1.9.2 ... 1.10 is for Natty :(
<RAOF> Any particular reason you want 1.10?
<Milos_SD> no :)
<RAOF> :)
<Milos_SD> I just want latest and gratest :D
<LLStarks> what package holds xorg-macros?
<LLStarks> nvm
<bryce_> Milos_SD, the amount of user-visible changes in 1.10 compared with 1.9 is not huge, maybe not compelling enough to trouble with it
<bryce_> oops just missed him
<bryce_> was going to suggest just running natty ;-)
<LLStarks> does rendercheck automatically log?
<bryce_> dunno
<bryce_> LLStarks, thanks for pushing the bug report upstream
 * bryce_ is way behind on getting bug reports upstreamed
#ubuntu-x 2011-03-03
<bryce_> RAOF, any ideas for bug #726179 ?  
<ubot4> Launchpad bug 726179 in xserver-xorg-video-intel (Ubuntu) "stuttery adobe flash chromium video playback (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/726179
<RAOF> bryce_: Um.  Nothing obvious.
<thesheff17> RAOF: I finally figured out what was crashing my x server....it is the virt-manager...it is when I switching between an open virtual machine window and going back to the desktop.  I opened bug #719036 Is there anything else I could try?
<ubot4> Launchpad bug 719036 in fglrx-installer (Ubuntu) "[fglrx] ATI FirePro 2450 512MB PCI-e x16 Graphics Video Card crashed X every 24-48 hours (affects: 1) (heat: 254)" [Undecided,New] https://launchpad.net/bugs/719036
<bryce_> RAOF, I'm not even sure what procedure to use for analyzing flash video playback problems.  Is this likely to not be an X issue?  Maybe there's a more appropriate package this should be filed against?
<RAOF> bryce_: It's probably better to file against the flash player?
<bryce_> ok
<bryce_> huh weird, we're getting a notable spate of "-fglrx doesn't install" bugs today
<bryce_> oh maybe someone's just triaging them over
<bryce_> RAOF, ok another "interesting" bug I'm nfi'd on - bug 721881
<ubot4> Launchpad bug 721881 in xserver-xorg-video-intel (Ubuntu) "compiz crashed with SIGSEGV in intel_region_data() (affects: 1) (heat: 10)" [Medium,New] https://launchpad.net/bugs/721881
<bryce_> seems to be unity crashing in some mesa code
<RAOF> Yeah, that's definitely mesa code.
<RAOF> Ah, sweet mipmapping fun.
<bryce_> do you have a 7.10.1 package in a ppa somewhere?  maybe having them test on that would be next action for this bug?
<RAOF> I don't have 7.10.1 anywhere yet.  That wouldn't be a bad idea, but I don't think there's anything new in the i915 mipmapping code there.
<tjaalton> hrm, after resume some parts of the screen are "dead", no input goes through
<tjaalton> running compiz --replace restored sanity
<tjaalton> RAOF: actually, I also have a personal git-tree on git.d.o, wonder if I could delegate write access to it..
<tjaalton> for xf86-input-wacom that is
<tjaalton> and whee, first patch accepted upstream (oneliner reported on lp)
<ara> RAOF, hello
<RAOF> ara: Howdie!
<RAOF> What's up? :)
<ara> RAOF, good, thanks! yourself?
<RAOF> A bit tired.  I've just been running around, doing push-ups, etc for an hour or so.
<ara> hehehe
<RAOF> But I have a coffee, and a patch to make unity less hateful on multi-head systems!
<ara> great, people will be happy :)
<ara> RAOF, cr3 told me that you mentioned a bug in Lucid that prevent installations for desktops without a monitor attached to them, do you remember the bug number?
<RAOF> I'll hunt it down.
<RAOF> It was fixed in 1.9.
<RAOF> Hah!  There it is.  Bug #337889
<ubot4> Launchpad bug 337889 in xorg-server (Ubuntu) "[needs 1.9] X server should fallback to vesa when a monitor isn't connected (heat: 4)" [Wishlist,Fix released] https://launchpad.net/bugs/337889
<RAOF> That didn't get fixed by falling back to vesa, by the way, but kms drivers will start X without a monitor attached because they can resize the framebuffer when a monitor *does* get plugged in.
<RAOF> ara: ^^^^
<ara> RAOF, thanks!
<ara> RAOF, do you think this will arrive as SRU to lucid at some point?
<RAOF> Probably not.
<RAOF> I could look to see how intricate it would be to backport if it's really important.
<ara> RAOF, well, right now, for our testing environment, it is a bit critical, as we have a bunch of desktops and only one monitor. But, oh, well, let's hope to get a KVM :)
<ara> RAOF, thanks for pointing me to the right bug 
<RAOF> And you need to start X on them?
<RAOF> Hm.  I guess so.
<dpm> Hi all
<dpm> Does anyone have an idea on how I could debug bug 726496 (or provide some more useful info so someone else more knowledgeable can debug it)?
<ubot4> Launchpad bug 726496 in compiz (Ubuntu) "Cannot use Unity or Classic desktop with effects after the latest nvidia+xorg update (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/726496
<tjaalton> dpm: well, fwiw classic with effects works here. is the whole screen frozen, or can you draw on the desktop on some part of the screen?
<dpm> hi tjaalton, the whole screen is frozen, as far as I can tell. The mouse pointer works. If I switch to a tty and then I switch back to the previous graphic screen, then the screen is black and the mouse pointer still works. Works, as in it moves, but clicking/hovering has no effect
<tjaalton> dpm: ok, so its broken
<dpm> yeah, the only workaround I've found is to switch to a tty, kill compiz and start metacity
<tjaalton> could be a bug in the nvidia driver then. works fine on my gf8600gt
<tjaalton> tseliot might have ideas when he shows up
<tjaalton> where did you upgrade from?
<dpm> ok, thanks tjaalton, I'll ask him
<dpm> what do you mean, where I upgraded from?
<tjaalton> you said there it used to work
<tjaalton> was it natty or..
<dpm> Oh, I see , I was already in natty, and the xorg+nvida had been held back for a while. As soon as there was a new nvidia driver in main a few days ago, I upgraded
<tjaalton> ok, so it's probably the driver then
<tjaalton> I've had a problem with compiz that it marks part of the screen "dead", where no input goes through
<tjaalton> after resume
<dpm> so do you think I shoud add a bug task for 'nvidia-current'?
<tjaalton> yeah
<dpm> ok, let me do that. In the meantime, do you think it might be worth going back to the previous xorg+nvidia versions? Are there instructions somewhere to do something like that?
<tjaalton> oh I'm probably seeing bug 723014
<ubot4> Launchpad bug 723014 in unity (Ubuntu Natty) (and 4 other projects) "New window tracking system breaks in the case where windows try to restack relative to destroyed windows that were never mapped (affects: 1) (heat: 503)" [Undecided,Confirmed] https://launchpad.net/bugs/723014
<tjaalton> dpm: that's an invasive change.. it's only possible if you have the old packages around
<tjaalton> aiui
<dpm> tjaalton, if it's only a matter of getting the old packages, I can see if they're still in the cache or I can get them from LP
<tjaalton> you'd need nvidia-current, xserver-xorg-core, xserver-xorg-input-evdev (and -synaptics it seems)
<tjaalton> at least those
<dpm> ok, I'll give that a go, thanks tjaalton!
<dpm> (but after work :)
<dpm> hi tseliot, how are you?
<dpm> if you've got some minutes, could you give me a hand debugging bug 726496?
<ubot4> Launchpad bug 726496 in nvidia-graphics-drivers (Ubuntu) (and 1 other project) "Cannot use Unity or Classic desktop with effects after the latest nvidia+xorg update (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/726496
<tseliot> hola dpm, fine thanks, you?
 * tseliot has a look
<dpm> fine as well, better than my laptop :)
<tseliot> hehe
<tseliot> dpm: what does this command say? update-alternatives --display gl_conf
<dpm> tseliot, http://paste.ubuntu.com/574939/
<tseliot> dpm: it looks fine. What driver/xorg were you using before the upgrade?
<dpm> I was using nvidia as well, let me check if I can find out the versions
<dpm> tseliot, I think I must have been using 260.19.29-0ubuntu1
<dpm> (nvidia)
<tseliot> ok, with the old xserver, I guess
<dpm> yeah
<tseliot> dpm: ok, I'll try to reproduce the problem here and then I'll talk to nvidia about it
<dpm> sounds great, thanks a lot tseliot!
<tseliot> dpm: oh, and please attach your nvidia-bug-report.log to the bug report. You can generate it in your home directory by running the nvidia-bug-report.sh script with root privileges
<tseliot> dpm_: oh, and please attach your nvidia-bug-report.log to the bug report. You can generate it in your home directory by running the nvidia-bug-report.sh script with root privileges
<dpm_> tseliot, ok, thanks for the heads up, done.
<tseliot> thanks
<lag> cnd: Are you around yet?
<cnd> lag, yep
<lag> cnd: Great, I have a query 
<cnd> been a while since I've chatted with you :)
<lag> cnd: I know, UDS I believe 
<lag> I've fallen into the world of Linaro
<cnd> so long ago :)
<lag> It's a dark place :)
<cnd> heh
<lag> I'm currently working on ST-Ericsson's new u8500
<lag> I have a Ubuntu desktop which is visible on the touchscreen
<lag> When I run evtest, I can see that my presses are being processed, but nothing happens to the desktop
<lag> Is there a missing link I should be aware of/can test in some way
<tjaalton> 20Mpix camera, oh please.. :P
<tjaalton> on u8500
<lag> tjaalton: Camera is broken :(
<tjaalton> lag: by design it seems :)
<lag> tjaalton: Proprietary 
<lag> tjaalton: Where were you looking to see that?
<tjaalton> 20MPix crammed on such a small area means problems anyway
<tjaalton> http://www.stericsson.com/platforms/U8500.jsp
<lag> Ah cool
<cnd> lag: https://wiki.ubuntu.com/Multitouch/Testing/uTouchEvEmu#Debugging
<cnd> if you can get me the device.prop and a sample device.record files
<cnd> then I can figure out what's wrong
<lag> tjaalton: http://www.linaro.org/snowball-announcement/
<lag> cnd: That's great - then you can teach me how to debug it myself :)
<cnd> ahh, I can do that right now if you want
<cnd> when you run evtest
<cnd> you should see ABS_{X,Y} events
<cnd> and I believe you should see BTN_TOUCH go from 0 to 1 when you are actively touching
<lag> cnd: I see: Event: time 1299161597.022652, type 3 (Absolute), code 54 (?), value 591
<cnd> I believe that is all you need for basic single touch touchscreen support
<cnd> ahh! you're getting multitouch!
<lag> I am - cool
 * lag 3 finger swipes the board
<lag> Rebooted ;)
<lag> I'll tell you something else ... when I touch the screen, screensaver is still activated
<cnd> lag, ok, MT is complicated
<lag> And in the console evtest is still seeing presses
<cnd> I don't think I have enough time to run through it all here :)
<lag> I just want it to work?
<cnd> if you can get me the evemu files
<lag> When I press Firefox, I want it to open
<cnd> I can virtually recreate your device on my machine here
<cnd> and figure out what's going on
<lag> That's neat 
<cnd> yep
<lag> No idea how to install it though
<lag> Where's the ARM *.deb?
<cnd> https://wiki.ubuntu.com/Multitouch/Testing/uTouchEvEmu#Debugging
<cnd> it's in ubuntu
<cnd> just follow the instructions
<lag> cnd: Saw that, but I don't have networking on the device
<cnd> oh
<cnd> then download it to a usb drive?
<lag> I can put it onto an SDCard - looking for the *.deb now
<lag> cnd: Wooooooo: http://ports.ubuntu.com/pool/main/u/utouch-evemu/
<cnd> lag, isn't this an armel board?
<lag> Yeah
<cnd> in which case you can find it at launchpad.net/ubuntu/+source/utouch-evemu
<lag> Is the one at http://ports.ubuntu.com/pool/main/u/utouch-evemu/ incorrect?
<cnd> I dunno
<cnd> I don't know anything about ports
<cnd> :)
<cnd> it could be the exact same file for all I know
<lag> cnd: Hopefully there isn't a loooooooong list of dependencies 
<cnd> lag, I'd be surprised if there was any list of deps, tbh
<cnd> it's c, and it operates directly on kernel ioctls and fds
<lag> dpkg: error processing utouch-evemu-tools (--install):                                                                      
<lag>  dependency problems - leaving unconfigured
<cnd> lag, you'll need it's lib package
<cnd> libutouch-evemu1
<cnd> but that's it
<lag> cnd: Yep, installing that now
<cnd> as long as you have libc too :)
<lag> Lots of SD card (which is also used for rootfs) swapping 
<cnd> heh
<lag> Do I have to do: evemu-device device.prop
<cnd> lag, nope
<cnd> that's for me to do to debug
<lag> Just the two files yeah?
<cnd> yeah
<lag> k
<lag> En route
<lag> cnd: Which repo are those tools in? I'm trying to install them on my desktop
<lag> cnd: Or are they just in your PPA?
<cnd> lag, they're in ubuntu
<cnd> ubuntu main
<cnd> natty
<lag> Oh, not Maverick?
<cnd> no
<lag> Ah
<lag> cnd: How's my input situation looking? :s
<cnd> lag, I got your files, but it's gonna be a bit for me to get back to you
<cnd> one of our team members is leaving tomorrow
<cnd> and a bunch of tasks are being doled out
<lag> cnd: NP, I'll move onto something else
<lag> cnd: Thanks
<agateau> hi
<agateau> is it possible to run GDM inside Xephyr?
<hrw> hi
<hrw> compiz is crashing like hell on my radeon5450 with ati drivers (natty)
<hrw> seb128 suggested to ask here
<hrw> I reported bug 728495 about it, will expand it with some new data
<ubot4> Launchpad bug 728495 in compiz (Ubuntu) "hangs machine on alt-tab or going to screen corner (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/728495
<hrw> other question: I run evolution, it gives me 'add account' wizard and if I cover 'forward' button with mouse all text from window disapears. on second step all is gone too but if I switch to other window then checkbox with 'restore evolution from the backup file' re-appears.
<hrw> re
<tjaalton> hrw: which version of libgl1-mesa-dri do you have?
<tjaalton> installed
<tjaalton> probably the latest, just want to make sure
<hrw> good question
<hrw>  *** 7.11.0+git20110203.7535f93e-0ubuntu0sarvatt 0
<hrw> will recheck with default ubuntu one
<tjaalton> it's newer
<tjaalton> the one from natty
<tjaalton> though the edgers one should have the fixes I'm looking at...
<hrw> this one is old edgers
<tjaalton> 7.10.1~git20110215.cc1636b6-0ubuntu2 is what I have
<Sarvatt> hrw: yeah ppa-purge xorg-edgers, natty should be better off. that edgers one is not using r600g either
<tjaalton> oh :)
<tjaalton> that might explain it then
<hrw> I thought that I dropped all from edgers when 6.14 got released
<Sarvatt> might want to add edgers to your sources, do an apt-get update (but dont upgrade) and ppa-purge xorg-edgers to make sure it cleans it all
<hrw> Sarvatt: 17:00 hrw@home:~$ dpkg -l|grep sarv|wc -l
<hrw> 0
<hrw> ok, restrted x11, lets press alt-tab 8 times
<hrw> works
<Sarvatt> glad it was something easy :)
<hrw> yes
<tjaalton> yep :)
<hrw> lets now test evo problem
<hrw> still exists ;(
<hrw> http://marcin.juszkiewicz.com.pl/download/screenshots/evo/ - can someone take a look and comment?
<hrw> ok, I need to get rid of compiz
<hrw> if I maximize evolution window then it does not accept any input
<tjaalton> heh, so the diff between winischofers sis driver and the 0.9.1 from xorg is 1.5MB
<tjaalton> and winischofers driver was the basis for SiS's 771/671 work
<tjaalton> actually, the basis was the premium version
<tjaalton> the diff between it and the one from SiS is manageable
<tjaalton> "manageable" meaning less than 1MB, but the SiS version has removed shadowfb and added xvmc
<Sarvatt> ok, color me confused.. this is happening just from updating the kernel to 2.6.38-rc7 from 2.6.38-rc6, even got him to double check its still fine with the old kernel - http://launchpadlibrarian.net/65546346/ThreadStacktrace.txt
 * Sarvatt shakes fist at https://bugs.launchpad.net/ubuntu/+source/nux/+bug/728672
<ubot4> Launchpad bug 728672 in nux (Ubuntu) "compiz crashed with SIGSEGV in intel_miptree_image_copy() (affects: 1) (dups: 1) (heat: 18)" [Medium,New]
<Sarvatt> bryce_: heads up we're going to get a ton of bugs if 2.6.38-rc7 (2.6.38-6) gets uploaded to natty soon, looks like unity and mutter are busted on it
<Sarvatt> (on intel 965+, sorry)
<bryce_> uh oh
<bryce_> Sarvatt, ref?
<RAOF> Eep.  On what hardware?  Everything, or just intel (or just *some* intel)?
<RAOF> Aah.  So, basically, on all intel.
<RAOF> Check.
<bryce_> apw, ^^^
<RAOF> Sarvatt: Does the kernel team know about this?  It sounds like something they might be interested in :)
<Sarvatt> #intel-gfx and the bug I just linked
<Sarvatt> looks like fedora is getting a bunch of bugs on it now that they updated too, i've been banging my head trying to figure out whats going on
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/nux/+bug/728672
<ubot4> Launchpad bug 728672 in nux (Ubuntu) "compiz crashed with SIGSEGV in intel_miptree_image_copy() (affects: 1) (dups: 1) (heat: 18)" [Medium,New]
<RAOF> Yay mipmaps!  Why are they always the things that are broken?
<Sarvatt> https://bugzilla.redhat.com/show_bug.cgi?id=681285
<ubot4> bugzilla.redhat.com bug 681285 in mesa "i965: crash in brw_wm_surface_state.c::prepare_wm_surfaces() where intelObj->mt == NULL" [Unspecified,New]
<Sarvatt> I asked the guy who reported the nux bug to try reverting c2e0eb167070a6e9dcb49c84c13c79a30d672431, only thing I can see remotely related
<RAOF> Sarvatt: I presume that bug also happens on mesa 7.10.1?  I've updated it in pkg-xorg git now, if you're interested.
<Sarvatt> not sure, was afk while waiting for him to test a revert, looks like c2e0eb167070a6e9dcb49c84c13c79a30d672431 (drm/i915: fix corruptions on i8xx due to relaxed fencing) is whats breaking userspace in 2.6.38-rc7 because its fine reverted..
<Sarvatt> and \o/ thanks for updating it there!
<RAOF> It obviously needs more testing before releasing on an unsuspecting populace, but it's there :)
#ubuntu-x 2011-03-04
<LLStarks> what's holding back the edgers stack?
<LLStarks> what are all these new abi deps?
<Sarvatt> LLStarks: someone to update it, haven't had time to keep up with all these packaging changes and mesa build system changes here
<LLStarks> hmm. how is osmesa implemented on ubuntu?
<tjaalton> first cleanup-patch for sis done
<tjaalton> making the delta 339 lines smaller
<tjaalton> ..but it's a start :)
<vish> gah! $echo 1 | sudo tee /sys/module/drm/parameters/debug   Â« not a great idea :s  ran out of space pretty quick 
<tseliot> try 4
<vish> oh!
<vish> tseliot: what does that do? , maybe we can add it as option to https://wiki.ubuntu.com/X/Backtracing#DRI%20/%20drm%20problems  ?
<vish> i'm having an ati X freeze which occurs at random while scrolling, and if does not happen in kernel .32, /me trying to narrow down when it started or what .. 
<tseliot> vish: that should give you a fair amount of details. Usually you don't want as many as 1 gives you
<vish> cool..! 
<Sarvatt> vish: include/drm/drmP.h explains the different debug levels
<vish> k..
<vish> .. heh, since it both kern.log and syslog get the messages, its 2x speed ;p
 * vish thinks it would be a good idea to mention 4 on the wiki too :)
<Sarvatt> there's 3 levels, DRM_DEBUG, DRM_DEBUG_DRIVER and DRM_DEBUG_KMS, can grep drivers/gpu/drm/ to see what each one does, 4 is DRM_DEBUG_KMS
<vish> Sarvatt: btw, finally got Bug #652934 fix committed :p
<ubot4> Launchpad bug 652934 in linux (Ubuntu Natty) (and 3 other projects) "[RV515] Guest session causes screen to flicker violently and session is unusable (affects: 2) (heat: 18)" [Medium,Fix released] https://launchpad.net/bugs/652934
<vish> phew ;)
 * tseliot sometimes is struck by amnesia... ;)
<Sarvatt> vish: whoa, thought that was fixed a loong time ago already
<vish> kernel has 5526 open bugs!! i wonder how they can get things done, way too many bugs IMO.. :s
<vish> hehe! once i figure this out, i'll add 1 more ;p
<vish> [drm:drm_ioctl], pid=1209, cmd=0xc0086464, nr=0x64, dev 0xe200, auth=1  Â« this seems to be overloading the logs, is that a normal message or useful/related to any X problem?
<vish> btw, when x froze and i returned from tty, got this message >  [drm:drm_mode_getfb] *ERROR* invalid framebuffer id 
 * vish wonders if "drm/radeon/kms: force legacy pll algo for RV515 LVDS" from upstream might have something to do with X freezing in RV515..
<vish> xorg-dbg > http://paste.ubuntu.com/575595/
<vish> bah, why cant X be nice.. i could just crash when doing $foo, but no, it likes to crash whenever it likes.. X needs a good spanking! ;p
<bryce_> heh
<bjsnider> Sarvatt, new blob
<Sarvatt> bjsnider: awesome, released it early! doesn't work on natty till we update to the final 1.10 xserver though
<bjsnider> i figured as much
<Sarvatt> apw: gen4 (965) and up is affected so your netbook would be fine if that's what you're testing on
<Sarvatt> apw: yeah I didn't notice that commit was sketchy from the description either since it looked like it only affected 8xx intel
<Sarvatt> apw: ickle did http://git.kernel.org/?p=linux/kernel/git/ickle/drm-intel.git;a=commit;h=bea96046b4245e9abd65ed7acfed9adfd5f6c639 to try to fix it but it's still broken with that, might be better off just reverting c2e0eb167070a6e9dcb49c84c13c79a30d672431 for rc7 and getting the fix when rc8 comes in
<apw> Sarvatt, yeah likely so, the title is just confusing.   but the mitigation seems sensible
<apw> i wonder why compiz crashes ... and whether nux needs some more protection none the less
<cnd> bryceh_, I think you forgot to git add 118_quell_error_msg.patch
<cnd> in xserver-xorg-input-synaptics
<cnd> I can't build it now :)
<bryceh_> hmm
<bryceh_> ah yes, patches ignored by default, dah
<bryceh_> cnd, pushed
<cnd> bryceh_, thanks!
<cnd> bryceh_, before you upload again
<cnd> I have a tiny one liner fix
<cnd> gimme a few mins and I'll have it pushed
<tjaalton> that's why i tend to use .diff postfix :)
 * cnd assumes you uploaded the previous pacakge
<cnd> oh, I see
<cnd> you uploaded a source package with the patch
<cnd> it just didn't make it into the git repo
<bryceh_> cnd, that's correct
<cnd> hrm, that seems silly, why would it assume a machine must have a synaptics device?
<bryceh_> I think it just tries to load all available drivers
<bryceh_> I see error messages for fglrx too
<cnd> bryceh_, anyways, I pushed my change, but you don't have to upload it now
<bryceh_> ok
<cnd> I thought you'd be reuploading cause the package was missing the patch
<cnd> this is a small patch that just needs to get in some time
<bryceh_> may as well do it now
<cnd> bryceh_, if you do, evdev has the same one line fix
<cnd> both are pushed
<bryceh_> cnd, -evdev and -synaptics changes uploaded
<cnd> bryceh_, great!
<cnd> ta
<kklimonda> wow, any idea why is my X using a lot of cpu when I do stuff? even when I don't do anything X still uses over 10% of cpu. it's natty with nvidia-curent 270.29
<kklimonda> oh, I don't run compiz - clean metacity, now with xcompmgr
<bryceh_> kklimonda, someone reported earlier seeing increased CPU load across the board with -nvidia
<bryceh_> he narrowed it to something (an unknown non-X package) that got changed between A2 and A3
<bryceh_> see LP for bug
<Sarvatt> hmm, I'm not seeing it, 3% idling
<Sarvatt> switched to metacity, 0%
<kklimonda> I have a gnome-terminal running in full screen
<kklimonda> and firefox with quite a few tabs - maybe that's related.. I often see plugin-container taking some cpu along with Xorg
<kklimonda> bryceh_: thanks, will check it
<bjsnider> probably firefox's fault
<kklimonda> may be
<kklimonda> yeah, closing Firefox helps
<bjsnider> i don't understand why people still use firefox on linux
<bjsnider> on windows, yeah. it's fast
<kklimonda> also, switching between virtual desktops that have gnome-terminal and firefox is much slower than keeping them both on a single desktop, and using alt+tab
<kklimonda> bjsnider: I haven't seen a good replacement for noscript
<Sarvatt> Mozilla Firefox for Ubuntu canonical 1.0? Hrm..
<bjsnider> chromium probably has it somewhere
<kklimonda> (for Chromium)
<kklimonda> probably, last time I checked it wasn't there
<bjsnider> kklimonda, it's an extension?
<kklimonda> for Firefox? it is
<bjsnider> https://chrome.google.com/webstore/detail/odjhifogjcknibkahlpidmdajjpkkcfn
<bjsnider> that maybe?
<kklimonda> bjsnider: probably, I'll check it out. 
<kklimonda> wow, I have to set up some password by editing file..
<kklimonda> really weird
<kklimonda> I can't imagine how anyone at google could think that this is the right way to do extensions..
<kklimonda> oh well, let's not complain about it here
#ubuntu-x 2011-03-05
<bryceh_> new wayland snapshot pushed to universe
<bryceh_> (might need a ffe, I don't remember if we need that for stuff in uni)
<kklimonda> bryceh_: we do
<bryceh_> [ubuntu/natty] wayland 0.1~git20110214.e4762a6a-0ubuntu1 (Accepted)
<bryceh_> looks like it got in anyway
<kklimonda> FFe is not enforced
<kklimonda> you are just supposed to ask for it before uploading :)
<bryceh_> alright, well I don't think it matters at all in this case
<kklimonda> neither do I, it makes sense to update wayland for as long as possible
<bryceh_> actually what I uploaded is the last snapshot we can do anyway
<bryceh_> next revision in git requires updating mesa to a git snapshot
<bryceh_> newer wayland will have to hang out in edgers
<kklimonda> does wayland really have a chance to replace X in the foreseable future? Is Nvidia going to support it at some point? I know they did say that they have no plans, but is it even something they can do without using KMS, GEM and other three-letter-long technologies?
<bryceh_> yep, all good questions
<bryceh_> well, even if we ignore NVIDIA or imagine -nouveau becoming a totally good replacement, there still is lots of work needed in compiz and gtk to be able to run on wayland
<bryceh_> so I don't think we're anywhere near close to switching
<bryceh_> I'm not even sure we're very close to wayland being a useful alternative 
<kklimonda> well, by foreseable future I meant 3 to 5 years
<kklimonda> or do you also mean that? :)
<bryceh_> ah, I assumed you meant 1-2 ubuntu releases
<kklimonda> well, 1-2 LTS releases :)
<bryceh_> yeah given 3-5 years I could see it happening
<bryceh_> but like I said it requires a whole heap of userspace work 
<bryceh_> and actually I suspect we'll see something like wayland used for the login screen, and then that launches into X for regular user stuff
<bryceh_> *that* we might see within a year or so
<kklimonda> is wayland even something that all involved parties has agreed upon?
<bryceh_> define all involved parties ;-)
<bryceh_> for us, it's what Mark wants, so...
<kklimonda> well, if we talk userspace then I meant Gtk+ and Qt developers mostly
<bryceh_> I've no idea
<bryceh_> it's another good question
<kklimonda> I know some work is being done, but so far it's mostly side projects.
 * bryceh_ nods
<bjsnider> Sarvatt, ath9k appears to be pretty good in the latest .38 kernel rc. they might have finally got it right.
<bjsnider> ath5k is good too
#ubuntu-x 2011-03-06
<soreau> 'apt-get build-dep xserver-xorg-video-ati' doesn't work with this repo?
<soreau> I get "E: Build-Depends dependency for xserver-xorg-video-ati cannot be satisfied because no available versions of package xserver-xorg-dev can satisfy version requirements"
<brobostigon> good afternoon everyone,
<brobostigon> iwas pointed over here,because i had found a gpulockup bug under natty on my eeepc.
<brobostigon> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/730099
<ubot4`> Launchpad bug 730099 in xserver-xorg-video-intel (Ubuntu) "[i915gm] GPU lockup 0c40b170 (ESR: 0x00000001 IPEHR: 0x02000011) (affects: 1) (heat: 6)" [Undecided,New]
<penguin42> there are 30+ bugs all with WARNING at radeon_fence.c:248 radeon_fence_wait+ wither 2ea,36f,365,23a, 24e - I know there isn't normally duping of kernel bugs, but is there something that should be done to mark those as all related?
<penguin42> (doing a launchpad search for   radeon_fence_wait is the easiest way to get a list)
<penguin42> or is that just the path many separate bugs eventually land at?
<tomreyn> hi, is there a separate channel for xorg-edgers?
<tomreyn> in case there is not: I added the drivers-only PPA but there seems to be no package list for Maverick... http://ppa.launchpad.net/xorg-edgers/drivers-only/ubuntu/dists/maverick/main/binary-amd64/Packages.gz gives a 404
<tomreyn> https://launchpad.net/~xorg-edgers/+archive/drivers-only
<tomreyn> Is there no updates driver support for maverick, and will there be any in the future? or should I be looking elsewhere?
<Azelphur> I really need help, the freeze bug I keep complaining about has worsened
<Azelphur> my PC will now lock up for 30-60 seconds over and over, it's actually usable for less time than it's frozen now
<Azelphur> and thus is completely unusable
<soreau> There is a bug that causes xv video playback to have strange colors on rv350. I went to bisect ddx but now I see that the bug is somehow related to xorg-edgers repo because I installed master xf86-video-ati to /opt/xorg and if I point X to load these modules, video playback is fine. However even after ppa-purging and reinstalling xorg-edgers, the problem persists. I also have confirmed at least one other person had this issue using xorg-edger
#ubuntu-x 2012-02-27
<Daviey> Has anyone reported losing right click ability on synaptic touchpads?
<bryceh> Daviey, dunno but cnd's been working on that chunk of code lately so he'd be the one to chat up
<bryceh> Daviey, upgrade or downgrade your -synaptics until you find a version that works.
<Sarvatt> Daviey: sorry was responding in #ubuntu-desktop
<Sarvatt> Daviey: easiest way is to disable the synaptics clickpad xinput option
<Daviey> Sarvatt: yes, sorry for x-posting
<Daviey> thanks
<Sarvatt> xinput --list, find the id for the bcm5974 device, xinput --list-props <id>, find the number for the clickpad property then xinput --set-prop <id> <clickpad id>
<Sarvatt> hmm there was a better bug cnd responded on, trying to find it
<Daviey> Sarvatt: sorry is the proprty the "Synaptic clickPad (259): 1) .. is it 1 or 259?
<Sarvatt> 259
<Daviey> Sarvatt: perfect, thanks!
<Daviey> That worked
<Sarvatt> guess its easier to link people to http://paste.ubuntu.com/859398/ this is going to come up a lot :P
<Sarvatt> not being able to right click at all is nasty
<bryceh> hmm
<sforshee> There have been multiple reports of desktop freezes on systems with sandy bridge (it doesn't seem to be related to RC6) which I am also seeing (bug 938770). For me they seem to go away if I downgrade mesa to 7.11-0ubuntu4. Can anyone suggest next steps for debugging?
<ubottu> Launchpad bug 938770 in unity (Ubuntu) "Desktop becomes completely unresponsive" [High,Confirmed] https://launchpad.net/bugs/938770
<sforshee> one user also reported that going back to a 3.0 kernel gets rid of the issue, but I can't confirm this as my graphics aren't working at all with any pre-3.2 kernel
<Sarvatt> sforshee: check your ~/.xsession-errors to see what desktop component failing and killing your session :)
<Sarvatt> sforshee: a lot of the dupes you're referring to i believe were the ones fixed in the 8.0.1 mesa upload so be careful looking for dupes until you find out whats actually going wrong
<Sarvatt> aka you'll see a lot of noise in the bug reports
<sforshee> Sarvatt, I'm not searching for dupes, these are from people reporting problems on the RC6 testing bug 
<Sarvatt> since when?
<Sarvatt> link?
<sforshee> let me find it...
<Sarvatt> i've been following the wiki closely with leann and cking and the intel guys since i'm the one that did the sauce patch to reenable it
<Sarvatt> haven't see anything
<Sarvatt> the rc6 freezes aren't an issue anymore with 3.2.0-17.27, with -17.26 and earlier kernels it was still enabling rc6p and there were some hard system power offs because the bioses put the voltages too the more aggressive rc6 states
<sforshee> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/818830/comments/70
<Sarvatt> err bioses put the voltages to low in the more aggressive rc6 states i meant
<ubottu> Launchpad bug 818830 in linux (Ubuntu Precise) "[Sandy Bridge] serious power regression from kernel 3.0.0-6 to 3.0.0-7 (rc6 disabled)" [Medium,Triaged]
<sforshee> that user still sees hangs with -17.27
<sforshee> and I do too :)
<Sarvatt> libre office intel antialiasing text crash..
<sforshee> I see it with chromium
<sforshee> it doesn't matter whether rc6 is enabled
<sforshee> I went back to older precise kernels too from when I wasn't seeing this issue, and it still happens
<sforshee> with rc6 disabled
<sforshee> any other reports I see haven't confirmed it with -17.27 though
<Sarvatt> compiz stuck polling in your backtrace, you should have something in ~/.xsession-errors saying what crashed and made your desktop unresponsive, especially if restarting compiz fixes it
 * Sarvatt is getting confused why you're mentioning rc6 with this userspace bug :)
<Sarvatt> you'll probably see some kind of assert killing things in there
<sforshee> Sarvatt, I figured when I said sandy bridge the first assumption would be that it was rc6 related :)
<Sarvatt> if ya can grab the log over ssh whenever it happens next
<sforshee> Sarvatt, http://pastebin.ubuntu.com/859778/
<sforshee> don't need ssh, my vts still work
<Sarvatt> its stuck right now?
<sforshee> that's .xsession-errors when it's hung
<sforshee> no, but I copied xsessin-errors while it was hung, and that's the contents
<Sarvatt> ** CRITICAL **: syncdaemon_status_info_get_online: assertion `SYNCDAEMON_IS_STATUS_INFO (sinfo)' failed
<Sarvatt> hmm
<sforshee> i can readily reproduce it, so if there's something else you'd like me to try let me know
<Sarvatt> thats part of gnome-settings-daemon
<Sarvatt> sforshee: do you have 2 instances of syndaemon running?
<sforshee> nope
<Sarvatt> sforshee: and no segfaults in dmesg?
<sforshee> no, no segfaults, no gpu hangs, nothing in i915_error_state
<sforshee> nothing interesting at all in dmesg when this happens
<RAOF> If compiz is polling it probably means it's waiting for a swap to complete.
<sforshee> I might have to take that back -- there's something interesting this time, but this is the first time I've seen it
<Sarvatt> sforshee: by any chance, does apport-collect 938770 add any more info?
<sforshee> init: hybrid-gfx main process (2809) terminated with status 127
<Sarvatt> i reassigned to xorg so we can get some logs on the bug
<RAOF> sforshee: Yeah, that's entirely benign; it's tselliot's âmake hybrid nvidia systems less awfulâ upstart script running.
<broder> RAOF: what source package did that script end up in? (curious to skim it)
<Sarvatt> sforshee: I see exactly what you're describing when I have clickpad support enabled and scroll with 2 finger scrolling for instance with xserver 1.12 and it's a synaptics/utouch issue, restarting unity from a VT makes it work again and its definitely not video related even though it looks it so that would be worth trying
<RAOF> broder: nvidia-common.
<sforshee> Sarvatt, I was thinking it might be clickpad related earlier
<Sarvatt> does unity --replace from a VT fix the desktop?
<sforshee> I couldn't reproduce on another system with radeon graphics and the same clickpad however
<Sarvatt> (note I have to unity --replace twice for it to actually work)
<sforshee> unity --replace does work, and I only had to do it once
<Sarvatt> when it happens to me, I get some warnings from utouch-frame in unity's stderr in the VT that dont show up in ~/.xsession-errors ever, WARNING: failed to get previous touch value
<Sarvatt> wonder if its the same issue, i should get off xorg-edgers and go back to stock precise to see if that newer synaptics is still busted there on this machine so i can file a real bug
<sforshee> Sarvatt, I don't see those
<sforshee> I get some 'invalid cast' warnings
<sforshee> and some icons it can't find, that's about it
<sforshee> Sarvatt, apport-collect has finished
<Sarvatt> sforshee: heh same exactly laptop as me
<sforshee> that's convenient :)
<Sarvatt> so there might be merit in it indeed being a synaptics/utouch issue i'm hitting on xserver 1.12, i'll downgrade to 1.11 in precise and get more info on this
<Sarvatt> there should be no reason i can only hit it in 1.12 since we have the same commits for input in both
<sforshee> I'm doing enablement on the machine and also on a macbook pro with the same touchpad but radeon graphics, and I can't reproduce it there
<Sarvatt> i'm going to go ahead and move this over to x-x-i-synaptics
<Sarvatt> xserver-xorg-input-synaptics              1.5.99+git20111212.9f9b55ab is fine, thats what i've been using for months to work around the issue
<Sarvatt> whats apple-bl-gmux btw?
<Sarvatt> ah
<sforshee> it's for some macbooks that need to control the backlight through the gmux (display mux device)
<sforshee> not needed for the air
<sforshee> Sarvatt, bug 940771 is a similar freeze with libreoffice, but he isn't using a touchpad. You think that one is different?
<ubottu> Launchpad bug 940771 in linux (Ubuntu) "Scrolling in LibreOffice Calc causes hang" [Medium,Confirmed] https://launchpad.net/bugs/940771
<Sarvatt> so libreoffice has other issues historically with antialiased text (which is turned on by default) on intel and those are actual crashes, i wouldn't necessarily assume its the same even if its while scrolling too but could be wrong
<sforshee> okay, thanks.
<Sarvatt> but yeah that is interesting
<Sarvatt> i dont *think* i had a screwed up actually enabling rc6p instead of rc6 in the place he linked
<Sarvatt> that was like 4 am saturday night though so all bets are off if i actually did that in a daze
<Sarvatt> the crashes from libreoffice were memory exhaustion related so it could be he didnt test the other one enough too
<Sarvatt> and they definitely show in dmesg which that person didn't attach
<sforshee> I think he was running an unofficial rc6 test kernel, so apport refused to collect the logs
#ubuntu-x 2012-02-28
<RAOF> Oh, man.  Stupid tests.
<RAOF> Ok.  There's the less annoying part done.
<RAOF> Now to make these tests reliably pass or fail, rather than by nondeterministically by the wondrous mysteries of server processing.
<RAOF> Dear unit-tests: What?
<bryceh> looks like our mesa friend is back in 8.0.1:  https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/942662
<ubottu> Launchpad bug 942662 in mesa (Ubuntu) "compiz crashed with SIGSEGV in intel_miptree_release()" [Critical,Incomplete]
<tjaalton> http://www.elisanet.fi/jarnoalanko/2012-02-28%2015.22.28.jpg
<seb128> bryceh, https://bugs.launchpad.net/ubuntu/+source/unity/+bug/926379 got reopened
<ubottu> Launchpad bug 926379 in mesa (Ubuntu) "compiz crashed with SIGSEGV in intel_miptree_release() (Needs mesa-8.0.1)" [High,Confirmed]
<bryceh> seb128, yes I know, I reopened it ;-)
<bryceh> er wait
<bryceh> seb128, actually I unduped 942662
<seb128> bryceh, if you want a new stacktrace tag the master apport-request-retrace
<bryceh> ok
<seb128> bryceh, that will tell the retracer to attach a new stacktrace from the next dup
<seb128> rather than cleaning the dup as it does
<bryceh> tjaalton, I see you included this bug # in the changelog for 8.0.1; by chance do you have any info on the issue beyond what was already recorded on the bug report?
<tjaalton> bryceh: not really, trusted Sarvatt that it would've been fixed.. too bad if it isn't :/
<bryceh> tjaalton, so niksula.hut.fi re-enabled c-a-b eh?  :-)
<bryceh> tjaalton, ok
<bryceh> Sarvatt, ^^ ideas?
<tjaalton> bryceh: seems so :) (I didn't work for them, this is the IT lab at the CS department)
<tjaalton> they're using 11.10 AIUI
<bryceh> right, the one with the buggy compiz
<Sarvatt> bryceh: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=46303
<ubottu> bugs.freedesktop.org bug 46303 in Drivers/DRI/i965 "[SNB] segfault in intel_miptree_release()" [Normal,New: ]
<tjaalton> libreoffice bugzilla? shared with fd.o?
<Sarvatt> guess so, all google searches for fdo bugs bring up libreoffice.org domain equivalents now, its really annoying
<tjaalton> heh
<bryceh> Sarvatt, thanks
<bryceh> so, is this a snb specific bug?
<Sarvatt> timely thread on intel-gfx mailing list 1330374538-8138-1-git-send-email-anuj.phogat@gmail.com
<bryceh> Sarvatt, subjectline?
<Sarvatt> mid.gmane.org/1330374538-8138-1-git-send-email-anuj.phogat@gmail.com
<Sarvatt> http://
<tjaalton> [Intel-gfx] [PATCH] drm/i915: Handle request to map a very large buffer object
<Sarvatt> [Intel-gfx] [PATCH] drm/i915: Handle request to map a very large buffer object
<Sarvatt> yah
<bryceh> thanks, yeah this looks pertinent
<bryceh> ok, so looks like it needs a mesa patch and libdrm patch.  But we probably need to find how to repro the bug first
<bryceh> tjaalton, do you have sufficient debian fu to wave tormod's intel-gpu-tools changes through?
<bryceh> http://anonscm.debian.org/gitweb/?p=users/tormod-guest/intel-gpu-tools.git;a=summary
<bryceh> http://alioth.debian.org/~tormod-guest/intel-gpu-tools/
<tjaalton> bryceh: sure, isn't that a pkg-xorg maintained package?
<tjaalton> if not, I don't have my account setup yet so can't upload atm
<bryceh> tjaalton, official repo is at http://git.debian.org/?p=pkg-xorg/app/intel-gpu-tools.git
<bryceh> so think it is
<tjaalton> yeah I can merge it there
<jcristau> well tormod can do that too
<jcristau> but i think he's waiting on a sponsor
<jcristau> ie kibi or me
<tjaalton> ok
<RAOF> Ahh, balls.  Is xserver-xorg-input-void broken?
<Sarvatt> writing tests for the barriers stuff?
<RAOF> Sarvatt: Indeed.  They work!
<RAOF> Sarvatt: Now, to make sure they work even if I touch my pointer :)
<bryceh> TMI
#ubuntu-x 2012-02-29
<RAOF> Oh, boo.
 * RAOF forgot xorg-gtest wasn't actually packaged.
<RAOF> That puts somewhat of a crimp on an otherwise damn-fine plan.
<tjaalton> RAOF: sure is
<RAOF> ...
<RAOF> So it is.
<tjaalton> :)
<RAOF> Ta
<wickedgrey> hello, i've got a 11.10 install with nvidia-current(-dev), and nvidia-current-updates(-dev).  originally these were the 280 drivers from ubuntu, but i recently added the x-swat PPA to get the 295 drivers.  however, it doesn't seem like the n-c-updates are in the PPA, so /proc/drivers/nvidia/version still shows 280 (even though n-c is installed and shows 295).  is there a way to fix this, or should i uninstall n-c-updates?  sorry if
<tjaalton> means the kernel driver didn't build
<wickedgrey> any suggestions on how to troubleshoot that?
<tjaalton> check the dkms logs in /var/log/dkms or such
<tjaalton> or just run dpkg-reconfigure linux-image-`uname -r`
<tjaalton> it should complain about it
<wickedgrey> hrm, i don't have a /var/log/dkms or anything that looks similar, and dpkg-reconfigure didn't seem to say anything about the gpu, or anything that looked like an error :(
<wickedgrey> thanks for your help, i'm off to bed
<tjaalton> sigh.. bug 942977
<ubottu> Launchpad bug 942977 in xorg (Ubuntu) "m" [Undecided,New] https://launchpad.net/bugs/942977
<tjaalton> ->close
<cnd> Sarvatt, bryceh, RAOF: I'm going to enable the right button area by default for clickpads, if that's alright with you?
<cnd> whot also is advocating for it
<cnd> it would fix bug 941046
<ubottu> Launchpad bug 941046 in xserver-xorg-input-synaptics (Ubuntu) "Recent "clickpad patch" breaks two-finger-right-click" [High,Triaged] https://launchpad.net/bugs/941046
<Sarvatt> cnd: "fix" :(
<cnd> Sarvatt, hmm?
<Sarvatt> two finger press right click is how these things have always worked, thats going to be a hot debate
<cnd> yeah
<cnd> sorry
<cnd>  I got it
<cnd> Sarvatt, what do you think would be better?
<Sarvatt> sounds good though, better than no right click :)
<cnd> clickpad support, or two-finger-right-click?
<Sarvatt> (disabling clickpad)
<Sarvatt> on bcm5974
<cnd> Sarvatt, why only on macbooks?
<Sarvatt> cnd: what does clickpad get you on these bcm5974's btw?
<Sarvatt> because none of them have button areas on the bottom
<cnd> Sarvatt, click and drag with two separate fingers
<Sarvatt> its not obvious
<cnd> Sarvatt, yeah, that's the reason I'm hesitant
<cnd> it's not obvious there's a right button area
<cnd> Sarvatt, people like vanhoof have been begging me for clickpad support
<cnd> and he uses the magic trackpad
<Sarvatt> ah yeah i see what you mean
<cnd> I'm guessing he would much rather have clickpad + right button area
<Sarvatt> yeah but magic trackpad wouldn't be affected since its not bcm5974
<cnd> Sarvatt, if you're going to do it to bcm5974, you should do it for hid-magicmouse too :)
<cnd> there practically the same
<cnd> they're*
<Sarvatt> gotcha, no worries, disabling clickpad is the better option for my own personal usage because right click is muuuch more important than click then moving with a second finger
<cnd> maybe I should send an email to ubuntu-devel and ubuntu-desktop
<Sarvatt> hmm, that would be trivial to add to g-c-c, i wonder if its too late
<cnd> Sarvatt, that's what I worry about
<cnd> that and it doesn't really solve the problem
<cnd> I don't want to have a checkbox for "Enable clickpad (and disable two-touch-click for right button)"
<cnd> however you phrase it
<cnd> I'm really just two weeks short of have the time to get it right I think
<cnd> I could put in some heuristics to re-enable click action + clickpad
<cnd> but it's a bit late...
<cnd> and I have other bugs I need to get to
<Sarvatt> cnd: click and drag with a second finger being for pinch to zoom i suppose?
<Sarvatt> or rotate or whatever
<cnd> Sarvatt, no
<cnd> just being able to perform a drag
<cnd> like dragging an icon on the desktop
<Sarvatt> never tried doing that without just dragging the finger i'm pressing into the touchpad with i guess
<Sarvatt> wish i never got used to this darn mac trackpad :)
<cnd> Sarvatt, the problem is if you try to drag beyond the bounds of your trackpad
<cnd> that's where you need to be able to do it with two fingers
<Sarvatt> ahh low acceleration values, i do raise mine a ton from defaults
<cnd> heh
<bryceh> cnd, I'm kind of two minds with the clickpad changes (caveat being I haven't re-tested in a week or so)
<bryceh> cnd, from an X perspective I think we do need to move forward with enabling the new functionality even if it regresses a bit.  Like I mentioned before, it'd be nice if it were configurable in some way, but admittedly it's too late in the game.
<bryceh> cnd, from a user perspective, in addition to my netbook, I also have ones for my mom, dad, and mother-in-law, and I can't envision any of them learning and using the gestures
<bryceh> cnd, on the plus side, they hate the pad in general already and pretty much all use external usb mice instead
<cnd> heh
<cnd> I think this is one reason they may hate it
<cnd> it's nearly impossible to click+drag
<bryceh> I suspect you may be right
<cnd> I think it makes sense to enable the right button area on synaptics at least
<cnd> that solves all issues there
<cnd> it's really just the apple trackpads
<cnd> if I didn't have people clamoring for clickpad support for apple trackpads, I might be tempted to enable clickpad support only for synaptics trackpads
<Sarvatt> cnd: magic trackpads people use on their non mac laptops where they are used to having right click buttons and want a button area, or people using internal mac trackpads where they have never had a right button area though? :P
<Sarvatt> if the touchpad clicks anywhere on the touchpad surface, it seems weird to want to click in the bottom right corner only to right click
<cnd> Sarvatt, people using the magic trackpad aren't used to having right button areas in any OS, as far as I can tell
<cnd> so that makes both internal and external the same
<wickedgrey> cnd: when you say "magic trackpad" do you mean only the external one?  my macbook pro trackpad has right-click functionality in the lower right corner of the pad
<Sarvatt> wickedgrey: did you enable that?
<cnd> wickedgrey, magic trackpad is external
<cnd> wickedgrey, how old is your laptop (or what is its model number?)
<Sarvatt> hmm i guess other distros wont even notice the mac change until they pick up "Input: bcm5974 - set BUTTONPAD property" which doesn't seem to be upstream yet
<cnd> heh
<cnd> yeah
<Sarvatt> oh it is upstream in 3.3
<wickedgrey> IIRC, i did have to enable that in settings somewhere.  i got the laptop in late 2010
<Sarvatt> cnd: if it ever got fixed in the future where 2 finger click could be right click while also  being able to drag with 2 fingers, would it be in the synaptics driver or do you think it'd need server changes? aka is there nothing stopping it from being SRUed ever if it did get fixed and we get bugs?
 * Sarvatt hate hate hates looking at synaptics bugs, they are mostly opinion on how the default settings should be
<cnd> Sarvatt, it would be in the synaptics driver
<cnd> could be SRU'd but it would be a big change
<cnd> imo
<Sarvatt> awesome
<cnd> wickedgrey, oh, you're probably meaning that you have right click from a tap in the lower right corner
<cnd> we're talking about a "press" in the lower right corner
<wickedgrey> what's the difference between a tap and a press?  sorry, not up on the jargon :)
<cnd> wickedgrey, if you have a clickpad you have to press on the touchpad to perform a physical click
<cnd> the touchpad physically goes up and down
<cnd> so a tap is where you momentarily touch the touchpad surface without the touchpad physically moving
<cnd> and a press is where you press the touchpad surface and move it physically
<wickedgrey> ah, gotcha.  i can press for right-click, but not tap.  sorry for the derail!  :)
<wickedgrey> (not sure if there are additional settings i could alter to change that or not)
<Sarvatt> bryceh: did i misread the scrollback or did you forward that mesa bug to fdo? got a link handy by any chance?
<bryceh> Sarvatt, I did forward it, one sec
<bryceh> https://bugs.freedesktop.org//show_bug.cgi?id=46739
<ubottu> Freedesktop bug 46739 in Drivers/DRI/i965 "[snb-m-gt2+] compiz crashed with SIGSEGV in intel_miptree_release()" [Critical,New: ]
<bryceh> https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/926379
<ubottu> Launchpad bug 926379 in mesa (Ubuntu) "compiz crashed with SIGSEGV in intel_miptree_release() (Needs mesa-8.0.1)" [Critical,Triaged]
<bryceh> no responses yet
<bryceh> however I also emailed Eugeni directly, and he confirmed they've escalated it on their end
<bryceh> (so... I'm surprised there's no further comment today)
<Sarvatt> bryceh: thanks a ton! yeah i didnt see anything on the lists about it
<bryceh> I should forward a few more bugs.  Been distracted hacking on libXrandrUtils this week
<bryceh> (up to crtcs and outputs and modes, oh my!)
<RAOF> Woot!
<bryceh> nvidia's seeing an influx of bugs the last couple weeks - http://www.bryceharrington.org/Arsenal/Reports/ubuntu-x-swat/totals-precise-workqueue.svg
<bryceh> -synaptics is getting a few more than usual too
#ubuntu-x 2012-03-01
<cnd> Sarvatt, bryceh, can you reply with your synaptics thoughts?
<bryceh> cnd, sure, although I don't really have a super firm opinion
<cnd> bryceh, that's fine
<cnd> bryceh, Sarvatt: note that we can always provide people with xorg.conf snippets on wiki.ubuntu.com
 * bryceh nods
<cnd> so we could disable clickpad for apple trackpads
<cnd> but tell people how to enable it if they want it
<RAOF> Oh, yeah!  Tests all pass again! \o/
<bryceh> what is the right terminology for non-Clickpad ?
<cnd> bryceh, non-clickpad, I guess :)
<cnd> I don't know
<bryceh> ok
<bryceh> cnd, when you say "Click actions is the term for supporting right
<bryceh> > button behavior by clicking on the trackpad with two fingers." by clicking do you mean press or touch ?
<Sarvatt> cnd: wow, 2 finger *tap* does still work?
 * Sarvatt is wondering why he is complaining now then, thats something people can change in the GUI options
<cnd> bryceh, I meant pressing there
<bryceh> cnd, ok
<cnd> Sarvatt, some people hate tap to click
<cnd> telling them they have to enable it to get right button support probably won't go over well :)
<bryceh> cnd, how does it detect two finger press vs. one finger press?
<bryceh> oh, nevermind.  heh
<bryceh> cnd, ok thoughts posted.  Hopefully not too blathery.
<bryceh> cnd, btw, enjoying the snow?
<cnd> bryceh, thanks
<cnd> luckily there's no snow here
<tjaalton> hmh, hud activates every time I hit ctrl-alt to release the kvm focus
<tjaalton> nope, not every time, but often
<FernandoMiguel> jHEELLOOO
<FernandoMiguel> I'm seeing some windows artifacts / parts not refreshed on 12.04 with Intel GPU
<RAOF> FernandoMiguel: Particularly menus?
<FernandoMiguel> yes
<RAOF> That's a known compiz bug.
<RAOF> I *think* it's fixed in trunk / the unity PPA.
<FernandoMiguel> RAOF: linky me!
<RAOF> The PPA, or the bug?
<FernandoMiguel> ppa
<FernandoMiguel> I can test it
<RAOF> ppa:unity-team
<cnd> RAOF, current xorg-server ubuntu branch fails to build for me
<cnd> you have the only commit since the last release
<RAOF> Huh.  Let me check...
<cnd> I'm trying to build again with the last release to be sure
<cnd> linker failure in hw/kdrive/fbdev
<cnd> libtool: link: gcc -std=gnu99 -g -O0 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z -Wl,relro -Wl,-Bsymbolic -o Xfbdev fbinit.o -Wl,--export-dynamic  ./.libs/libfbdev.a ../../../dix/.libs/libmain.a ../../../dix/.libs/libdix.a ../../../hw/kdrive/src/.libs/libkdrive.a ../../../hw/kdrive/src/.libs/libkdrivestubs.a ../../../fb/.libs/libfb.a ..
<cnd> /../../mi/.libs/libmi.a ../../../xfixes/.libs/libxfixes.a ../../../Xext/.libs/libXext.a ../../../dbe/.libs/libdbe.a ../../../record/.libs/librecord.a ../../../glx/.libs/libglx.a ../../../randr/.libs/librandr.a ../../../render/.libs/librender.a ../../../damageext/.libs/libdamageext.a ../../../miext/sync/.libs/libsync.a ../../../miext/damage/.libs/libdamage.a ../../../miext/shadow/.libs/libshadow.a ../../../Xi/.libs/libXi.a ../../../xkb
<cnd> /.libs/libxkb.a ../../../xkb/.libs/libxkbstubs.a ../../../composite/.libs/libcomposite.a ../../../os/.libs/libos.a -lgcrypt ../../../hw/kdrive/linux/.libs/liblinux.a -lpixman-1 -lXfont -lXau -lXdmcp -lpthread -ldl -lm -lrt
<cnd> collect2: ld returned 1 exit status
<cnd> can't see anything wrong though
 * RAOF carefully stashes his xorg unit-tests away.  This is where bzr's one-directory-per-branch model shines.
<jcristau> so it dies with no error message?  nice.
<cnd> RAOF, jcristau: I got a better error message this time:
<cnd> final link failed: No space left on device
<cnd> collect2: ld returned 1 exit status
<cnd> oops :)
<jcristau> hah
<RAOF> :)
<FernandoMiguel> LOL
<jcristau> anybody here good at shell scripting?
<cnd> jcristau, what's the issue?
<jcristau> need to do http://paste.debian.net/158247/ in shell
<cnd> I would say I'm competent :)
<cnd> but not good
<jcristau> bugs.debian.org/661627 has the details
<cnd> hmmm, as much as I'd like to, I think I have to pass :)
<jcristau> bleh, and there's no chmod --no-dereference
<jcristau> this stuff makes me sad
<jcristau> cnd: btw thanks a lot for the xorg-gtest relicense
<cnd> sure, though it really wasn't my decision :)
<jcristau> thanks anyway :)
<Sarvatt> crap, it definitely is happening with stock precise to so it's not xserver 1.12 specific. odd i've only seen reports of this happening on macbook air 4,1 or 4,2 touchpads https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/944415
<ubottu> Launchpad bug 944415 in xserver-xorg-input-synaptics (Ubuntu) "Input stops responding" [Undecided,New]
<Sarvatt> i'm sure this is the same bug sforshee was hitting, have to dig up his bug number
<sforshee> Sarvatt, bug 938770
<ubottu> Launchpad bug 938770 in xserver-xorg-input-synaptics (Ubuntu) "Desktop becomes completely unresponsive" [High,Confirmed] https://launchpad.net/bugs/938770
<Sarvatt> sforshee: have you figured out any behavior that triggers it faster by any chance?
 * Sarvatt just installed 338mb of dbgsym packages to look at it but its not dying again yet :)
<Sarvatt> hey it's not crashing anymore, must have fixed itself
 * Sarvatt said that hoping to make it crash
<Sarvatt> would love to know why themes are so screwed up and font changes dont apply after rebooting into a weeks worth of updates, nothing obvious standing out
<Sarvatt> icons in context menus look ancient, gtk2 apps look horrible and fonts are all different now. nautilus isn't affected but xchat/terminator/firefox/chrome are
#ubuntu-x 2012-03-02
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/944415/comments/3
<ubottu> Launchpad bug 944415 in xserver-xorg-input-synaptics (Ubuntu) "Input stops responding" [Undecided,New]
<Sarvatt> dang now it's hung 4 times in the past 5 minutes
<Sarvatt> testing out http://bazaar.launchpad.net/~bregma/utouch-geis/lp-937021/revision/209
<Sarvatt> err https://code.launchpad.net/~bregma/utouch-geis/lp-937021
 * Sarvatt shoots in the dark since disabling geis from unity yet again seems to fix it
<Sarvatt> hmm, xutils-dev could use going into backports
<bryceh> Sarvatt, agreed
<bryceh> Sarvatt, or even just FFe it in?
 * Sarvatt looks into whats needed for that
<bryceh> I know we have a few things wanting the newer version, does it have any deps itself we can't meet easily?
<Sarvatt> nope
<bryceh> any potential side effects or conflicts?
<Sarvatt> there were one or two releases of xutils-dev that build-dep'ed on xutils-dev that would have caused a headache but that was fixed a year ago
<Sarvatt> can't see how it could conflict or have side effects if its in -backports, people would have to willingly enable that and wouldn't screw with updates, it'd just let people backport newer drivers or X to old releases
<Sarvatt> ah it doesn't look automated, thought it was for some reason
<Sarvatt> hmm failsafeX is busted, no input
<bryceh> yeah I need to figure that out
<Sarvatt> sforshee: so, are you using the macbook air and want it stable, or are you just looking to get it fixed? I can send you unity packages that actually work if you need to be productive on it in the meantime if the latter :)
<sforshee> Sarvatt, I can usually get it to happen if I load up a long page in chromium and scroll with the touchpad, but at times it does seem to stop happening for a while
<sforshee> it also seems to happen sometimes after resume if I suspend by closing the lid
<sforshee> I don't need an immediate workaround, it's not my main machine and I can avoid it pretty well, I just want to see it fixed
 * Sarvatt nods
<Sarvatt> just wanted to be sure, i use this machine as my primary one and need it working :)
<Sarvatt> i haven't seen it from closing the lid yet, thats strange
<Sarvatt> but i dont suspend on lid close so maybe that explains it
<Sarvatt> that seems like it might not be the same bug though
<sforshee> for a while there was a bug where the machine wouldn't suspend when the lid was closed, and when I opened the lid it definitely looked the same
<sforshee> now it's on the text console rather than the desktop, but it's still similar in that the only thing that updates is the mouse pointer
<sforshee> heh, I just opened the lid and got the freeze. What to I look at to verify it's the same problem?
<Sarvatt> sforshee: i'm 100% sure you're hitting the same problem and it really seems higher up in the stack like in utouch-geis https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/944415
<ubottu> Launchpad bug 944415 in xserver-xorg-input-synaptics (Ubuntu) "Input stops responding" [Undecided,New]
<Sarvatt> from your other bugs compiz backtrack
<Sarvatt> backtrace
<Sarvatt> bah
<Sarvatt> its late, why am i awake :)
<sforshee> Sarvatt, this time the stacktrace is different
<sforshee> it's going through intel_update_renderbuffers()
<Sarvatt> so yeah suspend sounds like a different problem then
<Sarvatt> bugs all around!
<Sarvatt> intel_update_renderbuffers(), can you pastebin it?
<sforshee> yeah, just a minute
<Sarvatt> think i can point you at that bug
<Sarvatt> sounds like the other big bug we're hitting in mesa at the moment
<sforshee> http://pastebin.ubuntu.com/864587/
<Sarvatt> ok no thats different, its just trying to draw, the mesa problem was an actual crash
<Sarvatt> nothing in ~/.xsession-errors that time?
<sforshee> there was, but I forgot to save it. D'oh.
<sforshee> i should be able to produce it again with a little effort
<Sarvatt> me too, same machine and all
<Sarvatt> but cant seem to hit it.. 10 s3's so far
<sforshee> yeah, I don't see it that often anymore
<Sarvatt> maybe something in /var/log/lightdm/x-0.log?
<Sarvatt> just got http://paste.ubuntu.com/864594/ but it resumed fine that time
<sforshee> I'm not finding what I saw in .xsession-errors anywhere in /var/log, although x-0.log does show the 'unable to find touch point' messages
<Sarvatt> oh duh, i'm using a unity with geis support ripped out that actually works
<Sarvatt> thats probably why i can't reproduce it
<Sarvatt> i'll mess with it tomorrow, its too late here, thanks for the pointers :)
<sforshee> yeah, I need to go to bed too
<sforshee> thanks for looking!
<sforshee> Sarvatt, a little something for tomorrow morning: http://pastebin.ubuntu.com/864597/
<sforshee> that's .xsession-errors from the freeze after s3
<Sarvatt> wth is up with all the g-s-d xrandr spam
<Sarvatt> i dont get that
 * Sarvatt wonders what he's changed locally now
<sforshee> the xrandr spam isn't there before s3 but is afterwards, whether or not it freezes
<sforshee> Sarvatt, cnd: just got the desktop freeze coming out of s3 again. I posted some information I collected to bug 938770.
<ubottu> Launchpad bug 938770 in xserver-xorg-input-synaptics (Ubuntu) "Desktop becomes completely unresponsive" [High,Confirmed] https://launchpad.net/bugs/938770
<cnd> sforshee, if you do "unity --replace" does it fix things?
<sforshee> cnd, yes, "unity --replace" does fix it
<FernandoMiguel> alias compizB='DISPLAY=:0 compiz --replace &'
<FernandoMiguel> alias compizC='DISPLAY=:0 compiz --reload &'
<FernandoMiguel> :D
<cnd> sforshee, then it's probable that a touch is not getting rejected or accepted properly
<cnd> sforshee, please let me know if you figure out a reliable way to reproduce it
<sforshee> cnd, I can reproduce it pretty reliably on this machine, but not on any others
<sforshee> in fact, it just happened when I opened the lid
<cnd> sforshee, ok, see if you can figure out a series of steps that always or usually makes it happen
<sforshee> cnd, always is tough. I can usually get it by scrolling in chromium using gestures, although it might take a while to trigger it
<sforshee> but once in a while it becomes very hard to reproduce
<cnd> sforshee, I wonder if it occurs when you accidentally lightly brush a third finger while scrolling?
<sforshee> hmm, you might be right
<sforshee> two for two so far
<cnd> heh
<cnd> sforshee, are you momentarily touching a third finger?
<cnd> or dragging it along too
<cnd> i.e. would it be seen as a tap
<sforshee> i can trigger it with a 3-finger drag
<cnd> sforshee, any 3-finger drag?
<cnd> I mean to say, it triggers always when you do a 3-finger drag?
<sforshee> specifically over a chromium window, it doesn't do it with a 3-finger drag over the desktop
<sforshee> except now I can't :(
<cnd> sforshee, what about over other windows?
<sforshee> cnd, my system got completely hosed, I'm rebooting now
<cnd> ok
<sforshee> oddly, if i do a 3-finger drag over a blank desktop it acts like it's dragging a window
<sforshee> it's not happening with libreoffice calc, nor with firefox
<sforshee> but it happens immediately with chromium
<cnd> sforshee, chromium installed from the precise archives, correct?
<cnd> sforshee, do you have ginn running?
<sforshee> cnd, yes
<cnd> ps aux | grep ginn
<sforshee> cnd, sometimes it gets in a state where I can't trigger it even with chromium however
<cnd> sforshee, as soon as I get a new version of X synaptics uploaded to precise, I'll be switching to work on this bug
<cnd> hopefully I'll be able to reproduce it too
<Sarvatt> sforshee: did you have more macs than just the air?
<Sarvatt> wondering if its happening on other bcm5974's too
<sforshee> Sarvatt, I also have a macbook pro with the bcm5974
<sforshee> I just tried a minute ago and reproduced it
<cnd> Sarvatt, sforshee: when the bug occurs, does the whole desktop lock up?
<cnd> as though unity is hung?
<Sarvatt> cnd: yeah, it looks fine but you cant interact with anything, the cursor does change between a pointer and a text entry line when you move it over things though
<sforshee> cnd, pretty much, the only thing that works at all is that the mouse pointer moves
<Sarvatt> vt switch then switch back to vt7 and its black with just a cursor
<cnd> yeah, so I think that may be bug 942625
<ubottu> Launchpad bug 942625 in unity (Ubuntu) "Unity hangs when touching my touchpad/trackpad" [Undecided,Confirmed] https://launchpad.net/bugs/942625
<cnd> we have a wallpaper fix
<cnd> we're trying to figure out the underlying root cause
<cnd> the wallpaper fix is really adding proper error handling, so it's needed anyways
<Sarvatt> awesome, i'll check that out and see if it is
<Sarvatt> hopefully it doesn't need new nux and all the other stuff
<Sarvatt> oh cool r2047 is in https://launchpad.net/~unity-team/+archive/staging
<Sarvatt> going through and finding all of the dupes will be fun, they're splattered across all of the drivers and unity and compiz and the kernel
<Sarvatt> got it running now, lets see how this goes
<Sarvatt> wow 175 manual tests in checkbox-unity, seriously?
<Sarvatt> should randomize the test questions so everything gets some coverage because thats nuts
<Sarvatt> cnd: that does indeed look like the fix
<Sarvatt> select 11
<Sarvatt> print *data
<Sarvatt> $1 = {id = 4, device_id = 64176, window = 172, touches = 3, timestamp = 4764291, focus_x = 1129054208, focus_y = 1139212288, bound_x1 = -2594, bound_y1 = 5313, bound_x2 = 1465,
<Sarvatt>   bound_y2 = 6572}
<cnd> Sarvatt, what are you printing?
<Sarvatt> #11 GeisAdapter::GestureStart (cookie=<optimized out>, gesture_type=<optimized out>, gesture_id=<optimized out>, count=<optimized out>, attrs=<optimized out>)
<Sarvatt>     at /build/buildd/unity-5.4.0/plugins/unityshell/src/GeisAdapter.cpp:136
<Sarvatt>         data = 0x4b763d0
<Sarvatt>         self = <optimized out>
<Sarvatt> that fix did -  if (data->touches == 3)
<Sarvatt> +  if (data->touches == 3 && data->window != 0)
<cnd> yeah
<Sarvatt> 3 touches and window = 172 when its stuck
<cnd> that's the root window case
<cnd> which is fixed elsewhere
<cnd> I'm currently trying to figure out why data->window would ever be 0
<Sarvatt> cnd: awesome, ya added a synclient property for clickpad? \o/
<cnd> Sarvatt, yep
<cnd> synclient ClickPad=1
<Sarvatt> so much easier to tell people that instead of explaining how to use xinput properties
<cnd> Sarvatt, yeah, though I'm not sure how well it works when there are more than two trackpads
<jcristau> badly.
<cnd> for people who use a magic trackpad with a laptop
<Sarvatt> this unity is looking good so far, it does indeed look worked around in 5.6.0
<Sarvatt> cnd: is it normal none of the 3 finger gestures work?
<cnd> Sarvatt, I'm working on that right now :)
<cnd> there's a bug somewhere in the stack
<Sarvatt> oh cool
<cnd> where a rejected touch isn't being rejected fully
<cnd> or something like that
<cnd> and this causes future touch event handling to be wrong
<Sarvatt> 4 finger is kinda iffy too, sometimes it does a right click when i'm not pressing and have tap to click disabled
<cnd> yeah
<Sarvatt> first time using any of this
<cnd> we have the stack in place, just need to debug it now :)
<cnd> it's close, I think we're about 2 or 3 bug fixes from it working properly
<cnd> I need to figure out if unity/utouch is not accepting/rejecting touches properly
<cnd> or if the server isn't not handling accept/reject properly
<cnd> that's the next step
<cnd> Sarvatt, if you're interested in watching the recognizer, run: GRAIL_DEBUG=1 unity --replace
<Sarvatt> heh
<Sarvatt> Warning: failed to get previous touch value
<Sarvatt> but it doesn't die now
<Sarvatt> i get that from every single gesture
<Sarvatt> Warning: failed to get previous touch value
<Sarvatt> Warning: failed to get previous touch value
<Sarvatt> GRAIL ERROR (../../src/v3/recognizer.cpp:ProcessEvent:691): touch 305 failed to be rejected
<Sarvatt> GRAIL ERROR (../../src/v3/recognizer.cpp:ProcessEvent:691): touch 306 failed to be rejected
<Sarvatt> GRAIL ERROR (../../src/v3/recognizer.cpp:ProcessEvent:691): touch 307 failed to be rejected
<Sarvatt> GRAIL ERROR (../../src/v3/recognizer.cpp:ProcessEvent:691): touch 308 failed to be rejected
<Sarvatt> only grail debug i've seen so far
<cnd> hmm... that's not good :)
<cnd> that sounds like you have an old utouch-geis installed
<cnd> actually, that doesn't make sense
<Sarvatt> ah need a daily?
<cnd> nm
<cnd> I don't know why it would fail to be rejected
<cnd> but let me try to resolve the bug I can reproduce here first :)
<Sarvatt> http://paste.ubuntu.com/865832/ all i've seen so far
<Sarvatt> no worries sorry to distract you
<cnd> nah, no distraction :)
<cnd> just letting you know the order in which I'm tackling stuff
<Sarvatt> only doing 4 finger swipes up and down in the log, every gesture that does actually go through gives 4 errors
<cnd> ok, I found the problem in the X server
<cnd> but I know this area of code
<cnd> and there have been lots of issues with the logic here
<cnd> I hope I don't break anything else with a fix :)
<cnd> I'm going to make this fix, and propose an xorg-gtest testcase to go with it this time
<FernandoMiguel> my touchpad is terribly jumpy today :\
#ubuntu-x 2012-03-03
<FernandoMiguel> morning
<FernandoMiguel> The following packages will be REMOVED:
<FernandoMiguel>   compiz-plugins-extra
<FernandoMiguel> I guess we are losing even more effects :(
#ubuntu-x 2012-03-04
<FernandoMiguel> LOL
#ubuntu-x 2013-02-26
<britt> ricotz: I was quickly just wondering if the latest version of fglrx was going to make it into raring
<britt> it isn't specifically about the package, but moreso about how it is decided when to pull in a newer version
<ricotz> britt, tseliot is taking care of that, but he isnt around currently
<britt> i gotcha
<britt> well that's ok, I just noticed that your name was taged on the package so I thought I'd ask
<britt> I was just confused on why fglrx-updates in the stable repo never seems to get updated past the standard fglrx package
<britt> I'll wait to see if I can snag him for a question or just send him an email though
<britt> thank you for your time though :-)
<ricotz> yeah ask him, or maybe bryce wants to present the fglrx master plan ;)
<mlankhorst> guten tag
<apw> mlankhorst, had any reports of raring locking up ?  oldish intel h/w, dunno if it is compix or X
<mlankhorst> raring should be mostly the same as quantal at this point
<mlankhorst> only thing newer is xserver-xorg-video-intel I think
<apw> i just upgraded from there, literally this am, and not happy
<tjaalton> well there's sna and newer kernel
<tjaalton> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel?field.status:list=NEW&field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.status_upstream=pending_bugwatch&field.status_upstream=hide_upstream&field.status_upstream=resolved_upstream&field.status_upstream-empty-marker=1&field.upstream_target=xserver-xorg-video-intel&field.tag=raring+-kubuntu+-xubuntu+-ppc+-omit&fie
<mlankhorst> yeah
<tjaalton> oops, ugly url
<apw> i have definatly lost updates
<mlankhorst> but opengl is the same, I think
<apw> i hit a button in pidgin (which is broken it seems) and when i did 'X' has locked
<apw> and i have a nice static screen now, nothing in Xorg.log or dmesg as far as i can see
<mlankhorst> apw: you could try xserver-xorg-video-intel from quantal
<apw> joy
<tjaalton> apw: does the mouse pointer move, can you change the vt?
<apw> mouse moves yes
<mlankhorst> tjaalton: older intels have a really nice failure mode :-)
<tjaalton> so try killing compiz
<apw> i can change to VT1 but on trying to come back only my internal LCD has come back to X the other ... not so much
<tjaalton> I've had compiz lock up a few times on my ivb when I return to my session from the wife's
<apw> and now i cannot change VTs any moe
<tjaalton> heh
<tjaalton> ssh?
<apw> yep i am logged in
<tjaalton> does /sys/kernel/debug/dri/0/i915_error_state have anything on it?
<apw> [  1755.355] (II) AIGLX: Resuming AIGLX clients after VT switch
<apw> [  1755.355] (II) intel(0): switch to mode 1920x1200 on crtc 3 (pipe 0)
<apw> no error state collected
<tjaalton> what does oldish intel mean?
<tjaalton> ironlake or older?
<apw> 4 year old laptop
<apw> it looks to be using i810 ?
<apw> is that normal
<tjaalton> can't be :)
<apw> [     5.104] (II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
<apw> is what it says in the xorg.0.log
<tjaalton> that's just the first chip, read on
<tjaalton> first line
<tjaalton> lspci |grep vga
<tjaalton> VGA
<apw> 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
<tjaalton> so gen4
<apw> mediumly old :)
<apw> any debug steps, or should i start killing things to see what changes
<tjaalton> yeah, try killing compiz
<jcristau> sounds like gm45
<apw> nice, it is immune to kill -9
<tjaalton> top-of-the-line gen4 :)
<mlankhorst> apw: pssh, only init is really immune to kill-9
<mlankhorst> if you mask it off
<apw> mlankhorst, not if things are broken ...
<apw> i cannot attach to X either, it just hangs trying and now strace is stuck
<mlankhorst> true :D
<apw> i think this is well bust
<tjaalton> nothing in dmesg?
<apw> [ 1920.816540]  [<ffffffffa00e92e5>] intel_crtc_wait_for_pending_flips+0x75/0xd0 [i915]
<tjaalton> ahah
<apw> not this again, can't they do anything right
<tjaalton> :)
<mlankhorst> not our problem then! :D
<apw> have we lost that fix ...
 * apw goes check
<tjaalton> well they rewrote modesetting
 * apw *cries*
<apw> thanks guys
<mlankhorst> np!
<tjaalton> there is intel-gpu-tools with a kms_flip test
<tjaalton> iirc
<mlankhorst> i think that one could even be made to work on nouveau
<tjaalton> so you should be able to trigger it by just running that (and not X)
<apw> cool, though i think we were carrying a sauce patch for some flippage breakage
<tjaalton> apw: can you repro it in X?
<tjaalton> apw: there was some fix for precise in -intel
<apw> oh maybe that was what i was thinking
<tjaalton> the "blank screen on resume" bug
<tjaalton> +infamous
<apw> yeah
<mlankhorst> with 5 different possible causes!
<tjaalton> right
<tjaalton> just like the drm/whatever race
<apw> only 5 lets dogpile some more
<mlankhorst> tjaalton: hey at least it's no longer intel locks up on every hardware out there everywhere :D
<tjaalton> mlankhorst: yeah it's genuinely better now, and ickle looking at lp bugs directly, winning
<mlankhorst> haha we should push for him to be debian maintainer and get ubuntu ppu
<mlankhorst> >:X
<tjaalton> apw: you could file it too
<tjaalton> ubuntu-bug xorg
<tjaalton> or x-x-v-i
<apw> so switching vts works ok before i run anything
<apw> though the act of doing so kills unity i think
<apw> has anyone complained that vga output seems 'wobbly'
<tjaalton> it's working here with snb
<apw> i should clarify, that my head is telling me it is flickering very slightly, which i have never noticed before
<tjaalton> apw: one bug suggests that upstream does have a fix for gm45 hanging in X/compiz
<tjaalton> so if you can reproduce this one, then maybe try the drm-intel-nightly mainline build for a while to see if it's any better
<tjaalton> we can then pull the fix for 3.8
<tjaalton> and identify it too..
<apw> tjaalton, ok got a ref to that bug as well so i can look at the proposed fix
<tjaalton> apw: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1114370 but it doesn't point out anything specific
<ubottu> Ubuntu bug 1114370 in xf86-video-intel "[gm45] Hard hang when plugging, unplugging, or turning off LG 55LE5400 TV" [Medium,Confirmed]
<tjaalton> apw: some commits are also cc: stable
<tjaalton> but apparently they're aware that not all pageflip issues are fixed yet, if i'm parsing the pull request right
<apw> joy
<apw> i am struggling to work out how i am reporducing it
<apw> and i think compiz is breaking seapratlu first
<apw> what a pile of dung R is on this machine
<tjaalton> hmm, I should check how 965gm is doing..
#ubuntu-x 2013-02-27
<seph> I'm trying to use linux-generic-lts-raring and it seems to be missing kernel headers. I feel a little helpless asking, but I'm not sure how to tell if this is a known issue or where to report it. I can't find bugs for it anywhere in launchpad.
<tjaalton> where did you get it?
<seph> https://launchpad.net/~ubuntu-x-swat/+archive/r-lts-backport/  (which is why I'm asking here)
<tjaalton> the headers are there too
<mlankhorst> seph: would be a bug for the kernel team
<seph> AFAICT those header packages are incomplete. linux-headers-3.8.0-7-generic has symlinks to linux-headers-3.8.0-7, which has no files.
<mlankhorst> the kernel team maintains those packages in the ppa, and at the moment the xorg snapshot there is mostly to test the mechanics. :-)
<mlankhorst> erm those packages means the linux-* packages
<tjaalton> yeah looks like the headers package is broken
<seph> Okay. I can file it against the kernel team. (now filed as #1134441)
<seph> Thanks for the pointer. It's a bit weird trying to tell how to file things in all this :)
#ubuntu-x 2013-02-28
<Dandel> any ideas on when the xorg edgers will activate the vdpau implementation within mesa? it appears to be the only video acceleration method available under open source drivers since mesa removed va api support ( due to it being unmaintained )
<RAOF> Dandel: Intel has vaapi support via libva; the mesa acceleration is shader-based anyway.
<Dandel> RAOF: I know, but it helps reduce cpu load and in some cases ( like the amd e350, and systems using ddr2 memory ) it will allow users to play 1080p based content
<mlankhorst> morning
<mlankhorst> Dandel: vaapi never worked to begin with
<Dandel> mlankhorst: I didn't know that it didn't ever work... however the vdpau may be working ( good thing for slower pc's )
<mlankhorst> well apart from the decoding parft I'd guess vdpau worked :P
<Dandel> the main thing would be to at least get rid of the errors when running vdpauinfo ( since it looks for libs that are not on the host platforms )
 * mlankhorst tries
<mlankhorst> well the information in vdpuainfo is still completely wrong :P
<mlankhorst> ah well
<mlankhorst> I'll leave it as an excercise to the reader to fix it
<alkisg> Hi, in 12.04.1, there is an xserver-xorg-video-s3virge available,  but xserver-xorg-video-s3virge-lts-quantal
<alkisg> N: Unable to locate package xserver-xorg-video-s3virge-lts-quantal
<alkisg> Sorry pressed enter too early, let me ask again...
<alkisg> Hi, in 12.04.1, there is an xserver-xorg-video-s3virge available,  but not in 12.04.2 (xserver-xorg-video-s3virge-lts-quantal)
<alkisg> Is this because noone asked for it, or are there some technical reasons preventing it from being build+published?
<tjaalton> it was removed since precise, nothing to backport
<tjaalton> and on such hw you don't need the enablement stack anyway
<alkisg> I'm on precise and it's available there: $ apt-cache policy xserver-xorg-video-s3virge            
<alkisg>   Candidate: 1:1.10.4-4build2
<tjaalton> so
<tjaalton> ?
<alkisg> Moment please, phone... :-/
<tjaalton> if you actually have such hw, use the .1 installer
<mlankhorst> alkisg: the official viewpoint is that on old hardware you wouldn't need the new xserver or kernel anyway, so the official path to install is through installing 12.04.1 and then upgrading. :-)
<mlankhorst> s3virge doesn't exist in quantal either
<mlankhorst> https://launchpad.net/ubuntu/+source/xserver-xorg-video-s3virge
<mlankhorst> I think only xserver-xorg-video-qxl is the only video driver that quantal has, but the enablement stack doesn't
<alkisg> Sorry for the delay, long phone call...
<alkisg> So, a user with that card wants to download and use ubuntu
<alkisg> He goes to the site, selects 12.04, and gets 12.04.2
<alkisg> ...he'd need to google a lot before finding out he should go to some ftp server and locate 12.04.1 instead...
<tjaalton> well there is the link to alternative images
<alkisg> But anyways the reason I was asking is because we're providing a localized version of 12.04 for schools here,
<alkisg> and I'm trying to see if it would be best for those localized CDs to be (updated 12.04.1) or (12.04.02)
<alkisg> Considering also the problems with virtualbox (not working at all in 12.04.2), and samba (working only for the first client connection in 12.04.2), maybe it'd be best to stick to "upgraded" 12.04.1 CDs, even if now ubuntu.com/download suggests 12.04.2...
<alkisg> Thank you very much guys... :)
<tjaalton> the release notes has a link to .1, although it could've mentioned the ancient hw as well and not just virt
<mlankhorst> hm virtualbox has issues with 12.04.2? oh right the libpciaccess bug
<mlankhorst> Sarvatt: ^
<alkisg> https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1081307
<ubottu> Launchpad bug 1081307 in virtualbox (Ubuntu Quantal) "I'm upgrading the 12.04.1 to quantal 3.5 kernel - virtualbox-dkms 4.1.12-dfsg-2ubuntu0.2: virtualbox kernel module failed to build [merge request]" [Undecided,Confirmed]
<mlankhorst>  or that :P
<alkisg> Ah there's another one? Hehe, yet one more reason to stick to 12.04.1+upgrades :)
<mlankhorst> no that bug happened when you were in a vm trying to start cd for first time
<mlankhorst> it's probably in installation notes
<mlankhorst> bryce: http://www.bryceharrington.org/Arsenal/ubuntu-x-swat/Reports/package-status-lts-quantal.html doesn't update?
<bryce> mlankhorst, hmm, I'll investigate.
<darkxst> is mesa going to be updated to 9.0.3?
<darkxst> https://bugs.launchpad.net/mesa/+bug/1136475
<ubottu> Launchpad bug 1136475 in mesa (Ubuntu) "clutter freezes due to unsupported GL extension in vmwgfx" [Undecided,New]
<tjaalton> 9.1 is in staging ppa
<darkxst> tjaalton, where is the staging ppa?
<bryce> canonical-x/x-staging
<tjaalton> right
<darkxst> will that be landing in raring soon?
<bryce> I should send out an announcement
<bryce> the plan had been to hold off until the xserver was formally released, although now with the rolling release stuff being discussed, maybe we should re-think that
<darkxst> oh no, its even more broken with the new x server
#ubuntu-x 2013-03-01
<tjaalton> mesa doesn't need the new xserver
<tjaalton> but it has still regressed on intel with the slow dash animation, and doubt anyone has sent it upstream
<tjaalton> oh cool, whot has fixed the touch bug.. only 21 patches :)
<tjaalton> mlankhorst: https://blueprints.launchpad.net/ubuntu/+spec/client-1303-hwe-stack
<mlankhorst> morning
<mlankhorst> yikes 21 patches to fix it?
<tjaalton> and depend on master
<tjaalton> so even more for 1.13.x
<tjaalton> first seven hit the list
<tjaalton> I need to hack up a server without the video abi bump so that tegra3 & unity works
<tjaalton> to test this
<mlankhorst> no 2d fallback possible?
<mlankhorst> with modesetting and recent kernel
<mlankhorst> oh.. right
<mlankhorst> it's on 3.0
<tjaalton> yep
<mlankhorst> I can't wait to get THAT through sru :/
<tjaalton> hope it gets squeezed in for 1.13.3 :)
<mlankhorst> do we have a mre for that yet?
<tjaalton> no
<Sarvatt> llstarks: lts point release updates would have those updates most likely like they do currently, and in rolling we would just hold up pushing new X until things are ready, like we're currently staging xserver 1.14 for the IHV's to build against here https://launchpad.net/~canonical-x/+archive/x-staging
<Sarvatt> opt-in for people on LTS unless they install with a point release iso then it's there by default, someone on 12.04 can install xserver-xorg-lts-quantal and get the 12.10 X stack and kernel
#ubuntu-x 2013-03-03
<darkxst> Has anyone managed to get vmwgfx working with the xorg 1.14 RC stack in staging?
#ubuntu-x 2014-02-26
<shirgall> ricotz: ping ;)
<shirgall> Good morning.
<ricotz> shirgall, i guess you want to complain about 331.49?
<shirgall> ricotz: Not complain, but hoping there's a simple fix. 331.49 tries to apply the 3.13 kernel patch instead of 3.11 on Saucy.
<ricotz> shirgall, wait a few minutes for the fix to be published
<shirgall> ricotz: Cool, thanks. I had a hard time figuring out how to report it.
<ricotz> shirgall, yeah, a common problem while using ppas ;), but IRC helps
<shirgall> The PPA sends me to freedesktop.org, but I couldn't find a relevant category :/
<ricotz> shirgall, you can also try to contact the uploader which is can find int the detailed package-view of the ppa
<shirgall> ricotz: well, you weren't online at the time I noticed. :)
<ricotz> shirgall, there is an email-based contact too ;)
<shirgall> ricotz: True, I admit I looked at the changelog and pinged Alberto, which was going too far.
<ricotz> i see
<ricotz> tseliot, hi :), 331.49 and 304.119 are of course candidates for trusty, 334.16 is pretty unstable here
<tseliot> ricotz: hi. I plan to introduce 331.49 soon. As for 334.x, I won't include it in 14.04 as it's a short lived release branch
<ricotz> tseliot, good, yeah, and it seems to be 'really" a beta this time given the problems i noticed
<ricotz> tseliot, still 334.16 is the first with full egl/gles support
<tseliot> ricotz: right, for now we keep egl support disabled in the nvidia packages
<mlankhorst> Sarvatt: indeed ;D
<ricotz> tseliot, right, since currently there is only 32bit which has changed with 334.x ;)
<mlankhorst> 331.49 still doesn't work with 3.14 though
<tseliot> oh, I haven't looked into 3.14 yet
<ricotz> i am not running 3.14 yet, so i havent looked for fixes
<ricotz> hehe
<tseliot> we're not going to ship 3.14 though, are we?
<ricotz> i dont think so
<shirgall> ricotz: Thanks for the fix, all good now on Sauct
<shirgall> Saucy
<silenz> ey guys, i'm trying to learn more about ubuntu and linux as a whole, and i'm currently trying to wrap my head around x11 and an xindow system but i havent really seen a laymans explanation of how it works
<silenz> could somebody explain an x window system like they would to a 10 year old? O_o
<shirgall> silenz: Have you looked at http://tldp.org/HOWTO/XWindow-Overview-HOWTO/ ?
<silenz> no I havent, I was reading a book on ubuntu. I will read the link instead, thanks!
<shirgall> Admittedly, that's more than 10 years old itself.
<silenz> well... according to this book x hasnt changed in like 25 years right
<tseliot> silenz: this should help http://magcius.github.io/xplain/article/
<silenz> cool thanks the more references the better 
<silenz> it seems like a pretty basic concept to understand about ubuntu and linux
<silenz> so im trying to understand as much as possible. i thought the main thing in linux was the GUI which was either KDE or GNOME or now unity
<silenz> but now i get that the underlying thing is actually the window system that makes the GUI
<silenz> im going down the rabbit hole lol
<jarkko> is 12.04 ubuntu get newer mesa packages?
<jarkko> going to
<Sarvatt> it'll get 14.04's graphics stack 3-4 months after 14.04 releases, but that'll be the end
<jarkko> Sarvatt: was that answer for me?
<Sarvatt> yep!
<Sarvatt> its getting the 6 month releases backported to it but thats opt-in unless you install from point release media (like 12.04.4)
<Sarvatt> need to install a package to switch, like xserver-xorg-lts-saucy
<ricotz> mlankhorst, i am going push a patched 331.49 which builds on 3.14 to xedgers if you care
#ubuntu-x 2014-02-28
<tjaalton> huh, is qxl not the default gfx device on new kvm guests?
<hallyn> hi - the last few days, my laptop tends to lock up so that all that works is the sysrq- keys.  (and sshing in, but i didn't hae the needed keys elsewhere. sigh)
<hallyn> syslog shows: http://paste.ubuntu.com/7011147/
<hallyn> does that mean anything to anyone?
<tjaalton> mlankhorst: ^ :)
<mlankhorst> hallyn: a little, but need to know more context and a way to reproduce it
<hallyn> mlankhorst - heh, it's very random, and completely locks up so i can't evenn get to console.
<hallyn> next time is hould be able to ssh in remotely and look around, maybe gdb the task
<hallyn> (and then open a bug)
<mlankhorst> hallyn: up to date system?
<hallyn> yes
<hallyn> And I'm not really doing anything when it happens, usually
<hallyn> i.e. not playing videos or anything
<mlankhorst> seems weird
#ubuntu-x 2015-02-23
<smallfoot-> Will AMD release a new Catalyst driver with support for Xserver 1.17?
<mlankhorst> eventually..
<mlankhorst> we've had 1.17 in the ppa for ages..
<smallfoot-> Will Vivid get Xserver 1.17 or are we stuck with 1.16?
<smallfoot-> oh cool
<mlankhorst> https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging
<mlankhorst> but without fglrx..
<smallfoot-> thanks
<smallfoot-> AMD pisses me off
<smallfoot-> I won't buy any of their products, but I still get punished with old software because of them
<mlankhorst> why not use the free software drivers?
<mlankhorst> I haven't used the blob in ages on radeon, no need to
<JanC> I guess for gamers Catalyst is still needed maybe
<JanC> I haven't used fglrx for ages either
<smallfoot-> I use free software drivers, I only use free software drivers, I use Intel
<smallfoot-> but even when I use Intel, I am held back with old version of X thanks to AMD dragging their feet
<smallfoot-> and its the same thing every new X release
<smallfoot-> mlankhorst, any idea when 1.17 will be put into vivid repo?
<mlankhorst> when we get fglrx..
<smallfoot-> I see
<smallfoot-> is there any estimate of when AMD will give fglrx?
<tjaalton> any dates are under nda, so no
<smallfoot-> imho, ubuntu should switch to 1.17 asap and recommend intel and nvidia and give amd the finger
<tjaalton> that wouldn't solve a thing
<smallfoot-> well, it would pressure them to stop dragging their feet
<smallfoot-> and it would get us non-amd users the latest xorg faster
<smallfoot-> now we're all getting punished by amd whether we buy amd or not
<tjaalton> it would just punish fglrx users that's all
<smallfoot-> well, it would unpunish intel and nvidia users
<JanC> smallfoot-: actually, it would unpunish AMD users too
<JanC> (those who use the open source driver)
<JanC> OTOH, Ubuntu got permission to use a pre-release fglrx in the past, and I suppose they don't want to blow up that relationship prematurely
<smallfoot-> JanC, indeed
#ubuntu-x 2015-02-24
<tjaalton> mlankhorst: opinions about bug 1424263? I think it's a steam bug
<ubottu> bug 1424263 in mesa (Ubuntu) "Broken dependencies" [Undecided,Confirmed] https://launchpad.net/bugs/1424263
<mlankhorst> yeah probably
<mlankhorst> same thing happened with precise probably
<tjaalton> most likely
#ubuntu-x 2015-02-25
<ricotz> mlankhorst, hi, could you push your mesa upload to debian git?
<mlankhorst> oh right..
<mlankhorst> I'll fix that up when I get home
<mlankhorst> hm it was pushed.
#ubuntu-x 2015-02-26
<chrstphrchvz>  /msg NickServ set password freenodeCC
<mlankhorst> aw changed :p
<chrstphrchvz> oops, ignore that
<chrstphrchvz> While I'm figuring out a better password though, I was trying to help out with this bug here https://bugs.launchpad.net/bugs/1314924 ; the issue is resolved by upgrading to 14.04.2 but is it necessary?
<ubottu> Launchpad bug 1314924 in firefox (Ubuntu) "Adressbox Entries unreadable: Grey/Black Mask overlaying text" [High,Confirmed]
<chrstphrchvz> An affected user writes back, "Nobody wants to upgrade or enable the HWE..."
<mlankhorst> then bisect it..
<mlankhorst> oh you already have 2 bugs linked in fd.org 
<mlankhorst> just try those patches and do a stablereleaseupdate
<chrstphrchvz> The problematic package (firefox) has considered but not implemented a workaround. The actual issue was due to xf86-video-intel and it was fixed by the time Utopic was releasedâ¦
<mlankhorst> from the bug description it links to a fd.org bug
<mlankhorst> which links to https://bugs.freedesktop.org/show_bug.cgi?id=75818 or https://bugs.freedesktop.org/show_bug.cgi?id=77201
<ubottu> Freedesktop bug 75818 in Driver/intel "Odd color under menu on old hardware on google page with SNA" [Trivial,Resolved: fixed]
<ubottu> Freedesktop bug 77201 in Driver/intel "[855GM] Firefox textdisplay problems (partly or full blank lines) after update to xf86-video-intel-2.99.911" [Normal,Resolved: fixed]
<chrstphrchvz> So can that be made available to non-HWE 14.04 users?
<mlankhorst> https://wiki.ubuntu.com/StableReleaseUpdates is the procedure
<mlankhorst> bit of paperwork + making a fixed package
<chrstphrchvz> Thanks. I'm not a developer though, much less a maintainer or triager; is there somewhere else to ask with the SRU process (e.g. ubuntu-bugs)?
<chrstphrchvz> Would this issue even qualify under the "When" criteria?
<chrstphrchvz> @mlankhorst, from what Chris Wilson wrote on fd.org, there might be two possible patches since the resolution was not specific to the issue (it was marked duplicate)
<Chipaca> I'm trying to use an R9 285 (tonga) on 15.04, but getting no direct rendering at all
<Chipaca> anybody got any pointers for me?
<Chipaca> I've managed to get catalyst omega to work by fixing the code a little (removing a problematic ifdef), but it crashes too much
<Chipaca> and i'd much rather use the open drivers anyway
<tjaalton> Chipaca: get fully rid of fglrx first
<Chipaca> tjaalton: done that
<Chipaca> rebooted also
<Chipaca> then tried to get updated drivers but none of them seem to be building vivid
<tjaalton> so which is it, fglrx or oss?
<Chipaca> e.g. oibaf's stuff for vivid is just mesa
<Chipaca> tjaalton: not sure i understand the question
<Chipaca> tjaalton: neither the free software nor the fglrx ones that come in 15.04 work
<tjaalton> you want open source drivers but install fglrx?
<Chipaca> the only thing that has given me accelerated 3d has been a tweaked fglrx i downloaded and built from the amd site
<tjaalton> actually I'm not sure radeon supports that
<tjaalton> no idea about fglrx
<Chipaca> tonga? no it doesn't
<Chipaca> not in vivid at least
<Chipaca> tjaalton: as to what i want, i want the free software one to work, of course
<Chipaca> i can wait for it if the answer is "wait for it", using crashy fglrx until then
<tjaalton> it won't be in 4.0 either, no amdgpu driver exists
<tjaalton> and I know nothing of fglrx
<tjaalton> sounds like it's just buggy
<Chipaca> i don't think "buggy" is the word
<Chipaca> there should be something _under_ buggy
<tjaalton> fglrx? :)
<Chipaca> perhaps
<Chipaca> it reminds me of the drivers for AMR modems from way back when
<tjaalton> if you buy radeon for linux, choose wisely
<tjaalton> means not the latest
<Chipaca> :(
<tjaalton> some googling might've helped there
<Chipaca> i thought i had. i read about it being well supported by fglrx, and nearly there for the free drivers (performance was excellent with them, better than fglrx, they said)
<tjaalton> then use it on a release where it's stable
<tjaalton> not vivid
<Chipaca> i need vivid for work, and i'm not going to boot into an operating system just for 3d
<tjaalton> change the card then
<Chipaca> i tried, but have been told it's going to be tested with a windows machine, and if it works, the rma will be denied
<tjaalton> no i mean different vendor/generation
<Chipaca> so now i'm trying to sell it msyelf
<Chipaca> but i'm not very good at that, so i'm giving the free drivers one last runaround
<tjaalton> there is no free driver
<Chipaca> with the perhaps naive presumption that phoronix can't be 100% full of lies
<tjaalton> the kernel drm driver is not
<Chipaca> but there's an amdgpu tree on github, aiui
<Chipaca> anyway, rebooting back into fglrx so i can shoot people before bed
<Chipaca> thanks
<tjaalton> the kernel has amdgpu stuff already, just not r28x support on it
#ubuntu-x 2015-02-27
<ricotz> tseliot, hi, if you intend to update nvidia-346, please use the xorg-edgers tarball again
<tseliot> ricotz: right, thanks
<ricotz> tseliot, btw, is there really the need for this 3.18-kernel patch?
<tseliot> ricotz: I'm not sure about the latest nvidia but the one in the archive failed with linux 3.19
<ricotz> *3.18*
<ricotz> 346.35 didnt fail here anywhere
<ricotz> (i dropped all patches for xedgers as usual)
<ricotz> tseliot, please drop it then
<tseliot> ricotz: it wasn't a typo, it still needed that with linux 3.19 in -proposed
<tseliot> I'll get to that, and drop the patch if needed
<ricotz> tseliot, i see, but you are applying the patch unconditionally
<tseliot> ricotz: well, this is the condition:
<tseliot> #if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 18, 0)
<tseliot> and last I checked, it worked with whatever was in the archive
<ricotz> hmm, ok, pretty weird that is failed for you with 3.19, i didnt need a patch here
<tseliot> I'll check again
<ricotz> of course for 4.0rc1 there is patch needed
<ricotz> tseliot, http://paste.debian.net/plain/158182 -- https://devtalk.nvidia.com/default/topic/813458/linux/linux-4-0-rc1-346-47-build-error-_cr4-functions-fix/
<tseliot> yikes 4.0...
#ubuntu-x 2015-03-01
<smallfoot-> Anyone know when AMD will release the new driver with support for X 1.17? Or when 1.17 will be moved from staging into the repository?
<mlankhorst> I've filed a ffe, no idea about amd really.. 1.17 will be moved when fglrx exists for 1.17..
<smallfoot-> I see
<smallfoot-> Ubuntu/Canonical needs better contact and feedback from AMD
<tjaalton> why do you want 1.17 btw?
<tjaalton> it merged -modesetting in the server, what else?
<tjaalton> 1504 will have it, and it's on the ppa for everyone to use in the meantime..
<ricotz> tjaalton, mlankhorst, hi, did you here about drawing issues of cairo running with ati 7.5.0 and xserver 1.17.x
<ricotz> here/hear
<mlankhorst> no?
<ricotz> mlankhorst, https://bugs.launchpad.net/plank/+bug/1426847
<ubottu> Launchpad bug 1426847 in Plank "Graphical issues when the dock auto-hides" [Undecided,New]
<ricotz> this must be some cairo/backend bug, maybe triggered by the newer xserver
<mlankhorst> might also be a glamor bug? :P
<ricotz> yeah, please leave a comment then
<ricotz> mlankhorst, it seems ickle thinks the same
#ubuntu-x 2016-02-29
<furkan> so it seems that the problem with my multimedia keys might be related to udev or X
<furkan> after suspend/resume, this is what i see in my X log:
<furkan> [  4111.568] (EE) evdev: Microsoft MicrosoftÂ® 2.4GHz Transceiver v9.0: Unable to open evdev device "/dev/input/event6".
<furkan> [  4111.568] (EE) PreInit returned 2 for "Microsoft MicrosoftÂ® 2.4GHz Transceiver v9.0"
<furkan> same error if i unplug the USB receiver and plug it back in
<furkan> any ideas on how i can find the culprit? it was working fine with Ubuntu 15.10
<RAOF_> furkan: âPreInit returned 2â looks like a pretty good lead...
<RAOF> Survey suggests that this is BadValue...
<RAOF> furkan: Oh, right. That's caused by âunable to open evdev deviceâ
<RAOF> furkan: Is that *all* the log?
<furkan> RAOF: no i can share the whole thing, but that was the error
<RAOF> Errors are often caused by warnings earlier :)
<RAOF> Pastebin the whole log and I'll have a quick look at it.
<furkan> ok just 1 sec then because i'll have to do another suspend/resume, since i restarted
<RAOF> Oh, so it works fine at startup?
<furkan> yeah
 * RAOF guesses that this is going to be logind integration fallout
<furkan> ok got the log, pastebining it now
<furkan> RAOF: here it is http://pastebin.com/XNFwSp5S
<furkan> that's a fresh boot followed by a suspend/resume
<RAOF> â[    12.122] (EE) systemd-logind: failed to get session: PID 1038 does not belong to any known sessionâ is quite interesting.
<RAOF> What strange thing are you doing? :)
<furkan> i have no idea lol..
<furkan> all i did was reboot, log in
<furkan> test the volume buttons to make sure they were working
<furkan> and then suspend/resume
<furkan> and then of course test them again to verify that they're no longer working
<RAOF> Yeah, that's preeety odd.
<furkan> so i'm checking pid 1038
<furkan> root      1038 11.8  0.7 660072 131116 tty7    Ssl+ 21:23   0:48 /usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
<RAOF> It's almost certainly Xorg
<furkan> yeah
<RAOF> :)
<RAOF> It happily re-adds *most* of your wireless devices, just not the piece that's the multimedia keys.
<RAOF> ???
<furkan> yeah
<furkan> it's a keyboard + mouse combo
<furkan> MS Sculpt Ergonomic
<furkan> mouse works fine, and keyboard also works fine apart from the volume keys
<RAOF> It's not clear what's going wrong here; it might even be a kernel issue.
<furkan> i tried booting into an older kernel though, and it still persists
<furkan> not sure if the errors are the same
<RAOF> Good thinking; probably not that then.
<furkan> i also tried downgrading systemd/udev but dealing with the dependencies was hell
<RAOF> File a bug against xserver-xorg-input-evdev. If you want to do a little light debugging, the relevant code is in src/evdev.c:EvdevOpenDevice
<furkan> interesting, thanks for the tip
<furkan> should i file it on launchpad? or upstream?
<RAOF> Launchpad
<furkan> alright will do, thanks :)
<RAOF> If you've tried with xf86-input-evdev from trunk, you can also file upstream :)
<RAOF> But certainly Launchpad.
<furkan> i guess before i do that i'll also boot from a live ISO
<furkan> just to make sure that my configuration isn't somehow broken
<RAOF> Not a bad idea.
<tjaalton> furkan: does that device exist after resume? and test if it works with evtest
<tjaalton> from a vt
<furkan> tjaalton: no the device disappears after resume
<tjaalton> x doesn't do that
<tjaalton> reattaching doesn't help
<furkan> sorry i don't understand, you mean if the device disappears the problem lies somewhere else?
<tjaalton> yes
<furkan> oh ok i see
<furkan> so udev or something?
<tjaalton> oh and the other one was a question
<furkan> and i tried evtest in a VT
<furkan> hold on let me copy it
<furkan> it shows something like ^[[25@
<furkan> (that's from memory since i can't copy/paste from a VT)
<furkan> let me just write it on some paper to make sure
<furkan> yeah it's ^[[25~, ^[[26~, and ^[[[D, for mute, vol-, and vol+
<furkan> but it doesn't show the event time and stuff
<furkan> like it does for all the other keys
<furkan> oh and no, reattaching the USB receiver doesn't help
<tjaalton> so the event device is there after suspend?
<furkan> no the device is gone
<furkan> and with evtest, when i make keystrokes i get output like this for all the keys other than the volume ones:
<furkan> Event: time 1456725562.966902, -------------- SYN_REPORT ------------
<furkan> Event: time 1456725563.022896, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7002c
<furkan> Event: time 1456725563.022896, type 1 (EV_KEY), code 57 (KEY_SPACE), value 0
<furkan> but for mute/vol-/vol+ i get nothing like that, just ^[[25~, ^[[26~, and ^[[[D
<furkan> so it seems the keyboard sends something, but no event is registered?
<tjaalton> but how can you run evtest if the device is gone?
<furkan> i think the keyboard shows up as more than 1 device
<furkan> even in evtest it's listed twice
<tjaalton> sure, but then you can't test the one that is gone right?
<furkan> oh right, yeah, i was testing the remaining ones
<furkan> so i'm looking in /dev/input/by-path
<furkan> there's 3 symlinks, pci-***-event-kbd
<furkan> *** = some long number
<furkan> symlinked to ../event2, ../event4, and ../event6
<furkan> and the event4 symlink is broken, of course, since it's no longer there
<furkan> so should i file a bug against udev, then?
<tjaalton> what kernel used to work?
<tjaalton> 4.2 from 15.10?
<furkan> yeah 4.2
<furkan> but even if i boot up w/ 4.2 it doesn't seem to fix it
<tjaalton> the exact same 4.2?
<furkan> yeah i tried going even further back to 3.19, from 15.04
<furkan> i didn't purge my 15.04 + 15.10 kernels
<tjaalton> so then maybe udev rhen
<tjaalton> -then
<furkan> i tried downgrading udev to test, but so many dependencies
<tjaalton> having issues of my own right now, limited to just my phone atm :P
<furkan> oh sorry, i hate typing on my phone lol
<tjaalton> some local network snag
<furkan> i may try to see if i can downgrade udev later, but i'll have to manually download a whole bunch of packages (systemd, xorg, and some other misc packages)
<furkan> last time i tried i did 15 packages but there were still more that were broken
<furkan> downloaded them all individually from launchpad
<tjaalton> maybe ask pitti when he's around
<ricotz> tjaalton, hi, regarding your nvme issues, was this fixed and are the current daily iso working for you?
<tjaalton> ricotz: i'm not sure, haven't tried images since
<ricotz> tjaalton, ok
<tjaalton> but i upgraded a machine to xenial which needs it and it boots up fine
<ricotz> tjaalton, used trusty and upgraded to 4.5rc6 due missing hardware support, and this triggers the missing nvme problem, so initramfs in trusty still needs fixing 
<tjaalton> oh yes
<tjaalton> there is a bug too, somewhere
<ricotz> tjaalton, the xenial images simply hang on boot (black screen), and going a bit further with nomodeset
<ricotz> with i7-6560U
<ricotz> (trusty-daily boots and works)
<tjaalton> hmm ok, i can test tomorrow
<tjaalton> which kernel does it have?
<tjaalton> assuming 4.4.0-8 so no i915_bpo yet
<ricotz> tjaalton, I guess not
<ricotz> https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/log/?h=master-next
<tjaalton> yeah it's there, -9 should happen today
<tjaalton> oh, tagged already
#ubuntu-x 2016-03-01
<ricotz> tjaalton, jfyi :) this is what I am (massively) seeing here :\ https://bugs.freedesktop.org/show_bug.cgi?id=93858
<ubottu> Freedesktop bug 93858 in DRM/Intel "GPU HANG: ecode 9:0:0x85dfffff, reason: Ring hung, action: reset" [Normal,New]
<tjaalton> fun, try 4.5 & drm-intel-next mainline
<ricotz> (4.5rc6 + mesa 11.2rc1)
<tjaalton> 0x85dfffff might mean it's in mesa actually
<ricotz> I would say it was worse with 4.5rc6 + mesa 11.1.2-xenial
<tjaalton> ah
<ricotz> which could suggest it is mesa
<tjaalton> at least not a regression :)
<tjaalton> caused by 11.2
<ricotz> yeah
<tjaalton> i seem to have forgot how to bisect, or mesa is being an ass
<ricotz> tjaalton, found a trace do you care for it?
<tjaalton> upstream might
<ricotz> tjaalton, http://people.ubuntu.com/~ricotz/log/4.5rc6-mesa11.2rc1-iris540
<tjaalton> try latest drm-intel-next?
<ricotz> tjaalton, http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/current/ ?
<tjaalton> yes
<ricotz> ok, let's see
<ricotz> still happening
#ubuntu-x 2016-03-02
<tjaalton> RAOF: hey, still got powers to copy packages from a ppa to archive?
<tjaalton> probably a bit late for that though
<tjaalton> EOD-wise
<marlinc> Since a couple of days I'm no longer able to use the NVIDIA driver at all. It always crashes, at least Unity does. Saying that GLX can't be loaded
<tseliot> marlinc: seeing your dmesg, /var/log/gpu-manager.log, and the X log would help
<tseliot> (with the failure)
 * tseliot -> EOD
<ricotz> tjaalton, hi, this is fun https://patchwork.freedesktop.org/patch/71936/
<tjaalton> ricotz: what about it?
<ricotz> tjaalton, this is still missing in 4.5+ ;), but included in the bpo backport
<ricotz> totally missed that the firmware failed to load
<ricotz> which could be a cause for the mentioned problems
<tjaalton> ok
<ricotz> I guess it wasn't the cause then
<ricotz> it still hangs
#ubuntu-x 2016-03-03
<bigpet> did anything change regarding the procedure of getting intels vulkan drivers to run on the xenial preview? I got it working 3 weeks ago
<bigpet> but now I tried the same steps and I get a undefined symbol with a sha1 function in mesa
<tjaalton> it's broken
<tjaalton> still haven't fixed it
<bigpet> oh, ok. I was wondering. I recompiled mesa but didn't install the recompiled version just tried to set some env var to the vulkan loader json and got some other error
<bigpet> but theoretically just recompiling and then installing the recompiled version could fix it? or is there something else I'd be missing?
<tjaalton> a commit needs to be reverted
<tjaalton> or figure out why it works on fedora
<bigpet> I mean if it's just the sha1 thing, I found irc logs dating back to like october of last months of people disussing it being a bug in the configure script of mesa
<bigpet> *of last year
<bigpet> neat, got vkcube running
<bigpet> thanks for the help
#ubuntu-x 2017-03-01
<camako> hi, what's the easiest way to obtain and run vulkan sample apps (i.e. without having to build). 
<tjaalton> the only sample app available is vulkainfo in vulkan-utils
<camako> thanks tjaalton
#ubuntu-x 2018-02-26
<ricotz> tseliot, hi
<tseliot> ricotz: hi, I haven't had the time to look into your patch yet, but I will soon
<ricotz> tseliot, alright, make sure that the current build doesnt pass the NEW-queue
<tseliot> ricotz: I'm pretty sure it did already
<ricotz> no, not yet
<ricotz> armhf fails of course
<tseliot> yes, I'll fix that
<ricotz> didn't look into that, some missing ARM__EXCLUSEDs I guess
<tseliot> yes, easy stuff
<ricotz> still *-386 is not a good way, while real multi-arch is possible
<tseliot> yes, well, I used what Debian did, but I'm available to change it
<ricotz> ok, take your time
#ubuntu-x 2018-02-28
<ricotz> tseliot, please apply fixes correctly https://github.com/tseliot/nvidia-graphics-drivers/commit/27adcaeb811c7bb225a9ae001674557228a79afa
<ricotz> +#LIBDIR#/vdpau/vdpau/libvdpau_nvidia.so.#VERSION#                               #LIBDIR#/vdpau/libvdpau_nvidia.so
<tseliot> ricotz: I haven't uploaded anything yet, as I have to unblock things in -proposed first
<tseliot> but yes, I'll fix that
<ricotz> tseliot, hi, better don't get it NEWed at all and make the "fixed" version the first which enters the archive
<ricotz> nvm
<ricotz> it got NEWed :(
<tseliot> ricotz: BTW, all the changes I made, caused i386 and armhf to fail, for some reason https://launchpad.net/~albertomilone/+archive/ubuntu/nvidia-glvnd-temp/+packages
<ricotz> i386 built fine
<ricotz> for my earlier version
<ricotz> https://launchpad.net/~ricotz/+archive/ubuntu/experimental/+packages
<tseliot> I haven't looked into the binary-arch failure
<ricotz> did you thought about libnvidia-compute-* yet?
<tseliot> ricotz: the conflicts/replaces ?
<ricotz> I can take another look after lunch
<ricotz> yes, those doesn't play well with mulitarch
<tseliot> ricotz: yes please, I'm very busy right now
<ricotz> tseliot, I assume you didn't push everything yet, git doesn't match the upload
<tseliot> ricotz: no, as I couldn't test it. It's all in git, just in case
<tseliot> that would be the 390-ppa branch
<ricotz> ah, I see, was looking at 390 branch
<ricotz> tseliot, pushed some changes to https://github.com/ricotz/nvidia-graphics-drivers/commits/390-ppa
<ricotz> built here https://launchpad.net/~ricotz/+archive/ubuntu/experimental/+packages
<tseliot> ricotz: thanks, I'll have a look at them later
<ricotz> tseliot, more fixes coming
<tseliot> ricotz: thanks, I'll check them all out
<ricotz> tseliot, pushed
<tseliot> thanks again
<ricotz> tseliot, btw, why did you switch to the not "no-compat32" source?
<tseliot> ricotz: because the i386 package is going to be built on i386 anyway
<ricotz> exactly, but you are not using the no-compat32 run binary
<ricotz> (of course this can only be changed with the next upstream release)
<tseliot> I thought I did
<tseliot> too many negations :D
<ricotz> NVIDIA_DIRNAME_amd64	 = NVIDIA-Linux-x86_64-${NVIDIA_RELEASE}
<ricotz> NVIDIA_FILENAME_amd64	 = ${NVIDIA_DIRNAME_amd64}.run
<tseliot> yes, we'll use the no-compat one
<ricotz> this call seems to fail on install https://github.com/tseliot/nvidia-graphics-drivers/blob/390-ppa/debian/templates/nvidia-dkms-flavour.postinst.in#L75
<tseliot> I must have changed something when I removed the delayed build code
<ricotz> I think the earlier version parsing is broken at some point and the arguments for dpkg are incomplete
<ricotz> "dpkg: Fehler: Version Â»-Â« hat falsche Syntax: Revisionsnummer ist leer"
<tseliot> yes, that's the result of heavy multi-tasking with no testing
<ricotz> I think "generate-modaliases" is running too early
<ricotz> it should be run after install
#ubuntu-x 2018-03-01
<tseliot> ricotz: first of all, thanks for your work. I integrated your patches, and I added one more commit in the 390-ppa branch, so that libnvidia-compute-390:i386 won't have any problems overwriting /etc/OpenCL/vendors/nvidia.icd from the release in the archive
<tseliot> it works well here (I built it in the PPA)
<ricotz> tseliot, shouldn't it be in Conflicts rather than Replaces?
<tseliot> ricotz: with replaces the package will simply overwrite files from the previous release
<tseliot> we should probably clean up the -i386 packages though
<ricotz> tseliot, ah I see
<ricotz> tseliot, yeah, those should have never reached the archive :(
<tseliot> I know
<ricotz> afaic they don't conflict while they literally install to "/#/..."
<tseliot> yes, that's just a lucky mistake
<ricotz> I would ignore them, and them removed from archive, they should not have reached systems of a normal user yet
<ricotz> bionic is devel anyway
<tseliot> right
<tseliot> ricotz: ok, I'just pushed to the 390 branch, and I am going to upload
<tseliot> I'll need an admin to approve libnvidia-common
<ricotz> tseliot, alright :)
<tseliot> hmm... maybe I should also depend on the new X
<tseliot> as I did for 340
<tseliot> ok, pushed with that change
<tseliot> building in the PPA just in case
<tseliot> uploaded
<ricotz> nice
#ubuntu-x 2019-02-25
<alkisg> amdgpu-pro-dkms has build problems... I guess they need to stick with nomodeset until upstream fixes it
<tjaalton> need to use 4.15 with it
<tjaalton> bionic kernel
<alkisg> 4.15.0-20-lowlatency 
<tjaalton> doing audio stuff on it?
<tjaalton> anyway, that's old
<alkisg> Thanks, trying with a newer one
<alkisg> (weird situation, 32bit ubuntu on 64bit uefi, hence 2 kernels... meh)
<alkisg> Building initial module for 4.15.0-45-generic
<alkisg> Error! Bad return status for module build on kernel: 4.15.0-45-generic (i686)
<alkisg>  /var/lib/dkms/amdgpu/17.40-492261/build/make.log ==> https://termbin.com/rsv0
<alkisg> Ah, maybe you meant wth -hwe instead of just updated bionic... trying...
<alkisg> tjaalton: nah, I tried it on a 64bit VM with -hwe (4.18), it fails there too: termbin.com/l7u7
<alkisg> I'll tell the school to continue using nomodeset. I still have access if you have any ideas to test.
<alkisg> Installing libelf-dev as mentioned in the previous log, doesn't help: termbin.com/jnha
<alkisg> Maybe a 16.04 kernel is needed, not a new one...
<tjaalton> 17.40 is ancient
<tjaalton> alkisg: ^
<tjaalton> it doesn't support bionic
<tjaalton> it's at 18.50 now
<alkisg> tjaalton: oh my. I need to either blame google or myself. I'll choose to blame google. :D
<alkisg> Thanks again!
#ubuntu-x 2019-03-01
<mamarley> ricotz: I have (and have had) 318.43 ready in my staging PPA for a while now.  I know you said before that it needed a change, but I don't think you ever told me what that was.  I also have libvdpau 1.2 there.
<mamarley> ricotz: I have bunches of users bugging me about this.
#ubuntu-x 2020-02-25
<tjaalton> tseliot: have you seen patches for 5.6 support for nvidia? just a heads up, but at least 390 fails like here https://launchpadlibrarian.net/466479407/buildlog_ubuntu-focal-amd64.linux-restricted-modules-5.6_5.6.0-2.2_BUILDING.txt.gz
<tseliot> tjaalton, are we moving to 5.6?
<tjaalton> I'll create an oem kernel based on 5.6 but it's ppa-only for now, and having nvidia support isn't time critical yet
<tjaalton> for new enablement yes
<tjaalton> eventually
<tjaalton> oem 5.4 is just temporary
<tseliot> I didn't know we would have 5.6, so I didn't really look into that
<tjaalton> no worries
<tjaalton> but keep it in mind for the next upload if possible :)
<tjaalton> to focal
<tseliot> sure
#ubuntu-x 2020-02-26
<ricotz> mamarley, hi, may I ask how your nvidia card died?
<mamarley> ricotz: It didn't die, I just decided to replace the computer it was in because I was tired of maintaining out-of-tree drivers.
<ricotz> I am getting the feeling my card isn't doing so well either, I am getting the impression it killed my PSU
<ricotz> mamarley, ah I misunderstood then
