#ubuntu-x 2007-02-19
<Ubugtu> New bug: #67321 in initramfs-tools (main) "Logitech Cordless Desktop MX 5000 bluetooth desktop used to work but doesn't now (dup-of: 32415)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/67321
<seb128> tepsipakki: ping?
<tepsipakki> pong
<seb128> tepsipakki: had a good weekend?
<seb128> tepsipakki: ready for next round of updates? ;)
<tepsipakki> yes, managed to be offline for a while ;)
<tepsipakki> I'm on a lecture at the moment, but I guess we can continue with those at ~13.00UTC
<seb128> ok, good, I'm around let me know when you are ready to work on that
<Ubugtu> New bug: #86258 in xserver-xorg-video-i810 (main) "i810 driver: Using external widescreen monitor on a laptop needs a lot of complicated manual configuring" [Medium,Confirmed]  https://launchpad.net/bugs/86258
<Ubugtu> New bug: #86262 in xorg (main) "UI for changing X configuration is rather hidden" [Medium,Confirmed]  https://launchpad.net/bugs/86262
<tepsipakki> ok, I need to get lunch first.. 15min ->
<Ubugtu> New bug: #86266 in xorg (main) "No easy way to force laptops to use the external screen" [Medium,Confirmed]  https://launchpad.net/bugs/86266
<tepsipakki> ok, where were we
<tepsipakki> libx11, xft, libdrm, mesa, xorg-server
<tepsipakki> those should be done
<tepsipakki> I've seen reports that the window minimize -action got slower, and it's true
<tepsipakki> mouse freezes for a while when it does that
<tepsipakki> and another is font paths
<tepsipakki> it seems that the generated paths are bogus (/usr/share/X11/fonts, should be /usr/share/fonts/X11)
<tepsipakki> and the new server doesn't look in both of them
<seb128> tepsipakki: all the hard parts now, that's it? ;)
<tepsipakki> yes, just about
<tepsipakki> we maybe need to patch xorg-server to look in both places
<tepsipakki> performance issues can be dealt with later
<tepsipakki> noticed that I have touched xorg.conf on my laptop last October, and already then the font-path for misc was changed, maybe by me
<tepsipakki> amazing that it has gone unnoticed
<tepsipakki> oh, the xorg metapackage could be a tricky one as well
<tepsipakki> they differ so much
<seb128> is there anything easy or than we can sync left?
<seb128> what about drivers, they need to go after the server?
<tepsipakki> old drivers work
<tepsipakki> they can be merged later
<seb128> ok
<tepsipakki> but libx11 is ready, I've merged it, you can see the diff here: http://users.tkk.fi/~tjaalton/xorg72/new/
<tepsipakki> diff against -1
<seb128> ok, I'll have a look at that one next then
<jcristau> re: libx11, there seem to be bugs in sun java which cause assertion failures in xlib/xcb (bad locking), dunno if you care about that
<jcristau> there was a thread "java and xcb" last week on xorg@lists.fd.o
<tepsipakki> grah
<tepsipakki> I'll check that
<jcristau> libdrm, mesa and the server should be fine though
<tepsipakki> yep
<tepsipakki> seb128: you can sync libdrm from experimental, I'm preparing mesa
<tepsipakki> let's hold libx11 for a while
<seb128> ok
<tepsipakki> I'll try to reproduce that issue
<jcristau> tepsipakki: for the server, it'll probably be best to disable patch 42 for now, there's one report that it causes a regression
<tepsipakki> ok, thanks
<jcristau> also I changed debian/rules to run configure --with-os-vendor=Debian, I guess you'll want to change that :)
<tepsipakki> ah, indeed :)
<tepsipakki> hmm, maybe I just need to add /usr/share/X11/fonts/{misc,cyrillic...} to --with-default-font-path
<tepsipakki> hmm, no
<tepsipakki> doesn't solve anything :)
<jcristau> previous ubuntu releases use that path?
<tepsipakki> yes
<jcristau> :/
<tepsipakki> but there's nothing
<tepsipakki> in feisty
<tepsipakki> but configs point there
<jcristau> there's some code in xserver-xorg.postinst to modify font paths and replace the X11R6 paths into /usr/share/fonts/X11/foo
<tepsipakki> hmm
<tepsipakki> so maybe that could be modified
<jcristau> yep
<tepsipakki> that's in xorg?
<jcristau> yes
<seb128> tepsipakki: libdrm ok to sync then? ;) 
<tepsipakki> yeah
<seb128> doing that now
<seb128> tepsipakki: sync done
<tepsipakki> thanks
<tepsipakki> hmm, I can't reproduce that problem with java
<tepsipakki> downloaded josm-1.3.jar and ran it
<tepsipakki> with sun-java
<seb128> tepsipakki: if there is just a bug with java we probably have time to fix it before feisty
<tepsipakki> yes, maybe
<tepsipakki> if people bump into it
<tepsipakki> I'm wondering if the --with-xkb-path=/usr/share/X11/xkb change is an issue
<tepsipakki> for xserver
<tepsipakki> used to be /etc/X11/xkb
<seb128> well, we changed it so it should not be a problem no?
<seb128> we can make it Breaks on previous package
<tepsipakki> hmm
<tepsipakki> hah
<tepsipakki> indeed, xkeyboard-config uses /usr/share/X11/xkb
<tepsipakki> but xserver still had /etc/X11/xkb
<tepsipakki> so let's go with debian
<tepsipakki> ok, I have mesa ready
<cjwatson> er, we already switched to /usr/share/X11/xkb
<cjwatson> earlier in feisty
<tepsipakki> we did?
<cjwatson> yes
<seb128> yep
<seb128> some months ago
<cjwatson> note how everything in /etc/X11/xkb in current feisty is a symlink
<tepsipakki> so it seems
<tepsipakki> anyway, it's safe to build xorg-server with --with-xkb-path=/usr/share/X11/xkb?
<cjwatson> oh, yes, it's a bug that it isn't already
<tepsipakki> because the stuff is there
<tepsipakki> right
<cjwatson> presumably there's already a Depends or Conflicts or Breaks or something?
<cjwatson> on xkb-data
<tepsipakki> Recommends: xkb-data :)
<cjwatson> that doesn't help with upgrades
<tepsipakki> that's the old version
<tepsipakki> ah, same with the new one
<tepsipakki> edgy was the first with xkb-data?
<cjwatson> is that important?
<cjwatson> the server package should ensure that an incompatible version isn't installed - doesn't much matter what Ubuntu releases were involved
<tepsipakki> true
<tepsipakki> just to check the version.. edgy had 0.8.7
<tepsipakki> so this should Depends: xkb-data (>=0.9.4ubuntu1) or similar
<tepsipakki> oops, 0.9-4ubuntu1
<cjwatson> I'm not sure it should Depends, if it doesn't have a dependency already
<tepsipakki> ah
<tepsipakki> so Breaks or Conflicts
<Ubugtu> New bug: #43464 in xorg (main) "Feistys Quod Libet ignores keyboard shortcuts" [Medium,Unconfirmed]  https://launchpad.net/bugs/43464
<tepsipakki> maybe it's best to push the next uploads tomorrow, since I need to run to the choir practice. I'll take a look at xorg and figure out how to fix the font paths on xorg.conf
<seb128> tepsipakki: what about libx11?
<seb128> you have it ready for review?
<tepsipakki> ah, indeed.. that and mesa is ready at http://users.tkk.fi/~tjaalton/xorg72/new
<tepsipakki> I'll be online in 3+ hours
<tepsipakki> but maybe it's a bit late then
<Ubugtu> New bug: #86303 in xorg "Ctrl+Alt+Keypad-Plus Ctrl+Alt+Keypad-Minus do not function" [Undecided,Unconfirmed]  https://launchpad.net/bugs/86303
<seb128> tepsipakki: ok, I might have a look at libx11 then
<tepsipakki> nice
<tepsipakki> ok, need to go ->
<Ubugtu> New bug: #33318 in xkeyboard-config (main) "GNOME's keyboard layout is incorrect for French canadian" [Medium,Confirmed]  https://launchpad.net/bugs/33318
<Ubugtu> New bug: #86333 in xorg (main) "X not working on nvidia fx5600 with 'vesa' driver" [Undecided,Needs info]  https://launchpad.net/bugs/86333
<Ubugtu> New bug: #57156 in linux-restricted-modules-2.6.17 (restricted) "Screen refresh problem." [Undecided,Unconfirmed]  https://launchpad.net/bugs/57156
<Ubugtu> New bug: #86360 in gnome-applets (main) "[keyboard indicator]  "Show Current Layout" displays empty window (at least on amd64) (dup-of: 58083)" [Medium,Rejected]  https://launchpad.net/bugs/86360
<Ubugtu> New bug: #59429 in xkeyboard-config "Multimedia key partially working" [Low,Fix released]  https://launchpad.net/bugs/59429
#ubuntu-x 2007-02-20
<Ubugtu> New bug: #64428 in acpi-support (main) "Mouse cursor gone after hibernate/resume (dup-of: 63258)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/64428
<Ubugtu> New bug: #64333 in acpi (main) "Mouse cursor disappears after suspend (dup-of: 63258)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/64333
<Ubugtu> New bug: #55108 in xorg "radeon driver, INVALID IO ALLOCATION" [Undecided,Confirmed]  https://launchpad.net/bugs/55108
<tepsipakki> ok, I'm now going to merge xorg
<tepsipakki> bah
<tepsipakki> we have 7.1.1, debian has 7.1.0
<jcristau> does that matter?
<tepsipakki> not really
<tepsipakki> but I bet there will be someone who demands it to be 7.2* ;)
<tepsipakki> you haven't done one for 7.2 yet?
<jcristau> no
<tepsipakki> debdiff is 3.5MB, yikes
<tepsipakki> because of the translations, mostly
<jcristau> yay, fun :)
<jcristau> oh, ok
<jcristau> less fun, then ;)
<tepsipakki> don't hold your breath ;)
<tepsipakki> sigh
<tepsipakki> I guess the new one can be called 7.2-0ubuntu1
<jcristau> yeah
<tepsipakki> latest merge was with 7.0.22, 18 revisions after that
<tepsipakki> ok, diff is only 190kB
<tepsipakki> without po
<jcristau> a lot better then
<tepsipakki> yep
<tepsipakki> nice to have Depends/Conflicts etc in multiple lines.. a lot easier to actually find what has changed
<tepsipakki> not that the current one in Ubuntu has so...
<tepsipakki> gr
<jcristau> yeah I changed that for the x11-common conflicts recently
<jcristau> that line was really too fucking long
<tepsipakki> that's one massive list :)
<tepsipakki> ok, maybe best to keep the metapackages for now (xlibs-dev, xbase-clients, xutils), not touching those
<tepsipakki> later we can drop at least xutils and sync it from Debian
<tepsipakki> since there are some bugs open about missing xon
<tepsipakki> * debian/local/Xsession: set temporary umask when creating $ERRFILE.
<tepsipakki> -if (umask 077 && touch "$ERRFILE") 2> /dev/null && [ -w "$ERRFILE" ]  &&
<tepsipakki> +if touch "$ERRFILE" 2> /dev/null && [ -w "$ERRFILE" ]  &&
<tepsipakki> old version is from ubuntu
<tepsipakki> jcristau: I'll put a diff available when I'm ready, so you can see if some of the changes (like above) is something Debian might want too
<jcristau> cool, thanks
<tepsipakki> a security update too
<tepsipakki> "Fix race condition when chown'ing .xsession-errors."
<tepsipakki> CVE-2006-5214
<jcristau> indeed
<jcristau> can you file a bug about that?
<tepsipakki> sure, when I'm done with this
<jcristau> thanks
<tepsipakki> eh, the ubuntu dexconf still uses /usr/share/X11/fonts/*
<tepsipakki> but Debian still has /usr/X11R6?-)
<tepsipakki> both that and /usr/share/fonts/X11/*
<jcristau> yeah, for partial upgrades
<jcristau> I guess we'll change that post-etch
<tepsipakki> ooh, preseeding support
<tepsipakki> me like
<tepsipakki> not that we use fontservers..
<tepsipakki> hi seb128 
<seb128> Hi tepsipakki
<tepsipakki> I'm doing xorg now, but it'll take a while
<tepsipakki> lots of funky stuff in it
<seb128> k, I've been busy with other things yesterday, I'll have a look to your libx11 merge if nobody else is on it yet
<tepsipakki> cool
<tepsipakki> no mention on the changelog as to why dexconf has entries for wacom
<tepsipakki> not in Debian
<jcristau> tepsipakki: actually no need to file a bug for the Xsession umask stuff, I just committed the fix
<tepsipakki> heh
<tepsipakki> I'll add 2560x1600 to DEFAULT_DCRESOLUTIONS :)
<tepsipakki> I have such a beast
<tepsipakki> heh, nice typo on vars.i386
<tepsipakki> SERVER_XORG_DETECT_DEPENDS="laptop-detect, xresprobe, mdetect, discover1, dmidecode"
<tepsipakki> missing X
<tepsipakki> jcristau: vars.amd64 lacks  xserver-xorg-video-vmware for XSERVER_XORG_VIDEO_DEPENDS
<jcristau> I'm not sure if the bug is in vars.amd64 or all the others ;)
<tepsipakki> * Readd xserver-xorg-driver-vmware to vars.amd64 and remove it from non x86* arches. (Closes Ubuntu: #38070)
<tepsipakki> so yes
<jcristau> hmm
<jcristau> it's both, then :)
<tepsipakki> right :)
<tepsipakki> 3000 lines of diff to go
<tepsipakki> -[ -f /etc/default/rcS ]  && . /etc/default/rcS
<tepsipakki> +. /etc/default/rcS
<tepsipakki> * debian/x11-common.init: Only source /etc/default/rcS if it exists, allowing x11-common to be installed by debootstrap.
<tepsipakki> jcristau: you might want that
<jcristau> yeah, possibly
<jcristau> (although I don't think debootstrap ever installs x11-common in debian)
<cjwatson> not yet :-)
<cjwatson> we did that because we were switching to console-setup
<cjwatson> which needs xkb-data, which needs x11-common - if Debian ever makes that switch, then you'll need the same thing
<jcristau> cjwatson: ok, thanks
<tepsipakki> oh joy, next up: xserver-xorg.config.in
<tepsipakki> hmm, Debian doesn't have one :)
<tepsipakki> wondered why it looked strange
<tepsipakki> ah, it's in postinst
<tepsipakki>  * Incorporate the entire old xserver-xorg.config script in to the
<tepsipakki>     postinst script. This is hideously dirty, but it should allow the script
<tepsipakki>     to properly expect discover and xresprobe to be installed without having
<tepsipakki>     gross hacks in tasksel just for this task. We'll junk all this for etch+1.
<tepsipakki>     Thanks to Joey Hess for the solution.
<tepsipakki> cjwatson: so, should we dump the old one and go with Debian?
<cjwatson> we'd need to merge our changes to xserver-xorg.config.in into Debian's postinst
<tepsipakki> sure
<cjwatson> but yes, we should follow that change, imo
<cjwatson> 'cos then I can remove *our* gross hacks in tasksel
<tepsipakki> Ok, I'll do that after lunch.. my fingers are freezing which means that they scream for energy ;)
<tepsipakki> bbl ->
<jcristau> cjwatson: joeyh really pushed for that change :)
<cjwatson> don't blame him
<cjwatson> s/^/I /
<Ubugtu> New bug: #4229 in totem (main) "Totem receives BadAlloc when playing very large movies using Xv (dup-of: 35229)" [Medium,Confirmed]  https://launchpad.net/bugs/4229
<Hobbsee> tepsipakki: good point. 
<tepsipakki> hah
<tepsipakki> welcome
<tepsipakki> :)
<Hobbsee> :)
* Hobbsee doenst know much about X, but likes lurkign.  except that hardlocking is bad, of course
<Ubugtu> New bug: #33753 in gnome-screensaver "don't use OpenGL savers if no hardware support" [Medium,Confirmed]  https://launchpad.net/bugs/33753
<seb128> tepsipakki: ping?
<tepsipakki> pong
<seb128> tepsipakki: libxcb is dep waiting on libpthread-stubs0-dev and required for libx11
<seb128> looking at it
<tepsipakki> still?
<tepsipakki> ok
<tepsipakki> -  db_get debian-installer/language || debug_report_status "db_get debian-installer/language"
<tepsipakki> -  REALLANG=${RET%%:*}
<tepsipakki> -  REALLANG=${REALLANG%%@*}
<tepsipakki> +  REALLANG=${LANG%%@*}
<tepsipakki> hmm
<cjwatson> not sure what stripping :* achieved
<tepsipakki> REALLANG=${REALLANG%%.*} came after that
<cjwatson> that makes more sense
<tepsipakki> but the db_get -stuff.. do I leave it or not
<tepsipakki> I'll leave it for now
<cjwatson> using LANG should be OK I think
<tepsipakki> ok, cleaner that way
<cjwatson> tepsipakki: you are doing a merge from the base version of the merge to Debian's version, not just looking at the diff between Ubuntu and Debian, right?
<cjwatson> i.e. a proper three-way merge
<tepsipakki> no.. diffing latest ubuntu vs latest debian
<tepsipakki> grab-merge doesn't work
<tepsipakki> since xorg isn't in mergers.u.c
<jcristau> where is this debian-installer/language stuff? I don't see it in git
<cjwatson> argh
<cjwatson> you must do a three-way merge
<cjwatson> use snapshot.debian.net
<cjwatson> (to get the base version)
<cjwatson> you can't merge packages sanely without a three-way merge
<cjwatson> it's far too easy to lose stuff by mistake
<jcristau> oh, it's only in ubuntu
<tepsipakki> alright, looking
<tepsipakki> debdiff 7.0.22 - 7.1.1ubuntu8 is a measly 65kB :)
<seb128> tepsipakki: not good, after xcb installation and libx11 upgrade my gnome-session crashes directly
<seb128> gnome-session: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
<jcristau> seb128: there are patches in a few other X libs, did you upgrade them?
<seb128> jcristau: I'm uptodate with feisty
<jcristau> hmm
<seb128> might be that something didn't get synced or didn't build yet
<jcristau> can you get a backtrace?
<seb128> in which case the libx11 Depends needs to enforce the update
<seb128> #1  0xb7661df0 in raise () from /lib/tls/i686/cmov/libc.so.6
<seb128> #2  0xb7663641 in abort () from /lib/tls/i686/cmov/libc.so.6
<seb128> #3  0xb765b43b in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
<seb128> #4  0xb71d4651 in xcb_xlib_unlock () from /usr/lib/libxcb-xlib.so.0
<seb128> #5  0xb79c9bd4 in _XCBUnlockDisplay (dpy=0x8076140) at ../../src/xcb_lock.c:34
<seb128> #6  0xb7ab1601 in XRRQueryVersion () from /usr/lib/libXrandr.so.2
<seb128> #7  0xb7ab1762 in XRRSetScreenConfigAndRate () from /usr/lib/libXrandr.so.2
<seb128> let me install debug packages for it
<tepsipakki> ok, that's strange
<seb128> oh
<jcristau> probably a bug in libxrandr then
<seb128> my GNOME session set an another resolution than the xorg one with xrandr
<seb128> yep
<jcristau> unlockdisplay without holding the lock
<seb128> weird that it's triggered after the libxcb installation or the libx11 upgrade though
<seb128> let me downgrade libx11
<jcristau> looks like #400441
<tepsipakki> indeed
<seb128> ii  libxrandr2                1.1.1-0ubuntu1            X11 RandR extension library
<cjwatson> http://lists.debian.org/debian-devel-announce/2006/11/msg00010.html
<cjwatson> "Both of these represent bugs in a caller of libX11, and *not* in libX11
<cjwatson> or libxcb."
<seb128> I blame libxrandr
<seb128> let's see if 1.1.1 has the pointed patch
<seb128> bah
<seb128> libxrandr 1.1.1 doesn't have the patch
<seb128> tepsipakki: any reason we can't update libxrandr to 1.2.0 now?
<tepsipakki> jcristau: ^^ :)
<seb128> Debian has it
<tepsipakki> was it just released
<jcristau> yes, yesterday or so
<tepsipakki> oh, that old
<jcristau> it needs x11proto 1.2
<jcristau> err
<jcristau> x11proto-randr 1.2
<tepsipakki> maybe it won't break anything
<seb128> x11proto-randr |    1.2.0-1 | http://archive.ubuntu.com feisty/main Sources
<seb128> grumpf
<seb128> 99_configure
<seb128> Applying patches...failed! (check stampdir/log/patch for details)
<seb128> I hate that quilt patch
<seb128> s/patch/bug
<seb128> when there is no patch it tries to apply a 99_configure for whatever reason
<tepsipakki> sih
<seb128> mkdir debian/patches fixes it
<seb128> build new libxrandr
<jcristau> tepsipakki: by the way the server needs a patch in randr/randr.c
<tepsipakki> or run debian/rules prepare?
<cjwatson> jcristau: same as the damage patch?
<jcristau> yeah s/RANDR_MAJOR/1/;s/RANDR_MINOR/1/
<seb128> ok
<seb128> new libxrandr fixes gnome-session for me
<seb128> anybody has an objection with syncing 1.2.0 from Debian now?
<jcristau> libxrandr from experimental is buggy
<jcristau> I forgot to bump the shlibs
<seb128> ah :/
<jcristau> :/
<seb128> ah, only that
<jcristau> yeah
<seb128> I can fix that ;)
<jcristau> as far as I know :)
<seb128> should be safe to update before libx11, mesa, server, etc?
<jcristau> it's fixed in git, I guess I could just upload it
<seb128> would be nice
<seb128> that way we could just sync it
<jcristau> I have crappy uplink, but let's try it
<seb128> libxrandr is quite small
<seb128> especially if you don't have to upload the orig
<seb128> brb, restarting a proper GNOME session
<jcristau> seb128: you can get http://incoming.debian.org/libxrandr_1.2.0-3_i386.changes
<jcristau> should be fine now
<seb128> jcristau: nice, thank you!
<seb128> libxrandr sync done
<tepsipakki> finally.. xorg close to being ready
<tepsipakki> cjwatson: actually, it was a lot easier to merge that way..
<tepsipakki> since there wasn't a lot of upstream changes to distract you
<cjwatson> yeah, it can often be that way
<tepsipakki> I should probably keep the changelog as well
<tepsipakki> easy
<tepsipakki> ok, xorg is now in http://users.tkk.fi/~tjaalton/xorg/new
<tepsipakki> and also on my repository
<tepsipakki> tested it and it installed fine, but I guess it should
<tepsipakki> 've updated the xorg.conf font-paths
<tepsipakki> which it didn't do
<tepsipakki> ah
<tepsipakki> if [ -z "$UPGRADE" ]  || dpkg --compare-versions "$2" le "1:7.0.14"; then
<tepsipakki> we might want to bump that
<tepsipakki> but sadly, I need to go now..
<tepsipakki> xorg took longer than expected
<Ubugtu> New bug: #20283 in xserver-xorg-video-ati "[fgl v5000]  really bad sync" [Medium,Needs info]  https://launchpad.net/bugs/20283
<seb128> tepsipakki: libpthread-stubs has been accepted which should make libxcb build
<Ubugtu> New bug: #27466 in xserver-xorg-video-ati "[radeon]  can't do dual-link tmds, or second tmds transmitter" [Medium,Confirmed]  https://launchpad.net/bugs/27466
<tepsipakki> seb128: phew, progress :)
<seb128> tepsipakki: I think libx11 will be ready to go tomorrow morning
<seb128> I don't want to upload before stopping working today
<tepsipakki> thats fine
<tepsipakki> I packaged a new xorg-server which has a patch that makes it use randr protocol 1.1
<seb128> tepsipakki: why?
<seb128> tepsipakki: we have xrandr 1.2.0 now
<jcristau> seb128: xserver 1.2 doesn't speak randr 1.2
<tepsipakki> but xserver doesn't support that :)
<jcristau> 1.3 will
<tepsipakki> I took the damage-patch approach
<seb128> ah, ok
<tepsipakki> we don't seem to have an operator on this channel
<seb128> do we need one?
<seb128> ah, to set topic?
<tepsipakki> the url to my repo could be on topic
<tepsipakki> yes
<jcristau> the channel doesn't seem to be +t?
<Ubugtu> New bug: #85811 in xorg (main) "[Feisty-Herd4-alternate-amd64]  Cannot change screen resolution at installation time" [Undecided,Confirmed]  https://launchpad.net/bugs/85811
<seb128> tepsipakki, jcristau: can mesa be updated before libx11?
<jcristau> yes
<seb128> ok
<seb128> compiz just crash now
<jcristau> heh :)
<seb128> #3  0xb7cb343b in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
<seb128> #4  0xb7c5f651 in xcb_xlib_unlock () from /usr/lib/libxcb-xlib.so.0
<seb128> #5  0xb7eabbd4 in _XCBUnlockDisplay (dpy=0x8075388) at ../../src/xcb_lock.c:34
<seb128> #6  0xb7e13475 in __glXInitialize () from /usr/lib/libGL.so.1
<seb128> I think that's the same lock problem than libxrandr
<seb128> just for libgl
<jcristau> hmm, I'll have a look at mesa 6.5.2
<jcristau> seb128: that's probably fixed in 6.5.2, there are a number of fixes that seem related
<seb128> good
<seb128> that's next on the updates list then ;)
<jcristau> maybe https://bugs.freedesktop.org/show_bug.cgi?id=8521
<Ubugtu> Freedesktop bug 8521 in GLX "AllocAndFetchScreenConfigs unlocks twice" [Normal,Resolved: fixed]  
<jcristau> I wonder if xlib/xcb should conflict with previous versions of libs that have known locking bugs
<seb128> probably yep
<seb128> because otherwise it just breaks lot of things for people doing partial upgrades
<seb128> like the libxrandr bug broke gnome-session on my desktop
<jcristau> or is that a use case for Breaks?
<seb128> it's an usecase for Breaks
<seb128> but is Debian use Breaks yet?
<cjwatson> almost every use of Conflicts << is a use case for Breaks ;-)
<cjwatson> indeed, Breaks can't be deployed in Debian yet AFAIK
<cjwatson> talk to iwj ...
<Ubugtu> New bug: #86550 in xorg (main) "Video card no longer supported by Ubuntu" [Undecided,Needs info]  https://launchpad.net/bugs/86550
<Ubugtu> New bug: #86301 in xorg (main) "Feature Request: Dynamic head configuration in X.org" [Undecided,Unconfirmed]  https://launchpad.net/bugs/86301
<Ubugtu> New bug: #85451 in Ubuntu "Switch tty, shutdown, reboot cause colorful screen with Nvidia proprietary driver (dup-of: 63558)" [Undecided,Needs info]  https://launchpad.net/bugs/85451
<tepsipakki> jcristau: so, xserver 1.3 will be mostly a bugfix-release, and not targeted for 7.3?
<tepsipakki> reading http://wiki.x.org/wiki/XDC2007Notes
<jcristau> err
<tepsipakki> updates to the protocols yes.. can't blame that being just bugfixing :)
<jcristau> maybe if you count output-hotplug (randr 1.2) as bugfixing
<jcristau> :)
<jcristau> I think keithp wants to release 1.3 next week or so
<tepsipakki> so I've heard too
<seb128> tepsipakki: did you work on the mesa update yet?
<tepsipakki> seb128: it's in the same place as the rest
<seb128> ok
<seb128> can it be uploaded next?
<tepsipakki> http://users.tkk.fi/~tjaalton/xorg72/new
<tepsipakki> hell, why not :)
<seb128> just making sure if you consider it ready before looking at it
<tepsipakki> well, the changelog seems funny
<tepsipakki> need to fix it
<seb128> looks fine to me
<tepsipakki> the one in diff.gz isn't ;)
<seb128> I'll do mesa next tomorrow morning if nobody has an objection
<seb128> I looked at the .changes for the moment :p
<seb128> mesa needs to go before libx11
<tepsipakki> that sounds ok for me
<tepsipakki> oh it does?
<seb128> did you read what I wrote like an hour ago?
<tepsipakki> ah, you mean the libxcb breakage?
<seb128> right
<seb128> it's not libxcb which is broken though
<tepsipakki> right
<seb128> it's other packages
<seb128> and the mesa bug makes compiz crash after libx11 update
<seb128> so better to get the mesa update done first
<tepsipakki> yep
<seb128> ok, anyway enough work for today, I'll build mesa locally, install it and we will see for the upload tomorrow morning if it doesn't break half of my desktop ;)
<tepsipakki> you can delete the ubuntu0.1 part of the changelog while you're at it :)
<seb128> ok
<seb128> did you build it?
<tepsipakki> yes, it
<tepsipakki> damn
<seb128> it refuses to build due Maintainer not changer
<seb128> changed
<seb128> just wondering :p
<tepsipakki> oh
<tepsipakki> well maybe it was with older tools
<tepsipakki> a week ago or something
<seb128> ok, building now
<tepsipakki> it takes ~1h with my laptop
<seb128> we will see how it works
<tepsipakki> so didn't bother building it too often
<seb128> I'll tell you that tomorrow morning
<seb128> right
<tepsipakki> sure, g'night
<seb128> 'night
#ubuntu-x 2007-02-21
<Ubugtu> New bug: #36550 in xserver-xorg-video-i810 "[i855]  Clone Mode makes external display very blurry/wobbly" [Medium,Confirmed]  https://launchpad.net/bugs/36550
<Ubugtu> New bug: #86617 in xserver-xorg-video-nv (main) "2d sluggishness with 'nv' driver" [Undecided,Unconfirmed]  https://launchpad.net/bugs/86617
<Ubugtu> New bug: #28326 in xserver-xorg-video-i810 "i810 Xv crashes after suspend -> infinite resprawn" [High,Confirmed]  https://launchpad.net/bugs/28326
<tepsipakki> sigh
<tepsipakki> we have some network issues right now, can't push newer versions on my wwwhome
<tepsipakki> ok, new xorg_7.2-0ubuntu0.2 in http://users.tkk.fi/~tjaalton/xorg72/new
<tepsipakki> it will mangle the xorg.conf if the previous version is lt 1:7.2
<tepsipakki> oh, hi seb128 
<seb128> hey tepsipakki
<tepsipakki> damn, load-balancers are still f*cked up, so our www-servers are s-l-o-w
<tepsipakki> seb128: I just put xorg_7.2-0ubuntu0.2 in my new-dir
<seb128> I'll start with mesa
<seb128> and then libx11
<tepsipakki> yeah
<tepsipakki> what arguments are given to postinst on upgrade?
<tepsipakki> on package upgrade
<jcristau> in general, <postinst> "configure" <old-version>
<tepsipakki> right
<jcristau> policy, section 6.5 :)
<tepsipakki> I've printed it, but not at hand right now :)
<tepsipakki> I wonder why the xserver-xorg postinst doesn't change the font paths
<tepsipakki> if [ -z "$UPGRADE" ]  || dpkg --compare-versions "$2" le "1:7.2"; then
<tepsipakki> hmm
<tepsipakki> oh bugger
<tepsipakki> of course it didn't, since the old one was 7.2
<tepsipakki> already
<jcristau> heh
<tepsipakki> silly me
<tepsipakki> oh man, I'm blind
<tepsipakki> the font-path stuff in xserver-xorg.postinst.. it's commented out
<tepsipakki> and again
<tepsipakki> I just can't read sed :)
<jcristau> that sed expression is pretty fun
<tepsipakki> it should be ok, but there's something wrong with it or my conf, since the paths aren't changed
<tepsipakki> seb128: I'm offline again for the next five hours or so
<seb128> tepsipakki: ok, what should be uploaded next? libx11?
<seb128> do you consider it ready?
<tepsipakki> when mesa is ready
<tepsipakki> yes
<tepsipakki> xft can be synced as well
<seb128> I've uploaded mesa already
<seb128> ok
<tepsipakki> note that xft is/was libxft in ubuntu
<seb128> source package name change?
<seb128> ok, will have a look to that
<tepsipakki> yes
<jcristau> the source package was already "xft" in sarge :)
<tepsipakki> renamed for ubuntu for some reason..
<seb128> jcristau: any idea of why xorg team packages use quilt? ;)
<jcristau> the decision was taken in http://lists.debian.org/debian-x/2005/06/msg00061.html
<jcristau> with discussion earlier that year
<seb128> ok, thank you, maybe I'll read that
<seb128> I find it really annoying to use and I'm curious to know why people inflict that themself :p
<jcristau> what would you use?
<seb128> dpatch
<jcristau> heh, I find quilt a lot better :)
<seb128> it's so complicated to create a patch with it
<seb128> where dpatch or simple-patchsys just have one edit patch command
<jcristau> because you need to add each patched file individually?
<seb128> yep
<seb128> I'm trying to do an autoreconf patch
<seb128> and I don't fancy adding a zillion of autogenerated files to the list
<seb128> where I could a dpatch-edit-patch, run autoreconf and ctrl-D
<kylem> seb128, just cp the trees, run autoreconf, diff them, and plop it in patches/
<seb128> kylem: I just converted the debian/rules to cdbs with simple-patchsys and used cdbs-edit-patch
<kylem> it sucks, but it's effectively what dpatch would do.
<kylem> i hope you're the original-maintianer. ;-)
<seb128> for Ubuntu I am
<seb128> or sort of, it's compiz
<jcristau> keeping the autoreconf stuff in patches is a pain
<jcristau> so we just don't do it :)
<seb128> I'll not keep the debian/rules to cdbs though, that was just to be able to use cdbs-edit-patch
<seb128> jcristau: better than running autotools at package build imho ;)
<jcristau> debian/rules patch; autoreconf; fakeroot debian/rules clean; git-commit -a
<jcristau> works fine :)
<seb128> if you use git probably ;)
<jcristau> well, replace that with $scm commit
<Ubugtu> New bug: #47885 in xserver-xorg-video-ati (main) "Mouse cursor 'sticks' on screen 2 of dual head display" [Medium,Needs info]  https://launchpad.net/bugs/47885
<Ubugtu> New bug: #86753 in xorg-server (main) "Xorg Freezes on VT Switching in an AiGLX session" [Undecided,Unconfirmed]  https://launchpad.net/bugs/86753
<Ubugtu> New bug: #85766 in xorg (main) "mouse doesn't work in Warow any more" [Undecided,Unconfirmed]  https://launchpad.net/bugs/85766
<Ubugtu> New bug: #86841 in libxrandr (main) "beryl does not refresh content of windows" [Undecided,Unconfirmed]  https://launchpad.net/bugs/86841
<tepsipakki> that bug 86841 is real
<Ubugtu> Malone bug 86841 in libxrandr "beryl does not refresh content of windows" [Low,Rejected]  https://launchpad.net/bugs/86841
<tepsipakki> oh, rejected already
<tepsipakki> same in compiz
<tepsipakki> s/in/with/
<seb128> tepsipakki: is that a compiz, beryl problem or an xorg one?
<Ubugtu> New bug: #21265 in Ubuntu "Error activating XKB configuration. (dup-of: 21595)" [Medium,Rejected]  https://launchpad.net/bugs/21265
<seb128> tepsipakki: libx11 looks good, I'll upload tomorrow morning
<seb128> I would upload now but I want to be around it something breaks
<seb128> anything else that can be updated before the server?
<tepsipakki> xft
<tepsipakki> seb128: I haven't been able to run compiz before, so can't tell what makes it behave like that, but it someone else is seeing it..
<tepsipakki> s/it/if/
<Ubugtu> New bug: #86592 in xorg (main) "Live CD Installer causes screen to turn off when X starts" [Undecided,Unconfirmed]  https://launchpad.net/bugs/86592
<Ubugtu> New bug: #86870 in mesa (main) "/usr/lib/dri/i915_dri.so missing (feisty)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/86870
<Ubugtu> New bug: #71094 in xorg (main) "Colour depth problem on one display following upgrade to edgy" [Undecided,Unconfirmed]  https://launchpad.net/bugs/71094
<Ubugtu> New bug: #86881 in xorg (main) "X shuts down at various occasions" [Undecided,Unconfirmed]  https://launchpad.net/bugs/86881
<Ubugtu> New bug: #85081 in xorg (main) "Dual head broken in Feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/85081
#ubuntu-x 2007-02-22
<Ubugtu> New bug: #86890 in xorg (main) "X Dies Automatically On Boot" [Undecided,Unconfirmed]  https://launchpad.net/bugs/86890
<Ubugtu> New bug: #86904 in xmodmap (main) "xmodmap doesn't work in feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/86904
<tepsipakki> kylem: there's a bug on xorg which claims that the intel-drivers need new drm-stuff in kernel.. let me dig it
<tepsipakki> oh, it was here: https://launchpad.net/bugs/84731
<Ubugtu> Malone bug 84731 in xorg "Syncing and merging X.org 7.2" [Undecided,Unconfirmed]  
<tepsipakki> I'll take this to #ubuntu-kernel ->
<Ubugtu> New bug: #80890 in linux-restricted-modules-2.6.17 (restricted) "[Edgy]  Some Spanish chars doesn't look well in console when using nVidia closed-source Xorg video drivers" [Undecided,Needs info]  https://launchpad.net/bugs/80890
<Ubugtu> New bug: #86977 in xorg (main) "Xorg constantly uses 25% CPU time" [Undecided,Unconfirmed]  https://launchpad.net/bugs/86977
<seb128> tepsipakki: ping?
<tepsipakki> pong
<seb128> hi ;)
<tepsipakki> good morning!
<seb128> tepsipakki: so we are ready for libx11? ;)
<seb128> i reviewed the merge and it looks fine and the update works fine on my desktop
<tepsipakki> I guess so, but before we do that.. something has broke xmodmap, claims elmo
<seb128> so I'm ready to upload it if nobody has an objection
<seb128> yeah, I've read the bug yesterday
<tepsipakki> maybe it shouldn't slow us down
<seb128> nop, holding libx11 will not fix it
<tepsipakki> true
<tepsipakki> so, go for it
<seb128> is xmodmap broken for you as well?
<tepsipakki> yes, but maybe I need to confirm that on another machine and track it down
<tepsipakki> in GNOME I have US layout
<tepsipakki> when it should be Finnish
<tepsipakki> duh, works on a clean feisty
<Ubugtu> New bug: #86991 in xorg (main) "no dri for the second display (e.g. user switch)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/86991
<Ubugtu> New bug: #86997 in gnome-session (main) "[apport]  gnome-session crashed with SIGSEGV (dup-of: 81620)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/86997
<tepsipakki> heh
<tepsipakki> dpkg-gencontrol: warning: unknown substitution variable ${F:XServer-Xorg-Detect-Depends}
<tepsipakki> with the old version of xorg as well
<tepsipakki> but because xserver-xorg Recommends: laptop-detect, xresprobe, mdetect, discover1 | discover, things have worked
<tepsipakki> xorg is looking better all the time
<tepsipakki> finally..
<tepsipakki> I'll put the link usr/share/X11/fonts -> usr/share/fonts/X11 in xserver-xorg
<tepsipakki> seb128: alright, should we push xft next?
<seb128> tepsipakki: looks like a good idea, I need to look at that package name difference though, if we did rename it that's probably for a reason
<tepsipakki> funny that there is xft-2.1.10 in the archive
<tepsipakki> * Repackaged to fit all the other X packages.
<tepsipakki> that's all there is
<tepsipakki> regarding the rename
<seb128> ah ok
<cjwatson> I think Debian renamed it rather than us
<jcristau> cjwatson: it's named xft in sarge
<jcristau> daniels probably renamed it when he packaged modular to match the upstream name
<tepsipakki> yes, it seems to have been like that since 2002
<tepsipakki> probably
<cjwatson> mm, could be
<seb128> tepsipakki: we have an xft source package
<seb128> which is 2.1.10
<cjwatson> and also libxft in universe; looks like somebody forgot to blacklist it
<seb128> cjwatson: blacklist? it doesn't seem to come from Debian, that's rather a leftover which has not been cleaned no?
<tepsipakki> ok, maybe I need to take a closer look
<cjwatson> hmm, could be, the history looks very confused
<cjwatson> or at least confusing
<seb128> tepsipakki: for me it looks like xft can be simply synced no?
<tepsipakki> seb128: I think so, but to be sure..
<tepsipakki> where was the package cache again?
<seb128> the only change is the versionning of the Build-Depends on libfontconfig1-dev and libfreetype6-dev
<seb128> I'm not sure of why that was useful
<seb128> tepsipakki: what package cache?
<tepsipakki> seb128: nevermind, if you found out the diff already :)
<tepsipakki> I would've compared it to 2.1.10-1
<tepsipakki>   * Add build-dep on freetype 2.2.1 to force correct buildd queue ordering.
<tepsipakki>   * Ditto for fontconfig 2.3.2-6
<tepsipakki> maybe that?
<tepsipakki> it might not need it anymore
<seb128> I don't really get how versionning the Build-Deps force the buildd queur ordering
<tepsipakki> ask Mithrandir :)
<seb128> there is only one libfreetype6-dev to the archive no?
<tepsipakki> just sync it and we'll see how it goes
<cjwatson> doesn't force queue ordering, but it does mean that it won't build successfully until a suitable version is there ...
<cjwatson> but that sort of thing is usually only of historical interest if it's old
<seb128> tepsipakki: building locally, I want to try if it works fine first
<tepsipakki> seb128: ok
<seb128> tepsipakki: what is next then, the server?
<tepsipakki> with xorg, yes
<tepsipakki> I've cleaned xorg a bit
<seb128> that will be the tricky part
<seb128> do you have the server ready or are you still working on it?
<tepsipakki> there was this dh_gencontrol-trickery to put XSERVER_DETECT_DEPENDS-stuff in Depends:
<tepsipakki> which didn't work anyway
<tepsipakki> so I just put "dmidecode [amd64,i386,ia64] , fbset [hppa] " to Recommends: instead
<tepsipakki> seb128: server is ready
<tepsipakki> it's at -3ubuntu1
<tepsipakki> and while there is -4 available, I don't think it is meant for us
<tepsipakki> hm
<tepsipakki> the policy-manual isn't helping.. so how do I specify multiple architecture to package Depends?
<tepsipakki> this doesn't work: "dmidecode [amd64,i386,ia64] "
<jcristau> tepsipakki: in an arch:all package, you can't do that
<tepsipakki> gar
<jcristau> see the dependency on sparc-utils
<jcristau> for a workaround
<tepsipakki> yes, saw that
<tepsipakki> but again, how to specify it to more than one arch?-)
<seb128> [amd64 i386] 
<cjwatson> that only works for build-depends
<cjwatson> and build-depends-indep
<seb128> ah, right, didn't read the question properly
<cjwatson> for run-time relationship fields, you have to use substvars (the dh_gencontrol trickery you mentioned)
<tepsipakki> but it wasn't used for xserver-xorg, only x11-common which didn't need it
<cjwatson> due to the architecture: all issue, I'm coming to believe that this is a deficiency in dpkg, but nevertheless, it's reality
<tepsipakki> look at xserver-xorg Depends for a good laugh :)
<tepsipakki> (they are not there
<tepsipakki> +)
<tepsipakki> but because the packages are installed by other dependencies things have just worked despite that
<tepsipakki> bah, I'll just move the trickery to binary-indep: so that xserver-xorg gets it
<cjwatson> ah, that would do it
<tepsipakki> ok, new xorg for review
<tepsipakki> http://users.tkk.fi/~tjaalton/xorg72/new
<seb128> hum, linux 2.6.20 is not happy with my network card every now and then
<seb128> tepsipakki: I was saying that libxft looks good and I'm going to sync it now (dunno if IRC got that before network broke)
<tepsipakki> nope, it was lost :)
<seb128> tepsipakki: sync done now
<tepsipakki> nice
<tepsipakki> so, xorg-server and xorg needs reviewing
<seb128> those will require quite some works and I've other things I want to sort first
<tepsipakki> sure
<seb128> if anybody wants to start looking at them he's welcome though ;)
<tepsipakki> maybe I'll ask -devel
<seb128> feel free
<Ubugtu> New bug: #87035 in gnome-terminal (main) "Ctrl-Z shrinks window with Dvorak keyboard layout (dup-of: 23244)" [Medium,Rejected]  https://launchpad.net/bugs/87035
<Ubugtu> New bug: #87081 in xorg (main) "[feisty]  latest update breaks beryl" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87081
<seb128> grumpf beryl :p
<Ubugtu> New bug: #87092 in xmodmap (main) "man xmodmap gives wrong location for keysym database" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87092
<jcristau> tepsipakki: you might be interested in https://bugs.freedesktop.org/show_bug.cgi?id=10046
<Ubugtu> Freedesktop bug 10046 in Lib/other "libXrandr-1.2.0 makes use of the delete C++ keyword, breaking compiling with C++ applications" [Normal,Resolved: fixed]  
<Ubugtu> New bug: #87175 in linux-restricted-modules-2.6.17 (restricted) "totem segfaults with xinerama and nvidia" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87175
<tepsipakki> jcristau: thanks, definately useful
<Ubugtu> New bug: #47447 in xserver-xorg-video-ati (main) "3D screen saver crashes system" [Medium,Confirmed]  https://launchpad.net/bugs/47447
<Ubugtu> New bug: #87201 in xserver-xorg-video-i810 (main) "Changing brightness under lowest value restarts X" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87201
<Ubugtu> New bug: #46700 in xorg (main) "xorg.conf - synaptics touchpad misdetected?" [Medium,Needs info]  https://launchpad.net/bugs/46700
#ubuntu-x 2007-02-23
<kylem> tepsipakki, looked over the xserver debdiff, looks good.
<tepsipakki> thanks!
<tepsipakki> it's not that big either
<tepsipakki> but the xorg.debdiff is huge because of po/*
<kylem> indeed.
<tepsipakki> maybe I should filter that out to make reviewing easier..
<kylem> s'ok, i can filterdiff
<kylem> :)
<tepsipakki> filterdiff.. now there's a tool I've missed
<tepsipakki> and didn't know about :P
<tepsipakki> sheesh
<kylem> :)
<kylem> makes life easy
<tepsipakki> slightly, yes
<kylem> will take me a while to look over xorg debdiff.
<tepsipakki> of course
<tepsipakki> put a new diff without the po-stuff
<tepsipakki> for other potential reviewers
<tepsipakki> but now it's time to hit the sack
<tepsipakki> night and happy reviewing :)
<kylem> xorg packages looks fine as well.
<Ubugtu> New bug: #87245 in libx11 (main) "upgrade in libX11 causes azureus crash" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87245
<Ubugtu> New bug: #51991 in xorg (main) "Xorg process freezes, uses 100% of CPU. Can be killed by remote terminal." [Undecided,Confirmed]  https://launchpad.net/bugs/51991
<tepsipakki> kylem: whoa, thanks!
<tepsipakki> hey seb128 
<tepsipakki> kylem reviewed both xorg-server and xorg last night
<seb128> hi
<seb128> excellent
<seb128> and what did he say? ready to go? did he upload?
<tepsipakki> didn't upload, said they looked fine
<seb128> ok, good
<seb128> did you ask him to upload?
<seb128> kylem: ping? (he's probably sleep atm)
<tepsipakki> no, since I went to bed :)
<seb128> k, I'll have an another look on the server and upload then
<tepsipakki> I need to make a final version of xorg so it can be uploaded
<jcristau> seb128: you can sync libxrandr from experimental again :)
<tepsipakki> ah, indedd
<tepsipakki> s/ed/ee/
<tepsipakki> thogh pitti said that the new version wasn't on the mirror he syncs from
<tepsipakki> and, we already have a version with the patch :) (or part of it)
<jcristau> ah, ok
<jcristau> I didn't know that
<tepsipakki> it was uploaded last night
<tepsipakki> by someone
<jcristau> yeah, he sent a mail to debian-x too
<seb128> jcristau: good
<tepsipakki> seb128: where do you pull your syncs from?
<seb128> tepsipakki: Debian
<seb128> we might want to have at look at that libxrender patch: https://bugs.freedesktop.org/show_bug.cgi?id=9526
<Ubugtu> Freedesktop bug 9526 in Lib/Xrender "Length field in create gradient requests is not set correctly" [Major,New]  
<seb128> pointed by somebody working on compiz
<tepsipakki> seb128: from ftp.debian.org?
<tepsipakki> the new version is there, don't know where pitti looked
<seb128> tepsipakki: 
<seb128> ../../randr/randr.c: In function 'ProcRRQueryVersion':
<seb128> ../../randr/randr.c:482: error: 'SERVER_RANDR_MAJOR' undeclared (first use in this function)
<seb128> ../../randr/randr.c:482: error: (Each undeclared identifier is reported only once
<seb128> ../../randr/randr.c:482: error: for each function it appears in.)
<seb128> ../../randr/randr.c:483: error: 'SERVER_RANDR_MINOR' undeclared (first use in this function)
<seb128> 
<seb128> while trying to build the new xorg-server on my feisty desktop
<jcristau> replace them with 1 and 1 :)
<seb128> ?
<seb128> should they be declared by libxrandr?
<jcristau> no
<jcristau> that's only in the server
<seb128> tepsipakki: how come it built for you?
<seb128> or you didn't try to build it? ;)
<tepsipakki> hmm
<tepsipakki> I'll check in a moment
<tepsipakki> haha
<tepsipakki> I suck
<tepsipakki> I was being too clever with the patch
<tepsipakki> ..which was copypasted from the damage-patch
<tepsipakki> partly
<tepsipakki> so SERVER_RANDR_{MAJOR,MINOR} were not declared, insted *DAMAGE* :)
<seb128> you didn't even try to build the package then? ;)
<Ubugtu> New bug: #44878 in linux-restricted-modules-2.6.15 (restricted) "firefox & epiphany restart gdm" [Medium,Unconfirmed]  https://launchpad.net/bugs/44878
<tepsipakki> no, since that was the only change after my builds..
<tepsipakki> I'll roll up a new one
<seb128> ok, thank you
<tepsipakki> it's there
<seb128> tepsipakki: building
<tepsipakki> it took 17min on my laptop
<seb128> tepsipakki: updating the server alone is fine, right?
<seb128> no need to update xorg in the same time?
<tepsipakki> well, there is the fontpath issue
<seb128> what fontpath?
<tepsipakki> at least binary nvidia can't cope with the old config unless we provide a symlink to the new location
<tepsipakki> and xorg has that (xserver-xorg)
<seb128> oh, that's not good
<tepsipakki>   * debian/xserver-xorg.links:
<tepsipakki>     - ship a symlink "usr/share/X11/fonts -> usr/share/fonts/X11".
<tepsipakki> I think the right place for it is in xorg
<tepsipakki> so, maybe xorg should go _before_
<seb128> can we get a minor revision update doing just that first?
<seb128> then update the server
<seb128> and then look at the xorg merge
<tepsipakki> yes, that would be fine
<pitti> hi
<seb128> hi pitti
<seb128> <tepsipakki>   * debian/xserver-xorg.links:
<seb128>      - ship a symlink "usr/share/X11/fonts -> usr/share/fonts/X11".
<seb128>  I think the right place for it is in xorg
<seb128>  so, maybe xorg should go _before_
<seb128> 
<seb128> we are discussing that
<seb128> that symlinks needs to go before the server update
<seb128> so
<seb128> - either we upload xorg first and then the server
<seb128> - or we do a minor xorg revision just for that symlink, then update the server and deal with the xorg then
<seb128> any opinion?
<pitti> seb128: if it is beneficial to test the new xorg-server without the new xorg, then a separate upload would indeed make sense
<seb128> the 1st option might be the efficient one, I'm not that comfortable doing the xorg update though, that looks like the tricky part
<pitti> seb128: but do you really think it is hard to tell apart bugs in xorg from those in the new server?
<seb128> let me have a look at the xorg changes
<pitti> ah, I see
<seb128> I'm just scared by it
<pitti> well, option 2 can't hurt
<tepsipakki> actually xorg is tricky mostly for new installations or reconfigurations, shouldn't do much on updates AIUI
<seb128> if somebody else is wanting to have an another look on xorg we can probably go forward and that one done
<pitti> we should just make sure then that the new server conflicts to the older xorgs
<tepsipakki> seb128: I'm just about to do -0ubuntu1 of it
<seb128> tepsipakki: xorg?
<tepsipakki> which only has a reorganized changelog
<tepsipakki> yes
<pitti> as I already said, I doubt that xorg can be verified just by eyeballing
<pitti> maybe we should just do it ASAP and invest more time in testing the daily ISOs
<seb128> should we just try it on a few boxes and go ahead then?
<pitti> that might in fact make more sense
<pitti> seb128: I'm happy to test an xorg upgrade right now; I just can't test a server upgrade, because I'm on ISDN
<seb128> I would like to hear from cjwatson before going on with that one though
<pitti> seb128: right, or Tollef as RM
<seb128> pitti: ok, let's do that then
<seb128> cjwatson: around?
<pitti> seb128, tepsipakki: do we have a debdiff between current and new xorg somewhere?
<tepsipakki> pitti: not yet, I'll generate one in a minute
<cjwatson> seb128: yes - but from the sound of things, I'd say go for it; I'm not hearing anything that suggests we should be *particularly* concerned, nor that we couldn't fix it up after the fact
<pitti> tepsipakki: I'm happy to eyeball that diff for any obvious things that jump on me; that's the one that will show us what changes
<seb128> cjwatson: ok, so let's start with the xorg update, I'll test it and pitti is wanting to give it a try as well
<seb128> kylem had a look as well
<seb128> if there is no major problem let's upload it
<tepsipakki> give me 5min to finalize the changelog :)
<tepsipakki> hm, now I get gettext errors from debconf-updatepo
<tepsipakki> while building the source
<tepsipakki> this is a dapper box where I'm building it
<cjwatson> you probably want to build on something more current, as the line numbers generated by po-debconf have changed since then, and you'll end up with a huge diff
<cjwatson> (ideally, avoid running debconf-updatepo at all, though ...)
<tepsipakki> yep, I'll copy it to a feisty box
<tepsipakki> hrmh
<tepsipakki> now it expects to find an .orig.tar.gz
<tepsipakki> on feisty
<tepsipakki> and gettext complains as on dapper
<tepsipakki> /usr/bin/xgettext: warning: file `at' extension `' is unknown; will try C
<tepsipakki> /usr/bin/xgettext: error while opening "at" for reading: No such file or directory
<tepsipakki> thank god I had old version available..
<tepsipakki> a rollback solved it
<tepsipakki> ha
<tepsipakki> changing the maintainer-fields is what broke it
<tepsipakki> and if I put '@' instead of 'at' it stops complaining, how logical
<tepsipakki> so, which is it, do I ignore the error or change the email address to a valid one
<tepsipakki> ?
<tepsipakki> I'll just ignore it for now
<cjwatson> as in Maintainer vs. XSBC-Original-Maintainer in debian/control?
<tepsipakki> yes, "ubuntu-devel-discuss at lists.ubuntu.com" doesn't work right
<tepsipakki> xgettext doesn't like 'at'
<cjwatson> you definitely mustn't spam-obfuscate Maintainer in debian/control.
<cjwatson> yes, use @
<tepsipakki> ok, it's just used already :)
<tepsipakki> oh wait
<tepsipakki> maybe I copied it from an email
<tepsipakki> duh
<tepsipakki> ok, new and hopefully final version of xorg now at the same place as usual
<tepsipakki> with debdiffs
<tepsipakki> against debian and current ubuntu
<tepsipakki> I have a birthday party to attend to (on a ferry :), so I won't be around much longer..
<tepsipakki> so if xorg/xorg-server are going to be pushed today, I won't be online to work on the bugs until Saturday evening
<tepsipakki> not that there should be any, of course :)
<seb128> tepsipakki: ok, thank you for your work, I'll have a look on xorg now and upload if it looks fine
<tepsipakki> great, thanks!
<tepsipakki> I'm off now ->
<seb128> have fun
<tepsipakki> I sure will ;)
<seb128> I'll probably not do IRC during the WE but I read mails every now and then
<seb128> feel free to drop a mail if anything should be fixed
<tepsipakki> ok
<seb128> tepsipakki: still around?
<seb128> xserver-xorg Depends: xserver-xorg-core (>= 2:1.1.1-11)
<seb128> +# versioned dependency on xserver-xorg-core needed because xserver-xorg
<seb128> +# contains a symlink to the reportbug script shipped in that package starting
<seb128> +# with 2:1.1.1-11
<seb128> 
<seb128> that can probably be relaxed
<cjwatson> seb128: oh, there's one other bug fix I'd like to slot into xorg, if I have time
<cjwatson> just a keyboard map thing
<seb128> cjwatson: sure
<seb128> I've just installed the xorg update on my desktop (without type-handling)
<seb128> I'll do some testing with it now and then ask to pitti and other guys who wants to give it a try before upload
<seb128> let me know if you have a patch, I'll update my build (which is on http://people.ubuntu.com/~seb128/xorg) with it
<cjwatson> seb128: http://paste.ubuntu-nl.org/7210/
<cjwatson> I've a corresponding console-setup update on my disk, but it's not critical that they match up exactly
<kylem> how close are we to drivers? i can pretty easily review a few of those.
<seb128> kylem: drivers for next week probably
<kylem> ok.
<seb128> we are very close for xorg
<seb128> maybe server today
<kylem> (i have a selfish interest, -i810 isn't working horribly well on my crestline, need newer drivers.)
<seb128> you can probably start on driver after the server update if you want
<kylem> ok.
<seb128> kylem: how much did you review xorg and xorg-server yesterday?
<kylem> i looked over the debdiff rather thoroughly (i thought) but i didn't get an opportunity to test them. can do that this morning if you'd like
<seb128> testing is welcome
<seb128> http://people.ubuntu.com/~seb128/xorg
<seb128> xorg upload candidate, source and i386 binaries
<seb128> if you want to give it a try
<kylem> ok, i'll have to rebuild for amd64.
<kylem> i'll kick that off in a few mins.
<seb128> it's like 40 seconds to build
<kylem> hehe.
<cjwatson> the hardest test will be whether the installer still works :)
<seb128> right
<cjwatson> but it's too painful to try to test that before upload with something this size
<seb128> brb, trying the update
<seb128> ok, looks like the update doesn't break the world on update
<seb128> somebody else wants to test the update?
<Ubugtu> New bug: #21817 in xorg-server (main) "xnest: can't type control characters in Xnest clients" [Low,Unconfirmed]  https://launchpad.net/bugs/21817
<seb128> ok
<seb128> xorg update works fine for me and dholbach and not real reason to break upgrades and we can sort new install when people send bugs about them
<seb128> anybody has a reason to not upload it? otherwise I'll do that now ;)
<seb128> ok, uploading
<seb128> hum
<seb128> the xorg-server update is weird
<seb128> there is a bunch of binaries like scanpci not installed to any deb
<Ubugtu> New bug: #87244 in xorg (main) "ati driver crashes X on MacBook Pro" [Undecided,Needs info]  https://launchpad.net/bugs/87244
<Ubugtu> New bug: #38939 in xorg (main) "MPlayer receives BadAlloc when playing very large movies using Xv" [Medium,Confirmed]  https://launchpad.net/bugs/38939
<Ubugtu> New bug: #49360 in xserver-xorg-video-i810 (main) "BadAlloc error when playing a video with xv" [Low,Confirmed]  https://launchpad.net/bugs/49360
<Ubugtu> New bug: #52490 in xorg (main) "Xorg can't handle large XV buffers  (badalloc) (dup-of: 49360)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/52490
<Ubugtu> New bug: #86340 in mplayer (multiverse) "Mplayer crash when opening a file (dup-of: 49360)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/86340
<dholbach> hey guys
<dholbach> <dholbach> seb128: no xorg, does not load /usr/lib/xorg/modules/libint10.so
<dholbach>  "no screens"
<dholbach> dholbach it also complained about wacom and dri, so I disabled those, but still no love
<seb128> hi dholbach
<dholbach> does the new xorg-server work for all of you?
<dholbach> i can try on my amd64 too
* dholbach prepares for the worst ;)
<seb128> I'm going to try it now, brb
<dholbach> strange
<dholbach> the amd64 (with nvidia) is happy
<dholbach> hey seb128
<dholbach> how did it go?
<seb128> not really good
<seb128> xorg starts
<seb128> compiz says there is no composite extension though
<seb128> and with standard GNOME switching windows take like 10 seconds
<seb128> with xorg using 99% CPU
<dholbach> urg, so you get that bug now too :-/
<seb128> "too"? I thought it was not starting for you
<dholbach> yeah, but pitti and mvo had the "takes like 10 seconds" problem
<seb128> ho
<seb128> that's not an update bug then?
<seb128> hum
<seb128> how did they fix it?
<dholbach> I think they both used nvidia instead of nv
<dholbach> but there was also slomo having problems
<dholbach> and I think glatzor too
<seb128> I'm using ati
<dholbach> but I might be mistaken
<dholbach> i remember somebody complained about other drivers too
<seb128> nice to see that somebody tried to report or fix the problem :p
<dholbach> :-/
<dholbach> do you need any other info for that i810 does not start problem?
<dholbach> anything I could try to make it work?
<seb128> (II) Loading /usr/lib/xorg/modules//libint10.so
<seb128> dlopen: /usr/lib/xorg/modules//libint10.so: undefined symbol: Int10Current
<seb128> (EE) Failed to load /usr/lib/xorg/modules//libint10.so
<seb128> dholbach: not really, I just know now than the server is no-go today
<dholbach> alright
<dholbach> that's the message I get too
<seb128> the libint10 is not what breaks it though
<seb128> yeah, but it starts for me
<dholbach> weird
<seb128>  you copy you /var/log/Xorg.0.log on p.u.c/~dholbach?
<seb128> in case somebody wants to look at it
<dholbach> http://daniel.holba.ch/temp/Xorg.{,2}0.log.old
<seb128> 96.43% of the time spent to memcpy according to sysprof
<dholbach> weird
<seb128> called by exaCopyDirtyToSys called by exaMoveOutPixmap
<seb128> looks like an EXA problem, I'll try without it
<seb128> brb
<seb128> ok
<seb128> iz EXA bog
<seb128> works fine without it
<dholbach> what is EXA?
<dholbach> apart from buggy? :)
<seb128> and option for the ati driver, I used it because without it compiz had that refreshing problem
<dholbach> hopefully the driver updates will fix that
<seb128> http://en.wikipedia.org/wiki/EXA
<dholbach> aha
<Ubugtu> New bug: #87351 in xorg (main) "Xorg uses 100% CPU" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87351
<dholbach> interesting did we ever ship a kernel named 2.6.18.2?
<seb128> dholbach: no
<dholbach> what I thought - suspicious ;)
<seb128> where did you read about that?
<dholbach> in the bug report that Ubugtu mentioned
<seb128> I call it a week, see you on monday
<pochu> dholbach: aren't you going to reject that bug?
<pochu> hello :)
<dholbach> hi pochu
<dholbach> no, it still might be valid
<dholbach> even if he compiled his own kernel
<pochu> oh, ok
<pochu> I say it because we reject bugs when the user is running beryl :)
<pochu> even if the crash isn't in beryl...
<dholbach> right
<pochu> dholbach: just a little question if you know it: about the current policy, when rejecting a bug, should I also change its importance field, or, as I'm rejecting it, I shouldn't?
<dholbach> it doesn't really matter
<dholbach> you can do as you like
<pochu> dholbach: ok, ty!
<Ubugtu> New bug: #87385 in xorg (main) "xserver-xorg-7.2-0ubuntu1 upgrade causes apps to hang in fontconfig" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87385
<pochu>  Topic: Ubuntu X Development channel only | bug report to LP or ban | request for help in #ubuntu or ban | please drive trough if you are not dealing to help. No we are not nice people here
<pochu> lol
<pochu> nice topic :D
<Ubugtu> New bug: #87390 in libx11 (main) "c->xlib.lock" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87390
<Ubugtu> New bug: #87384 in xorg (main) "3d acceleration does not work on ATI Mobility 9000" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87384
#ubuntu-x 2007-02-24
<Ubugtu> New bug: #36956 in xserver-xorg-video-ati (main) "Brightness reset to max when starting/restarting Xorg or waking from sleep" [Medium,Confirmed]  https://launchpad.net/bugs/36956
<Ubugtu> New bug: #87475 in xorg (main) "x11-common fails to upgrade (Fiesty)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87475
<Ubugtu> New bug: #29975 in xserver-xorg-video-nv (main) "screen distorted when X starts with nv driver" [Medium,Confirmed]  https://launchpad.net/bugs/29975
<Ubugtu> New bug: #87491 in xorg-server (main) "xnest doesn't process mouse movement events correctly" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87491
<Ubugtu> New bug: #34188 in 915resolution (universe) "1.4.1.3-0ubuntu1 ignores DDC information " [Medium,Rejected]  https://launchpad.net/bugs/34188
<Ubugtu> New bug: #87520 in xorg-server (main) "fglrx x server crashes on video overlay initialization" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87520
<Ubugtu> New bug: #87496 in xorg (main) "Not detected nvidia GeForce Go 7400" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87496
<Ubugtu> New bug: #87522 in xorg (main) "nvidia-glx breaks xorg on GeForce Go 7400" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87522
<Ubugtu> New bug: #87531 in xkeyboard-config (main) "Package not translateable in launchpad" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87531
<Ubugtu> New bug: #87532 in xkeyboard-config (main) "Finnish translation for xkeyboard-config" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87532
<kylem> morning.
<Ubugtu> New bug: #41148 in xserver-xorg-video-savage (main) "buggy display of video in totem" [Medium,Unconfirmed]  https://launchpad.net/bugs/41148
<Ubugtu> New bug: #87608 in xorg (main) "ATI 9600XT support with Samsung 192N" [Undecided,Needs info]  https://launchpad.net/bugs/87608
<Ubugtu> New bug: #87549 in xorg (main) "Herd4 startup screen artifacts" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87549
<Ubugtu> New bug: #87530 in xorg (main) "Can't install Feisty Fawn Herd 4, graphic card problem" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87530
#ubuntu-x 2007-02-25
<Ubugtu> New bug: #87713 in libxrandr (main) "libxrandr2 version in feisty makes beryl don't work. Downgrading to edgy's version make the trick" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87713
<Ubugtu> New bug: #87714 in libxrandr (main) "libxrandr2 version in feisty makes beryl don't work. Downgrading to edgy's version make the trick" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87714
<Ubugtu> New bug: #37328 in xserver-xorg-video-savage (main) "IBM T23: resuming from sleep, display is blank or switched to VGA output" [Medium,Unconfirmed]  https://launchpad.net/bugs/37328
<Ubugtu> New bug: #87743 in xkbutils (main) "[apport]  xkbcomp crashed with SIGSEGV in _IO_file_read()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87743
<Ubugtu> New bug: #87744 in xkbutils (main) "[apport]  xkbcomp crashed with SIGSEGV in _IO_file_read()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87744
<Ubugtu> New bug: #87786 in xorg (main) "Choppy xorg after upgrade to xorg 7.2" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87786
<Ubugtu> New bug: #87791 in libx11 (main) "[feisty/x86]  new libX11 with XCB crashes Matlab" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87791
* pochu is going to upgrade to 7.2
<pochu> I have an intel gma, don't know if you have had problems/feedback with it, but sure you will have notices from me :)
<pochu> works really fine :)
<pochu> great job guys!
<Ubugtu> New bug: #15219 in xserver-xorg-video-ati "r100 lockups during/after dri (dup-of: 63503)" [Medium,Confirmed]  https://launchpad.net/bugs/15219
#ubuntu-x 2008-02-18
<ubotu> New bug: #148110 in xserver-xorg-video-intel (main) "compiz opengl rendering artefacts" [Medium,Confirmed] https://launchpad.net/bugs/148110
<ubotu> New bug: #145294 in xserver-xorg-video-intel (main) "Copmiz is incompatible with GL screensaver as desktop background (root window)" [Low,New] https://launchpad.net/bugs/145294
<ubotu> New bug: #177655 in compiz (main) "compiz not starting after upgrading kernel to 2.6.22-14-generic (dup-of: 192253)" [Medium,Incomplete] https://launchpad.net/bugs/177655
<ubotu> New bug: #134446 in linux-restricted-modules-2.6.24 (restricted) "Compiz causing Hard Locks on certain systems" [Undecided,Confirmed] https://launchpad.net/bugs/134446
<ubotu> New bug: #67440 in usplash (main) "edgy: usplash (?) blocks console after kdm shutdown (dup-of: 63558)" [Undecided,Confirmed] https://launchpad.net/bugs/67440
<ubotu> New bug: #192873 in xserver-xorg-video-intel (main) "[915GM] X freezes after resume" [Undecided,New] https://launchpad.net/bugs/192873
<ubotu> New bug: #192881 in linux-restricted-modules-2.6.24 (restricted) "DVB-T with Kernel 2.6.24 do not work" [Undecided,New] https://launchpad.net/bugs/192881
<ubotu> New bug: #192883 in displayconfig-gtk (main) "displayconfig-gtk crashed with AttributeError in isXorgConfigChanged() (dup-of: 192253)" [Undecided,New] https://launchpad.net/bugs/192883
<soren> tjaalton: What happened to my vmware driver patch?
<Q-FUNK> speaking of patches, was bartman's 3rd patch ever merged?
<ubotu> New bug: #186186 in xulrunner-1.9 "web page background render errors" [High,Confirmed] https://launchpad.net/bugs/186186
<tjaalton> soren: sorry, I pushed it to git but didn't apply on our package. will upload it today
<soren> \o/
<ubotu> New bug: #191578 in firefox (main) "[hardy] rendering issues (dup-of: 186186)" [Undecided,New] https://launchpad.net/bugs/191578
<soren> X has died on my 4 times today already. I'm using the Intel driver (intel 945).. Is it known to be jittery?
<tjaalton> i think the drm bits need an update
<tjaalton> should be filed already if I'm not mistaken
<soren> Cool.
<tjaalton> vmware uploaded
 * soren hugs tjaalton 
 * tjaalton hugs soren back
 * tjaalton just saw "300" and feels Spartan
<tjaalton> sigh, and the list of typos just keep on growing
<tjaalton> another vmware upload on the way..
<ubotu> New bug: #192930 in xserver-xorg-input-keyboard (main) "Numeric keypad no longer works in Hardy" [Low,Incomplete] https://launchpad.net/bugs/192930
<ubotu> New bug: #192958 in xorg-server (main) "gnome/compiz crashes" [Undecided,New] https://launchpad.net/bugs/192958
<seb128> bryce: what do you think that totem is doing wrong to cause bug #130696?
<ubotu> Launchpad bug 130696 in totem "xine and totem-xine crashes with the fglrx driver" [Medium,New] https://launchpad.net/bugs/130696
<seb128> especially that xine crashes the same way
<seb128> I reassigned to xine-lib, let me know if you think I'm wrong
<ubotu> New bug: #192638 in compiz (main) "[hardy] compiz can't start after 2008-02-15 updates (dup-of: 192253)" [Undecided,Incomplete] https://launchpad.net/bugs/192638
<ubotu> New bug: #145800 in linux-restricted-modules-2.6.24 (restricted) "Compiz Fusion in Gutsy Gibbon Beta -- Momentary Freezes" [Undecided,Confirmed] https://launchpad.net/bugs/145800
<ubotu> New bug: #193018 in xorg (main) "SHIFT+ALT != ALT+SHIFT" [Undecided,New] https://launchpad.net/bugs/193018
<ubotu> New bug: #184071 in wxmaxima (universe) "wxmaxima fails after xorg update (dup-of: 183969)" [Undecided,New] https://launchpad.net/bugs/184071
<ubotu> New bug: #151268 in xserver-xorg-video-ati (main) "compiz with ATI Radeion RV100 QY [7000/VE] corrupts screen after video playback" [Undecided,Incomplete] https://launchpad.net/bugs/151268
<bryce> seb128: I get those "...received an X Window System error" messages with my xrandr gui all the time, and it's caused by making an incorrect xlib call
<bryce> seb128: the error message indicates a coding error in the client application rather than an error in X
<seb128> bryce: I'm not an xorg guy, but those errors often happen when using compiz or special xorg option, or some drivers, etc
<bryce> seb128: I wish xlib provided more detailed explanations of the errors - I've not yet figured out what the code numbers indicate or whatever
<seb128> why does playing the same video with the same software works when not running compiz in some cases?
<bryce> seb128: yeah I know.  It's actually sort of a generic error message though, like "syntax error" or "out of memory"
<seb128> on gutsy for example xv video playing doesn't work on some intel cards when using compiz, right?
<bryce> so what I suspect is that in each case, the client app is making a different call, but they're all xlib calls (XReply probably), which returns its errors in that generic fashion
<bryce> I gather gtk or glib has some sort of catch() routine that is capturing the error and generating the error message... perhaps that routine ought to be made to give better diagnostics (if that's possible)
<seb128> how could the application know abou those limitation and don't do standard calls?
<seb128> there is a gdk_x_error() right, you can break on it and get a gdb backtrace in such cases
<seb128> but still, I'm not sure if that's the application which should know about driver bugs and try to workaround those
<seb128> I would tend to say that if xorg doesn't handle standard requests that's something in the xorg stack to blame
<bryce> seb128: well, assuming that's the case, at a minimum I would need to know what xlib routine that the client app is trying to access
<seb128> alright
<bryce> my guess is that it's trying to call some xlib routine which isn't valid with fglrx
<seb128> in this case I've reassigned the bug to xine because I think the multimedia framework is likely the one doing the call
<bryce> perhaps some sort of visualization thing...  a 3d call, or maybe even xrandr
<seb128> and the guy get the issue using xine which seems to confirm that
<seb128> right, that's possible
<bryce> I notice some apps do xrandr calls to get screen layout info (maybe so they can tell where to pop up windows or whatever), but fglrx (and nvidia, etc.) don't support xrandr
 * bryce ponders
<seb128> totem doesn't thing like calling xrandr when not using xv and switching to fullscreen video
<bryce> I would assume that it would be the client apps' responsibility to check for if a given module is loaded before trying to access its functionality, but not sure
<seb128> but is it possible for the application to know that xorg doesn't support xrandr?
<seb128> is there an x11 api for that?
<bryce> yes
<bryce> yep
<seb128> ok
<seb128> for the xrandr call it likely make sense
<bryce> yeah, in fact there is code in Screen Resolution which does exactly this
<bryce> and if you don't have the xrandr module it pops up an error dialog
<seb128> I don't think those issues are due to xrandr
<bryce> it also has code to check that you have a new enough version loaded
<seb128> but I'll try to get a backtrace and ping you next time I've a such bug
<seb128> maybe I can learn about how to debug those ;-)
<bryce> well, iirc, it's a generic api for checking the xorg modules that are loaded, so could be similarly used even if it was say glx or exa or something
<bryce> cool
<bryce> yeah I really wish X didn't give such cryptic errors
<ubotu> New bug: #158453 in xserver-xorg-video-intel (main) "[compiz] System bell causes blur to lose acceleration" [Undecided,Incomplete] https://launchpad.net/bugs/158453
#ubuntu-x 2008-02-19
<ubotu> New bug: #193111 in xserver-xorg-video-unichrome (universe) "Unsupported VT3371" [Undecided,New] https://launchpad.net/bugs/193111
<Q-FUNK> guys, are we including the CPUID patch from bug #180742 for Hardy?
<ubotu> Launchpad bug 180742 in xorg-server "xf86-video-amd: switching to a vcons fails" [Unknown,Confirmed] https://launchpad.net/bugs/180742
<Q-FUNK> it's the last of 3 x86emu patches needed to bring x86emu back into line.
<ubotu> New bug: #193192 in xorg (main) "DPMS is broken" [Undecided,New] https://launchpad.net/bugs/193192
<tjaalton> Q-FUNK: I'll add it today
 * tjaalton drops eyes to the floor... ati 6.8.0 released
<tjaalton> sheesh
<Q-FUNK> thanks!
<Q-FUNK> hehe
<bryce> heya
<Q-FUNK> hey :)
<tjaalton> bryce: I guess we want the new ati in hardy?-) Unstable already has it, I'm looking at the merge or sync
<bryce> tjaalton: yeah probably, but we should review the changelog to get a sense of the proportion of new features to bug fixes
<bryce> and also testing results of course...  if there's a lot of confirmed bug fixes, we definitely want it
<tjaalton> it's a stable release, we have a six weeks old snapshot.. :)
<tjaalton> sorry, eight weeks
<bryce> yes quite true
<ubotu> New bug: #193198 in xorg (main) "Screen errors in ATI Mobility Radeon X700 in Hardy" [Undecided,New] https://launchpad.net/bugs/193198
<tjaalton> we should be able to sync it
<tjaalton> the only patch is from upstream
<bryce> ok
<tjaalton> Ng: upstream want's you to try git master to fix the graphics bugs with 855
<tjaalton> -'
<tjaalton> well, the last commit on the stable branch
<tjaalton> http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-intel.git;a=commitdiff_plain;h=aa1813e4807e500fb122f36af988cf60f91e05a5;hp=1cea254b70158600d9dfff8ba66fb2ec0a6e0f67
<Ng> tjaalton: can I build that independently of xorg*
<Ng> +?
<bryce> Ng, yup
 * Ng installs git
<Ng> is it just git co http://thaturl     ?
<tjaalton> just wget that patch and apply it on the packages
<tjaalton> -s
<tjaalton> or build the git version
<tjaalton> and copy the drv.so
<Ng> aha
<ubotu> New bug: #149479 in linux-restricted-modules-2.6.24 (restricted) "Graphic set-up is problematic" [Undecided,New] https://launchpad.net/bugs/149479
<mvo> tjaalton: I would like to talk to you about the fglrx issue when they drop support for cards (you filed a update-manager bug about it). do we have a list of pci ids available of the cards that are supported or where support got dropped?
<Ng> hmm, don't spose anyone still has a copy of xserver-xorg-video-intel 2.2.0+git20080107-1ubuntu2 lying around, do they? if this doesn't work I'd like to be able to revert back to the working driver ;)
<bryce> Ng, the (probably crude) approach I've taken when working with git drivers, when done is to do apt-get remove <driver>; apt-get install <driver>.
<bryce> there's probably a cleaner solution tho
<tjaalton> mvo: hmm, what bug #?
<bryce> I believe you can do apt-get install <driver>=<version> or something to force it to a particular version
<Ng> bryce: sure, but aiui, older packages get purged from the archive, so apt won't be able to find it
<saispo> hi
<bryce> Ng, ahh, yes that's true
<bryce> saispo: heya!
<mvo> tjaalton: #110388 you reassigned this one to update-manager on saturday
<saispo> :)
<saispo> little question: anyone know how can i do not invoke xorg postinst in gutsy installer ? because it build a xorg.conf automatically and i don't want it :)
<bryce> saispo: there isn't a way to suppress the initial generation of it, however you should be able to delete it at any point during install by switching to a terminal console and deleting it.  (Perhaps I misunderstand what you need tho.)
<tjaalton> mvo: oh that one
<saispo> bryce: yes, i see no other solution :|
<saispo> bryce: you see right ;)
<saispo> bryce: i will use a d-i command for doing this
<bryce> saispo: if you have X trouble during installation, another workaround is to use the alternate install CD, which does a text-mode install
<saispo> thanks
<bryce> sure
<saispo> bryce: i use this, but it's for a custom distro
<saispo> bryce: with feisty i have no trouble
<tjaalton> mvo: lrm includes the modules.alias.override -files which could be used
<bryce> ah
<Q-FUNK> seb128: could you tell me what was the name of the gnome componet that draws the bacground image?
<tjaalton> nautilus?
<seb128> Q-FUNK: depends, gnome-control-center or nautilus
<seb128> what is the issue?
<tjaalton> bryce: do I file the sync request for ati?
<bryce> tjaalton: sure go for it
<tjaalton> ok cool
<Q-FUNK> seb128:  zoom image behavior changed. it used to center and zoom, now it left-aligns and zooms
<Q-FUNK> seb128: in hardy
<seb128> not sure, you can open it on gnome-control-center if you want, attach an example to the bug maybe, I don't notice the issue on my installation
<Q-FUNK> seb128: I tried both with the left-click option on the dektop and with the appearnce dialog. the result is the same in both cases.
 * Ng goes with a ghetto solution of tarring up the contents of the current working package ;)
<seb128> Q-FUNK: the left click option starts the appearance capplet
<Q-FUNK> seb128: ok
<tjaalton> Ng: just copying intel_drv.so is enough
 * Ng lost in a sea of version numbers. I want to be building 2.2.0.90, right?
<ubotu> New bug: #193211 in xserver-xorg-video-ati (main) "Please sync a new version from Debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/193211
<tjaalton> Ng: yes, and the patch on top of that
<Ng> hmm, then I reckon it's working. I thought I'd built the previous snapshot version that was working, but I seem to have build 2.2.0.90. I'd like to try again with absolutely-definitely-guaranteed pristine source though ;)
<tjaalton> ah :)
<Ng> I have some hardy updates to apply first too
<bryce> tjaalton: wow, long changelog for -ati.  I'll keep my fingers crossed that it's stable
<tjaalton> sure it is
<bryce> night
<ubotu> New bug: #193233 in linux-restricted-modules-2.6.24 (restricted) "nvidia api mismatch when installing nvidia-glx-new" [Undecided,New] https://launchpad.net/bugs/193233
 * Ng up to date. building driver again...
<tjaalton> bryce: btw, the changelog was 6.6.3 -> 6.8.0, so it's considerably shorter for 6.7.197 -> 6.8.0
<ubotu> New bug: #193323 in xserver-xorg-video-cirrus (universe) "x fails to startup in qemu" [Undecided,New] https://launchpad.net/bugs/193323
<ubotu> New bug: #187645 in linux-restricted-modules-2.6.24 (restricted) "Evolution calendar consumes 100% CPU with mouse-over info" [Low,New] https://launchpad.net/bugs/187645
<seb128> I reassigned this evolution calendar issue
<seb128> that's basically cairo rendering being slow on fglrx when not using composite
<seb128> not sure if that's cairo, xorg or the driver to blame though
<Ng> tjaalton: it looks to me like that patch works
<Ng> either that or I'm utterly confused about versions ;)
<bryce> tjaalton: ahh, that explains it
<tjaalton> Ng: cool, I'll let upstream know
<Ng> :)
<Ng> can has a new upload with the patch? :D
<tjaalton> just apt-get reinstall the driver to see it really was the patch that fixed it?
<tjaalton> we'll see :)
<Ng> I'll do the reinstall when I get home (couple of hours)
<Ng> I'd prefer not to break things while I'm working ;)
<tjaalton> heh, ok
<ubotu> New bug: #192994 in xorg (main) "X doesnt shut down. Requires CTRL ALT BACKSPACE to kill it so it can shut down" [Undecided,New] https://launchpad.net/bugs/192994
<ubotu> New bug: #193419 in xserver-xorg-video-intel (main) "External monitor loss - intel 945" [Undecided,New] https://launchpad.net/bugs/193419
<mvo> bryce, tjaalton: what is the latest status with regard to i965 and exa/xaa ? I got some mails asking about this for compiz and I was wondering if there is a decision about this yet
<bryce> mvo, in fact I'm just now working on my patch for it
<bryce> mvo, so I should have more news by the end of the day
<mvo> bryce: the patch that makes it happy with exa?
<bryce> yes
<mvo> thanks
<tjaalton> well, 965
<tjaalton> but the rest should use XAA
<bryce> tjaalton: aside from my patch, is there anything else we need to do to ensure <965 are using XAA?
<mvo> I have still distorted window shadows on the 965, but I guess you know about this, right?
<mvo> <i965 should be fine, as long as the patch I did for gutsy to use the hardware overlay for Xv is still applied
<mvo> (compiz-wise all should be fine for those)
<tjaalton> bryce: yes, there's a commit which switched EXA on, so revert that and then add to your patch the rule to use EXA for 965
<bryce> yup, in fact that's what I'm using to check if this is working
<bryce> mvo, I have a simple patch to fix those borders which has been tested to work, but if this greedy patch solves it, we don't need that patch
 * mvo nods
<bryce> tjaalton: hmm, sounds like I'll need to also do a patch to force EXA for 965... currently I just check if both those are enabled, and then turn on greedy too
<mvo> great, thanks for the update. I'm looking forward to it
<tjaalton> mvo: ah so it was your patch :)
<tjaalton> bryce: right
<mvo> tjaalton: eh, did it broke anything :) ?
<tjaalton> mvo: no, I was just wondering where it came from :)
<mvo> aha, ok :)
<mvo> I think we talked about it when I uploaded the packages, but it was a while ago. it bugged me to no end that i965 wouldn't work, until I discovered that the hardware is missing
<mvo> yeah for no docs from intel (fixed now fortunately)
<bryce> there's an article on lwn complaining that the community invests more resources in things like reverse engineering nvidia drivers where there aren't docs, and none in -intel where there are (now) plenty of docs.
<bryce> I don't know if I would agree there - I suspect it's just that Intel ends up hiring everyone that works on -intel ;-) - but an interesting point of view
<pwnguin> id argue as well that nvidia drivers are more valuable
<pwnguin> given that the chips are more capable
<bryce> pwnguin: do you mean because of nvidia's hardware performance potential?
<pwnguin> yea
<pwnguin> unless intel has some magic i havent read about since i last went laptop shopping
<bryce> whoohoo!!
<Q-FUNK> intel voodoo incantation required.
<bryce> think I got it working...
<bryce> yup :-)
<bryce> tjaalton: ok with my greedy patch, borders are now correct, and I've verified greedy is turned on for 965
<bryce> tjaalton: what else do we need to check?
<tjaalton> that should be enough for now, if it forces EXA as well?
<bryce> no I still need to code up that patch
<bryce> first want to finish up this one and get it in
<bryce> I figure I'll do the two things as separate patches so it'll be easier to drop one or the other independently in the future if we need to
<tjaalton> sure
<bryce> hmm, doesn't fix the glxgears issue but I guess that's separate.  Movie playback is a lot better
<tjaalton> what issue?
<tjaalton> btw, someone said that setting EXNoComposite true would improve the performance, but I couldn't tell the difference
<bryce> the issue is, run glxgears, then move the window, and it doesn't clear the screen properly
<tjaalton> isn't that true for all free drivers atm?-)
<tjaalton> maybe the cleanup works with xaa though
<bryce> oh is it?  I didn't see it on gutsy with -ati, but maybe it's a 1.4 issue?
<bryce> oh and I'm not running compiz, duh
<tjaalton> ah
<mvo> bryce: that is unfortunately a known issue with compiz :(
<mvo> we tried to come up with a workaround, but its (unsurprisingly) pretty difficult
<bryce> hmm, this is odd - I rebooted my 965 laptop without installing any greedy patched versions, which had the tearing issue and so forth, and now I cannot reproduce the issues
<tjaalton> using the defaults?
<bryce> I think so... doing some more testing...
<ubotu> New bug: #193458 in xinit (main) "Xsession fails due to an incorrect COLUMNS value" [Undecided,New] https://launchpad.net/bugs/193458
<bryce> btw, here are the deb's I just tested, which seem to work:  http://people.ubuntu.com/~bryce/Testing/Greedy/
<bryce> so far testing is confirming it, but would be nice for independent verification
<bryce> performance seems about the same either way, hm
<tjaalton> try scrolling in firefox
<bryce> ok
<bryce> ah, nastiness
<bryce> aha, ok all issues reproduced on test hw without patch... now trying with patched driver...
<bryce> ahhh, yes that's much better
<bryce> cool even the screen tearing's gone
<soren> Did something get updated in gutsy relatively recently that could cause my wife's laptop's X to die a few times of day?
<tjaalton> only the security patches a month ago
<tjaalton> hm, unless the intel driver got in updates
<bryce> don't think that's happened
<bryce> tjaalton: ok, the xserver patch portion of the fix is ready to be uploaded:  http://people.ubuntu.com/~bryce/Uploads/
<tjaalton> 3 is uploaded already ;)
<bryce> hmm, apt-get source only pulled a 2 for me
<tjaalton> I uploaded it earlier today
<bryce> ok, here is an xserver 1ubuntu3, and -intel 2ubuntu5: http://people.ubuntu.com/~bryce/Uploads/
<bryce> could you upload both of those?  Next I'll do the force-exa-on-for-965 patch
<tjaalton> sure
<bryce> hrm
<Ng> tjaalton: ok, that patch is needed, it stops the weird 16-bit look-a-like pixmaps
<Ng> (which seems to affect 2d and 3d, weirdly)
<Ng> I see it on the ubuntu logo in gdm and on the photo icons on my desktop without the patch
<Ng> (I also tried with/without the migration config bits in xorg.conf)
<tjaalton> Ng: thanks, I'll add that to the upstream bug
<bryce> tjaalton: oh, hmm I forgot, but maybe the depends for -intel should be increased to require that newer xserver
<Ng> tjaalton: is there likely to be another upstream drop into hardy before release?
<bryce> I've got the xaa-default-except-i965 patch ready to go, I'll roll that depends update into it too if that sounds good to you
<tjaalton> Ng: likely
<Ng> groovy
<Ng> hmm, I don't remember if I actually filed that as a bug
<bryce> tjaalton: could you remind me why we prefer XAA for <i965? stability or performance?
<tjaalton> performance
<tjaalton> Ng: yep you did
<tjaalton> Ng: I'll apply the patch on our intel for now
<Ng> k
<Ng> wrt XAA/EXA, subjectively i think EXA is as fast on 855 with the greedy migration doodad
<tjaalton> hmm
<tjaalton> maybe it doesn't hurt to let alpha5 be with EXA+greedy for all
<bryce> could be, although iirc there are some hardware specificness for EXA performance
<tjaalton> it would be nice to not go back to xaa
<tjaalton> if possible
<tjaalton> I mean staying as close to upstream as possible
<bryce> ok, well I'm almost done with the revert back to xaa by default except i965 patch...  let me complete that
<bryce> ...ok done - http://people.ubuntu.com/~bryce/Uploads/ 2ubuntu6
<bryce> hmm
<bryce> oh, btw I built the above but didn't test to ensure it goes to xaa on <965
<bryce> but the patch looked very straightforward, I'd be surprised if it didn't do exactly what's intended
<bryce> oh crap, I forgot to update the depends... one sec
<tjaalton> of the driver?
<tjaalton> I can do it locally
<bryce> yeah
<bryce> oh okay cool
<tjaalton> although
<bryce> if we even want to do that... the driver will build and work against older 1.4 drivers, just will not be using greedy in that case
<tjaalton> right
<bryce> so yeah, probably no need to change depends I guess
<tjaalton> yep, so I'll just upload this one
<tjaalton> man, I hope all those drm fixes are backported to the hardy kernel.. should fix a number of intel suspend/resume/hibernation issues
<bryce> tjaalton: ok!  I've uploaded a third patch which would do greedy for ALL chipsets, to bug 177492
<ubotu> Launchpad bug 177492 in xserver-xorg-video-intel "EXA is balls-achingly slow" [Critical,Confirmed] https://launchpad.net/bugs/177492
<bryce> tjaalton: all else being equal, I think shipping all-EXA on would be ideal, however I'm not sure what effect turning greedy on for everyone would have
<bryce> tjaalton: but all the patches now exist to take whichever route seems best
<tjaalton> at least 945 suffers from performance issues
<bryce> with greedy?
<tjaalton> I uploaded ubuntu6, so 965 should be covered now
<tjaalton> ah no, with plain EXA
<bryce> ok cool; will those bugs auto-close or should I mark them fix released myself?
<tjaalton> they'll auto-close
<bryce> okie.  --> lunch
<tjaalton> hmm, I wonder if 'dput -u foo' was enough, I can't see those packages on the list yet
<tjaalton> instead all vdr plugins are there, and those were uploaded a few minutes ago
<tjaalton> anyway, time to get some sleep.. night!
<Ng> cya tjaalton 
<ubotu> New bug: #69082 in gnome-power-manager (main) "Screen goes blank regardless (dup-of: 30969)" [Undecided,New] https://launchpad.net/bugs/69082
#ubuntu-x 2008-02-20
<bryce> tjaalton: hmm still haven't seen the uploads come through; perhaps something is stuck
<ubotu> New bug: #188549 in xserver-xorg-driver-nv "Hardy a4: graphics on XPS m1330" [Undecided,New] https://launchpad.net/bugs/188549
<ubotu> New bug: #193544 in xserver-xorg-input-synaptics "Synaptics touchpad not detected on MacBook Santa Rosa" [Undecided,New] https://launchpad.net/bugs/193544
<ubotu> New bug: #144914 in compiz (main) "putting glxgears below another window when running compiz looks funny (dup-of: 96991)" [Medium,Confirmed] https://launchpad.net/bugs/144914
<ubotu> New bug: #148434 in compiz (main) "compiz opengl rendering artefacts (dragging, rotating) (dup-of: 96991)" [Undecided,New] https://launchpad.net/bugs/148434
<bryce> (yes, I've gone on a dupe spree *grin*)
<bryce> tjaalton: I've set bug 96991 as the master for all the compiz/3d redirected direct rendering issues.
<ubotu> Launchpad bug 96991 in xorg-server "3D stuff breaks with Compiz:  Redirected Direct Rendering is needed in DRI" [Wishlist,Triaged] https://launchpad.net/bugs/96991
<bryce> down to 1377 total bugs
<tjaalton> bryce: maybe the archive was frozen already
<bryce> morning tjaalton
<bryce> no I think it's a soft "on your honor" freeze
<tjaalton> hmm
<tjaalton> slangasek send an email saying that main is frozen, but it shouldn't have been at the time
<bryce> tjaalton: should we ask slangasek or someone for help?
<tjaalton> bryce: I think so
<tjaalton> maybe also with syncing -ati?
<bryce> yeah
<bryce> there's a platform meeting on #ubuntu-meeting he'll be at in about half an hour; might be good to bump his elbow about these things at the start of that
<tjaalton> oh ok, I'll be there
<tjaalton> bryce: what should we do with input-hotplug? all this time there has been the possibility to generate an fdi file for it either from xorg.conf or /etc/default/console-setup, but the problem was (and still is) that which package should own the script
<bryce> tjaalton: hmm good question.  xorg would be my first guess
<bryce> but maybe that's more just because I'm less familiar with console-setup
<tjaalton> hal upstream has not answered to my questions about the hal-script approach which would make the fdi-file unnecessary
<tjaalton> yeah I think xserver-xorg would be the place
<bryce> did you talk with cjwatson about it last week?
<tjaalton> yes, and as a result I sent the email to hal-list..
<bryce> ok, maybe it would be a good thing to bring up at the meeting tonight
<tjaalton> yep
<bryce> I need to get direction as well about the xrandr gui.
<bryce> I think merging with redhat is the right way to go, but I'm concerned we don't have enough time left
<bryce> however with all the bug stuff I did today I feel a *lot* more comfortable about or stability
<tjaalton> well, since it's just a gui, it should be able to touch it late in the release process
<bryce> getting 965 working was a very important goal, so I'm really glad that all has worked out
<tjaalton> I'm concerned about i-h, since there are a number of bugs where I said that "this will be fixed in hardy blahblah" :)
<bryce> what's i-h?
<bryce> oh input-hotplug?
<tjaalton> yeah ;)
<tjaalton> or i12 from now on :)
<tjaalton> maybe not
<bryce> yeah, I've got a long list of input issues I've promised people I'd look at, but haven't yet
<tjaalton> bryce: I have to go to the swimming hall, but will get back in ~2h
<bryce> ok cool
<bryce> <cjwatson> bryce: looks like Timo didn't re-sign xorg-server
<bryce> <cjwatson> 07:15:35 WARNING Upload was rejected:
<bryce>  07:15:35 WARNING        Signer is not permitted to upload to the component 'main' of file 'xorg-server_1.4.1~git20080131-1ubuntu4.dsc'
<bryce> tjaalton: so I think if you re-debsign my package and upload it, it should go through
<bryce> oh, and you may be happy to hear I finally sent in my core-dev app tonight.
<bryce> seb128: cjwatson and I discussed about xrandr gui plans at the meeting today
<bryce> seb128: after giving it thought, the right approach seems to be to drop what I've been working on and instead focus on integrating and finishing the RedHat tool
<seb128> ah, why?
<bryce> seb128: cjwatson suggested that I ask if you would be able to assist me with this integration
<seb128> sure
<bryce> seb128: well, firstly because it seems there is little chance of getting our tool upstream.
<bryce> seb128: but also because the underlying structure that redhat has put in place is better designed than what I've rushed together
<seb128> ok
<bryce> I'm writing a reply to get some additional information; I'll cc you.
<seb128> ok
<bryce> sent
<bryce> seb128: from what it looks like, it will require some integration work to gnome-desktop, gnome-settings-daemon, and gnome-control-center
<bryce> seb128: I want to find out if they are using a VCS (currently I just wget -r the files, which is a pain)
<bryce> http://www.gnome.org/~ssp/randr/
<seb128> bryce: better to reply on the list to ask that, I don't know what they are using
<bryce> maybe we take a snapshot and put into bzr to work on...?
<seb128> sounds good
<bryce> yeah, that was my first question in my email
<bryce> seb128: have you worked with Soeren Sandmann before?
<seb128> no
<mvo> hey bryce! thanks for your mail about i965 and compiz
<mvo> we removed the blacklist for it a while ago (when exa was enabled), but I'm happy that I don't have to reenable it again :)
<bryce> mvo, :-)
 * mvo upgrades his i965 system to test
<bryce> mvo, the packages haven't been uploaded quite yet, but should be as soon as tjaalton returns
<bryce> but I stuck debs up for testing at http://people.ubuntu.com/~bryce/Testing/Greedy/
<bryce> anyway, got an early meeting tomorrow morning.  g'night
<mvo> good night
<mvo> bryce: works nicely here bte
<mvo> btw
<mvo> great work!
<tjaalton> hmm, I thought that a simple dput -u would've worked, but guess not
<tjaalton> yeah, now they got accepted
<soren> How do you figure out which driver to use for input?
<tjaalton> soren: hmm what do you mean=
<tjaalton> ?
<soren> Not sure how I can explain it better. I've found the answer, thouhg :)
<soren> though..
<tjaalton> heh, ok
<tjaalton> evdev is the one that input-hotplug uses by default, for instance
<soren> input-hotplug?
<soren> Ok, it seems that my problem is that mdetect is not installed by default anymore. I'm assuming that's intentional somehow?
<soren> ..
<soren> No, it seems that won't help me either.
<tjaalton> hotplugging input devices, a new feature in xserver 1.4 but not yet used by default
<tjaalton> soren: what problems are you having?
<soren> I want to use vmmouse when running inside kvm.
<soren> That solves pretty much everything.
<soren> ...w.r.t. to X pointers, at least.
<soren> :)
<tjaalton> it's used by default on vmware guests
<tjaalton> at least should be
<soren> Right, but that depends on a) mdetect being installed when dexconf runs and b) actually running inside vmware (doesn't work with kvm).
<tjaalton> right
<tjaalton> xserver-xorg recommends mdetect
<soren> Well, on the live cd, it's not installed when I log in.
<tjaalton> ok, so it's not strong enough
<soren> Do you happen to know how fedora does it? They get it right, you see.
<tjaalton> nope, no idea
<soren> I looked at system-config-display, but ti doesn't say vmmouse anywhere in the source, afaics.
<tjaalton> maybe dexconf could use the same QEMU_KVM hack as for the device driver
<tjaalton> to detect that it's running under kvm
<soren> Well.. We could, but I think it's a horrible, horrible hack.
<tjaalton> indeed :)
<soren> tjaalton: Oh!
<soren> tjaalton: You're the one who did the vmmouse detection stuff in dexconf.
<tjaalton> was I
<tjaalton> hmm
<soren> Oh, you just merged it.
<soren> Sorry, it was bryce.
<tjaalton> yep, I think it didn't work before, and still doesn't if mdetect isn't installed
<soren> bryce: Why bother with the vmmouse_detect thing in dexconf instead of just detecting if the device is there?
<tjaalton> and do it in the server?
<mvo_> tjaalton: will we get xf86-video-ati 6.8.0 (will that work with our xserver)?
<tjaalton> mvo_: after alpha5, and yes it works
<mvo_> rock!
<soren> tjaalton: Well, dexconf is still fine, but I'm guessing the device itself must be identifiable (rather than looking at the environment)
<mvo_> any pre-deps available already? I have a r500 and can't wait to switch to radeon again
<tjaalton> mvo_: no, just get the source from debian and build it
<tjaalton> mvo_: no 3D though
<tjaalton> not yet anyway ;)
<tjaalton> soren: did you look at vmmouse_detect how it does the detection?
<tjaalton> soren: if it really is something generic that the server should support (and not just vmware specific), then I think it would be possible to get it in the server itself
<tjaalton> although, in the input-hotplug world I think it should be hal that needs to know that the system is a virtual guest
<ubotu> New bug: #193667 in xserver-xorg-video-intel (main) "bad performaces on intel x3100" [Undecided,New] https://launchpad.net/bugs/193667
<ubotu> New bug: #193690 in xorg (main) "Xorg + PCI card = INVALID IO ALLOCATION" [Undecided,New] https://launchpad.net/bugs/193690
<ubotu> New bug: #192136 in xulrunner-1.9 (main) "Background image when scrolling" [Undecided,Incomplete] https://launchpad.net/bugs/192136
<soren> tjaalton: WEll, it turns out that if the vmmouse driver doesn't detect the vmware stuff, it just passes control on to the regular mouse driver. For this very reason, Fedora has actually defaulted to vmmouse for the last couple of releases.
<soren> tjaalton: Do you reckon we could do the same?
<ubotu> New bug: #193575 in xserver-xorg-input-synaptics "Synaptics touchpad periodically disconnects" [Undecided,New] https://launchpad.net/bugs/193575
<soren> bryce: Where did you find the vmmouse_detect code?
<bryce> soren, mdz passed it along to me from one of the vmware guys iirc
<soren> bryce: Ah.
<soren> bryce: You wouldn't happen to have a name and an e-mail for that guy?
<bryce> soren: yeah hang on (sorry was in a conf call with amd)
<soren> Cool.
<soren> While we're sort of on the subject..
<soren> 16:16:26 < soren> tjaalton: WEll, it turns out that if the vmmouse driver doesn't detect the vmware stuff, it just passes control on to the regular mouse driver. For this very reason, Fedora has  actually defaulted to vmmouse for the last couple of releases.
<soren> 16:33:37 < soren> tjaalton: Do you reckon we could do the same?
<bryce> Philip Langdale
<bryce> From: Philip Langdale <ubuntu.philipl@overt.org>
<bryce> he's a vmware guy according to mdz, despite the email's url
<bryce> wow, odd
<tjaalton> soren: sounds nice
<tjaalton> duh, now we get bugs about intel chips being too slow
<bryce> hehe
<bryce> tjaalton: I decided to wait on bringing up the input-hotplug issues since I thought it would be more productive if you were there; last time I talked with cjwatson about it he recommended to stick with the current configuration approach for this release
<bryce> tjaalton: but perhaps you and I can talk with colin on the side to work out a better plan
<tjaalton> bryce: yeah sure
<bryce> soren: so regarding the vmmouse configuration, if the current approach isn't working then I'm definitely open to better ideas
<bryce> soren: it would be nice to have the input-hotplug stuff squared away before undertaking any things that would take a large effort; defaulting to vmware sounds like it would be simple (assuming it didn't cause other issues); adding support in the xserver to detect it would be more effort but probably the better solution
<tjaalton> but there's no need to touch the server, if the driver has all the nuts and bolts in it
<bryce> right...  "xserver and/or the driver"
<tjaalton> apparently it just loads another driver (in this case, mouse) if the host system is not a virtual guest
<tjaalton> and if we end up using input-hotplug fo hardy, evdev
<tjaalton> although maybe there's a better way to do it with i-h
<tjaalton> hmm I'll try it on my laptop
<bryce> I wonder if debian has looked at this already?
<tjaalton> doesn't look like it
<bryce> ok, well sounds like defaulting to vmmouse is a decent solution.   It'd be interesting to hear debian's opinion
<tjaalton> of course
<bryce> Intrepid Ibex.  mm
<ubotu> New bug: #193726 in xorg-server (main) "package xserver-xorg-core 2:1.4.1~git20080131-1ubuntu2 failed to install/upgrade: falha em buffer_write(fd) (10, ret=-1)rsa" [Undecided,Invalid] https://launchpad.net/bugs/193726
<tjaalton> yep, wonder what the nickname will be.. intrepid is too long so maybe just ibex
<tjaalton> vmmouse works fine on my laptop
<tjaalton> hmm actually it doesn't even use it
<tjaalton> "the core pointer device wasn't specified in explicitly in the layout. using the default mouse configuration". right.
<tjaalton> soren: so, the current code in dexconf has no meaning since it doesn't write a ServerLayout section anymore
<tjaalton> the server should default to vmmouse if we want to use it
<jcristau> i think if it finds a device with Option CorePointer, it uses that as the mouse device
<tjaalton> jcristau: yep, probably so
<tjaalton> changing evdev -> vmmouse from the example fdi-file worked, but now all mouse clicks are doubled
<tjaalton> so i-h doesn't like "mouse"
<tjaalton> but I guess that was common knowledge
<jcristau> tjaalton: pretty much, because then you get the events both from /dev/input/mouseN and /dev/input/mice
<jcristau> or something like that
<jcristau> which sucks
<tjaalton> yep, even the movement is doubled :)
<bryce> fun
<tjaalton> and for some reason, i-h on my laptop is party broken, "up" generates "printscr"
<tjaalton> my desktop works fine, same config
 * bryce delves back into xrandr gui work
<jcristau> tjaalton: that's a xkbmodel mismatch between evdev and something else afaik
<tjaalton> jcristau: normally I would agree, but the gnome kb-layout capplet seems to show correct values (=evdev layout)
<jcristau> what about setxkbmap -print?
<tjaalton> or is it perhaps something else then.. need to investigate later
 * jcristau doesn't trust gnome
<tjaalton> hehe
<tjaalton> Heroes first :)
<tjaalton> jcristau: ok, here's the diff:
<tjaalton> --- setxkbmap-normal	2008-02-20 22:15:02.000000000 +0200
<tjaalton> +++ setxkbmap-ih	2008-02-20 22:17:47.000000000 +0200
<tjaalton> @@ -1,7 +1,7 @@
<tjaalton>  xkb_keymap {
<tjaalton> -	xkb_keycodes  { include "xfree86+aliases(qwerty)"	};
<tjaalton> +	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
<tjaalton>  	xkb_types     { include "complete"	};
<tjaalton>  	xkb_compat    { include "complete"	};
<tjaalton> -	xkb_symbols   { include "pc+fi(kotoistus)+level3(ralt_switch)"	};
<tjaalton> -	xkb_geometry  { include "pc(pc105)"	};
<tjaalton> +	xkb_symbols   { include "pc+fi(kotoistus)+inet(evdev)+level3(ralt_switch)"	};
<tjaalton> +	xkb_geometry  { include "pc(pc104)"	};
<tjaalton> geometry is different
<ubotu> New bug: #193793 in mesa (main) "[hardy] X crashes on r300 during f-spot slideshow" [Undecided,New] https://launchpad.net/bugs/193793
<ubotu> New bug: #193800 in xdm (universe) "outdated Depends dependency relationships" [Undecided,New] https://launchpad.net/bugs/193800
<bryce> seb128: I've roughed out a todo list for the xrandr gui work - https://wiki.ubuntu.com/X/DisplayConfig
<bryce> seb128: when you get a chance please take a look and give me your feedback
<seb128> bryce: ok
<seb128> bryce: looks good to me
<seb128> bryce: I can look at the gtk and gnome* fedora patches tomorrow and give you my opinion on them if that works for you
<bryce> ok
<seb128> bryce: is that something we still want for hardy?
<bryce> yes
<seb128> ok, will look at that tomorrow then
<bryce> the gtk patch adds certain new xrandr 1.2 functionality the other code requires
<seb128> it's getting late now and I don't feel like starting on that now ;-)
<bryce> seb128: sure, but first a couple questions...
<seb128> sure
<seb128> questions are fine
<seb128> I just don't want to start reading code changes ;-)
<bryce> seb128: should I go ahead and set up a bzr repo for us and stick this in it for us to work on?
<seb128> do you think the level of change is important enough to justify a bzr?
<bryce> seb128: oh, hmm that's my only question :-)
<bryce> well, it seems they don't respond swiftly so if we have patches it may take some time to get them accepted, so it may be easier to manage them in a vcs
<bryce> seb128: I assume we'll need to do some work on the code in order to make it fit and look proper
<bryce> well, we could wait and decide tomorrow if you'd prefer?
<seb128> sorry was busy with other things
<seb128> well
<seb128> if we do take the redhat patches and only small bug fixing there, which I expect will be the case for gtk, gnome-desktop, gnome-settings-daemon I'm not convinced bzr will be useful
<seb128> if we need to write code, which will likely be the case for gnome-control-center I think that's useful
<bryce> ok, yes that's what I suspect to be the case
<bryce> gnome-desktop may also require some additional coding; most of the xrandr logic is implemented there
<bryce> however I've not looked at it deeply enough yet
<bryce> but for now, I could create a branch for gnome-control-center?
<seb128> sure
<bryce> ok cool
<seb128> do you want this one to be used for packaging and everything?
<seb128> or only to hack on that and we can merge with the packaging branch on updates, etc?
<bryce> I was thinking just for hacking on, to assist in producing patches 
<bryce> right, the latter
<seb128> sounds good to me
<seb128> in which case feel free to set bzr for other things if you need too
<bryce> ok great
<seb128> that should not impact on normal desktop updates
<seb128> we can merge changes from the hack bzr to the package one when we want
<bryce> yup
<seb128> and keep on doing normal updates in the meantime
<seb128> cool
<seb128> thanks
<bryce> great, thanks
<jcristau> tjaalton: i think the difference in xkb_symbols is what matters here
#ubuntu-x 2008-02-21
<tjaalton> jcristau: actually, the output is identical to what is on my desktop :/
<bryce> hey tjaalton, hmm, I did a system upgrade on my 965, and confirm that the new -intel and xserver are installed, yet greedy is not getting turned on
<tjaalton> hi bryce, I'll check mine
<bryce> tjaalton: have you done an upgrade on your system?  is it all working properly?
<bryce> thanks
<tjaalton> indeed.. hmm
<bryce> maybe the -intel built against an older version of the xserver?
<bryce> maybe we do need to up the build-depends after all?
<tjaalton> bryce: did you notice that apparently i945/950 have problems with XAA and Xv with compiz?
<tjaalton> oh, could be
<bryce> yes I did notice a spate of similar 945 and even some 915 issues that sounded suspiciously similar
<bryce> to the 965 issue
<bryce> I requested people test greedy with those the other day
<tjaalton> comment 44 on bug 177492
<ubotu> Launchpad bug 177492 in xserver-xorg-video-intel "EXA is balls-achingly slow" [Critical,Fix released] https://launchpad.net/bugs/177492
<tjaalton> should I drop the xaa patch?
<bryce> sounds like it
<tjaalton> ok, I'll disable it and bump up the build-dep on xserver-xorg-dev
<tjaalton> ready
<tjaalton> build tested too
<bryce> awesome
<tjaalton> damn, I had old headers and it's still broken, another try
<tjaalton> hmm, xorg-server 1ubuntu4 is not in the archive
<bryce> what?
<tjaalton> at least I can't install it
<bryce> apt-cache madison xserver-xorg-core says it's there
<bryce> weird
<tjaalton> but not on archive.u.c
<tjaalton> so the source is there, but it's not built
<bryce> huh
<tjaalton> bryce: I'll upload this anyway, it'll get built when the deps are available
<bryce> ok
<tjaalton> bryce: replied to the core-dev application :)
<bryce> thanks!
<bryce> seb128!
<seb128> hello bryce
<bryce> got some good news
<seb128> ah?
<bryce> yeah, in digging through the redhat code I found it already had scripts to generate patches
<bryce> they were written for rpm tools, but I was able to generalize them fairly easily
<seb128> good
<bryce> also, I built the gtk.patch against libgtk and it built fine, and I think it's probably ready for integration
<bryce> but I think you should look at it - it drops some xinerama api things that I'm concerned might break apps that are currently using that api
<bryce> anyway, I also created a bzr branch here:  https://code.launchpad.net/~bryceharrington/gnome-control-center/ssp-xrandr
<bryce> I stuck in a README there with more details on how to build things and so on
<bryce> I also put the TODO-UBUNTU from wiki into there for convenience; Launchpad went offline most of the day today and I couldn't access the wiki
<bryce> seb128: anyway, it's getting late for me, but if you could look into getting the gtk.patch integrated (with or without the xinerama changes), that would be a great first step - I think it's a prerequiste for the rest of this code.
<seb128> ok, will do
<seb128> bryce: good night
<ubotu> New bug: #128543 in xorg (main) "suspend works from command line, but not via GNOME menu" [Undecided,New] https://launchpad.net/bugs/128543
<ubotu> New bug: #193990 in xorg (main) "Empty Screen and Graphics preferences" [Undecided,New] https://launchpad.net/bugs/193990
<ubotu> New bug: #194055 in pixman (main) "package libpixman-1-dev 0.9.6-1 failed to install/upgrade: Versuche, ?/usr/lib/libpixman-1.so? zu ?berschreiben, welches auch in Paket libpixman1 ist" [Undecided,New] https://launchpad.net/bugs/194055
<seb128> bryce: around?
<bryce> yup
<bryce> seb128: what's up?
<seb128> bryce: fedora is using no gtk patch apparently?
<bryce> seb128: really?
<seb128> yes
<bryce> seb128: I actually don't know any specifics about the gtk.patch
<bryce> where have you heard this?
<seb128> I looked on their viewcvs as I usually do when I look at their patches
<bryce> I was testing last night with it installed and did not find it made a difference
<bryce> (but I figured I'd done something wrong)
<bryce> hmm... well perhaps it simply hadn't been submitted yet?
<bryce> reading Soeren's email it sounds like they're planning on including it for fedora 9
<bryce> ah, ok - grepping through the source code, none of the new functions in gtk.patch are actually referred to by the new code
<bryce> so I guess we can ignore it for now
<bryce> tjaalton: cjwatson is asking me about bug 173411.  got thoughts on how we should solve it?  obviously restoring the input portions to xorg.conf would be a possibility, but are there other approaches?
<ubotu> Launchpad bug 173411 in xorg "[Hardy][Regression] Touchpad vertical scroll does not work" [Medium,Confirmed] https://launchpad.net/bugs/173411
<tjaalton> bryce: well, input-hotplug would be the alternative, :)
<bryce> tjaalton: well, but what work needs to be completed on that to resolve this bug?
<tjaalton> bryce: maybe asking if david has any pathces he started to work on, or write a script which generates an fdi-file from xorg.conf
<bryce> hmm
<ubotu> New bug: #194078 in xterm (main) "Setting boldMode to false does not disable the behaviour" [Undecided,New] https://launchpad.net/bugs/194078
<ubotu> New bug: #194090 in linux-restricted-modules-2.6.24 (restricted) "fglrx restricted driver doesn't work on hardy" [Undecided,New] https://launchpad.net/bugs/194090
<ubotu> New bug: #193828 in xserver-xorg-video-ati (main) "ATI Radeon 9000 + Asus VW195D 1440x900 lcd monitor: left black bar showed at highest resolution" [Undecided,Incomplete] https://launchpad.net/bugs/193828
<ubotu> New bug: #192231 in dell "[Hardy] Machines with nvidia cards resume to a white screen (dup-of: 160264)" [High,Confirmed] https://launchpad.net/bugs/192231
<pwnguin> i love people who come into an inactive bug, ask if there's still a problem, and then take off because they have no idea how to solve the problem
<pwnguin> maybe this guy's different though. there's a "We" somewhere
<pwnguin> perhaps one of the people he represents will have a clue I'm missing
<bryce> pwnguin: which bug?
<pwnguin> bug #140644
<ubotu> Launchpad bug 140644 in gnome-power-manager "xset fails to turn off LCD screen" [Low,Incomplete] https://launchpad.net/bugs/140644
<pwnguin> i dont have the laptop with me
<pwnguin> and unless you've got a toshiba handy
<bryce> nope
<pwnguin> i doubt you'll be able to fix it either
<pwnguin> which is why it's been sitting
<bryce> wasn't planning to ;-)
<bryce> just curious who the  triager was
<pwnguin> never seem em on irc
<bryce> I don't recognize the name either, although he's got a decent amount of karma
<pwnguin> i just get a bit frustrated at the cookie cutter reports using the imperial form
<pwnguin> like im not part of "We"
<bryce> yeah, I feel the pain...  personally I try avoiding use of canned replies, although I understand when going through a lot of bugs, cut and paste is easier
<bryce> I gave a reply there that is probably equally useless but a bit less canned ;-)
<pwnguin> if i recall correctly
<bryce> I suspect the bug may be mis-filed against g-p-m, but it really requires someone more knowledgeable in the power management side of things to tell
<pwnguin> i filed it against gpm because thats what gpm uses
<pwnguin> and it fails
<pwnguin> therefore gpm fails
 * bryce nod
<bryce> +s
<bryce> that's the right starting guess to make
<bryce> g-p-m triagers need to evaluate and then decide if it's really an underlying problem with acpi, the kernel, X, ...
<pwnguin> judging by the gpm bug lists, i think they have bigger fish to fry
 * bryce nods
<pwnguin> i think i found that out while hunting for the reason dpms triggers while watching more than one episode with totem
<bryce> g-p-m is my biggest annoyance with linux these days (mainly the screen blanking behavior)
<bryce> er s/blanking/dimming/
<ubotu> New bug: #173837 in xorg-server (main) "gdmflexiserver or 'new login in a window' doesn't refresh screen" [Undecided,New] https://launchpad.net/bugs/173837
<ubotu> New bug: #194149 in xorg (main) "Microsoft Wireless Notebook Mouse: horizontal scroll not working + wishlist" [Undecided,New] https://launchpad.net/bugs/194149
<ubotu> New bug: #194150 in xserver-xorg-video-intel (main) "dual monitor" [Undecided,New] https://launchpad.net/bugs/194150
#ubuntu-x 2008-02-22
<ubotu> New bug: #189580 in mythtv "mythfrontend.real crashed with SIGSEGV in glXMakeCurrentReadSGI()" [Undecided,Invalid] https://launchpad.net/bugs/189580
<ubotu> New bug: #194198 in linux-restricted-modules-2.6.22 "linux kernel overwrites menu.lst causing bad boot" [Undecided,New] https://launchpad.net/bugs/194198
<bryce> a couple of the xrandr gui changes ready to go --- http://people.ubuntu.com/~bryce/Testing/XrandrGui/
<ubotu> New bug: #189318 in ubuntu "tty not working (dup-of: 129910)" [Undecided,New] https://launchpad.net/bugs/189318
<ubotu> New bug: #194214 in xorg (main) "Keys get "stuck" down" [Medium,Confirmed] https://launchpad.net/bugs/194214
<ubotu> New bug: #177494 in xserver-xorg-driver-nv "samsung 2232bw 22" widescreen wrong resolution" [Undecided,New] https://launchpad.net/bugs/177494
<ubotu> New bug: #155276 in xserver-xorg-video-intel (main) "Resolution on i915 can't set mode 1600x1200" [Undecided,New] https://launchpad.net/bugs/155276
<bryce> good morning mvo
<mvo> hey bryce!
<bryce> morning seb128
<seb128> hello bryce
<seb128> bryce: looks like try they landed the xrandr gtk changes in the new unstable tarball they rolled
<tjaalton> morning guys
<bryce> heya tjaalton
<bryce> seb128: aha
<tjaalton> nvidia 9600GT.. a new blob should be on it's way then
<seb128> we will not track the new serie for hardy but I'll have a look to backporting that to the stable one if they didn't do it yet
<bryce> seb128: great
<bryce> seb128: I emailed a couple patches your way for review.  The gnome-desktop one may be ready for inclusion; the daemon I think still needs more testing
<bryce> I'm working on the gnome-control-center patch presently
<seb128> ok
<seb128> the freeze is still in action?
<bryce> I'm not sure if steve's cut alpha5 yet
<seb128> bryce: http://launchpadlibrarian.net/6875673/%3Cfdopen%3E
<seb128> bryce: does that looks like an xorg bug to you or something the client lib is doing wrong rather?
 * bryce looks
<seb128> that's bug #94076, looks like his computer was in a weird state, probably not worth spending to much work
<ubotu> Launchpad bug 94076 in gnome-panel "[apport] gnome-panel crashed with SIGSEGV in _dl_fini()" [Medium,Confirmed] https://launchpad.net/bugs/94076
<bryce> hmm, it looks like the error came in around #27-#29 and was due to a dropped music link connection
<bryce> the _X stuff in #4-#7 look like just calls to set up the gtk error handling stuff
<bryce> it's a fairly nasty looking backtrace though
<seb128> I think #7 is the xorg call to change the icon used for the dialog
<seb128> but it could be that the call is made using a broken argument
<bryce> yeah
<seb128> I asked the guy if he had the issue again
<seb128> those bugs are not easy to debug if they can't be triggered
<bryce> it sort of looks like the client app is entering a failure mode, and trying to send something to the X server (#6 an XSend call) but that's failing for whatever reason
<bryce> yeah
<bryce> I would guess it's that the error handling code is not making a valid call to the X server, so it's returning an error
<bryce> s/error/IO error/
<bryce> I can easily imagine that - app developers often don't test their error handling logic as well as their routine operation logic, so there can be hidden bugs in it
<bryce> I think it'd probably be necessary to synthetically reproduce the error situation in order to fully debug the issue
<bryce> but there might already be enough info in that backtrace for upstream.
<seb128> right
<seb128> he wrote that the computer was not responding
<seb128> it might have been that xorg or something was in a buggy state
<seb128> anyway, let's see what he replies
<bryce> ah, like an out of memory situation or something...
<seb128> if that was a one time thing I'll likely close the bug
 * bryce nods
<ubotu> New bug: #106846 in linux-restricted-modules-2.6.24 (restricted) "When using ATI binary driver, Menu Item has wrong 'command' specified for fireglcontrolpanel" [Undecided,New] https://launchpad.net/bugs/106846
<ubotu> New bug: #119561 in xorg (main) "Not getting full screen resolution" [Undecided,Incomplete] https://launchpad.net/bugs/119561
<ubotu> New bug: #133444 in xorg (main) "Radeon IGP 330M/340M/350M" [Undecided,Incomplete] https://launchpad.net/bugs/133444
<ubotu> New bug: #138721 in xorg (main) "radeon 9600 dual graphic card secondery monitor works not" [Undecided,Incomplete] https://launchpad.net/bugs/138721
<ubotu> New bug: #145846 in xorg-server (main) "screen goes blank when switching user" [Undecided,New] https://launchpad.net/bugs/145846
<ubotu> New bug: #114782 in xorg (main) "ATI Radeon card with Acer AL1916W incorrect resolution" [Undecided,Incomplete] https://launchpad.net/bugs/114782
<ubotu> New bug: #117075 in xorg (main) "X server crash (Firefox related?)" [Undecided,New] https://launchpad.net/bugs/117075
<ubotu> New bug: #164805 in xorg (main) "driver for x1400 doesnt work" [Undecided,New] https://launchpad.net/bugs/164805
<ubotu> New bug: #163282 in linux-restricted-modules-2.6.24 (restricted) "cannot use advanced features of desktop" [Undecided,Invalid] https://launchpad.net/bugs/163282
<ubotu> New bug: #156308 in xorg-server (main) "9700 mobility video" [Undecided,Incomplete] https://launchpad.net/bugs/156308
<ubotu> New bug: #194403 in xserver-xorg-input-synaptics "Random 4-way scroll button behaviour with Alps touchpad" [Undecided,New] https://launchpad.net/bugs/194403
<ubotu> New bug: #181114 in linux-restricted-modules-2.6.24 (restricted) "virtual terminals and dpms resume video scrambled" [Undecided,Confirmed] https://launchpad.net/bugs/181114
<seb128> do you guys have an opinion on whether bug #32963 is a driver issue or not?
<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
<ubotu> New bug: #189844 in xserver-xorg-video-nv (main) "[Hardy-Alpha 4 PPC] Screen resolution correct but shifted to the right" [Undecided,Confirmed] https://launchpad.net/bugs/189844
<bryce> seb128: hmm, interesting - some people report that it occurs only on upgrades, not fresh installs
<bryce> seb128: especially with comment #108 it sounds like totem is getting messed up by old totem preferences imported from a prior install...  that'd be my guess based on the comments
<bryce> from comment 107 it sounds like the particular Totem settings are XV_SATURATION and XV_BRIGHTNESS
<bryce> on the other hand, some people are also reporting trouble with other video players...  but maybe there is more than one bug being reported here
<bryce> seb128: so from the comments it seems pretty clear its an issue with how totem handles its preference settings, and is not a driver bug
<seb128> ok
<seb128> I've no idea what XV_SATURATION and XV_BRIGHTNESS are though
<seb128> and why totem would change those
<seb128> #116 has the same issue using xine
<bryce> I'm not familiar with them either, but can imagine how setting them to invalid values could result in the behavior described
<bryce> my guess is that totem is changed how it interprets the values resulting in it using invalid settings
<bryce> I think 116 may be an unrelated bug.  The commenter says his image differs from what others are reporting
<bryce> seb128: have you had a chance to look at the packages I sent last night?
<seb128> bryce: not really looked to those yet because we are frozen, but I plan to look at upload things which are good on monday if we are unfrozen
<seb128> as said the GTK change is in trunk so likely good enough to be pushed to users ;-)
<bryce> ok
<ubotu> New bug: #193777 in totem (main) "Totem-xine crashes on startup (dup-of: 111257)" [Undecided,Invalid] https://launchpad.net/bugs/193777
<seb128> bryce: did you test the failsafe xorg on cds?
<seb128> bryce: bug #194187, the guy says gdm doesn't restart after configuring xorg, not sure if that's something you read about before
<ubotu> Launchpad bug 194187 in gdm "livecd gdm failure after low-graphics dialog" [Undecided,Invalid] https://launchpad.net/bugs/194187
<bryce> seb128: on the alpha5 cd's?  no, but I know there are several issues
<seb128> if I understand things correctly xorg doesn't start, he gets the displaygtk-config thing and then doesn't go back to gdm and can't log in
<bryce> hmm
<bryce> interesting, this is different than I expected
<bryce> it looks like it's just that gdm is failing to get stopped / restarted properly by the scripts
<bryce> displayconfig-gtk seems to have all worked properly other than that, and it sounds like it generated a correctly working xorg.conf
<bryce> perhaps it's an amd64 specific issue?  I didn't run into that in my testing of it
<seb128> dunno, I tried on normal install but not on CD
<seb128> is there a known issue that displayconfig-gtk breaks the keyboard layout in gutsy?
<bryce> no not that I know of
<bryce> displayconfig-gtk didn't touch anything in relation to input configuration for gutsy
<ubotu> New bug: #193545 in compiz (main) "pressed keys repeats when mouse is clicked (dup-of: 194214)" [Undecided,New] https://launchpad.net/bugs/193545
<ubotu> New bug: #194521 in xserver-xorg-video-ati (main) "ATI Mobility M1 -- the mouse cursor garbles some underlying pixels" [Undecided,New] https://launchpad.net/bugs/194521
<ubotu> New bug: #194528 in nvidia-settings (universe) "[Hardy] nvidia-settings crashed with SIGSEGV in g_closure_invoke()" [Undecided,New] https://launchpad.net/bugs/194528
<ubotu> New bug: #194532 in xulrunner-1.9 (main) "The HTML graphics renderer in Firefox displays top menu of Ubuntu's desktop multiple times (dup-of: 186186)" [Undecided,New] https://launchpad.net/bugs/194532
#ubuntu-x 2008-02-23
<ubotu> New bug: #194571 in xserver-xorg-video-intel (main) "Regression: 2:2.2.0.90-2ubuntu7 from 2:2.2.0.90-2ubuntu6: Slow scrolling" [Undecided,New] https://launchpad.net/bugs/194571
<ubotu> New bug: #194599 in linux-restricted-modules-2.6.24 (restricted) "nvidia-glx-new is unstabile and doesnt allow some games (driver issue)" [Undecided,New] https://launchpad.net/bugs/194599
<ubotu> New bug: #194526 in xkeyboard-config ""Use keyboard LED to show alternative layout" doesn't work at all" [Undecided,Confirmed] https://launchpad.net/bugs/194526
<ubotu> New bug: #34155 in xserver-xorg-driver-ati "Suspend-To-Ram (S3) doesn't work on Dell Latitude C640" [Medium,Confirmed] https://launchpad.net/bugs/34155
<ubotu> New bug: #194703 in xorg (main) "wrong window behavior with two tfts" [Undecided,New] https://launchpad.net/bugs/194703
<ubotu> New bug: #194552 in libxrandr (main) "Hardy starts with wrong display resolution (dup-of: 191878)" [Undecided,New] https://launchpad.net/bugs/194552
<ubotu> New bug: #156621 in xserver-xorg-video-intel (main) "[gutsy] Closing the lid will crash the system no matter how the gnome power manager is set, but system (Dell X300) will suspend/resume just fine in any other way." [Undecided,Confirmed] https://launchpad.net/bugs/156621
<ubotu> New bug: #194826 in xserver-xorg-video-via (main) "Corrupt display while/after booting on VIA P4M900 internal graphiccard" [Undecided,New] https://launchpad.net/bugs/194826
<ubotu> New bug: #194827 in linux-restricted-modules-2.6.24 (restricted) "package nvidia-glx-new 169.09+2.6.24.8-7.19 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/194827
<ubotu> New bug: #194845 in xorg (main) "No X when starting the latest daily-live Kubuntu-KDE4 liveCD" [Undecided,New] https://launchpad.net/bugs/194845
<ubotu> New bug: #150143 in xserver-xorg-driver-nv "nvidia driver crash with a big screen" [Undecided,New] https://launchpad.net/bugs/150143
<ubotu> New bug: #194637 in compiz (main) "[Hardy] Keyboard stuck when spacebar pressed and mouse used (dup-of: 194214)" [Undecided,Incomplete] https://launchpad.net/bugs/194637
#ubuntu-x 2008-02-24
<ubotu> New bug: #194932 in compiz (main) "Compiz Memory Leak (dup-of: 151168)" [Undecided,New] https://launchpad.net/bugs/194932
<ubotu> New bug: #194936 in xserver-xorg-video-intel (main) "Problem with shutdown and reboot with Intel X3500 82G35 Express Integrated Graphics Controller " [Undecided,New] https://launchpad.net/bugs/194936
<desertc> :)  :)  :)  :)
<desertc> http://www.phoronix.com/scan.php?page=article&item=amd_tcore_release&num=1
<bryce_> wow
<ubotu> New bug: #194963 in linux-restricted-modules-2.6.24 (restricted) "ATI Driver not working on Compaq V2321US (Xpress200)" [Undecided,New] https://launchpad.net/bugs/194963
<ubotu> New bug: #194991 in xorg (main) "Dell e173fp flat panel screen resolution issues" [Undecided,New] https://launchpad.net/bugs/194991
<ubotu> New bug: #195051 in xserver-xorg-video-ati (main) "X freezes when Compiz is enabled on ATI Radeon Mobility" [Undecided,New] https://launchpad.net/bugs/195051
<ubotu> New bug: #195062 in xserver-xorg-video-intel (main) "skype video crashes xorg" [Undecided,New] https://launchpad.net/bugs/195062
<ubotu> New bug: #182584 in wine (universe) "[hardy] Wine makes X crash (dup-of: 178292)" [Undecided,New] https://launchpad.net/bugs/182584
<ubotu> New bug: #191757 in ubuntu "Ubuntu 8.04 LTS (Hardy Heron) Alpha 4 livecd Freezes Black Screen (dup-of: 176377)" [Undecided,New] https://launchpad.net/bugs/191757
#ubuntu-x 2009-02-16
<amason_> hey guys is UXA & DRI2 working in jaunty with -intel ? i know there are known issues with alpha4 and EXA. I was hoping to test out some newer GUI packages and can deal with most things not working but need the display in order to test 
<DBO> can I just me too on this question.  I am very curious about intel on jaunty as I keep hearing very scary things about it
<RAOF> UXA may or may not work for you.  For some people it's fantastic, for some people it fails to bring up X.
 * DBO glares at RAOF
<DBO> RAOF, any idea what the plans are looking like for intel if UXA cant be brought in line?
<amason_> RAOF: if UXA isn't working can EXA be used ?
<amason_> doesn't have to be fast
<amason_> just working
<RAOF> amason_: EXA should still work.  Apparently, it's alarmingly slow for some people, but it should still work.
<amason_> RAOF: ok thanks 
<pwnguin> how long as the font size optimization been in?
<tjaalton> pwnguin: since the sprint
<pwnguin> a few weeks ago?
<tjaalton> yes
<pwnguin> interesting
<pwnguin> a few weeks ago i noticed my jaunty laptop font kerning is screwy
<pwnguin> the thing is, my monitor reports a dpi of 96
<pwnguin> so there shouldn't have been a change
<tjaalton> only forcing the 96dpi was removed
<tjaalton> but maybe something else changed too
<tjaalton> and I believe it was before that
<tjaalton> since my terminal font is smaller now
<tjaalton> uh, so unplugging the only keyboard isn't too useful
<mnemo> amason_: if you're still here and you're still interested in how well UXA works on jaunty, check out this page --> https://wiki.ubuntu.com/X/UxaTesting
<RAOF> Hm.  We should probably do a bit more to ensure that GDM starts _after_ HAL is _fully_ initialised.
<jcristau> RAOF: 4844bff in xorg-server
<RAOF> jcristau: Is that a git hash, or a mis-spelled bug number?
<jcristau> the former
<RAOF> Right.  So, it'll be heading up soon, and I can stop killing my VTs by SAKing X.
<maxb> I discovered that if you SAK VT1, the kernel panics :-)
#ubuntu-x 2009-02-18
<tjaalton> oh man..
<tjaalton> whot's latest blog entry would suggest that evdev now does what wacom does?
<Alexia_Death> ?
<Alexia_Death> link?
<tjaalton> http://who-t.blogspot.com/2009/02/generic-axis-support-in-evdev.html
<tjaalton> needs xserver master though
<Alexia_Death> hmm...
<Alexia_Death> Will be while untill it gets in general use.
<tjaalton> for jaunty+1
#ubuntu-x 2009-02-19
<maco> how can i find out how recent the drivers i'm using in jaunty are as compared to upstream Xorg?
<maxb> look at the version number? :-)
<maco> i mean as compared to git snapshots
<maco> i'm being asked about the ddx
<RAOF> We don't appear to be using git snapshots at all.
<RAOF> Wel, with the exception of nouveau and openchrome.
<RAOF> If you're not on either of those, the answer is "pretty close to the release version".
<maco> well i'm going to go ahead and try git master for intel and see if it's better than what's in jaunty, because the gpu wedges fairly often in jaunty. (uxa has no effect on how often)
<maco> (that's on i965, if anyone cares. also when that happens and i alt+sysrq+k, it just makes vertical stripes. X doesn't die cleanly, so GDM doesn't re-spawn.)
<bryce> morning
<mnemo> hi bryce :)
<mnemo> either you overslept badly or, you're in US western timezone?
<tjaalton> yes
<mnemo> "bryce harrington" sounds so british ;>
<bryce> mnemo: I had an early morning meeting, then went for breakfast
<bryce> it was a meeting about X gfx driver support on ARM
<mnemo> ah cool
<bryce> which sounds like it's going to be b!tch and probably the result is going to make nobody happy
<bryce> but we'll see
<mnemo> oh, whats the issue that makes it hard?
<bryce> there is currently no driver developed for the hardware, and the discussions so far are that the interested companies want to make a proprietary driver
<mnemo> aah
<bryce> anyway
<bryce> on the plus side, I've really made some good progress against the -ati bug load the past couple days :-)
<mnemo> sweet
<bryce> with tormod and other's help, we've gone from 158 bugs at the start of last month, to about 111 right now
<bryce> and a big bulk of those are closed as fixed, not as expired
<mnemo> i guess all bugs were against the open source ati driver right?
<bryce> right, I'm not counting the -fglrx bugs
<bryce> there were several which were just problems in -ati after having leftover bits of -fglrx, so don't know if those really should be counted as fixed, but the person's problem was solved in those cases
<bryce> I don't want to look at -intel right now tho
<mnemo> yea lots of people asking about intel perf etc
<mnemo> have you seen this bug btw? --> https://bugs.launchpad.net/ubuntu/+source/libsdl1.2/+bug/328932
<ubottu> Ubuntu bug 328932 in libsdl1.2 "X11 driver not configured with OpenGL" [High,Triaged]
<mnemo> its an SDL bug but its sort of annoying
<mnemo> i want to stress UXA with some games but..
<bryce> http://people.ubuntu.com/~bryce/totals.svg
<bryce> wish we could unsub ubuntu-x from lrm-2.6.24, heh
<mnemo> whats lrm?
<bryce> linux-restricted-modules
<mnemo> aah
<bryce> mnemo: I don't normally look at libsdl bugs tbh, but will review real quick in case it is an X issue
<mnemo> i think its a packing bug in libsdl
<mnemo> so its definitely not in your area
<bryce> ok
<bryce> looks like they're using -nvidia
<mnemo> it repros on all cards
<mnemo> so its like all sdl+GL games on all cards
<mnemo> bryce: for the the arm stuff.. are you considering ubuntu nvidia tegra?
<bryce>     + Switch build-dependency to libgl1-mesa-dev from xlibmesa-gl-dev.
<bryce>     + Switch dependency of libsdl1.2-dev to libglu1-mesa-dev from 
<bryce>       libglu1-xorg-dev.
<bryce> those changes in 1.2.13-3 seem relevant
<mnemo> aah right
<bryce> the ubuntu changes are all just sound stuff, which I wouldn't think could cause this
<bryce> the 1.2.13-4 changes seem innocuous
<bryce> lots of changes in 1.2.13-3 though; that'd be my guess as to where to look.  Those mesa deps changes seem like the most relevant changes
<bryce> hmm, although in the previous ubuntu version before that, it already had one of those changes:
<bryce>     - Prefer libgl1-mesa-dev build-dependency over xlibmesa-gl-dev.
<mnemo> I also have a vague memory that it worked in early feb
<mnemo> but i dont remember exact date when it stopped working
<bryce> well it would probably be good to revert to libsdl1.2 (1.2.13-2ubuntu1) and verify you cannot reproduce the issue
<mnemo> yea I will try that
<mnemo> thanks
<bryce> if that is the case, then it points to one of the libsdl1.2 changes between that version and the current one
<mnemo> yup
<bryce> if not, then perhaps something in mesa or -nvidia is to blame
<bryce> iirc we got new -nvidia drivers around that time
<bryce> mesa 7.3-1ubuntu1 got merged at the end of Jan, so sort of fits the timeframe too, although that was just going from an rc to the official release so was mostly just bug fixes
<bryce> anyway, good luck
<mnemo> thx
#ubuntu-x 2009-02-20
<federico1> bryce: pingety ping
<federico1> bryce: sorry if I sound like a broken record... do you remember that bug in the intel driver where it said that VGA was connected when it actually isn't?
<bryce> hi federico1
<bryce> uhh, vaguely
<federico1> I thought you had a patch?
<federico1> s/you/ubuntu
<bryce> lemme check
<bryce> 108_dont_disable_vga_centering_bit.patch ?
<federico1> hmm
<bryce> commit 3aa8591abfbe8db0f13912910c850fdd748808df
<federico1> one sec, let me check
<bryce> not sure that's it, that's for bug #17235
<ubottu> Launchpad bug 17235 in ubuntu "CXX transition : rudiments" [Medium,Fix released] https://launchpad.net/bugs/17235
<bryce> silly ubottu
<bryce> for ubottu, bug #324913
<ubottu> Launchpad bug 324913 in xserver-xorg-video-intel "With my Sony Vaio (i945) I can swith to have my internal screen also on the projector with "xrandr --auto" but when unplugging the projector the internal screen image disappears" [High,Fix released] https://launchpad.net/bugs/324913
<federico1> the b.f.o doesn't look like it
<federico1> I remember that patch being way bigger
<bryce> hmm, don't see any other patches relevant to that, can you give me some more context to jog my memory?
<federico1> I have this url in my journal - http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/i830_quirks.c
<federico1> or maybe the patch was a quirk for a certain model?
<bryce> oh that could be
<federico1> we had a problem where you boot with no external displays connected, and gnome-panel appears at 1024x768 while your LCD is in fact much bigger
<federico1> it happened because the driver lied about VGA being connected, and defaulted to 1024x768 --- then, the panel was stupid and assummed that the first output was the primary display
<bryce> did xrandr show a phantom output in that case?
<bryce> yep, that's not an uncommon issue
<bryce> https://wiki.ubuntu.com/X/Quirks
<federico1> bryce: yeah, it showed an output that wasn't in fact there
<bryce> that's usually more common with phantom s-video or lvds outputs
<bryce> federico1: generally the procedure is to have the user verify that by setting Option "Ignore" on the output, that it makes the issue go away
<bryce> if it does, then upstream can (usually) quirk it
<federico1> it's probably quirkable for some cards
<federico1> although I remember keithp or anholt saying that this was a race condition when initializing the driver
<bryce> mm, there is a quirk_ignore_crt() available
<federico1> maybe I should ask them :)
<bryce> Sony VGC-LT71DB has no VGA output (bug #17395) 
<ubottu> Launchpad bug 17395 in kbd-chooser "kbd-chooser: new changes from Debian require merging" [Medium,Fix released] https://launchpad.net/bugs/17395
<bryce> that's the only hw with that quirk currently
<bryce> yep, best to ask one of them, or jesse
<federico1> which jesse?
<federico1> yeah, it looks a lot like that bug
<bryce> barnes
<federico1> bryce: thanks
<bryce> sure thing
<federico1> oh, I don't know him :)
<federico1> so
<federico1> I'm talking to the fedora guys, trying coordinate some RANDR love
<federico1> I've been doing a lot of randr stuff for opensuse
<federico1> the gnome stack is pretty much okay except for some panel problems, and probably some gdm ones
<federico1> I have three or four main areas of bugs:
<federico1> - panel
<federico1> - intel driver
<federico1> - hooking to signals from gnome-power-manager (re-detect displays on unsuspend) and something about docking stations (re-detect on dock/undock, figure out what people actually do there)
<federico1> so if we could split up the work...
<bryce> there's also a set of bugs that seem to be particular to randrwrap in gnome-display-properties, i.e. that can't be reproduced using just the xrandr cmdline tool
<bryce> I find those frustrating, because they're ambiguous who to upstream them to
<bryce> do you know if the fedora guys had special plans for working on these bugs?
<federico1> the randrwrap ones?
<bryce> well, any of the above, but yeah the randrwrap ones in particular
<federico1> I've been hacking on randrwrap - don't really know what soeren is doing these days
<federico1> so ping me about those
<bryce> ok
<bryce> lately esp. this week I've been focusing mostly on -ati bugs
<federico1> about the other bugs, I'm discussing things with mclasen in #fedora-desktop
<federico1> ooh
<bryce> the next couple weeks I've planned to focus on xserver crash bugs, since we now have some good crash capturing tools in place with apport so are getting better auto-collected backtraces
<federico1> bryce:  my fucking ATI driver will sometimes do a RANDR change, and freeze the displays.  I have to switch to a text VT and then back, and then it will be correct
<bryce> mm, which version of -ati?
<federico1> but a weird kind of freeze - you don't see the mouse pointer move, but if you move it, you see that some widgets highlight/spin/whatever
<federico1> hmm, Xorg.0.log says:
<federico1> Module radeon blah blah, module version = 4.3.0 - is that what you need?
<bryce> hmm, I'd expect 6.9.xxx
<federico1> one sec, I'll tell you the real version
<bryce> anyway, I've not run across a bug report similar to that so far
<federico1> 6.9.0 plus a few patches which are probably backports
 * bryce nods
<federico1> bryce: ok
<federico1> hmm
<bryce> what chip class?  lspci | grep VGA
<federico1> what info would you need to diagnose this?
<federico1> RV280 [Radeon 9200 SE]
<bryce> ahh
<bryce> lots of bugs on that one
<federico1> so
<federico1> normally I have VGA connected
<federico1> when I plug a second monitor in the DVI and configure it to the *left* of the VGA one, and make it use a smaller resolution, I get that kind of freeze
<bryce> there is a tool called radeontool you can get from git.freedesktop.org in airlied's stuff, which provides register dumps
<federico1> I'm not yet sure if it's 100% reproducible, but happens often enough for me :)
<bryce> with bugs like these, I would collect register dumps once from when you see the problem and once when you are nto seeing the problem, and then file a bug at freedesktop.org with that info, plus Xorg.0.log and lspci info
<federico1> sweet
<federico1> thanks, I'll do that
<bryce> here's some rv280 / xrandr bugs we have:
<bryce> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-
<bryce> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/205085
<ubottu> Ubuntu bug 205085 in xserver-xorg-video-ati "[RV280 9250] Graphical glitches after resolution change with compiz enabled" [High,Incomplete]
<bryce> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/291715
<ubottu> Ubuntu bug 291715 in xserver-xorg-video-ati "[RV280 9200] ati driver with xrandr borked in intrepid" [High,Incomplete]
<federico1> oh, yeah, compiz seems full of epic fail
<bryce> yeah none of those seems an exact match, but seems there is something screwy with the xrandr behavior on rv280
<federico1> yeah
<federico1> oh, I remembered - I also get funny output when rotating 90 degrees
<federico1> anyway
<federico1> hmm
<federico1> I'll write a mail to you and interested people
<federico1> what's your email again?
<bryce> bryce@canonical.com
<federico1> thanks
<bryce> federico1: btw is your card AGP?  If it is, there's some quirking which sometimes helps
<federico1> yeah
<bryce>       Option "AGPMode" "2"
<bryce> try 1, 2, 4, 8
<bryce> _sometimes_ there is one that works better than others
<federico1> will do
 * federico1 sees todo.txt grow uncontrollably
<bryce> if so, quirks can be added - see http://wiki.ubuntu.com/X/Quirks
<bryce> heh, sorry :-)
<bryce> getting back to the panel bugs, I don't have the todo.txt space to work on them myself, but they seem to be the most commonly reported problem so far.  
<bryce> federico1: oh also at the last ubuntu developer sprint I collected a "projector sh!t list" of issues people were running into
<bryce> cross driver, xserver, gnome panel, and capplet
<federico1> url me :)
 * bryce eyeballs the ratty sheet of paper in his briefcase
<bryce> I'll have to type it up first.  I'll ping ya when I get that in
<federico1> hehe, I have a similar list here - http://en.opensuse.org/GNOME/Multiscreen 
<bryce> nice
<bryce> yeah I'll review that and my list, maybe in sharing notes we can squish a few of the bugs 
<federico1> oh, duh, I had a link to the intel bug I was asking you about right in that page - https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/152416
<ubottu> Ubuntu bug 152416 in xserver-xorg-video-intel "GNOME panels are smaller than detected and set resolution" [Low,Fix released]
<bryce> aha 
<bryce> ok yeah that quirk patch went upstream already
<federico1> bryce: make sure you have a b.n.c account, or our @#$% bugzilla won't show you bug dependencies.  Also, if you find a bug for which you don't have permission, it's probably a SLED bug - tell me and I'll make it visible (we have an annoyingly paranoid bugzilla team...)
<bryce> ok cool
<federico1> anyway
<federico1> my clearinghouse is https://bugzilla.novell.com/show_bug.cgi?id=multiscreen-tracker
<dholbach> hiya
<dholbach> I have an interesting case of something weird in X going on :)
<dholbach> in dmesg:
<dholbach> [15560.738232] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0
<dholbach> in /var/log/Xorg.0.log.old (had to restart X over SSH to un-black it)
<dholbach> http://paste.ubuntu.com/120487/
<dholbach> any idea?
<mnemo> dholbach: EXA or UXA? and what chipset?
<dholbach> VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
<seb128> dholbach: what issue do you have?
<dholbach> yes, EXA (didn't change from the default and it says something about it in the log
<dholbach> seb128: 
<dholbach>  I have an interesting case of something weird in X going on :)
<dholbach>  in dmesg:
<dholbach>  [15560.738232] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0
<dholbach>  in /var/log/Xorg.0.log.old (had to restart X over SSH to un-black it)
<dholbach>  http://paste.ubuntu.com/120487/
<dholbach>  any idea?
<seb128> hum, no, no idea
<seb128> I've the same card on my laptop but no such issue
<dholbach> it was the first time it happened to me
 * dholbach tries pulling the plug again :)
<dholbach> ok, worked this time :)
<mnemo> dholbach: check the backtrace in xorg... if it's like an ioctl then probably the chip or hung... if it's a segv or something the stacktrace alone might be actionable for upstream
<mnemo> i've seen the "vblank on disabled pipe" message before but on a machined that "worked"
<mnemo> so I think you might have both the vblank warning and then some other thing as well that causes the crash
<dholbach> mnemo: there was no backtrace - no segfault
<mnemo> so xorg is inside the WaitForSomething() function??
<mnemo> i mean check the backtrace in gdb (dont look for a stacktrace in xorg.log)
<dholbach> ok
<Ng> hmm, should I be using EXA or UXA on jaunty atm? (965)
<Ng> I seem to be using the former and switching desktops isn't the fastest thing ever, it has to be said
<seb128> exa works fine for me
<seb128> uxa makes xorg crash on resume
<Ng> well it feels a lot snappier now I don't have sunbird eating my CPU like there's no tomorrow
<Ng> different to intrepid, but not really slow
<tjaalton> Ng: bug 320813
<ubottu> Launchpad bug 320813 in linux "[drm] compiz animations cause temporary freezes with vblank" [High,In progress] https://launchpad.net/bugs/320813
<tjaalton> I'll disable vblank again once I get home
<Ng> aha
<tjaalton> with uxa you get dri2 and hence no vblank
<tjaalton> and mine crashes on resume also with exa
<Ng> interesting. I've not yet done a suspend/resume cycle
<Ng> bah why is ssh-agent running
<Ng> vte feels a bunch faster, which rocks
<Ng> so yeah, I have x-session-manager spawning ssh-agent and seahorse-agent - isn't seahorse supposed to be at the top?
<seb128> Ng: echo $SSH_AUTH_SOCK
<Ng> seb128: that's pointing at /tmp/keyring-blah/socket.ssh, but nothing appears to be connected to it
<Ng> I did get a gnome style ssh password prompt the first time, but since then ssh has been prompting me in terminals
<Ng> (this was all working with auto-unlocked keyrings in intrepid, but I've hit problems before when ssh-agent and seahorse-agent were both running, afair)
<bryce> karmic koala
<bryce> seb128: "uxa makes xorg crash on resume" has it crashed more than the one time?  
<seb128> bryce: I tried several times during the sprint each time, I switched back to exa since but I can try again if you think that's fixed now
<bryce> ok.  no, no reason to think it's fixed yet
<seb128> what is this speed issue on intel every speaks about?
<seb128> xorg doesn't feel slow on jaunty for me on my laptop which has an intel card
<seb128> ie compiz animations are smooth, video plays correctly
<bryce> yeah, performance has been ok for me as well, even just with EXA
<bryce> but several people showed me their intel systems which were slow for desktop switching in compiz (which may be fixed now)
<seb128> you mean some seconds hangs and high cpu usage?
<seb128> some seconds or 1 second which seems long enough to watch
<bryce> iirc some people were having performance problems even with compiz off.  don't remember if anyone showed me that specific case
<james_w> not fixed yet, at least for me
<seb128> what is the issue?
<bryce> I had heard people were seeing on the order of seconds.  However all the examples I saw it was <1 sec between switches, but noticeably laggy
<seb128> I had a very slow animation and high cpu usage issue
<seb128> which I workarounded using 
<seb128> <driconf>
<seb128>     <device screen="0" driver="i965">
<seb128>         <application name="Default">
<seb128>             <option name="vblank_mode" value="0" />
<seb128>         </application>
<seb128>     </device>
<seb128> </driconf>
<seb128> drirc
<seb128> tjaalton gave me that workaround I think
<seb128> he said that was a patch dropped which will be added back no?
<bryce> yep, that was the issue that I am wondering if it may be fixed now.  it required a kernel change, which timg had on his todo list
<bryce> I'm uncertain if that patch will fix all the performance issues, or just this specific one
<seb128> well, once that fixed speed is as good as intrepid for me
<seb128> I'm wondering what are the other concerns
<bryce> ok, good to know
<seb128> I don't think we should switch to uxa if it's not tested for jaunty
<seb128> we are trying to get some credibility back from users who think we are breaking too much between ubuntu version and quality is going down this cycle
<bryce> er, who said we were considering uxa?
<seb128> so better to stay on what is proved to be stable if we can
<seb128> I was reading the mailing lists discussions
<bryce> which list?
<seb128> and it was not clear from me if we were considering exa performances as a blocker or not
<crevette> "let's going back to intel driver 2.2.x"
<crevette> :)
<bryce> well, getting the exa performance issues solved is a high priority.  I think the testing done so far shows uxa is not ready for prime time.  I talked with upstream about this choice (jesse) and he agreed sticking to exa probably makes the most sense so far
<seb128> "video card (intel) problems in jaunty" on ubuntu-devel-discuss
<bryce> oh heh, I unsubbed from that list a while ago.  Too much angst ;-)
<seb128> I tend to go through the title quickly and read some of the discussions just to know what the issues raised by users
<bryce> anyway, I told everyone to help test uxa and report bugs upstream.  If the issues everyone reports get all solved, then I guess we can consider uxa, but it's too unstable so far
<seb128> I think it's too late in a cycle we want to be stable do consider a such change now
<seb128> better to stay on exa and try fix performances issues
<bryce> heh, I see there's also a long thread on ctrl-alt-backspace
<seb128> that's noise
<seb128> I didn't read this one ;-)
<bryce> yep, looks like a tedious discussion
<tjaalton> bryce: hey, I'll disable intel-vblank again in mesa, once I get back home :)
<tjaalton> I don't think there's enough time to get it stable for jaunty
<bryce> ok
<bryce> seb128: btw I could only find one post there on "video card (intel) problems in jaunty"
<bryce> and it sounded mis-informed
<seb128> bryce: right, there is only one question and one reply, I was just not sure how informed the discussion was about the plans for jaunty
<adelie42> what package is X a member of? running ubuntu-minimal 8.10, installed xserver-xorg-core, xinit, and xauth but there is still no /usr/bin/X. any help?
<adelie42> he he,  installing 'xorg'. i'll see if that fixes it till somebody responds
<tjaalton> adelie42: xserver-xorg
<adelie42> sweet, thanks
#ubuntu-x 2009-02-21
<bryce> just got -ati bugs < 100
<tjaalton> huh, dist-upgrade killed X when configuring checkbox
<albert23> tjaalton: isn't it just asking if you want to replace a checkbox config file?
<albert23> that question seems to underpop sometimes
<tjaalton> albert23: that's what it asked when I ran 'dpkg --configure -a' after logging back in
<tjaalton> dpkg was hung in the background, trying to configure checkbox, so I had to kill it first
#ubuntu-x 2009-02-22
<maxb> The spurious config file prompt from checkbox is just a misuse of ucf btw. Bug is filed.
#ubuntu-x 2010-02-22
<Sarvatt> yuck, gpu hang on resume with the backported drm kernel
<RAOF> Booo.
<bryceh> tjaalton, looks like it was nvidia-settings where a lot of extra bugs were hiding
<RAOF> Mmm.  i915 doesn't like vga16fb claiming fb0 either.
<RAOF> Not one little bit.
<tjaalton> bryceh: hmm I think that was already separated from the remainder, or was that what you meant? can't find other than the obsolete totals.svg on p.u.c right now..
<tjaalton> the new one is well hidden and not linked to from anywhere I can find :)
<bryceh> tjaalton, http://www2.bryceharrington.org:8080/X/Graphs/totals.svg
<tjaalton> bryceh: yeah I noticed the email on ubuntu-x
<tjaalton> but nvidia-graphics-drivers is still in remainder?
<bryceh> tjaalton, is there really a 'nvidia-graphics-drivers' package?
<tjaalton> bryceh: yes, it's the latest one
<tjaalton> no -180 anymore
<bryceh> tjaalton, ok added http://www2.bryceharrington.org:8080/X/Graphs/totals.svg
<bryceh> currently it's a minuscule amount
<bryceh> btw nvidia-graphics-drivers == 'nvidia' in the chart
<tjaalton> yes, but the remainder looks more realistic now :)
<bryceh> hahaha
<bryceh> tjaalton, I did add some code to exclude some dead things like -keyboard and -joystick
<tjaalton> ~150 bugs there
<bryceh> so that brought -r128 and libx11 up into being shown
<tjaalton> joystick ain't dead, and keyboard has 0 bugs :)
<bryceh> it's close to dead
<tjaalton> hm, should request 1.5.0-2 to be uploaded to ubuntu
<tjaalton> urgh
<bryceh> and 0 bugs == dead in my book
<tjaalton> debian
<tjaalton> yes, keyboard is gone from the archive
<bryceh> ~150 bugs in which?
<tjaalton> in remainder
<bryceh> oh right
<bryceh> but I think there are lots of remaining X.org packages, and some have just ~1-2 bugs
<tjaalton> aren't those included in the remainder=
<tjaalton> ?
<tjaalton> that's how I understood it
<bryceh> yes, that's what I mean
<tjaalton> right
<bryceh> ~150 bugs but spread across ~100 packages
<tjaalton> I've been cleaning those from time to time
<bryceh> ah good
<Sarvatt> well, my intel machine definitely hates the backported drm kernel
<Sarvatt> which is odd because I usually run the mainline daily kernels on it and dont have any problems like this
<Sarvatt> 2 gpu hangs after resume and a dpms off randomly that i had to suspend/resume to recover from
<RAOF> Well wicked.
<Sarvatt> haven't had a chance to play with it on nouveau yet
<RAOF> Oh, yeah.  I was going to see whether 3D works for me with xorg-edgers again.
<RAOF> xorg-edgers has all the necessary 0.0.16 kernel interface packages, right?
<Sarvatt> yep!
<BUGabundo> cool
<Sarvatt> i put upstream nouveau which is based on 2.6.32 in it, had to make some changes to not put list_sort stuff in there since its a 2.6.33 thing
<BUGabundo> will have to try it again
#ubuntu-x 2010-02-23
<rickspencer3> bryceh, I'm installing Sauerbrten right now
<bryceh> hmm, with current lucid bits, I'm seeing a [drm:drm_mode_getfb] *ERROR* invalid framebuffer id and some garbage. 
<bryceh> rickspencer3, ok
<rickspencer3> *the* definitive graphics stress test
<bryceh> hah
<bryceh> it's a good one
<BUGabundo> eheh
<RAOF> How are we with the work-items for nouveau?  In particular, what can we do about nouveau-firmware?
<BUGabundo> it really pushes my laptop to its limits
 * bryceh uninstalls plymouth and eliminates the fb id issue
<BUGabundo> bryceh: :D
<BUGabundo> half of lucid test users, will end up without it :D
<bryceh> RAOF, I think the kernel team intends to obsolete nouveau-firmware with the generator thingee upstream is doing
<bryceh> I don't know if it's at the top of their todo list at the moment though, but it might be good to remind them if they don't get to it in the next few weeks
<RAOF> Ok, but that's not going to land before A3 :).  I've been tracking it in #nouveau, though, and it looks like mwk's making progress.
<bryceh> RAOF, in the meantime I agree we should add it as a dependency, although I'm not sure exactly where
<bryceh> RAOF, I need to read your email more closely
<bryceh> RAOF, does it need to be a kernel-level dependency?  If so then I suggest we bring it to apw and sconklin and let them decide
<RAOF> nouveau-firmware?  It pretty much is a kernel-level dependency, in that the kernel module shipped in lbm-nouveau wants the firmware.
<superm1> why not just put it in lbm-nouveau for now then and pull it out when it's time to go?
<superm1> would keep things far simpler without needing to obsolete the package
<RAOF> One reason might be it's uncertain licensing, but it *would* be simpler it it were just shipped in lbm-nouveau.
<superm1> what's this generator thing that upstream is working on?  it generates it on the fly for the HW?
<RAOF> Yes.
<RAOF> They're presume that's how the blob does it, too.
<superm1> what's it generating it from then?  the VBIOS?
<RAOF> From primitive operations & a description of the actual card hardware, I think.
<RAOF> There's already a voodoo generator for nv4x, which is why my laptop doesn't need the nouveau-firmware package.
<superm1> so then where did the firmware that exists today actually come from?
<RAOF> MMIO traces of the binary blob.  It's a dump of how the binary driver initialises the card.
<superm1> yucky
<RAOF> Hence âuncertain licensingâ
<superm1> so more importantly, what's the HW do w/o that firmware in place then?
<RAOF> It's not quite firmware.  It is really a small GPU program that's run on context switches.
<RAOF> So, without the voodoo you don't get context switches, which means you don't get any acceleration.
<superm1> so not the end of the world, just fairly inconvenient
<RAOF> Yeah.
<RAOF> It interacts badly with the fact that nv5x+ chips don't expose a linear framebuffer, though, which means that CPU fallback is quite a lot slower.
<RAOF> So nouveau needs to read VRAM, unswizzle the bits, do the CPU fallback, reswizzle, then push back to VRAM.
<RAOF> Current status of the voodoo generator for nvAx cards appears to be â[In quake 3] depending on place in the level where you're standing, and the direction you're looking, you can get anything from perfect display, through textures replaced with pink, up to totally bogus geometryâ
<rickspencer3> bryceh, so, this is totally subjective, but saurbraten seems smoother and more stable in Lucid
<rickspencer3> I suppose that's mostly -intel
<bryceh> nice
<bryceh> there has been some performance work done with -intel
<rickspencer3> bryceh, yeah, I'll really test it out this weekend when I have more than 10 mins ;)
<RAOF> tseliot's done a bang-up job on making the binary nvidia driver work nicely - Enabling & Disabling nvidia in Hardware Drivers just works.
<bryceh> sweet
<RAOF> Sarvatt: Your xorg-edgers mesa packages don't actually build nouveau's gallium driver because you've misspelt â--enable-gallium-nouveauâ - you've got â--enable-nouveau-galliumâ.
 * Sarvatt slaps forehead
<Sarvatt> uploaded a fixed one just now
<Sarvatt> sorry about that
<Sarvatt> was just that last upload with the problem, ran into some problems with the rules and did it by hand
<RAOF> You can make it up to me by telling me about how you build those packages, so I can fix it myself next time :).  I understand that there's a script that you run to automate the package uploads.
<Sarvatt> do you have auto-xorg-git?
<Sarvatt> ./auto-xorg-git -H hooks -g -d origin/ubuntu -p mesa -a 0ubuntu0sarvatt is what I use for mesa, I need to update the hooks though in bzr
<RAOF> Where's auto-xorg-git?
<Sarvatt> i'll update xorg-pkg-tools in bzr now
<Sarvatt> https://code.edge.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools
<snap-l> Having some problems with an Intel card and a new load of Karmic
<snap-l> The graphics for programs like Nexuiz and Stellarium are corrupted
<snap-l> Nexuiz won't display other players/ floors, etc. intermittently
<snap-l> Stellarium displays the toolbars with some fuzzed out look (like some memory corruption).
<snap-l> Any thoughts on how I can get 3D working properly on this machine?
<snap-l> It's an Asus K60I with an IntelÂ® Graphics Media Accelerator 4500M
<snap-l> 32 bit load of Ubuntu 9.10. Seems to be using the i915 driver
<RAOF> snap-l: Hm.  I've got the same chipset, but on Lucid, and I haven't noticed any corruption.
<RAOF> That said, I'm not the most demanding of 3D users.
<snap-l> Yeah, Compiz works just fine, but this is a bit strange
<snap-l> it seems like anything that requires several layers of textures gets messed up
<snap-l> Not sure if it's memory allocation or something else.
<Sarvatt> RAOF: for the nouveau ddx I use ./auto-xorg-git -H hooks -t + -g -d origin/ubuntu -a 0ubuntu0sarvatt nouveau    mesa: ./auto-xorg-git -H hooks -g -d origin/ubuntu -p mesa -a 0ubuntu0sarvatt
<RAOF> There have been any number of fixes to the Intel drivers in Lucid; you might want to try an alpha 3 livecd in a couple of days to see if it's fixed there.
<Sarvatt> anything with a + in the changelog is something i do by hand
<RAOF> Sarvatt: Ta.  I should probably make it so that the xorg-edgers nouveau DDX contains the driver date; it's a useful piece of debugging information.
<RAOF> Also, nouveau gallium works again on nv4x, modulo crazy update slowness.
<Sarvatt> i have to disable that snapshot date patch because you try to patch configure that doesnt exist after a git checkout, it clones then patches then runs autoreconf after the patching
<RAOF> Oooh, and wobbly works, too!
<RAOF> I think that you should actually be able to apply that patch now.  Why don't I check? :)
<Sarvatt> comment out the line in hooks/xserver-xorg-video-nouveau.prepatch
<Sarvatt> actually just drop the -H hooks line from it completely
<Sarvatt> that patch removal is the only hook
<Sarvatt>  ./auto-xorg-git -t + -g -d origin/ubuntu -a 0ubuntu0raof nouveau would work :)
<RAOF> Bah.  No, of course it doesn't just work.  In fact, it'd be wrong, wouldn't it?
<RAOF> What actually needs to happen is to run get-orig-source and import that...
<Sarvatt> could just run the script with the hook, let it build then reenable the patch in the series and debuild -S -sa again
<Sarvatt> i'll just do that next time i update it
<RAOF> I was thinking of running get-orig-source in the prepatch hook, git-import-orig'ing it, and then letting it do it's funky thing.
<RAOF> Also, nouveau gallium is awesome until compiz stops updating the screen.
<bjsnider> i wonder if the nvidia drivers are really working as well on lucid as you think RAOF 
<Sarvatt> hmm maybe try toggling the unredirect fullscreen windows option RAOF?
<bjsnider> there are loads of complaints all day in +1
<RAOF> bjsnider: And when I followed up with one of them, they'd manually installed the drivers from the nvidia website and broken everything.
<bjsnider> hahahaa
<bjsnider> you're kidding
<bjsnider> are you kidding?
<RAOF> Well, no.  They had, at one point in the recent past manually installed the drivers from nvidia.com.
<bjsnider> but you'd have to remove jockey for that
<RAOF> Do you?
<RAOF> Why?
<bjsnider> you'd have to remove ubuntu-desktop
<RAOF> Do you?  Why?
<bjsnider> because jockey blocks the nvidia installer
<Sarvatt> jockey is optional :)
<bjsnider> jockey isn't part of ubuntu-desktop?
<Sarvatt> nope, i dont have it installed and ubuntu-desktop is installed
<bjsnider> somehow i automatically associate everything on a default system with a metapackage
<bjsnider> it's on a default system anyway
<RAOF> Jockey blocks the nvidia installer?  AWESOME.
 * Sarvatt would love a ncurses jockey he could actually use
<bjsnider> what about the guy who said the 195 driver is crashing his rig every few minutes? what about all of the people who say they've lost opengl?
<Sarvatt> most of the problems are from nvidia.com or installing PPA versions and screwing things up from what i see
<RAOF> I guess that upgrades might be broken?  But my best guess would be Sarvatt's, yeah.
<bjsnider> can someone go over to that channel and explain that? these complaints are getting annoying
<bjsnider> all issues with jockey not being able to activate the appropriate alternatives are solved right?
<Sarvatt> yep, i did see a bug earlier where someone was upgrading from hardy-lucid and didn't have a new enough dpkg to set up the alternatives though
<Sarvatt> bryceh: we're going to get those record extension patches in the next xserver update already
<Sarvatt> just a heads up they'll be obsoleted with the next merge from debian, they'll be on 1.7 branch next point release (i think friday)
<Sarvatt> i've been watching that bug for a few weeks getting ready to pounce on it when they hit, just went on server-1.7-nominations 2 hours ago
<bjsnider> Sarvatt, you're going to pounce on a defenseless little bug?
<Sarvatt> bjsnider: are you using the blob right now? can you tell me the number returned from xlsclients | wc -l if so?
<bjsnider> not on lucid, no
<bjsnider> on karmic it's 22
<Sarvatt> was just wondering how the heck BUGabundo had >256 the other day
<bryceh> Sarvatt, ok no prob, just wanted to ensure the patch didn't get dropped
<bryceh> oh there's another 1.7 point release in the works?  nice
<Sarvatt> wonder how much space we could save on the cd dropping some dri drivers that arent even usable like sis and mach64, they're about 2.3MB each
<bjsnider> Sarvatt, a guy in +1 just left a list of things the nvidia-installer left behind: http://paste.ubuntu.com/382004/
<bjsnider> fascinating
<Sarvatt> so he didnt even run the installer with --uninstall then...?
<bjsnider> i'm not sure
<bjsnider> but it leaves stuff behind even if you do
<Sarvatt> i think its --uninstall anyway, --help tells you the uninstall command
<bjsnider> and now mysteriously his lucid system has no opengl
<Sarvatt> it deletes that stuff when i use the uninstaller
<bjsnider> gee, i wonder why...
<Sarvatt> heck, i think its actually called nvidia-uninstall
<Sarvatt> installs a progam called that i mean
<bjsnider> do you trust it?
<Sarvatt> another case of pebkac if he didnt run that :)
<Sarvatt> yeah i use it all the time
<bjsnider> of course these people could say they uninstalled it whent hey really didn't
<Sarvatt> i've always used them straight from nvidia.com instead of using ppa ones, one of the reasons i dont like having an alternative installed in mesa :)
<bjsnider> if you don't know enough to use the uninstaller between drivers, should you be using the nvidia-installer?
<Sarvatt> i think the nvidia.com installers should work again once libgl is moved back to /usr/lib though
 * bryceh flushes xserver-xorg-video-nv bugs
 * bryceh ker-puuushes
<RAOF> Whoop!  Whoop!
<bryceh> allgone
<RAOF> What is occasionally killing X when I press enter?
<RAOF> Is that plymouth attacking me *again*?
<bryceh> yep
<RAOF> Argh.
<RAOF> Next question: what's causing evolution-data-server to consume a core!  It's a non-stop cavalcade of fun1
<bryceh> nfi
<bryceh> maybe ask on #ubuntu-desktop once seb128 is online
<RAOF> I'll see if there's anything obvious in gdb first.
<bryceh> interesting, when I try forcing fbdev to load via xorg.conf I get lots of lines like this:
<bryceh> (EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
<alkisg> I installed Lucid a while ago, and the -pae kernel was automatically selected for me. On some updates the non-pae kernel was pulled in, so I now have both of them installed. The problem is that I can't uninstall the non-pae kernel, without removing xorg:
<alkisg> sudo LANG=en_US.UTF-8 apt-get purge linux-image-2.6.32-14-generic
<alkisg> The following packages will be REMOVED:
<alkisg>   linux-backports-modules-nouveau-2.6.32-14-generic* linux-backports-modules-nouveau-lucid-generic* linux-image-2.6.32-14-generic* xserver-xorg-video-all*  xserver-xorg-video-nouveau*
<alkisg> Is that problem caused by the nouveau driver?
<RAOF> bryceh (should have) fixed that with the most recent xserver-xorg-video-nouveau updload.
<alkisg> Ah thanks, let me try to update, I haven't updated in the last 2 days...
<bryceh> yeah alkisg let me know if it does not fix it
<alkisg> bryceh: thanks, I think it's not published yet, so I'll wait until it does and give some feedback then.
<kklimonda> hmm, my laptop doesn't wake up from sleep anymore.. damn
<kklimonda> how can I get some informations?
<alkisg> kklimonda: I've read this a while ago, maybe it could help you: https://wiki.ubuntu.com/DebuggingKernelSuspendHibernateResume
<kklimonda> alkisg: thanks - I'll probably wait till a3 is released and try it on the fresh system
<alkisg> BTW, would anyone care to help me troubleshoot nouveau? It doesn't work for me, I have a laptop with 8600 GT M.
<bryceh> hmm, to -intel 2.10 or not -intel 2.10
<bryceh> tjaalton, any strong opinions?
<tjaalton> bryceh: no, haven't tried it myself
<tjaalton> but maybe it's more tested against the .33 drm
<tjaalton> dunno
<bryceh> ok.  I don't know of pressing issues impelling us to 2.10, but since it drops UMS I'm hesistant to go with it.  Hard to make a firm decision though.
<tseliot> bryceh: a colleague reported that -sharevts + rootless X causes X to crash with Ctrl-C (it works fine without that paramter)
<jcristau> means the vt is not put in raw mode
<jcristau> (also i assume by rootless you don't mean rootless, but euid != 0)
<tseliot> rootless as in run without root privileges
<bryceh> tseliot, filed a bug?
<tseliot> bryceh: nope
<jcristau> tseliot: see hw/xfree8/os-support/linux/lnx_init.c.  we only set RAW mode if (!ShareVTs).  my guess is, whoever owns the vt should do that.
<tseliot> jcristau: ok, thanks
<tseliot> bryceh: do you mind if I fix bug #467490?
<ubottu> Launchpad bug 467490 in nvidia-graphics-drivers-180 "nvidia drivers don't work due to -Q in obsolete /etc/modprobe.d/lrm-video" [High,Triaged] https://launchpad.net/bugs/467490
<bryceh> tseliot, sure feel free to reassign
<tseliot> ok
<Sarvatt> RAOF: you're getting the sigquit when pressing enter after first boot problem?
<jcristau> Sarvatt: i've seen a sigquit report on bugzilla a few days ago... #26689
<tjaalton> fdo bug 26689
<ubottu> Launchpad bug 26689 in devmapper "Device mapper devices have incorrect ownership and permissions." [Medium,Fix released] https://launchpad.net/bugs/26689
<tjaalton> i'm lazy :)
<tjaalton> bah
<Sarvatt> http://bugs.freedesktop.org/show_bug.cgi?id=26689
<ubottu> Freedesktop bug 26689 in DDX/xorg "Crash in WaitForSomething() (maybe?) on first execution on radeon-git/KMS" [Normal,New]
<tjaalton> freedesktop bug 26689
<ubottu> Freedesktop bug 26689 in DDX/xorg "Crash in WaitForSomething() (maybe?) on first execution on radeon-git/KMS" [Normal,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=26689
<tjaalton> yeah
<Sarvatt> RAOF: can you compile this and load it before hitting enter and reproducing it? http://sarvatt.com/downloads/trace-signal.c
<Sarvatt>  touch Makefile ; make obj-m=trace-signal.o -C /lib/modules/`uname -r`/build M=`pwd` modules    will compile it
<Sarvatt> wonder if gentoo is using plymouth too, that'd rule that out if not.. it didn't happen without plymouth here before and I cant reproduce it at all anymore even with plymouth :( the majority of people hitting the bug are using the blob though
<Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=22679
<ubottu> Freedesktop bug 22679 in Server/general "Xorg sporatically crashes during first session after boot running compiz" [Normal,New]
<Sarvatt> OsSigHandler (signo=3 there too, thread on it here http://www.mail-archive.com/xorg@lists.freedesktop.org/msg07782.html
<jcristau> oh, i'd forgotten about that threa
<jcristau> d
<_stink_> hey folks.  i'm trying to debug an X driver using the gdb info here: http://www.x.org/wiki/Development/Documentation/ServerDebugging
<_stink_> the problem is that X never really starts using this driver.
<_stink_> how can i still hook gdb in if X doesn't stay running, but crashes during the startup procedure?
<_stink_> fwiw, it's kind of an obscure driver, and not one that's widely used or anything.
<_stink_> so i'm not reporting a huge bug or anything. :D
<jcristau> if you're lucky you can start X from gdb
<jcristau> otherwise, get X to dump core, and run gdb on that
<_stink_> jcristau: thanks!
<_stink_> i should be using something other than startx to start it if i'm invoking from gdb, right?
<_stink_> looks like xinit is what i want
<baptistemm> hi there, do you need other information for https://bugs.edge.launchpad.net/ubuntu/+source/xorg/+bug/526662
<ubottu> Launchpad bug 526662 in xorg "[lucid] Screen randomly goes off (aka IDLETIMER issue)" [Undecided,New]
<jcristau> yes.  need a reliable way to reproduce.
<baptistemm> jcristau, that's the problem ...
<jcristau> because afaik 1.7.5 has all the existing fixes in this area, so if you still have issues there then you need to tell us how to reproduce, or give us a patch
<baptistemm> chrisccoulson, ^^ you said this afternoon some bits could be missing, and you had a patch
<chrisccoulson> baptistemm, jcristau, yeah, i think i might know what happens there. baptistemm, do you see the screen dim first (if you're on battery)?
<chrisccoulson> i'll discuss it in a bit though
<chrisccoulson> i'm busy with other things atm
<baptistemm> yeah, not a problem
<bjsnider> RAOF, is docky using xrender or opengl?
<chrisccoulson> baptistemm, jcristau, see gnome bug 609720 for the remaining race i found in gpm
<ubottu> Gnome bug 609720 in gnome-power-manager "Can sometimes miss idle reset alarm, causing display to blank when it shouldn't do" [Normal,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=609720
<chrisccoulson> we committed a patch to fix it, but it actually caused more issues
<chrisccoulson> so it's been reverted again for now
<baptistemm> chrisccoulson, thanks a lot
<chrisccoulson> baptistemm, i'm not saying for certain that's your issue, but i can occasionally hit that issue
<baptistemm> chrisccoulson, should I reopen the bug as the patch was reverted
<chrisccoulson> baptistemm, please do. that's on my list of things to look at soon
<jcristau> hrm, there's http://bugs.freedesktop.org/show_bug.cgi?id=26469 which might be related, i guess?
<ubottu> Freedesktop bug 26469 in Lib/Xext "Multiple xsync timers fail to fire" [Normal,New]
<chrisccoulson> jcristau, that's possibly related
<chrisccoulson> although less exposed now, as gnome-screensaver doesn't directly rely on the idletime counter now
<chrisccoulson> although, thinking about it, gpm only registers a single alarm anyway
<RAOF> bjsnider: docky is using cairo, which is using xrender.
<bjsnider> RAOF, understood, sir
<Sarvatt> bryceh: looks like 2.9.1 with some way to selectively disable KMS by default on 8xx is the way to go. can you think of an easier way to implement that logic outside of patching the kernel? a kernel patch to do it wouldn't be that hard if not I'm pretty sure
<bryceh> Sarvatt, "that logic" == blacklisting kms on 8xx?
<bryceh> yeah apw has talked about that but I don't know the implementation details of how that's done
<Sarvatt> yeah using modeset=0 just on specific pci id ranges
<bryceh> right, I think we need to mindmeld with apw and sconklin about that
<bryceh> but yeah I'm also getting more and more certain about 2.9.1 rather than 2.10
<RAOF> Sarvatt: X died just as I was building trace-signal on my first boot; I've upgraded, rebooted, insmoded, and will drop you dmesg when X does it's swandive.
 * BUGabundo comments nouveua PPA
<BUGabundo> are you serious?
<BUGabundo> I was about to upgrade
<Sarvatt> if it didnt happen the first time you pressed enter it probably wont happen this boot RAOF, no need to leave it modprobed
<Sarvatt> everything in xorg-edgers/nouveau is already in lucid BUGabundo 
<Sarvatt> i'm curious how fbdev over inteldrmfb works for 8xx people
<BUGabundo> Sarvatt: so where's the 3D?
<Sarvatt> xorg-edgers/ppa
<Sarvatt> if we did ship 2.10 and 8xx isnt fixed, can we just provide say a xserver-xorg-video-intel-legacy with 2.9.1 that has a modprobe.d conf with options i915 modeset=0?
<BUGabundo> Sarvatt: did that nvidia settings got updated?
<BUGabundo> so I can test that comand you told me to improve speed of nvidia blob
<Sarvatt> no i have no idea if thats why, that option doesnt work if your card isnt new enough anyway so that might be why
<BUGabundo> 8400mG
<BUGabundo> 2 yo
<RAOF> Sarvatt: Aaaand there it goes!  Crash when I pressed enter to say âIt doesn't always crash on the first press of enterâ :)
<Sarvatt> i think only G96+ supports the stuff, GT200+ and some older things like 8200 integrated and ion
<BUGabundo> Sarvatt: I think mine is g85 or older
<Sarvatt> RAOF: got the dmesg output when it sigquit?
<RAOF> Sarvatt: Have an (unfortunately trunkated) dmesg: http://paste.ubuntu.com/382574/
<Sarvatt> ok its in there at line 1599 at least, looks the same as that fdo bug :(
<RAOF> The rest made it into syslog, so if you'd like (much, much!) more context, I can fish it out of there.
<bryceh> Sarvatt, re: splitting out a -legacy intel driver yeah that's an option.  honestly though, looking through the changelog for 2.10 most of it is code deletions.  There's the Xv stuff which is new, and a few random things that might be bug fixes
<Sarvatt> bryceh: http://sarvatt.com/downloads/patches/103_increase_idgng_stride.patch http://sarvatt.com/downloads/patches/102_disable_bo_reuse_on_shadowfb.patch  2 backports from 2.10+ that I saw that would  be relevant on 2.9.1
<bryceh> ok
<Sarvatt> hmm src/libplybootsplash/ply-terminal.c is screwing with the tty
<apachelogger> hullos
<apachelogger> could someone help me debug a problem with xsetroot?
<Sarvatt> i'm guessing theres something racy, and ply_terminal_set_buffered_input (around line 196 of src/libplybootsplash/ply-terminal.c) is sometimes not getting the original term attributes and resetting the ISIG flag on X's VT so the enter key (0x1c) becomes the quit character (0x1c)
<apachelogger> or at least I think it is because of xsetroot :D
<Sarvatt> hmm http://suse-moblin.com/obs-status/Moblin:Factory/aaa_base/aaa_base-bootsplash.patch
#ubuntu-x 2010-02-24
<Sarvatt> RAOF: bored? want to try testing out a plymouth change to see if fixes it? wish i could still reproduce it :( it'll show up here - https://edge.launchpad.net/~sarvatt/+archive/bugfixes
<RAOF> I'll give it a whirl next time I reboot.
<Sarvatt> i just changed it to stop resetting the ISIG flag on plymouth's VT. i think our gdm/plymouth integration stuff is screwing up with that because its using the same VT
<superm1> Sarvatt, and here i thought i was crazy that I was crashing X by hitting enter on my terminals the other day :)
<johanbr> hi... what could be the problem if nouveau says "(EE) [drm] failed to open device" ?
<johanbr> this is on lucid + xorg-edgers, completely updated
<Sarvatt> did you boot the 2.6.32-14 kernel?
<johanbr> yep
<johanbr> http://paste.ubuntu.com/382674/ for X log
<johanbr> uname -a
<johanbr> oops :)
<Sarvatt> were you the person that didn't update things and just updated individual packages instead?
<johanbr> yes, definitely 32-14 :)
<johanbr> I've done that sometimes yes
<johanbr> but I remembered our conversation, so did a full dist-upgrade this time :)
<Sarvatt> is it a laptop with the lid closed by any chance?
<johanbr> laptop yes, lid closed no
<Sarvatt> actually, i think acpi=noirq might be messing with it, can you try booting with lbm-nouveau.ignorelid=1 added to grub?
<johanbr> absolutely
<johanbr> I'll try removing the acpi= option too
<johanbr> back in a minute... 
<Sarvatt> that'll ignore the acpi lid status, log looks like mine does when i boot with the lid closed
<Sarvatt> hmm he said he was using edgers but.. 	compiled for 1.7.5, module version = 0.0.15
<Sarvatt> oh nevermind mine says that too, the drm message later is where it says its 0.0.16
<Sarvatt> any luck?
<johanbr> afraid not... still didn't work, but log now slightly different
<johanbr> http://paste.ubuntu.com/382680/
<johanbr> "drmGetBusid returned ''" doesn't look good
<johanbr> it was "lbm-nouveau.ignorelid=1", right?
<Sarvatt> can you paste your dmesg?
<johanbr> sure, just a sec
<johanbr> http://paste.ubuntu.com/382683/
<johanbr> I do have the experimental 3d stuff installed... could that be interfering?
<Sarvatt> do you have nouveau-firmware installed?
<Sarvatt> no i dont think so, some pretty nasty errors in dmesg there
<johanbr> yep, nouveau-firmware is installed... 20091212-0ubuntu1
<RAOF> All these people with shiny new nv5x+ cards!  They'll get to test out the ctxprog generator soon, I think; it sounds like mwk's gearing up for a test-request on it.
<Sarvatt> johanbr: hmm I think i'd start by purging plymouth and seeing if that helps any
<johanbr> I actually just installed plymouth to see if that would help :)
<johanbr> but I'll try purging it and removing the boot options, I haven't tried that combination
<johanbr> back in a bit...
<RAOF> Why is that drm rather than lbm-drm?
<Sarvatt> where?
<RAOF> In johanbr's dmesg logs.
<Sarvatt> hmm
<Sarvatt> good point
<RAOF> Someone's got a stale version of 0.0.15 from upstream; it's 2.6.32-847-nicelogshasum
<RAOF> Actually, it might be nouveau-kernel-source.
<Sarvatt> ugh yeah gotta be, [   12.306932] [drm] Initialized nouveau 0.0.15 v2.6.32-847-g50ebb93924038778b for 0000:01:00.0 on minor 0
<Sarvatt> completely missed that
<RAOF> It might be nice to get that info into the lbm-builds, too.
<Sarvatt> [   13.428170] [lbm-drm] Initialized nouveau 0.0.16 20090420 for 0000:05:00.0 on minor 0 here
<RAOF> Actually... what would be nice in there is âinitialized nouveau 0.0.16 lbm-drm $PACKAGE_VERSION ...â
<Sarvatt> deleting nouveau-kernel-source from edgers
<Sarvatt> i'm sure thats what he did
<Sarvatt> think i should upload lbm-nouveau with http://0x04.net/~mwk/0001-drm-nv50-Implement-ctxprog-state-generation.patch ?
<Sarvatt> eh might as well, its crack anyway :)
<Sarvatt> http://lists.freedesktop.org/archives/nouveau/2010-February/005137.html
<Sarvatt> uploaded
<johanbr> finally!
<johanbr> downgrading the X server made nouveau work again
<johanbr> Sarvatt, I *think* it was this upgrade that broke it:
<johanbr> [UPGRADE] xserver-common 2:1.7.4.902~git20100205+server-1.7-branch.85b04bb0-0ubu
<johanbr> ntu0sarvatt3 -> 2:1.7.5~git20100216+server-1.7-branch.f0ec2e0d-0ubuntu0sarvatt
<Sarvatt> johanbr: you installed nouveau-kernel-source
<Sarvatt> thats an obsolete package and screwed things up
<johanbr> oh!
<Sarvatt> i deleted it off edgers so noone else would do that
<johanbr> ahhh...
<Sarvatt> we probably need to get nouveau-kernel-source deleted from the archive too?
<Sarvatt> xserver should be 1.7.5-1ubuntusomething btw, theres newer in the archive than whats in lucid
<Sarvatt> err than whats in edgers
<Sarvatt> johanbr: sudo apt-get purge nouveau-kernel-source should fix you up
<johanbr> yep, just that did that :)
<johanbr> I'll just reboot and make sure everything's okay
<johanbr> many thanks for your help
<Sarvatt> no worries, you'll see lbm-drm in your dmesg instead of drm all over the place
<Sarvatt> if its working right
<Sarvatt> any luck?
<johanbr> yep, back to working order now
<johanbr> thank you
<Sarvatt> no worries, sorry about that, should have removed that package a long time ago
<Sarvatt> bryceh: nouveau-kernel-source should probably be removed from the archive for lucid :)
<bryceh> Sarvatt, heh
<Sarvatt> i put a firmwareless nouveau package up on edgers also to get more testing
<Sarvatt> http://lists.freedesktop.org/archives/nouveau/2010-February/005137.html
<Sarvatt> i'm guessing it'd work fine for whats going in lucid, its the 3D stuff thats iffy with it
<Sarvatt> maybe we should patch out this error message from evdev - (EE) ioctl EVIOCGNAME failed: Inappropriate ioctl for device
<Sarvatt> alot of people posting  bug reports thinking its actually a problem
<Sarvatt> its just because of how we load evdev always then another driver if it fits later from how the udev rules are set up
<Sarvatt> http://sarvatt.com/downloads/patches/0001-Silence-EVIOCGNAME-error.patch  ?
<bryceh> AGREED
<bryceh> I just triaged a bug about that
<RAOF> Sarvatt: Wow, you're quick.  I was going to apply that voodoo generator later this afternoon :)
<bryceh> Sarvatt, works for me
<bryceh> Sarvatt, do you have git access to the -evdev tree?  If so, go ahead and commit that.  If not, I'll take care of it tomorrow
<Sarvatt> sure thing bryceh, i'll merge everything into the ubuntu branch and set it all up. should I set the changelog to UNRELEASED or leave it lucid?
<Sarvatt> xserver-xorg-input-evdev (1:2.3.2-3ubuntu1) lucid; urgency=low
<Sarvatt> i merged the xserver-xorg-input-evdev-1_2.3.2-3 tag into ubuntu since thats what we're on in lucid, origin/ubuntu was really old since we've been syncing from debian for lucid
<Sarvatt> building it now to see if its working right before i push it
<Sarvatt> yay works fine, http://paste.ubuntu.com/382729/
<Sarvatt> well I just left the changelog as lucid, hope I dont screw anything up doing that :)
<Sarvatt> pushed it all here http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-input-evdev.git;a=shortlog;h=refs/heads/ubuntu
<Sarvatt> bryceh: do you want a debdiff? should I include the changelog with the ubuntu history in it if so since the synced one just has the debian history? here's one if thats right - http://sarvatt.com/downloads/patches/xserver-xorg-input-evdev_2.3.2-3ubuntu1.debdiff
<bryceh> Sarvatt, looks great
<bryceh> Sarvatt, only other thing is if you can associate the debdiff to a launchpad bug report, it's good to do so
<bryceh> Sarvatt, upload sponsored
<Sarvatt> thanks bryceh 
<Sarvatt> go figure I found one after - https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/517316
<ubottu> Launchpad bug 517316 in xserver-xorg-input-evdev "ioctl EVIOCGNAME failed on lucid" [Undecided,Fix released]
<Sarvatt> was on virtualbox-ose :)
<bryceh> heh, yeah that always happens to me
<bryceh> sometimes doing a google against site:bugs.launchpad.net for the error message turns up some bug matches
<bryceh> probably would get too many hits in this case though
<Sarvatt> label:ubuntu-x-swat eviocgname in gmail here :)
<Sarvatt> almost 11k bug emails in there
<bryceh> closing out all the -nv bugs make a good dent in our peak - http://www2.bryceharrington.org:8080/X/Graphs/totals.svg
<bryceh> also with james_w's help I sorted out a bug that's been preventing my triaging scripts from running for the last few months, so I'm hoping they'll kick in and start catching up on triaging work
<Sarvatt> nice!
<bryceh> I think outside the scripted triaging, I'm personally just going to be focusing  on bugs marked 'lucid' (maybe I mentioned that already)
<Sarvatt> nvidia stuff is going to be *hard*, so many bugs that are just people screwing things up for themselves and needing help fixing it instead of actual bugs
<bryceh> er, s/marked/tagged/
<bryceh> yeah, totally
<bryceh> I've complained about that at the last few ubuntu gatherings
<bryceh> they're more like support requests than bug reports
<bryceh> i.e., "Please fix this issue that is making my system broken" vs. "This is a flaw in the Ubuntu product that should be fixed"
<Sarvatt> yeah the kind of thing you can spend 8 hours helping 8 people fix it when you have 1000+ bugs worth of it to go through..
<bryceh> yep
<bryceh> what chaps my hide is when the bug reporters get dickish about it... e.g. #121574
<bryceh> although I've noticed it's rarely actually people who actually report bugs, but more likely drive by commenters who've never filed bug reports before who have the worst manners
<DawnLight> compiz is leaking memory i'm gonna run out i wanna report what do i do quick
<DawnLight> ?
<bjsnider> Sarvatt, i don't doubt that you're correct about nvidia users having screwed up their own systems and now they need help, but can you give a few examples of that?
<apw> under KMS if your edid information is wrong or hidden by a KVM switch is there any way to tell KMS drivers a sensible resolution override line one used to do in /etc/xorg.conf ??
<jcristau> i think you can pass something like video=VGA1:1024x768 to the kernel
<tseliot> can it be video=LVDS1 too (when using a laptop)?
<jcristau> â¦
<smb> tseliot, Hm, if I would now any name. On laptops I would look into acpi info but on a desktop...
<tseliot> ???
<smb> tseliot, Sorry, trying the thing apw has askd before
<tseliot> ah, ok
<smb> Getting a different video mode on a kms
<smb> But its a desktop to acpi knows nothing about gfx hw
<smb> And its nouveau and behind a switch that hides the EDID 
<tseliot> ouch
<smb> Atm, it feels to me we got 3 kernel/grub arguments which all do *not* work. Or I just have not found out how they are supposed to work
<tseliot> what arguments?
<smb> vga= is deprecated, video= and gfxpayload=
<apw> tseliot, have you ever tried video= on kms?
<tseliot> nope
<tormod> please cherrypick for mesa, bug 515846
<ubottu> Launchpad bug 515846 in mesa "mesa 7.7 DRI crash, assertion in driNewRenderbuffer()" [Undecided,Confirmed] https://launchpad.net/bugs/515846
<tjaalton> is it not in 7.7-branch?
<tjaalton> seems to be
<tjaalton> so we'll get it anyway
<RAOF> Sarvatt: I don't think your -11 plymouth fixed the enter crash for me.
<BUGabundo> bRoas
 * jcristau sighs at subscriber-only ubuntu lists...
<bryceh> ahem, "spam-free" subscribe-only ubuntu lists...
<BUGabundo> eheh
<BUGabundo> humm
<BUGabundo> don't member be able to email to every list?
<BUGabundo> *Members/Motu
<bryceh> dunno
<jcristau> well at least kernel-team@ seems to be moderated, rather than outright rejecting non-subscriber posts
<BUGabundo> AFAIK all lists are moderated
<jcristau> that's not what mailman tells me
<tormod> tjaalton, hi, "we'll get it" like soon? I think it is a blocker for all non-intel/ati
<tjaalton> tormod: like after alpha3
<tjaalton> bgoglin is about to upload 7.7-4
<tormod> goodygood
<kklimonda> so the latest nouveau broke it for me :/
<kklimonda> update*
<kklimonda> the one from xorg-edgers ppa 2.6.32-14.999~xorgedgers4
<RAOF> Broke in what way?
#ubuntu-x 2010-02-25
<yotux> I saw request for help with Nvidia Drivers I would like to help out
<RAOF> Which request?  Nouveau or the binary nvidia drivers?
<yotux> proprietary drivers, so I think binary
<yotux> Sorry I failed to read who to email
<bryceh> yotux, contact ara
<yotux> am going to do so thank you
<tjaalton> bryceh: merged mesa 7.7-4, though it pulled from the stable branch and probably would need some paperwork
<tjaalton> didn't upload of course due to a3
<bryceh> tjaalton, ok
<tjaalton> do you think we need standing FFe's for mesa & xserver? there's 7.7.1 coming late March and 1.7.6 "some time"
<bryceh> tjaalton, as long as we can justify them as bug-fix only releases, I think we're covered by the point release policy
<bryceh> tjaalton, although it couldn't hurt to do an FFe anyway if you think it'd help to have added visibility on them
<tjaalton> bryceh: alright, maybe when those point-releases happen then :)
<bryceh> btw, I've started tagging bugs by the release they were reported against, so when looking at bugs we can query for has_tag==lucid
<tjaalton> is there a tag for edgers=
<tjaalton> ?
<bryceh> no, but there probably should be
<bryceh> do you like 'edgers'?  I can add that to the processor
<tjaalton> it's alright I guess
<bryceh> done
<bryceh> the script runs once a week on saturday
<tjaalton> ok
<bryceh> 1.6.4 feels sooo old
<tjaalton> ancient..
<toabctl_> hi
<toabctl> hi
<toabctl> can anybody help with bug #527912 ?
<ubottu> Launchpad bug 527912 in xf86-input-wacom "Wacom Bamboo CTH-661 not recognized" [Undecided,New] https://launchpad.net/bugs/527912
<tjaalton> toabctl: http://sourceforge.net/mailarchive/forum.php?thread_name=4B3A8A6B.20205%40openwebboard.org&forum_name=linuxwacom-discuss
<toabctl> tjaalton, why do you know that the kernel component doesn't support the tablet?
<tjaalton> toabctl: because the id isn't listed there
<toabctl> ok
<tjaalton> none of the new bamboo's are
<toabctl> hm. shit
<Sarvatt> tjaalton: i'm pretty sure mesa shouldn't require a FFe, i dont see any new features since our snapshot just bugfixes? xserver probably would though since it reenables the record extension though then again thats just fixing something that was broken.. :D kklimonda: got a dmesg from it failing with the newer nouveau? I added the no firmware required patch to that one
<tseliot> Sarvatt: what change in mesa?
<Sarvatt> 7.7-4 from 7.7-3
<tseliot> ok
<Sarvatt> maybe we should drop mach64 since its not in the kernel and would save ~1MB of cd space
<Sarvatt> if squashfs compresses similar to gzip -9 that is
<Sarvatt> makes almost no difference in the deb size since its lzma but its about 930k at gzip -9
<Sarvatt> it required building the drm kernel modules from libdrm 2.4.15 or older and all that was dropped from libdrm
<tjaalton> Sarvatt: ok
<tjaalton> is the cd-size an issue still?
<Sarvatt> i see them talking about dropping language packs all the time in -devel and not being able to fit french or german right now
<jcristau> Sarvatt: seems sane to me..
<tjaalton> heh, ok
<Sarvatt> i810 and sis i'm unsure about too, i never was able to get sis to work at all but I havent found any more info on it
<kklimonda> Sarvatt: I got nothing in dmesg but there was a "CtxProg is still running" message printed on vt along with some other message - I didn't have a camera to make screenshot and couldn't get it to display again later so I guess it doesn't help :)
<kklimonda> Sarvatt: no - wait, I have it
<kklimonda> Sarvatt: http://pastebin.com/u3yLdEvW - SAK is from me trying to get some response from system :)
<bryceh> Sarvatt, -sis we should keep; I periodically get bug reports on it so someone must use it
<bryceh> i810 can go, that's long obsolete
<bryceh> I think with disk space, the dropping of Gimp bought a bit of breathing room, but we're adding nouveau bits now so if there's stuff we can excise from the cd it'd be a nice thing to do
<bryceh> and of course debdiffs welcome :-)
<toabctl> tjaalton, in xf86-input-wacom-0.10.4/src/wcmUSB.c are some lines like:{ 0xD3, 2540, 2540, &usbBamboo     }, /* CTL-660 */
<toabctl> but there is no line for the cth-661
<toabctl> i would like to add a line but i don't know what the 3 parameters stand for.
<tjaalton> toabctl: so the cth-661 and ctl-660 share the same id
<tjaalton> no need to change anything
<tjaalton> linuxwacom has the needed kernel bits
<tjaalton> too bad that the git repo doesn't
<toabctl> tjaalton, linuxwacom==linuxwacom-0.8.4 ? and git==xf86-input-wacom? right?
<jcristau> for the kernel, git == linux-2.6.git, i guess
<toabctl> tjaalton, i don't know where to find the kernel module for wacom
<tjaalton> wacom-kernel git actually
<tjaalton> toabctl: get the linuxwacom tarball
<tjaalton> 0.8.5-10
<toabctl> tjaalton, and there's the code for the kernel module? (the code organisation looks very confusing for me)
<tjaalton> yes (and it is)
<toabctl> tjaalton, and where can i find the kernel driver in the ubuntu repository?
<jcristau> comes with your kernel.  /lib/modules/*/kernel/drivers/input/tablet/wacom.ko
<tjaalton> right
<toabctl> jcristau, and how to find out from which source this module was build? from 0.8.4? or 0.8.5.10 ?
<tjaalton> toabctl: what came with the kernel
<tjaalton> linuxwacom used to ship the code as well
<tjaalton> see what version it declares
<tjaalton> in the linuxwacom kernel source
<toabctl> tjaalton, so the module is shiped by the mainline kernel? it's not a ubuntu patch?
<tjaalton> right
<toabctl> ah. ok. 
<tjaalton> the kernel code was split into wacom-kernel git, but seems like it's not being updated
<toabctl> tjaalton, and how do i know which kernel version i need for linuxwacom-0.8.5-10? this version doesn't compile for me..
<tjaalton> toabctl: you don't want or need to compile the whole of linuxwacom
<tjaalton> diff the kernel code and patch the kernel sources, or just copy the files and then build the kernel
<toabctl> tjaalton, thanks for the help. but i think it's to complex for me to fix it.
<tjaalton> toabctl: :)
<toabctl> tjaalton, do you think it's a big thing or will tha tablet be supported in some weeks? or no idea?
<tjaalton> toabctl: I'm not sure it'll be supported in lucid at all, tbh
<tjaalton> judging by what was said on #ubuntu-kernel earlier
<toabctl> tjaalton, ok. thanks a lot for the help and information!
<superm1> tseliot, is it intended that users are switched from nvidia->nouveau on karmic->lucid upgrade?
<superm1> i just upgraded one of my installs two days ago and this happened to me
<tseliot> superm1: I don't think so
<superm1> would it be expected if I had nvidia-glx-195 installed (rather than -190) though?
<superm1> er -190 rather than -185 that is
<bjsnider> also, what happens to the nvidia-xxx-libvdpau package in such a situation?
<superm1> i can file a bug with whatever logs came up for this to help diagnose
<superm1> but i suspect it's the same thing that will happen to anyone using that ppa of yours bjsnider 
<superm1> would the appropriate thing be 'ubuntu-bug update-manager' to grab all such logs?
<bjsnider> superm1, you were using the 190 driver out of my ppa?
<superm1> bjsnider, i'm not sure if it was your PPA or the ~mythbuntu PPA.  it's basically the same packaging either way though
<tseliot> superm1: we have 195 in Lucid now and, unless your package was epoched it should have gone well
<superm1> certainly wasn't
<bjsnider> tseliot, why not add a conflicts: nvidia-xxx-libvdpau to nvidia-current?
<superm1> but nvidia-glx-185 might not have been installed 
<superm1> because of it being named differently in the ppa's
<superm1> so the upgrade process might not have known what to do about it
<tseliot> superm1: I guess my packages only replace nvidia-glx-185
<superm1> well i'll file the bug when i get home and we can all look and see what's possible for a solution
<superm1> i'm certain there's lots of users using these PPAs for newer drivers, so it would be best to try to cover as many of them as possible
<superm1> even if the solution is pushing something new to those PPAs for people to upgrade to before the upgrade
<bjsnider> i could do that
<superm1> it was certainly a poor experience when i tried to go play a recording and the machine just hung there because it couldn't find a suitable vdpau backend anymore :)
<bjsnider> superm1, you mean it went to nouveau without you realizing it at the time?
<superm1> bjsnider, yup
<superm1> i mean there wasn't any tell-tale signs since i didn't use 3d, and i still had 1080p being output
<superm1> i only used the video playback acceleration of vdpau
<bjsnider> nouveau must work pretty well on your hardware
<bjsnider> you wouldn've had kms too
<superm1> i didn't pay attention to the bootup - the tv was off, so i have no idea if KMS was working
<superm1> i did notice the redraws were a little slow in the menus though
<bjsnider> superm1, what is the difference between mythbuntu and mythtv?
<superm1> bjsnider, mythbuntu is a preconfigured installation with lots of things to better integrate with the OS setup for you
<superm1> and extra tools for configuration of other pieces that aren't part of mythtv either
<superm1> you can certainly add any of them to an ubuntu install though
<bjsnider> such as what extra things?
<superm1> mythbuntu-control-center is the biggest
<superm1> it's kinda a one-stop shop for configuration of anything HTPC related on the box
<bjsnider> so it's supposed to integrate with ubuntu better than mythtv by itself would?
<superm1> well all the stuff is in the ubuntu archive, so you can achieve the same results yourself by installing all the pieces if you want
<superm1> the stuff on the PPA's is just daily builds of mythtv
<bjsnider> i see
<superm1> some of the goals of the ubuntu desktop clash with what you would normally use an HTPC for too, so this only gives you the components you're gonna need for HTPC usage
<bjsnider> is it built for multiple distros?
<superm1> No, it's ubuntu only
<tseliot> superm1: what's the PPA?
<superm1> our cdimages are produced on cdimages.ubuntu.com etc 
<superm1> tseliot, the ~mythbuntu PPA?
<tseliot> superm1: the one with the nvidia packages
<bjsnider> superm1, i mean different ubuntu distros, like jaunty, intrepid etc.
<superm1> tseliot, it was either this https://edge.launchpad.net/~mythbuntu/+archive/trunk-0.22 or the vdpau ppa
<tseliot> BTW I made 195 available in my proprietary drivers PPA
<superm1> bjsnider, oh yeah it's been since 7.10
<bjsnider> cool
<superm1> project is a few years old now
<bjsnider> nvidia-current is the 195 at this point isn't it?
<superm1> i'm pretty sure our nvidia-graphics-drivesr-190 on that PPA came from the vdpau PPA
<tseliot> bjsnider: yep
<superm1> it was just put here because mythtv had to be built against libvdpau for it to work
<bjsnider> superm1, i just updated it last week or something. i hope you're staying current with it
<tseliot> superm1: maybe it was some libvdpau that caused the problem? I'm too tired to tell ;)
<superm1> tseliot, i haven't even reviewed the logs yet.  i was still sorting out other upgrade problems
<bjsnider> against ibvdpau?
<superm1> i'll get the bug filed tonight with all the pieces
<bjsnider> my driver doesn't install it, i use the external package
<superm1> bjsnider, no it hasn't been updated.  is it something important?
<bjsnider> which 190 is it? is it .42?
<superm1> 190.53
<bjsnider> that driver does not come with libvdpau anymore
<bjsnider> only the nvidia vdpau driver is packaged in that one
<superm1> yeah, hence we have the external libvdpau on that PPA too
<superm1> and that's what mythtv had to build against
<bjsnider> oh, ok
<superm1> particularly libvdpau-dev
<bjsnider> wel, hte most recent update added execstack in karmic, updated prerm/postrm scripts, basically in line with the standard karmic package
<superm1> okay so for the users, if they're up and working probably not critical stuff
<bjsnider> no
<bjsnider> but whatever, a lot of them probably use the vdpau ppa
<tjaalton> bryceh: hey, shouldn't the apport hook links be named according to the source package?
<bjsnider> we don't have any stats or numbers of any kind do we?
<superm1> i dont think so, but that would be awfully nice
<superm1> it would help  to know which PPAs to give priority to keeping more stable
<bjsnider> i know ppa usage stats were proposed at one point
<bjsnider> i'd like to know how many people are using old distros, because i think it's a lot
<bryceh> tjaalton, for manual reporting, yes
<bjsnider> i get emails from jaunty and even intrepid people all the time
<bryceh> tjaalton, for crash detection it needs to be against the binary package
<bryceh> tjaalton, did you spot an inconsistency?
<tjaalton> bryceh: yeah, there's no xf86-input-evtouch, -wacom..
<tjaalton> probably others too
<bryceh> tjaalton, heh, I just happened to fix a whole bunch just yesterday
<bryceh> tjaalton, unreleased but check the xorg git tree
<tjaalton> you removed xf86-input-evtouch and wacom-tools?
<bryceh> tjaalton, a second set of eyes to doublecheck that everything's correct would help
<tjaalton> er, evtouch was renamed
<bryceh> well, replaced it with source_xserver-xorg-input-wacom.py
<tjaalton> but the source package is xf86-input-wacom :)
<tjaalton> so maybe they both need to be there, for crashers and manual stuff
<tjaalton> wacom-tools is good to go, since lucid doesn't have it anymore
<bryceh> $ apt-cache search wacom  
<bryceh> xserver-xorg-input-wacom - X.Org X server -- Wacom input driver
<bryceh> weird.
<bryceh> anyway yeah feel free to add whatever to the x11-common.links file
<tjaalton> that's the binary package
<bryceh> I don't look at updating it as often as I probably should
<tjaalton> apt-cache show xserver-xorg-input-wacom |grep Source
<tjaalton> yeah I'll add those
<BUGabundo> boas noutes
<tjaalton> toabctl: usb.ids is missing a bunch of wacoms, like all the intuos4's
<tjaalton> but it has nothing to do with the funcionality of the driver
<tjaalton> +t
<toabctl> tjaalton, but it's a first step, isn't it?
<tjaalton> toabctl: no, it's a "good to have for a nicer lsusb output", but that's it
<tjaalton> my intuos4 works just fine without that
<toabctl> tjaalton, ah.ok
<toabctl> tjaalton, your intuos4 works with lucid?
<tjaalton> yes
<toabctl> then i know what to buy next :)
<toabctl> tjaalton, the newest kernel driver for wacom is available in the wacom-kernel git in drivers/input/tablet, right?
<tjaalton> toabctl: no, it's not updated yet. it's in the latest linuxwacom tarball
<toabctl> tjaalton, in which directory? the names ended with 2.6.27
<tjaalton> there
<tjaalton> diff it against the ones in 2.6.33 and you see what has changed
<tjaalton> hmm, there's thel linuxwacom cvs too
<tjaalton> -l
<toabctl> lol
<tjaalton> http://linuxwacom.cvs.sourceforge.net/viewvc/linuxwacom/linuxwacom-dev/
<tjaalton> the commits are really messy.. "Updated new Bamboo support and fix a tablet rotation issue
<tjaalton> "
<toabctl> tjaalton, i installe the latest xorg driver now (xf86-input-wacom-0.10.4) and the kernel module from linuxwacom-0.8.5-10 and when i insert the tablet now, i got in /var/log/message:
<toabctl> Feb 25 23:37:19 zitrone kernel: [ 8308.664191] usb 3-1: USB disconnect, address 3
<toabctl> Feb 25 23:37:25 zitrone kernel: [ 8315.380103] usb 3-1: new full speed USB device using uhci_hcd and address 4
<toabctl> Feb 25 23:37:25 zitrone kernel: [ 8315.546334] usb 3-1: configuration #1 chosen from 1 choice
<toabctl> Feb 25 23:37:26 zitrone kernel: [ 8315.553354] input: Wacom BambooFun 2FG 6x8 Pen2 as /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1:1.0/input/input18
<toabctl> Feb 25 23:37:26 zitrone kernel: [ 8315.568645] input: Wacom BambooFun 2FG 6x83 as /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1:1.1/input/input19
<tjaalton> that also includes support for intuos4 OLEDS
<tjaalton> ok, that's better
<toabctl> and something happen when i move my finger over the tablet and when i press anywhere. but it's not usable..
<tjaalton> what does udevadm info --export-db show now?
<tjaalton> or the Xorg.0.log?
<tjaalton> does the pen work?
<bryceh> tjaalton, btw do you know why it is that debian renames xf86 -> xserver-xorg ?
<tjaalton> bryceh: no..
<tjaalton> takes longer to type?-)
<bryceh> seems to me that for consistency sake, -evtouch and -wacom ought to be renamed to match
<toabctl> the pen works more or less (maybe it's me who don't know how to use)
<tjaalton> yes, but they are not maintained by xsf
<bryceh> otherwise I wonder why not just go with xf86- and become consistent with upstream
<bryceh> tjaalton, are they ubuntu-only packages?
<tjaalton> they are going to be merged to the server anyway, so
<tjaalton> bryceh: no, -evtouch is maintained by malattia, -wacom by ron
<tjaalton> toabctl: ok, that's great then
<toabctl> tjaalton, here's the output of udevadm info
<tjaalton> toabctl: do you have the module somewhere? if it's i386 and built for the -14-generic kernel I might try it on mine
<toabctl> http://paste.ubuntu.com/384000/
<toabctl> tjaalton, yes arch=i386 and the newest kernel from repository
<toabctl> and i updated the package of xf86-input-wacom with uupdate
<toabctl> i'll write it down in the bug report how to fix it.
<tjaalton> toabctl: hmm it loads synaptics and evdev too
<toabctl> do you want to have the kernel module?
<tjaalton> so maybe the udev rules need an update
<tjaalton> yes please
<tjaalton> one more test before I pass out :)
<tjaalton> toabctl: well?
<toabctl> tjaalton, https://code.launchpad.net/~toabctl/+junk/bamboo
<toabctl> tjaalton, can i finetune the response of the tablet anyway?
<tjaalton> toabctl: it loads the wrong driver for it
<tjaalton> the touch function that is. I see synaptics being loaded
<tjaalton> could be that wacom doesn't support that yet
<toabctl> tjaalton, ah. so new udev rules should fix this?
<tjaalton> I don't know, check the wacom lists
<toabctl> tjaalton, the pen only work if i don't touch the tablet. i have to "fly" over the tablet with the pen
<tjaalton> that's probably evdev then
<tjaalton> yes you could try to fix the udev rules
<toabctl> tjaalton, should i report a bug against the actual kernel? is it possible that the new driver from linuxwacom will be merged into the ubuntu lucid kernel?
<tjaalton> I get an error "invalid module format"
<toabctl> tjaalton, i build with generic-pae kernel
<tjaalton> toabctl: I added the linux task already
<tjaalton> ok, I don't have pae here
<tjaalton> anyway, that's ok
<toabctl> tjaalton, i filled already a bugreport to debian that they should update xf86-input-wacom to 0.10.4
<tjaalton> and I'm not sure if this will be added to lucid
<tjaalton> heh, good luck
<toabctl> tjaalton, why? because ron don't answer?
<tjaalton> toabctl: if he thought 0.10.4 was worth it, it would've been packaged already I think
<tjaalton> but he's right most of the time too
<toabctl> ok
<tjaalton> the current one is patched, since vanilla 0.10.3 didn't work properly
<toabctl> tjaalton, to get the pen working correct, what i have to do?
<tjaalton> not load evdev for it
<toabctl> tjaalton, and how to do that?
<tjaalton> ie. make it match in the wacom udev rules
<toabctl> with udev?
<toabctl> ok
<tjaalton> so it doesn't fall through the cracks so that the evdev rules catch it
<tjaalton> anyway, been up 20h already and can't sit straight anymore. night!
<toabctl> tjaalton, bye and thanks a lot!!!
<toabctl> tjaalton, you are my hero!:-)
<Sarvatt> bryceh: I was talking about the mesa dri drivers, sorry
#ubuntu-x 2010-02-26
<Sarvatt> kklimonda: updated lbm-nouveau uploading now that should fix it
<Sarvatt> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=53293422072043e897c2d755d4139b5e4d5532de
<RAOF> Sarvatt: Have you made it conflict/replaces nouveau-kernel-source?
<Sarvatt> nope, will do that next upload, working on libdrm/ddx now and libdrm is a pain in the butt
<RAOF> *Another* update to nouveau_class.h?
<RAOF> Bah.
<Sarvatt> yeah they do this all the darn time, part of the reason i was so skeptical about nouveau in lucid
<RAOF> But they haven't updated the DDX for those changes; does the DDX not use them at all?
<Sarvatt> think its just mesa that needs the updated nouveau_class.h for now
<Sarvatt> they added texture_from_pixmap to nouveau_vieux to have texture_from_pixmap and stuff a few hours ago
<Sarvatt> err, ignore the bad english :)
<RAOF> Ah.
<Sarvatt> the nv50 stuff just looks like formatting changes and new defines instead of changed values? I dont know
<Sarvatt> guess we'll see if it builds
<Sarvatt> guess i should hold off just incase it needs updating huh? :D
<Sarvatt> libdrm is *such* a pain to update, dont mind holding off :)
<RAOF> :)
<Sarvatt> maybe the kernel guys should just bring nouveau in from upstream instead of linus since its 2.6.32 based and could go right in the kernel without backporting all of drm, that way nouveau would just be the only sketchy thing :)
<RAOF> It's not really 2.6.32-based, though.
<RAOF> It's 2.6.32+drm-next
<RAOF> IE: It's basically 2.6.33's drm stack (and, soon, is likely to be 2.6.34-rc1's drm stack).
<superm1> hmm umm is there any known scenarios that nouveau freezes and next time you try to boot the machine is hung before the BIOS screen...?
<superm1> just a flashing volume LED, no POST no nothing...
<RAOF> It would be theoretically possible for nouveau to do that, I think.  I've never experienced it, though.
<RAOF> You've powered-off, rather than warm-rebooted?
<superm1> unplugged, and removed battery
<superm1> i was just using the machine all day today with a 9.10 install no problems and was trying out the today's 10.04 daily
<RAOF> I don't know; I've never run into anything like that.  I'd give raising this in #nouveau a whirl.
<superm1> * #nouveau :Cannot send to channel
<superm1> is there something special to do to be allowed to talk there?
<RAOF> Are you registered with nickserv?
<superm1> i must have lost my registration during a netsplit or something
<Sarvatt> wow, that would be insane
<Sarvatt> can you blind flash whatever model you're using? alot of people had that happen with the shipping bios on these aspire ones but luckily we can blind flash these to fix it
<Sarvatt> maybe try pulling power/battery and holding the power button for a few minutes and trying again?
<RAOF> Looks like darktama's on it in #nouveau.
<superm1> Sarvatt, flashing unfortunately requires it to be booted on these, and only from DOS binaries
<Sarvatt> no hidden key combo to bypass it and flash? i think its function+escape in most insyde bioses
<superm1> if it at least POSTed maybe, but it's definitely hung on boot when trying to POST - the backlit keyboard doesn't even turn off
<superm1> which is normally BIOS controlled
<Sarvatt> function+escape, press power, wait a few seconds and release function+escape and the power light blinks
<Sarvatt> when mine crashes i dont get POST or anything and it still has a recovery blind flash you can do at least
<superm1> same behaviors when i'm trying that
<Sarvatt> does it through the insyde efi internal stuff instead of the bios emulation layer or something
<Sarvatt> oh that means it should work
<superm1> no i mean same behaviors as what i was seeing before
<superm1> flashing volume LEDs, frozen backlit keyboard no POST
<Sarvatt> need a usb stick formatted fat, with the bios named whatever.FD on it
<Sarvatt> oh ok
<superm1> well i'm not sure i want to sacrifice another laptop like this to try'n fetch the X log
<Sarvatt> RAOF: forgot to attach the debdiff?
<RAOF> To the lbm bug?  No.  Just filing first, so I can close it in the changelog :P
<RAOF> Do we currently have somewhere to publish that for ctxprog testing?  I don't have any cards new enough to need it.
<Sarvatt> The attached debdiff pulls the nouveau changes from 2.6.33-rc7 to 2.6.33
<Sarvatt> :P
<Sarvatt> maybe x-updates?
<RAOF> It's attached now :P
<Sarvatt> or delete all of xorg-edgers/nouveau and just put that in there
<Sarvatt> kklimonda had problems with just the ctxprogs generator :(
<Sarvatt> there was another fix in upstream git for it
<RAOF> Was that with the fix?
<RAOF> Right; that's in the debdiff, too.
<Sarvatt> i'm  not sure if that fixed it for them though
<RAOF> That's what I was thinking, but I think bryceh has disabled xorg-edgers/nouveau?
<Sarvatt> ya should be able to reenable it
<Sarvatt> only me and tormod are admins so i think anyone can
<Sarvatt> done
<RAOF> And are you subscribed to lbm in lucid, or something? :)
<Sarvatt> nope, I was just looking into joining bug-control and saw the bug rss feed link, yours was the first one on the list :)
<RAOF> Hah.
<Sarvatt> Posts per week: 1,537.2
<Sarvatt> sheeeesh
<Sarvatt> i thought ubuntu-x-swat was bad :)
<Sarvatt> http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-drv-nouveau/nouveau-bgnr.patch?view=markup
<Sarvatt> yoink
<RAOF> Ah.  We want that for plymouth, don't we.
<Sarvatt> we have 189_xserver_1.5.0_bg_none_root.patch in xserver but none of the ddx specific patches enabling it there
<Sarvatt> looks like its being used too /usr/bin/X :0 -nr -verbose -auth /var/run/gdm/auth-for-gdm-j5c54J/database -nolisten tcp vt7
<Sarvatt> (the -nr option)
<Sarvatt> http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-drv-intel/copy-fb.patch?view=markup
<Sarvatt> intel version
<Sarvatt> well thats for 2.10, 2.9.1 version is http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-drv-intel/copy-fb.patch?revision=1.9&view=markup
<Sarvatt> ah we've got the intel one in the lucid package, explains why i lost the smooth transition when i switched to edgers :)
<Sarvatt> gotta add that nouveau one though
<Sarvatt> imagine theres a radeon one we need to pick up too
<RAOF> It looks pretty simple.
<Sarvatt> the smooth transition  looks really nice, leaves the logo on the screen while the panel loads and stuff
<Sarvatt> not just a jerky 1 second ubuntu splash to  a black screen like it is without it
<Sarvatt> uploading a new nouveau snapshot on edgers with that patch
<RAOF> Huzzah.
<Sarvatt> there's radeon's patch -  http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-drv-ati/radeon-6.9.0-bgnr-enable.patch?view=markup
<Sarvatt> ahhh looks MUCH better now
<Sarvatt> i didnt understand the point of a 1 second splash screen but its nice with these ddx patches at least
<RAOF> I've also applied that to nouveau in pkg-xorg git.
<Sarvatt> woot just need to see if radeon has the patch or not now
<Sarvatt> btw found a api 0.0.16 patch for 2.6.33, might use that on top of linus' for nouveau http://cvs.fedoraproject.org/viewvc/devel/kernel/drm-nouveau-abi16.patch?view=markup
<Sarvatt> all kinds of crack in fedora cvs
<tjaalton> bryceh: doesn't bzr hate you just as much when you forget to do 'bzr extmerge --all' or something?-)
<Sarvatt> fbdev bgnr patch, that'd help out arm - http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-drv-fbdev/BGNoneRoot.patch?view=markup
<Sarvatt> http://sarvatt.com/downloads/patches/xserver-xorg-video-fbdev_0.4.1-1ubuntu1.debdiff
<toabctl> hi
<bryceh> tjaalton, haven't found bzr hating me so far
<tjaalton> bryceh: just because you haven't done any merges like that with it :)
<tjaalton> no tool does that automatically
<tjaalton> bryceh: bh.org:8080 fails to connect
<bryceh> tjaalton: yeah I'm in the middle of a hardy->lucid upgrade and it's an old machine so it's hit a variety of glitches
<tjaalton> bryceh: heh, ok. I'm doing karmic->lucid on my home desktop, though it still needs more space on /
<tjaalton> it's a 500GB disk and root has 11GB.. how wise was that?
<bryceh> /dev/sda4              13G   11G  2.1G  83% /
<bryceh> I wasn't much smarter tjaalton
<bryceh> but it's just a webserver so I've been able to just uninstall stuff to get it down
<bjsnider> there aren't any remaining issues with jockey being able to activate the nvidia driver are there?
<bryceh> bjsnider, probably will always be some issues, but at the moment I believe we believe it should work properly
<bjsnider> cool
<bjsnider> the +1 channel is choked with people complaining about it, but i think it's where they upgraded from that's the problem
<bryceh> ah, are they mostly upgrading from self-installed nvidia's?
<bjsnider> good question. i'm guess they were using the nvidia installer
<bryceh> tseliot has been looking to these kinds of bugs so he might want to look into it
<superm1> bryceh, tseliot perhaps a good solution is to have update-manager attempt to detect a situation that the nvidia installer has been manually ran just like the packages do, and block the upgrade until it's removed
<bjsnider> superm1, what if the user does not know how to remove it?
<Sarvatt> we should probably have nvidia-current packages conflict with -190 and -195 even though they were never in ubuntu since alot of people used PPAs
<Sarvatt> how about a preinst script for nvidia that tries to find a nvidia-installer binary, and calls it with nvidia-installer --uninstall before?
<Sarvatt> or just wont install if it exists since it's only there if the blob has been manually installed as far as I can see
<mvo> superm1: if someone gives me instructions what to look for I'm happy to implement that
<apw> RAOF, about?
<Sarvatt> jcristau: \o/ \o/ \o/ THANK YOU! :)
<Sarvatt> for the patch on dri-devel
<Sarvatt> moving libdrm headers to /usr/include/libdrm will be so much better
<superm1> tseliot, can you provide mvo that information?
<Sarvatt> I think you could check for /usr/bin/nvidia-bugreport.sh
<Sarvatt> i see that in the extracted .run but its not installed in the package
<tjaalton> instead of nvidia-bug-report.sh, which was installed by the deb?
<Sarvatt> ah darn yeah its in /usr/lib/nvidia-current/bin/ in the deb
<Sarvatt> tls-test isnt in the deb though
<tjaalton> /usr/bin/nvidia-bug-report.sh in karmic
<tjaalton> but that's 185
<bryceh> tjaalton, btw bh.org back online.  upgrade complete.
<Sarvatt> --slave /usr/bin/nvidia-bug-report.sh nvidia_bug_report /usr/lib/nvidia-current/bin/nvidia-bug-report.sh \
<tjaalton> bryceh: ah, good
<Sarvatt> /usr/bin/tls-test isnt installed in the nvidia-current package though, no clue if its installed manually but its in usr/bin/ in the extracted blob
<Sarvatt> /usr/lib/libGL.la?
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/nouveau-kernel-source/+bug/528683
<ubottu> Launchpad bug 528683 in nouveau-kernel-source "Please remove nouveau-kernel-source from the archive (lucid)" [Undecided,New]
<Sarvatt> wish i could set wontfix, closing out a crapload of nouveau-kernel-source lucid bugs
<johanbr> superm1, any luck with your half-dead laptop?
<superm1> johanbr, yes it's back to life per some comments in #nouveau, but it certainly freezes on any lucid boot now, and is broken again
<Sarvatt> the new lbm-nouveau that just got uploaded should help you superm1
<superm1> Sarvatt, okay i'll wait until a new daily image to try again
<Sarvatt> it still might be iffy, the chipset generation you have is one of the sketchier ones with the ctxprog generator and you might need to boot with lbm-nouveau.noaccel=1 manually from tomorrows livecd
<Sarvatt> bryceh: if we're sticking to 2.9.1 shouldnt we stop passing --enable-kms-only for intel? so these 8xx people can boot with UMS
<Sarvatt> actually, i'm wondering if these people saying booting with i915.modeset=0 on 8xx are actually using vesa when they say it works that way because of that
<Sarvatt> saying that works I mean
<Sarvatt> because if thats the case it changes my opinion on the 2.9.1/2.10 debate :)
<bryceh> Sarvatt, yep, it's on my todo list to reverse that
<bryceh> who is saying that modeset=0 works for them?  I agree it'd be good to look at their xorg.0.log
<Sarvatt> that blog you linked the other day for one, i dont have any specific bug #'s handy but i'll keep an eye open when i see another next
<Sarvatt> because if it works with modeset=0 and they are using vesa that way because of the intel configure flag just moving them to vesa + modeset=0 or fbdev on top of KMS with intel 2.10 might be better. reverting that configure flag might break things again since they'd be using UMS intel instead
<bryceh> mm true
<bryceh> still, I think it's a good strategy for us
<superm1> bryceh, recently cjwatson removed xforcevesa from the daily's afaik.  if new nvidia hardware is gonna be iffy with nouveau, i think it'll be important to still have that as an option
<superm1> although i guess the nouveau kernel module is still gonna load with that isn't it..
<superm1> so still potential to break
<bryceh> superm1, yeah
<superm1> so perhaps xforcevesa should still live on, but blacklist intel/radeon/nouveau?
<bryceh> superm1, on the plus side, failsafex now uses fbdev properly with kms (and I even tested it on nouveau), but I think that kicks in only for X breakage.  If something is wrong at the KMS layer, I'm not sure it'll help
<bryceh> superm1, sounds like something we need to chat with sconklin and apw about
<bryceh> superm1, along with that is the need for enabling users to override the mode detection such as if a KVM is blocking edid (as per discussion on kernel list the other day)
<superm1> bryceh, yup
<superm1> well once things are declared more "stable", the QA folks should try on newer hardware and see if the need is really still there too
<bryceh> superm1, would you mind writing this up as a bug report to the kernel?  I'll +1 it and bump up priorities for it with apw/sconklin
<Sarvatt> video=blah doesnt work for whoever had that problem bryceh?
<bryceh> Sarvatt, I've heard it didn't; I've not tested that myself so dunno if that is a general solution to this or not
<bryceh> you tested it yet?
<Sarvatt> yeah it works here but i only played with it with a console boot
<Sarvatt> so a kernel command line option that launches a failsafe X would work right? is that all xforcevesa did before?
<Sarvatt> oh spiffy, you got the fbdev + kms stuff working in failsafeX bryce? gotta try that out
<BUGabundo> boas noites
<tjaalton> superm1: xforcevesa hasn't been useful since we stopped using dexconf
<tjaalton> ie. it did nothing aiui
<superm1> tjaalton, not true, please see casper bzr
<tjaalton> not without a link :)
<superm1> lp:ubuntu/casper/lucid
<superm1> it's in casper-bottom
<tjaalton> a browser link
<superm1> 20xconfig
<tjaalton> bah, don't bother :)
<tjaalton> trust your word on it
<bryceh> Sarvatt, yeah failsafeX should be good to go with KMS now
<bryceh> Sarvatt, I'm not sure that xforcevesa made failsafex launch, or just make the system boot with vesa
<bryceh> if the latter, then maybe what's needed is something to force fbdev?
<bryceh> s/make/made/
<bryceh> (I builk software too much)
<bryceh> Sarvatt, it might be nice to have a way to launch into failsafex from grub or from the safeboot option maybe
<bryceh> not sure
<bryceh> maybe a lucid+1 thing
<tseliot> superm1: ?
<tseliot> superm1: the installer might break things in different ways and you need to shut down X in order to do --uninstall (if I remember correctly)
<superm1> tseliot, well the thought process is tell the user they need to do that to upgrade, so you dont knowingly break
<superm1> they had to stop X to do it once, they can do it again
<tseliot> superm1: aah, ok
<bjsnider> superm1, but do they know about the --uninstall option?
<bjsnider> it would be better if nvidia just didn't provide an installer at all
<superm1> bjsnider, you tell them in the popup from update-manager
<bjsnider> cool
<superm1> warning: you installed using the nvidia installer, you must uninstall using blah blah command 
<superm1> and give them directions
<bjsnider> confusing
<bjsnider> if i didn't already know what it is i might ask what the nvidia installer is
<tjaalton> heh, could reproduce the "package foo in installed and configured already" 'bug' while upgrading to lucid
<tjaalton> happened because root got full, despite u-m thinking it had enough space before it started the upgrade
<tjaalton> s/in/is/
<superm1> bjsnider, well hopefully they'll remember that they manually ran said command to install the nvidia driver the first time
<Sarvatt> bryceh: hmm, failsafe no workie here at all - http://pastebin.com/j9tCXSsR
<Sarvatt> at least with the old echo foobar > /etc/X11/xorg.conf method
<bryceh> Sarvatt, got an Xorg.failsafe.log ?
<Sarvatt> its from feb 11th, it didnt even try to use failsafe
<bryceh> got any xorg.conf.failsafe ?
<Sarvatt> yeah the old vesa one
<bryceh> hmm
<Sarvatt> from feb 11th too
<bryceh> doublecheck that you're using the latest version of xorg - verify that /etc/gdm/failsafeXServer has a timestamp of yesterday or newer
<bryceh> if that's good, then check the udev rule that is supposed to trigger failsafeX
<Sarvatt> -rwxr-xr-x 1 root root 4484 2010-02-23 01:37 /etc/gdm/failsafeXServer
<bryceh> pastebinit /etc/gdm/failsafeXServer
<bryceh> I think it should have a newer timestamp, it might be missing the fbdev bits.
<Sarvatt> http://pastebin.com/Uzg5YFBC
<bryceh> but that should have at least touched Xorg.failsafe.log
<bryceh> yep that's the right version of failsafeXServer
<Sarvatt> yeah it didnt even try, it just used a normal session and failed
<bryceh> check the udev rule
<Sarvatt> trying to find it
<bryceh> that's one bit I did not test
<Sarvatt> nothing in /lib/udev/rules.d/ that matches for grep -R failsafe .
<bryceh> hmm
<Sarvatt> its a udev rule that triggered it before? didnt know that
<bryceh> originally it was gdm that triggered it
<bryceh> but they dropped the functionality from gdm that we needed 
<bryceh> (I guess redhat didn't need it for anything *grin*)
<bryceh> so slangasek did a udev rule for it in karmic
<bryceh> x11-common.failsafe-x.upstart
<Sarvatt> no x11-common.failsafe* anywhere on my system
<bryceh>         dh_installinit -px11-common --no-start --upstart-only --name failsafe-x
<Sarvatt> ah init script
<Sarvatt> theres a /etc/init.d/failsafe-x
<bryceh> that's probably it
<BUGabundo> guys how can I find out the EDID of my external LCDTV plugged via vga?
<bryceh> BUGabundo, xrandr --verbose or get-edid
<Sarvatt> dont be surprised when your tv doesnt expose all the resolutions i t works at over vga
<BUGabundo> I know
<BUGabundo> vga has limits
<BUGabundo> *lower
<Sarvatt> most 720p hdtv's i've messed with just do 800x600 :(
<BUGabundo> mine goes higher
<BUGabundo> but its cutting of part of the screen
<BUGabundo> or off center
<BUGabundo> depending on res
<BUGabundo> $ xrandr --verbose | pastebinit 
<BUGabundo> http://paste.ubuntu.com/384746/
<Sarvatt> so i guess you could just do sudo /etc/init.d/failsafe-x start to start failsafe instead of the xorg.conf trick
<BUGabundo> http://paste.ubuntu.com/384748/
<Sarvatt> /etc/init.d/failsafe-x just looks like a skeleton
<bryceh> it's a symlink
<Sarvatt> cant wrap my head around how failsafe is started
<bryceh> there must be a config file installed somewhere
<BUGabundo> wow
<BUGabundo> at 800x600 the pic is really nice
<bryceh> ah /etc/init/failsafe-x.conf
<Sarvatt> you have that?
<Sarvatt> thats a leftover from superm1's dkms thing i think?
<Sarvatt> its .unused here
<Sarvatt> failsafe-x.conf.unused
<Sarvatt> it got marked .unused during an upgrade a few months ago
<bryceh> hrm
<bryceh> I'm fairly sure this machine is a fresh install within the last month or two
<Sarvatt> you have an /etc/init/failsafe-x.conf bryceh? maybe I screwed something up
<bryceh> yeah I used the alpha-2 cd to install from
<Sarvatt> will check my other machines when i get home
<tjaalton> I have that after the upgrade
<Sarvatt> i wouldnt put it past me to have renamed it screwing around with something
<Sarvatt> .unused or .conf?
<tjaalton> .conf
<Sarvatt> ahh i screwed with it then, sorry about that
<bryceh> $ dpkg --contents /var/cache/apt/archives/x11-common_1%3a7.5+1ubuntu6_all.deb | grep failsafe
<bryceh> -rw-r--r-- root/root       132 2010-02-18 16:02 ./etc/gdm/failsafeBlacklist
<bryceh> -rwxr-xr-x root/root      8610 2010-02-18 16:02 ./etc/gdm/failsafeXinit
<bryceh> -rwxr-xr-x root/root      4595 2010-02-18 16:02 ./etc/gdm/failsafeXServer
<bryceh> -rw-r--r-- root/root       291 2010-02-18 16:02 ./etc/init/failsafe-x.conf
<bryceh> lrwxrwxrwx root/root         0 2010-02-18 22:06 ./etc/init.d/failsafe-x -> /lib/init/upstart-job
<bryceh> Sarvatt, try reinstalling x11-common
<Sarvatt> i bet it was when i was getting failsafe every time a fsck was run and it was annoying me :D
#ubuntu-x 2010-02-27
<Sarvatt> bryceh: failsafe works *great* now with kms/fbdev, thanks for fixing that :)
<bryceh> sweet
<superm1> Sarvatt, i only changed it at one point, and my changes were reverted
<tjaalton> so nvidia suspend/resume results in corrupt compiz effects
<tjaalton> meh
<tjaalton> if we get the .33 drm in the kernel, then radeonhd should be obsolete even for the hdmi-audio users
<tjaalton> huh, jockey makes me use -nv instead of nouveau when I disable the blob?
<tjaalton> and lbm_drm doesn't load, so I get vesa without xorg.conf
<tjaalton> it was the -pae kernel which made it not load
<tjaalton> plain generic works, though the monitor goes to sleep until plymouth kicks in several seconds later
<tjaalton> oh right, I don't have the lbm for -pae
<yofel> hi, would this be an X or goldendict bug: http://imagebin.ca/view/fg6r1MN.html
<yofel> (on lucid)
<baptistemm> grep -i record /var/log/Xorg.0.log sould say if you have record extensios nor not
<jcristau> yofel: X.
<baptistemm> apparently it is disabled on lucid, there is even a bug number in the X start log 
<jcristau> will be fixed in 1.7.6
<yofel> jcristau, baptistemm, thanks!
<johanbr> weird... starting abiword when running nouveau gives me a hard lockup
<johanbr> (only with 3d enabled, though)
#ubuntu-x 2010-02-28
<LLStarks> bryceh, why does nvidia-current keep getting pulled on my intel box. it keeps ****ing up my libgl.
<bjsnider> i believe nvidia-current is always installed by default. it is only activated if done manually through jockey
<tjaalton> not true
<tjaalton> I don't have it
<bjsnider> maybe he has a metapackage or something
<bjsnider> nvidia-common?
<tjaalton> that's installed on every system, but it doesn't pull -current
<tjaalton> LLStarks: purge it, it should say what depends on it
<bjsnider>  restricted modules?
<tjaalton> apt-cache rdepends nvidia-current shows the deps
<LLStarks> i do, but somehow it ends up back on my system once in a while.
<tjaalton> one of those is the culprit
<LLStarks> i don't know how to keep my libgl alternates from changing
<tjaalton> well trace the deps from aptitude
<LLStarks> well, how i do use the proper libgl without uninstalling nvidia-current?
<tjaalton> uncheck it from jockey
<bjsnider> i don't see why nvidia-current couldn't be installed on any system, as well as fglrx, as long as it isn't activated and isn't in the xorg.conf file, if there is one
<bjsnider> but i thought that was supposed to be the policy in lucid
<tjaalton> yes, it _can_ be installed and not used, but they are not installed by default
<LLStarks> it's getting activated somehow and i forgot the update-alternatives command for libgl.
<bjsnider> so then jockey prompts the user to not only activate it but to actually install it too
<LLStarks> i don't use jockey driver manager
<tjaalton> bjsnider: at least the first time, yes
<bjsnider> is nouveau installed by default?
<tjaalton> yes
<bjsnider> oh my goodness that's funny
<tjaalton> why?
<bjsnider> nvidia is the preferred driver
<tjaalton> by whom?
<bjsnider> typical nvidia users
<tjaalton> could be
<tjaalton> ubuntu has never installed it (or fglrx) by default
<tjaalton> and doing so wuld be a pr loss among the devs
<tjaalton> would
<bjsnider> installed but _not_ activated
<bjsnider> would be a pr loss?
<tjaalton> yes
<bjsnider> but it would be easier on users
<tjaalton> why? they still need to enable it
<tjaalton> besides there is no space on the cd's
<bjsnider> true
<bjsnider> there would be on the dvd
<bjsnider> and the network install
<tjaalton> I don't think it's ever going to be installed by default
<bjsnider> this boils down to a FOSS issue correct?
<tjaalton> it's already made as easy as possible, no need to go further
<tjaalton> lucid+1 will have nouveau 3D-support
<tjaalton> so even less of a reason to push for the blob
<tjaalton> speaking of nouveau, starting a second session fails when checking the drm, and then the first session breaks as well
<tjaalton> it's like the vt's were on top of the X session, since the mouse cursor works and changes as if there were windows under it
<ryanakca> Is there a reason xorg depends on x11-apps instead of simply recommending or suggesting it?
<jcristau> hysterical raisins i'd think
<ryanakca> I doubt people really use xlogo, xbiff, xedit, xeyes, xgc & co any more
<jcristau> otoh what harm are they doing?
<ryanakca> jcristau: They take up space on the LiveCD that doesn't need to be taken up :)
<ryanakca> If someone has been long around to use xbiff or xman or xclock, they've been long around enough to apt-get install x11-apps
<jcristau> oh.  i guess there are people who care about that..
<fabounet> @saravatt / bryceh / jcristau : Hi
<fabounet> I was told you could help regarding some problems Cairo-Dock has with some graphic cards
<fabounet> s/saravatt/Sarvatt
<matttbe> I'm sure: They watch TV (USA vs. Canada) ^^
<matttbe> (but I don't say the current result :P )
<RAOF> fabounet: It's probably a good idea to just state the problems cairo-dock has with some graphics cards; there are others who could help, too.
<fabounet> yep, I'm looking forward to solve this, if possible
<fabounet> actually it seems some drivers still have an incomplete support of OpenGL 2.0
<fabounet> old ATI, but also some Intel cards
<fabounet> the problem seems to come from the lack of pbuffers support
<jcristau> and?
<jcristau> afaik pbuffers are deprecated
<fabounet> they are part of opengl though
<fabounet> and supported on most cards
<jcristau> not on the free drivers iirc
<fabounet> sometimes indirect rendering gives good results
<fabounet> do you mean pbuffers are banned from Intel drivers now ?
<jcristau> probably not.
<jcristau> but i still don't know what your problem is
<fabounet> the situation varies depending the card
<fabounet> for instance on nettbooks (GMA450), using indirect rendering makes everything works, but on not GMA800
<jcristau> what's gma800?
<fabounet> maybe it was an other number, don't remember exactly.
<fabounet> some more evoluted model
<fabounet> had this bug recently
<fabounet> anyway all Intel cards don't behave the same
<RAOF> Isn't it pretty much always the client's responsibility to check for needed GL extensions & fallback if necessary?  Can't you detect the presence of the necessary GL support & react appropriately?
<fabounet> I was expecting they would eventually have the same level of support for OpenGL2.0
<jcristau> i915 can't go above 1.4 or 1.5 according to wikipedia
<fabounet> well I do detect the presence of pbuffers.
<fabounet> bt soetimes indirect rendering is needed to make them work
<fabounet> and sometimes it's the opposite (Gallium ATi R3xx drivers)
<jcristau> i965 can do 2.0 or 2.1
<fabounet> seems there is no definite method to be sure
<RAOF> I do recall compiz wanting a GLX call to determine what GL extensions a particular context supports, so it could discriminate between extensions supported with a direct context & those only supported with an indirect context.
<fabounet> that would be helpful
<fabounet> currently I check that GLX is >= 1.3
<fabounet> if not, then it's unclear
<jcristau> anyway from what i understood (i know nothing of GL) the recommended method is to use fbos instead of pbuffers.
<fabounet> do you remember the way to be sure whether indirect rendering would be needed ?
<RAOF> That's my (somewhat second hand) understanding, too.
<fabounet> fbo is younger than pbuffer, is it more supported though ?
<jcristau> #dri-devel might be a better place for this, it has people who know gl and write those drivers..
<fabounet> ok, well I'll go and ask them then.
<fabounet> thanks for your advices !
<jcristau> seems like i didn't misremember too much :)
<fabounet> yep, seems I'll have to rewrite some part with fbo ^^
<RAOF> What's meant to be shipping drm.h at this point?  I can't build nouveau because I can't find drm.h :)
<tjaalton> linux-libc-dev
<libv> which interestingly also carries driver specific headers.
<RAOF> Ah.  Why is linux-libc-dev not providing drm.h for me?
<Sarvatt> if you're using edgers its libdrm-dev and you have to reinstall it every time theres a linux-libc-dev update
<Sarvatt> hope jcristau's libdrm header patch goes upstream :)
<RAOF> Hm.  Maybe that did'nt get replaced when I un-edgered.
<Sarvatt> yeah i have a note on the page saying you need to reinstall linux-libc-dev when you switch away from edgers
<Sarvatt> hmm looks like xserver-xorg-video-intel 2.10.901 requires >= xserver 1.7 now? http://launchpadlibrarian.net/39848281/buildlog_ubuntu-karmic-i386.xserver-xorg-video-intel_2:2.10.901%2Bgit20100226.a0ee9c3d-0ubuntu0sarvatt~karmic_FAILEDTOBUILD.txt.gz
#ubuntu-x 2011-02-21
<raevol> there's been a lot of work done on it since it was pulled into maverick before release, and i'd like to take advantage of some of the new code :/
<RAOF> There's always xorg-edgers.
<raevol> yea i'm not that harcore :[
<raevol> hardcore* god my typing is terrible today
<cnd> RAOF, I have good news :)
<cnd> I'm right now packaging all the stuff up to test and push to my ppa tonight
<RAOF> cnd: Excellent.
<RAOF> I'll try to have 1.10RC2 merged by the time you're ready, then :)
<RAOF> cnd: You've been a-workin' on the weekend? :(
<cnd> RAOF, umm, and last weekend too...
<cnd> I haven't had a day off for two weeks now :(
<cnd> RAOF, when will you be uploading xorg-server to ubuntu (or to git)?
<cnd> when I'll be able to get the source, basically
<RAOF> I'll probably be able to get it done today, so that would be in <6hrs time.
<cnd> ok, so after I
<cnd> I'm asleep :)
<RAOF> I was thinking that we'd use this opportunity to also fold in the Xi 2.1 stuff; that'll just be a couple of patches, right?
<cnd> yeah
<cnd> so if you want, you can push to git
<cnd> and then I can push my updates to git
<cnd> and then you can upload
<cnd> sound good?
<RAOF> That'd work.
<cnd> RAOF: when do you want to push by?
<RAOF> If you've got stuff ready now you could just push to git and I'd just fold that in with the rest of the merge.\
<cnd> it's not ready quite yet
<RAOF> Or you can push after me, which would be tomorrow morning for you I guess ;)
<cnd> I'm making packages right now
<cnd> and then I need to test locally
<RAOF> Soft!
<cnd> and I was hoping to have one day tomorrow to have people bang on it
<RAOF> Real men test in the archive :)
<cnd> heh
<RAOF> Ok.
<RAOF> There's no OMGHUGE rush for the merge; a day's testing wouldn't hurt it, either.
<cnd> k
<cnd> I'm so excited :)
<RAOF> Obviously FF is our deadline :)
<RAOF> And you just can't hide it?
<cnd> especially since it actually works :)
<RAOF> :D
<cnd> the one thing holding me back is that I'm still glossing over a few things
<cnd> like what do you do for pointer emulation of a new touch when there's an active grab on the pointer?
<cnd> corner cases like that
<RAOF> Fiendish protocol-level corner cases.  Yay.
<cnd> I think it won't fall over, but I'm not 100% sure it'll behave as one might assume
<RAOF> And you'll also get to take a couple of days off once the FF deadline hits, right?
<cnd> heh, I hope so :)
<cnd> oubiwann is awesome, he'll probably make me take the time off :)
<RAOF> :)
<cnd> testing looks good, time to push to git repos and make source packages :)
<cnd> tjaalton, it looks like you've uploaded a new libxi, but the git tree hasn't been updated
<cnd> can you update it for me?
<RAOF> Ooh, funky.  Damage bugs!
<cnd> it takes waaaay too long to upload a qt package...
<cnd> 207 MB source tarball...
<RAOF> Xi2.1 Qt?
<tjaalton> cnd: it's been synced from debian, there were no ubuntu changes
<RAOF> Oh, no.  intel/nouveau switcheroo problems :(
<RAOF> I suspect bug #718620 of being switcheroo related.
<ubot4> Launchpad bug 718620 in xorg-server (Ubuntu) "Xorg assert failure: X: ../../dix/pixmap.c:118: AllocatePixmap: Assertion `pScreen->totalPixmapSize > 0' failed. (affects: 9) (dups: 11) (heat: 92)" [Medium,New] https://launchpad.net/bugs/718620
<tjaalton> RAOF: regarding bug 718331, there's a newer upstream release which could help
<ubot4> Launchpad bug 718331 in xf86-input-wacom (Ubuntu Natty) (and 1 other project) "Xorg crashes on wacom input moule (affects: 5) (dups: 1) (heat: 30)" [High,Incomplete] https://launchpad.net/bugs/718331
<RAOF> tjaalton: Aah, quite possibly.
<RAOF> Argh.  Why doesn't everyone have debugging symbols installed all the time? :(
<tjaalton> 0.10.11, though .12 should be arriving too at some point
<tjaalton> right :)
<tjaalton> all the xorg-packages should imho also have a -dbg counterpart
<tjaalton> but wacom is maintained by ron
<RAOF> Nah; -dbgsym is easy.
<tjaalton> it's not apt-get'able?
<RAOF> *Debian* should have -dbgsym, and we should drop all the trivial -dbg packages.
<RAOF> tjaalton: It totally is.
<tjaalton> oh
<RAOF> See https://wiki.ubuntu.com/DebuggingProgramCrash :)
<tjaalton> i'm missing the source then
<tjaalton> fixed
<RAOF> I wonder whether we shouldn't have that in the default sources.
<RAOF> At least during development.
<tjaalton> right
<tjaalton> huh, uses a different signing key
<tjaalton> oh wacom 0.10.11 was released last week, so it's quite fresh
<RAOF> cnd: xserver is in git, for your delectation.
<RAOF> tjaalton: I don't suppose you have a switchable graphics system to confirm my suspicion that 718620 is switcheroo-based (and get a better backtrace at the same time âº)?
<tjaalton> RAOF: nope..
<tjaalton> does switcheroo work on a desktop with embedded and discrete graphics, or is it laptop only? (not that I have such a desktop either)
<RAOF> It requires ACPI support; it's likely that only laptop manufacturers bother.
<tjaalton> ok
<tjaalton> RAOF: i've a patch to fix mumble, will push soon
<tjaalton> to xorg-server
<RAOF> tjaalton: Sweet.  I'd also like to convince myself that 718620 isn't an xserver problem.
<tjaalton> RAOF: yeah, nasty..
<tjaalton> lunch->
<RAOF> It's probably something in the plymouth integration patch that doesn't work when copy_from_fb fails.
<tjaalton> eh, https://launchpad.net/xserver
<cnd> tjaalton, true, but I still can't find it in git
<cnd> I can push the changes to git though
<tjaalton> cnd: the ubuntu-branch there is stale, last updated 21 months ago
<tjaalton> cnd: so you can pretty much do whatever you like with it :)
<cnd> yeah
<apw> cnd, playing with mumble to try and work out why the PPT buttons don't work
<apw> its looking like the xserver hasn't sent us the events we asked for ... is there any way to ask the Select extenstion whats goign on?
<apw> or any small examples of asking for key events i can use for testing
<jcristau> there's a fix for the mumble thing in git, aiui
<apw> oh ... pthth ... 
<apw> jcristau, got a pointer to the git so i can look ?
<jcristau> http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=commitdiff;h=74acb8b958a0e19beae993f0c1f4627ab2296ee0
<apw> jcristau, oh so its an xserver issue ...
<jcristau> (also at http://patchwork.freedesktop.org/patch/4200/)
<apw> do we already have that fix coming?  and i am just behind or ?
<jcristau> it's queued for whenever the next upload is, i think
<apw> jcristau, heh then thank you i can go back to ignoring it for a bit :)
<tjaalton> apw: you're subscribed to the bug, should've seen that it's "fix committed" :)
<cnd> apw: the next upload should be tomorrow
<cnd> with my multitouch stuff :)
<apw> tjaalton, heh oops
<apw> cnd, sounds good ... except i expect it'll be all broke :)
<cnd> apw, of course it will!
<cnd> I'm going to try my hardest to somehow cause a kernel panic from multitouch :)
<ricotz> Sarvatt, hi, perhaps it is useful to propose the pixman update before FF while the notify-osd update seems to take longer
<lilstevi> is there a way to get an onscreen keyboard to automatically launch with netbook launcher
<tjaalton> ricotz: national holiday in US today ;)
<ricotz> tjaalton, oh, ok ;)
<Sarvatt> ricotz: yeah been 2 weeks now, sounds good to me :)
<ricotz> Sarvatt, are you able to sponsor it?
<Sarvatt> ricotz: nope I don't have permissions for it. tjaalton, would ya be willing to sponsor a pixman 0.20.2 update for ricotz? his update looked good to me when I reviewed it
<ricotz> tjaalton, that would be great http://people.ubuntu.com/~ricotz/pixman/
<Sarvatt> 0.21.x isn't appropriate for natty, 0.20.2 is the latest stable release, there is just an issue with notify-osd popups looking screwed up that has been waiting to have the fix uploaded since december but feature freeze and all, dont think we can wait anymore
<seb128> it's easy enough to grab the notify-osd commit and upload to natty
<seb128> don't bother about small breakages in unstable series
<ricotz> seb128, yeah, macslow said he wanted to do it soon
<seb128> usually having things broken motivate to get the fix in when that has been not really moving for a while
<seb128> he was sick this weekend and has work to finish before feature freeze
<seb128> so it's likely to not land before feature freeze
<ricotz> right, but we wanted to prevent a bug flood ;)
<ricotz> ok
<Sarvatt> seb128: well I was getting a crazy amount of emails about the problem just from edgers and was worried about when it actually went in the distro
<seb128> can't you just upload a notify-osd with the patch in natty?
<Sarvatt> not sure the guy signed the contributor agreement
<seb128> Sarvatt, no need to have a c-a for a distro patch
<seb128> that's only an issue to merge in the upstream trunk
<tjaalton> Sarvatt: sure, i'll upload it later when i'm back home
<ari-tczew> shrugs, when we will get new nvidia driver?
<ricotz> tjaalton, thanks
<ricotz> ari-tczew, depends on when nvidia decides to release a working one
<ari-tczew> ricotz: changing resolution and fan's speed every boot making me crazy
<ricotz> ari-tczew, nouveau should work pretty fine detecting the right resolution, of course it doesnt take care of your fan speed
<ari-tczew> ricotz: 1024x768 is not native resolution for my lcd
<ari-tczew> so it's not prettty
<ricotz> ok, if you are nouveau and nvidia blob is removed, it looks like a bug which might be reported
<ricotz> probably an edid problem
<alex_mayorga> on bug 553789 should I provide further peeks?
<ubot4> Launchpad bug 553789 in xserver-xorg-video-nouveau (Ubuntu) (and 2 other projects) "X freeze/crash with nouveau driver (affects: 22) (dups: 5) (heat: 108)" [High,Confirmed] https://launchpad.net/bugs/553789
<alex_mayorga> X keeps freezing every 2-4 hours or so
<alex_mayorga> what else should I gather?
<alex_mayorga> I have an ssh window to the frozen laptop
<alex_mayorga> bryceh: ping
<tjaalton> alex_mayorga: no
<alex_mayorga> tjaalton: so for now is just patience and frequent reboot?
<alex_mayorga> or should I try edgers or something?
<alex_mayorga> or is there a way to restar X from an ssh window?
<hyperair> restart gdm
<hyperair> or rather, sudo restart gdm
<alex_mayorga> hyperair: thanks! Let me try that
<alex_mayorga> didn't do unfortunately
<tjaalton> alex_mayorga: there is no known fix, nor is there one on the horizon
<alex_mayorga> tjaalton: I see, this would bug me on every distro right?
<tjaalton> a workaround is to disable acceleration, the upstream bug, at least, has th details
<alex_mayorga> also I hear the nvidia blob is not much better anyway
<tjaalton> yes
<alex_mayorga> let me review, but I think accel is already off here
<alex_mayorga> is there other driver that I can use other than nouveau
<alex_mayorga> vesa perhaps?
<tjaalton> not unless you disable kms
<yofel> really? I did try vesa as a replacement for nouveau once, did work, but with rather low resolution
<yofel> could be that I had nvidia installed and just nouvea blacklisted maybe
<tjaalton> probably
<yofel> I'll try nouveau.noaccel=1 later, I don't use it anyway
<yofel> tjaalton: would my bug be a dup of that one too? I think so since I've an GT218 here
<tjaalton> yofel: dunno, i'd have to check
<yofel>  bug 711908
<ubot4> Launchpad bug 711908 in xserver-xorg-video-nouveau (Ubuntu) "[natty] frequent nouveau freeze on GT218 [NVS 3100M] (rev a2) (affects: 2) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/711908
<tjaalton> yofel: yeah looks like it
<tjaalton> i can reproduce it when i _disable_ dri
<tjaalton> though i have nv5x
<tjaalton> and had to switch firefox to chromium
<tjaalton> otherwise it would crash, though the bt looks different
<tjaalton> ricotz: no _source.changes for pixman?
<ricotz> tjaalton, sorry, should be there now
<tjaalton> ricotz: thanks, uploaded
<cnd> bryceh, or anyone else who's a core dev: can someone review the utouch-grail upload and push to ubuntu?
<cnd> https://bugs.launchpad.net/ubuntu/+source/utouch-grail/+bug/722780
<ubot4> Launchpad bug 722780 in utouch-grail (Ubuntu) "Upload utouch-grail 1.0.19 to Ubuntu (affects: 1) (heat: 8)" [Undecided,New]
<cnd> it's a dependency of the new xi 2.1 work
<tjaalton> cnd: i can check it out a bit later
<cnd> tjaalton, that would be great!
<cnd> let me know if you need anything
<tjaalton> sure
<tjaalton> cnd: ok, what exactly should I do to upload it?
<cnd> usually didrocks helps out, but he seems unavailable
<cnd> we give him a link to our packaging branch
<cnd> he builds the package and signs it
<cnd> and uploads it
<cnd> I can build it for you instead
<cnd> if you'd prefer that
<tjaalton> the source, yeah
<tjaalton> or wait
<tjaalton> I'll try something first
<cnd> sure
<cnd> the packaging branch is linked in the bug, if you've got that handy
<tjaalton> yep
<tjaalton> hmm no, I'd need the tarball anyway etc. guess it's best if you prepare the source and I'll debsign&dput it to the archive
<cnd> ok
<tjaalton> I haven't used bzr for packaging, so :)
<cnd> ahh
<tjaalton> don't know what the workflow is
<cnd> it's actually quite nice, especially if you are doing packaging of new upstream sources
<cnd> there's a command that takes the upstream tarball and the current packaging branch, and does crazy commits and merges for you
<cnd> and then gives you a new commit in your packaging branch that's all ready for you to upload
<tjaalton> alrighty
<cnd> tjaalton, it's up at people.canonical.com/~cndougla/utouch/
<tjaalton> oh it was a native package
<tjaalton> but thanks, will upload
<cnd> wait
<cnd> no, it's should be native
<cnd> tjaalton, why do you think it's native?
<tjaalton> cnd: normally the upstream tarball is a separate file
<cnd> oh wait
<cnd> I forgot to put it there
<cnd> let me upload it too
<tjaalton> that explains it then :)
<tjaalton> hmm EPERM too
<tjaalton> +NO
<tjaalton> :)
<cnd> ?
<cnd> I just uploaded the tarball
<tjaalton> can't access them
<tjaalton> forbidden
<tjaalton> chmod 755?
<cnd> I'll try
<tjaalton> or 644 at least
<cnd> tjaalton, I did chmod a+x *
<cnd> sorry a+r
<cnd> so hopefully you can get them now
<tjaalton> yep
<tjaalton> forgot to finalize the release?-)
<cnd> oh yeah...
<cnd> grrr
<cnd> sorry
<tjaalton> heh
<cnd> usually didrocks does that for us :)
<tjaalton> indeed, since he'd have to sign it himself
<tjaalton> um
<cnd> well, if you mean putting your name in the changelog
<tjaalton> i mean create the source package
<cnd> you can sign without doing that
<tjaalton> yes
<cnd> anyways, I'll create a new package as released
<cnd> and upload again
<tjaalton> cool
<cnd> sorry for the trouble
<tjaalton> np
<cnd> tjaalton, ok, the new package is ready for you
<tjaalton> cnd: and uploaded
<cnd> tjaalton, thanks!
<cnd> we need to make a packaging group for utouch so I can upload them...
<cnd> I just never got around to requesting it
<tjaalton> heh, right
<bryceh> cnd, yep
<bryceh> cnd, or just get core-dev ;-)
<cnd> bryceh, how high is the bar for that?
<cnd> I've so far only touched linux-firmware, utouch*, and x stuff
<bryceh> cnd, generally you'd get motu first, which that's probably enough.
<bryceh> it's more about "do we trust him" than "does he have enough experience"
<cnd> I don't touch much in universe :)
<bryceh> again, it's not so much a point of having experience in the area as much as being trusted to upload stuff in that area
<cnd> and most of the stuff I do need privs for are core packages
<cnd> ok
<cnd> maybe I should at least attempt motu now
<bryceh> once you've gotten motu, spend a bit of time doing some random package sponsorship and stuff for a month or two, to gain some sponsor statements (which should be easy for you), then put in for core dev.
<cnd> ok
<cnd> bryceh, RAOF: got some questions for you about versioning
<cnd> we're pushing xi 2.1 stuff
<bryceh> ok
<RAOF> cnd: Shoot.
<cnd> but there's no official upstream input proto packages yet
<cnd> nothing like inputproto 2.0.99.901
<bryceh> cnd, so you need a git snapshot?
<cnd> so I've been just adding them into ubuntu patches on top of what's already there
<cnd> well, it's not even upstream git snapshot yet
<cnd> not in the official repo
<cnd> so I've just been incremening the ubuntu version suffix
<cnd> and adding patches
<RAOF> That seems reasonable to me.
<cnd> one issue is that for libxi lintian complains because we're adding symbols with an ubuntu version
<bryceh> that can probably be ignored in this case
<cnd> it's actually a lintian error
<RAOF> Lintian is wrong.  Feel free to silence that with an override if you want.
<cnd> will that cause an issue?
<bryceh> don't think so
<cnd> I didn't think so either, since I remember xorg-server having lintian errors too :)
<RAOF> It'd cause an issue in Debian because dak's started to reject packages with lintian errors; I don't believe soyuz does that :)
<cnd> ahh
<bryceh> cnd, yeah doing incrementing ubuntu versions is probably fine.  I think I'd probably do it that way myself
<cnd> ok
<cnd> I'm going to prepare packages right now
<RAOF> There's probably no way we can stick an ubuntu string into the input ABI version, is there?
<cnd> RAOF, that sounds really ugly :)
<cnd> but it may be helpful
<cnd> RAOF, the alternative is to leave the input abi at 12
<cnd> and to assume the input abi includes the new mt stuff in evdev and synaptics
<cnd> I'm almost tempted to say that's a better route
<RAOF> We could also bump the minor version of the input abi?
<cnd> because in reality, input abi 13 should be backwards compatible with 12, but whot likes to bump the major version for some reason
<cnd> RAOF, even that could potentially be an issue if they bump the minor version upstream
<cnd> though that's highly unlikely at this point
<cnd> rc2 is a little late for that :)
<cnd> RAOF, ok, I'm thinking that may be a good idea
<cnd> bump the minor to 12.3
<RAOF> I think aaronp has declared the ABI frozen.
<cnd> and I can convince whot to bump the major to 13 when mt is added
<cnd> leaving the major at 13 would also mean we don't have to rebuild all the input module packages
<RAOF> Major at 12, you mean?
<cnd> I'm glad someone has finally declared it frozen :)
<cnd> yeah, leaving it at 12
<cnd> :)
<bryceh> seriously
<cnd> bryceh, was that in response to my comment about abi frozen declarations?
<bryceh> cnd, yep
<cnd> heh, ok
<cnd> it puzzled me for a moment, I thought you had better ideas about the input abi handling :)
<bryceh> not seriously
<cnd> heh
<cnd> everyone should play with qt's fingerpaint demo
<cnd> it makes me happy :)
<cnd> and they have a pinch to zoom demo where there's a giant world of cheese with mice running on it
<cnd> and you can pinch to zoom in and out
<RAOF> Oh, bah.
<cnd> RAOF, btw, thanks for fixing that doxygen issue :)
<cnd> it was really getting on my nerves :)
<RAOF> Debian's X server Provides: xorg-video-abi-9, we Provides: xorg-video-abi-9.0
<RAOF> cnd: KiBi also fixed it :)
<cnd> ahh
<RAOF> bryceh: Do we want to go with Debian's packaging and incur another rebuild of the world, or diverge for now to include the minor version in those ABI virtual packages too?
<cnd> tjaalton, I think your xi 1.x fix is causing warnings:
<cnd> http://pastebin.ubuntu.com/570315/
<cnd> just a guess since I think your patch touched that file
<cnd> RAOF, so you think you'll be ready for uploads today?
<RAOF> cnd: I think so, yes.
<cnd> cool
#ubuntu-x 2011-02-22
<bryceh> RAOF, offhand I'm thinking stick with debian even though it'd cause a mass rebuild
<RAOF> That was my thinking.
<bryceh> just on the thought that doing that pre-FF is probably going to be easier than having to do it post-FF
<RAOF> Yup!
<cnd> RAOF, bryceh: is the input-abi like that too?
<RAOF> cnd: Yes.
<bryceh> plus we gotta test the script we did last time ;-)
<Prf_Jakob> Oh X people here, how do I disable the unhelp full restart X server after the GPU has crash feature in Ubuntu?
<cnd> that could be annoying if we need to change the xi 2.1 abi
<bryceh> Prf_Jakob, huh?
<Prf_Jakob> bryceh: The thing that tries to start the X server a couple of times and then tries to bring up some sort of helperscreen but fails and makes it imposible for me to access the consol terminal
<bryceh> "The thing" == "gdm"
<Prf_Jakob> I would guess so yes.
<bryceh> "helperscreen" == "failsafex" which is in /etc/gdm
<Prf_Jakob> cool thanks!
<Prf_Jakob> btw any of you guys in London?
<RAOF> None who are awake now, I think :)
<Prf_Jakob> heh :)
<cnd> RAOF, bryceh: what do you do when debian git has a new version of package, but it's unreleased
<cnd> do you rebase onto the last released package commit?
<RAOF> cnd: This depends.  Do we care about those changes?  If so, merge from the unreleased package, and say so.  If not, merge in the last release tag.
<cnd> well, it's just a lintian standards bump :)
<cnd> so I think that's a no :)
<RAOF> Then merge from whatever the tag is; Debian's ususally pretty good at tagging the uploads.
<cnd> yeah
<bjsnider> is it true that the x-server 1.10 abi didn't stabilize until after rc2?
<RAOF> After RC1, yes.
<RAOF> I don't believe there have been any ABI breaks post-rc2
<bjsnider> well, i find that very difficult to understand
<bjsnider> shouldn't a release candidate be considered stable?
<bjsnider> just maybe with the odd bug here and there, kind of thing?
<cnd> bjsnider, x.org bends the definition of rc really
<cnd> instead of having alpha, beta, rc, release
<cnd> they just have a series of rc's and then a release
<cnd> to x.org, rc seems to be just an arbitrary abbreviation
<bryceh> unfortunately
<bjsnider> well, let me register this for the record: i think that stinks.
<cnd> bjsnider, I had thought the abi freeze was at the merge window closure
<cnd> but apparently that wasn't the case
<cnd> I think the window needs to be slammed harder next time :)
<cnd> the release manager needs to be like torvalds :)
<bjsnider> i suppose
<cnd> almost done...
<cnd> RAOF, I've got stuff ready
<cnd> do you want me to push to git.debian.org?
<RAOF> Yes please.
<RAOF> Oh, actually!
<cnd> I'm still here :)
<RAOF> Now.
<RAOF> Just pushing up a local commit.
<cnd> commit to what?
<RAOF> xorg-server
<cnd> ok, let me know when you're done
<RAOF> It's done.
<cnd> ok
<RAOF> I guess the other option would have been to pull --rebase it.  Eh.
<cnd> well, that's what I'll be doing :)
<cnd> one of us had to do it
<cnd> ok, I'm going to push now
<cnd> oh wait, I should test rebuild the server just to be sure...
<cnd> since you added a patch
<cnd> it'll only take 15 mins
<RAOF> K.
<cnd> RAOF, do you have any mt devices?
<RAOF> No.
<cnd> I was hoping I could get one more tester before the push :)
<RAOF> unless a synaptics touchpad counts :)
<cnd> but please, smoke test it to ensure pointing continues to work well
<cnd> I only publicly made the packages available today
<cnd> and I think only myself and henrik tested them :(
<cnd> and he found a bug that I spend half of today fixing
<cnd> but it wasn't a crasher
<cnd> anyways, build looks good
<cnd> I'm going to push stuff to git now
<RAOF> K.
<cnd> RAOF, it's alright if I overwrite an old stale ubuntu branch
<cnd> like in x11proto-input
<cnd> ?
<RAOF> Yup.
<cnd> ok
<cnd> no need to rename it to something else?
<cnd> I guess it still has a git tag
<cnd> or should have a git tag
<bryceh> cnd, some of those stale branches got abandoned once the package reached a state where we could sync it
<cnd> yeah
<cnd> RAOF, git is updated
<RAOF> Awww, coordinations to windows is gone :)
<cnd> xorg-server, x11proto-input, xserver-xorg-input-evdev, xserver-xorg-synaptics, and libxi
<cnd> :)
<cnd> I think you'll find a way to live without
<cnd> RAOF, stuff is officially handed off to you :)
<cnd> I am going to go have a life for the rest of the night :)
<bryceh> yay, wayland good to go
<bryceh> even works on radeon :-)
<RAOF> Yay natty-tmpfs-local schroot.
<bryceh> \p/ wayland now uploaded to natty universe
<RAOF> Sweet!
<bryceh> subject: [ubuntu/natty] wayland 0.1~git20101129.ac93a3d3-0ubuntu1 (New)
<bryceh> it's the snapshot from last Nov, which I'd done enough testing on before.  Looks like I need to rejigger the packaging a bit in order to update to a newer snapshot.
<bryceh> something to keep me busy tomorrow ;-)
<bryceh> bbl
<RAOF> :)
<RAOF> Aha!  *That's* why the udeb build fails (sometimesâ½)
<RAOF> Woot.  rebuild-all-drivers fixed to add appropriate build-depends.
<tjaalton> cnd: ok, should be easy to fix
<bryceh> RAOF, nice!
<RAOF> Oh, wow.  virtualbox pulls in >800MB worth of build depends.
<tjaalton> :)
<tjaalton> RAOF: hey, you identified the n-trig wacom crasher?
<RAOF> Yeah.
<tjaalton> where was it?
<RAOF> tjaalton: Want to upload the new wacom?
<tjaalton> sure
<tjaalton> it should fix it?
<RAOF> Yeah.
<tjaalton> cool
<tjaalton> I've had a personal git repo for it, but haven't been keeping it up
<RAOF> (Although I haven't tested, so I can't be 100% sure that) the problem was that the device probe failure path was freeing the device private data, then UnInit was being called, dereferencing the private pointerâ¦
<RAOF> cooperteam.net/Packages has the new wacom, which doesn't free in the cleanup path :)
<tjaalton> I'll test it with my intuos4 that it doesn't break anything :)
<tjaalton> though i doubt it would
<tjaalton> works, ship it
<tjaalton> uploaded
<tjaalton> tormod: re savage merge; just put the source package somewhere and I'll sponsor it
<tjaalton> debdiffs are so passÃ© :)
<tormod> tjaalton, thanks. just that I think it needs RAOF's new xserver because the packaging uses dh_xsf_substvars
<RAOF> Isn't that from a Dandy Warhols song? :)
<tjaalton> tormod: ah, ok then
<tormod> tjaalton, that's why it's only a debdiff, wouldn't build on my system :)
<tjaalton> RAOF: debdiffs, heroin, what's the difference :)
<RAOF> tormod: You can check it builds if you like; xserver is in git.
<tjaalton> so it needs xorg merge?
<tjaalton> +d
<RAOF> The xserver merge includes dh_xsf_substvars
<tormod> tjaalton, I think it needs xorg-server-dev 2:1.9.99.902-2ubuntu1
<RAOF> Right.
<tjaalton> oh thaat
<tjaalton> -a
<tjaalton> damn kbd
 * RAOF is just checking that the world successfully rebuilds against 2:1.9.99.902-2ubuntu1, although there's no reason to expect anything would fail.
<RAOF> Whoops.  Don't try building virtualbox on a tmpfs.
<tjaalton> heh
<RAOF> bryceh: So, current xserver status, before I go to bed.  I'm rebuilding the world locally, to check that it works.  This has identified an essentially cosmetic transition problem with the abi substvars which I'll fix when I get up tomorrow.  Apart from that, all's good.
<RAOF> And now, to sleep!
<tjaalton> duh, didn't check the patch still applies to the new x11-apps
<Sarvatt> yeah all of those patches need refreshing, most shouldn't be needed anymore even
<Sarvatt> turned out a lot of the apps ones were because of some debian specific .pc changes that got reverted
<tjaalton> ah, ok
<tjaalton> so if it builds in pbuilder it should be good?
<Sarvatt> should be, lessee..
 * Sarvatt always gets confused which apps are in which of the -apps packages
<tjaalton> could've tried it myself, but whatever :)
<Sarvatt> 5K/second from ftp.debian.org :D
<Sarvatt> lets see, oclock fails still
<Sarvatt> /usr/bin/ld.bfd.real: oclock.o: undefined reference to symbol 'XtAddEventHandler'
<Sarvatt> /usr/bin/ld.bfd.real: note: 'XtAddEventHandler' is defined in DSO /usr/lib/libXt.so.6 so try adding it to the linker command line
<Sarvatt> /usr/lib/libXt.so.6: could not read symbols: Invalid operation
<Sarvatt> not done yet but looks like the oclock hunk is the only one needed still
<Sarvatt> tjaalton: http://sarvatt.com/downloads/patches/100-fix-linking-with-no-add-needed.patch is all thats needed for x11-apps 7.6+4
<tjaalton> Sarvatt: cool, can you push it? I'll upload it then (unless you were core-dev too?)
<Sarvatt> okie one sec
<tjaalton> Sarvatt: thanks, uploaded with the new patch
<ricotz> bryceh, hi, did you want to upload wayload to natty?
<ricotz> ... wayland
<bryceh> ricotz, yes
<ricotz> bryceh, nice, but why didnt you use the latest git?
<bryceh> ricotz, I plan to, but had this snapshot ready to go right now
<ricotz> bryceh, ok, i see
<bryceh> also, dunno yet if newer wayland has changed dependency requirements or needs packaging rejiggered
<ricotz> yes the demos are splitted into a separate tree
<bryceh> ricotz, interested in helping work on it?
<ricotz> perhaps, if i find a moment ;)
<ricotz> i am able to upload to the wayland ppa
<Sarvatt> ubuntu too no? no way thats going in main I'm sure
<bryceh> yeah worst case if newer wayland requires git mesa or some such, I'll refresh the ppa
<bryceh> Sarvatt, universe
<ricotz> bryceh, i think it would be better to put it in edgers where mesa git is up2date ;)
<bryceh> true
<Sarvatt> speaking of which, need to redo mesa packaging in there *yet again* :(
<ricotz> Sarvatt, dont forget to keep the nouveau nvc0 patch ;)
<Sarvatt> ricotz: oh crap, I might have overwritten that already
<ricotz> Sarvatt, i was desperately searching for the problem until i noticed it
<Sarvatt> i'm about to drop lucid/maverick in there, updating all drivers with the new dropped xsfbs stuff isn't gonna happen
<ricotz> i updated it on the we to fix it
<Sarvatt> ricotz: did I screw it up already? it's an automated script so I probably did, lets see
<Sarvatt> oh cool
<Sarvatt> adding the patch in a hook so i wont drop it again
<ricotz> good :)
<cnd> RAOF, found two bugs in the xi 2.1 work
<cnd> I'm testing fixes right now
<cnd> would you be able to wait for them before pushing to ubuntu?
<ricotz> bryceh, could you upload a package to the natty new queue for me?
<ricotz> tjaalton, ^ do you mind?
<bryceh> cnd, I think he's asleep.  But I can wait for you.
<bryceh> ricotz, if you have the packaging all ready to go, sure
<cnd> bryceh, ahh, ok, whoever is pushing
<cnd> I've got the patch ready
<cnd> just slogging through pushing it out
<ricotz> bryceh, thank you, http://people.ubuntu.com/~ricotz/libbluray/
<ricotz> bryceh, i will ping an archive-admin to look at it if it is up
<bryceh> ricotz, ok looks good.
<bryceh> ricotz, uploaded
<ricotz> bryceh, thanks!
<bryceh> dunno if there are any special new package requirements for java stuff, but presumably if there are the archive admins will know
<cnd> bryceh, I've pushed a new commit to git
<cnd> we should be ready for upload now
<bryceh> cnd, hey I only signed up for waiting!
<bryceh> ;-)
<cnd> oh :)
<cnd> heh
<cnd> I got ya
<bryceh> cnd, fill me in... what packages/git repos should I pull?
<cnd> you don't have to push if RAOF was going to :)
<cnd> but in case you are interested, xorg-server, x11proto-input, xserver-xorg-input-evdev, xserver-xorg-input-synaptics, libxi
<bryceh> if you can wait 3 hours he should be on then, but I can push if it's an emergency
<cnd> nah, no need for you to push
<bryceh> ok cool, yeah if RAOF has been your primary xorgician probably best if he tends to it
<cnd> he's also been getting rc2 ready for upload
<cnd> so I think he'd rather do it
<cnd> when you chimed in, I thought you and he had decided that you would be pushing it instead
<cnd> that's what you get for being sly over irc :)
<bryceh> [ubuntu/natty] libbluray 0.2~git20110213.20739ed-0ubuntu1 (New)
<bryceh> heh, yeah I knew I was taking a risk given how many days you've operated without a weekend reboot ;-)
<jcristau> Sarvatt: is that oclock patch upstream? (too lazy to check..)
<Sarvatt> jcristau: doesn't look like it, it might be caused by our libXt .pc though still, lets see.. i did try to push all of those app toolchain changes a few months ago
<Sarvatt> oh we aren't patching the .pc in libxt, hmm
<jcristau> we might be removing xt from Requires somewhere
<Sarvatt> yeah pretty darn sure I double checked them all and none were appropriate upstream back then.. 
<trinikrono> tormod: ping i would like to ask you about that drawpix utility you mentioned in bug 579071
<ubot4> Launchpad bug 579071 in mesa (Ubuntu) (and 1 other project) "savage_drv fails drawpix glDrawPixels demo/test/benchmark (affects: 1) (heat: 8)" [Undecided,Confirmed] https://launchpad.net/bugs/579071
<tormod> trinikrono, hi, you've this bug too?
<trinikrono> tormod: you asked in bug 705464 to look this bug
<ubot4> Launchpad bug 705464 in xserver-xorg-video-savage (Ubuntu) "Ubuntu 10.04 doesn't set hardware acceleration on ProSavageDDR video card (affects: 1) (heat: 8)" [Undecided,Incomplete] https://launchpad.net/bugs/705464
<trinikrono> and i am wondering how to run drawpix
<tormod> trinikrono, ok I see. drawpix should be in mesa-demos
<trinikrono> tormod: is that a package to install?
<tormod> trinikrono, hmm it does not exist in maverick
<trinikrono> tormod: i use lucid
<tormod> trinikrono, I put a drawpix binary here: http://alioth.debian.org/~tormod-guest/libdrm/
<tormod> trinikrono, and it requires this picture file: http://git.debian.org/?p=pkg-xorg/app/mesa-demos.git;a=blob_plain;f=src/images/girl.rgb;hb=HEAD
<trinikrono> it says error loading libglut.so.3
<tormod> trinikrono, you need to install the freeglut3 package
<tormod> trinikrono, but you should also see the bug simply by running /usr/lib/xscreensaver/antspotlight
<trinikrono> :D i get the black screen also
<trinikrono> tormod: and the ant looks really strange
<tormod> trinikrono, the ant looks strange, that's another separate bug. but do you get small dots/patches all over the screen
<tormod> trinikrono, I will try to make a lucid package for my PPA
<trinikrono> tormod: can i speak to you also about bug 705464
<ubot4> Launchpad bug 705464 in xserver-xorg-video-savage (Ubuntu) "Ubuntu 10.04 doesn't set hardware acceleration on ProSavageDDR video card (affects: 1) (heat: 8)" [Undecided,Incomplete] https://launchpad.net/bugs/705464
<tormod> trinikrono, sure
<trinikrono> you saw my latest comment, is it a bug really?
<tormod> trinikrono, I consider it a bug in Ubuntu if you have to fiddle with xorg.conf to get things up and running
<tormod> trinikrono, do you know what in your xorg.conf makes DRI work?
<trinikrono> tormod: in the Module section it has : dri, dbe, dri2, glx and record
<tormod> trinikrono, I have uploaded the lucid savage package to my PPA, but it will take some time before it is built
<tormod> trinikrono, and if you remove the Module section, there is no DRI?
<trinikrono> tormod: i can try that for you
<trinikrono> tormod: going to restart x wish me luck
<trinikrono> tormod: you know if i delete the xorg.conf it works fine
<tormod> trinikrono, so you never needed any xorg.conf?
<trinikrono> tormod: thats the thing i did
<trinikrono> thats why i created a xorg.conf in the first place
<trinikrono> but when i delete it now it is fine
<trinikrono> tormod: the only way i can be sure is too reinstall lucid and see if it needs a xorg.conf to work properly, do you agree with this?
<tormod> trinikrono, I do not think reinstall is necessary
<cnd> RAOF, ping me when you get on
<RAOF> cnd: Pong.
<RAOF> (But in a desktop team meeting, so low bandwidth)
<tormod> trinikrono, maybe your xorg.conf was needed in an earlier version, but no longer in lucid
<cnd> RAOF, just wanted to say I've got one more small patch
<cnd> I'm testing right now
<trinikrono> tormod: well maybe we can close that bug because it does seem to reproducible and the reporter is happy
<cnd> so if you haven't pushed, it would be good to get this in
<tormod> trinikrono, maybe you can attach your Xorg.0.log to the drawpix bug report, and test the driver from my PPA, it is built now.
<RAOF> tormod: Do you want to push our mesa savage patches upstream?  I've been meaning to do it but there always seems to be something better to do :)
<tormod> trinikrono, I'll wait a bit longer for feedback from David before closing that report
<cnd> seb128, do you know who I should talk to about pushing a patch to enable multitouch in qt?
<cnd> I'm readying it now, and I want to push before feature freeze
<tormod> RAOF, which patches? weren't they cherry-picked from upstream?
<seb128> cnd, Riddell
<RAOF> I'm pretty sure the patches adding ARGB visuals aren't upstream.
<cnd> seb128, thanks!
<seb128> you're welcome
<tormod> RAOF, oh I see, 03_savage-expose_fbmodes_with_nonzero_alpha.patch
<RAOF> Yeah.
<tormod> RAOF, I know nothing about it, where it came from or what it really does
<tormod> RAOF, it is from "knarf". maybe you can ask him
<tormod> for reference it was bug 467474
<ubot4> Launchpad bug 467474 in netbook-launcher (Ubuntu) (and 2 other projects) "netbook-launcher crashed with SIGSEGV in glGetString() (affects: 13) (dups: 3) (heat: 9)" [Medium,Fix released] https://launchpad.net/bugs/467474
<trinikrono> tormod: installed from ppa, result is the same and attaching xorg to bug report
<tormod> trinikrono, thanks! disappointing the ppa package didn't help though
<tormod> RAOF, are you uploading the xserver soon? just wondering if there will be window between new xserver and FF for driver sync/merges without having to add ugly build-depends
<RAOF> tormod: I take it you've *got* a savage card?  That would let you piglit-test that patch :)
<RAOF> You'll need to add the ugly build-depends anyway, at least for a merge?
<tormod> RAOF, I am the privileged owner of a savage card
<RAOF> And, yeah.  It should be ready before lunchtime.
<RAOF> I've just got a niggle to fix, and then some more testing.
<tormod> RAOF, why would I need build-depends for a merge? if the Debian packaging requires e.g. 1.9.4
<RAOF> Because the packaging requires dh_xsf_substvars, which only appeared in 1.9.99.902-2ubuntu1?
<RAOF> I mean, you *could* just rely on that particular version being available, but it's not a bad idea to actually have correct build-depends :)
<bryceh> apw, do you have plans for bug #702090?  We've been accumulating dupes at a pretty good rate.
<ubot4> Launchpad bug 702090 in xserver-xorg-video-intel (Ubuntu Natty) (and 4 other projects) "i965gm GPU lockup if vesafb is left loaded (EIR: 0x00000010 PGTBL_ER: 0x00000100) - *ERROR* EIR stuck: 0x00000010, masking (affects: 45) (dups: 34) (heat: 353)" [High,Triaged] https://launchpad.net/bugs/702090
<tormod> RAOF, hmm strictly speaking yes
<tormod> but for a sync we rely on such things all the time right
<RAOF> Right.
<RAOF> If that were the only diff, I wouldn't keep it for a sync.  If there was any other diff, I'd keep it.
<tormod> anyway have a nice lunch while I sleep :)
<RAOF> Sleep well :)
<cnd> RAOF, ok, I'm done now
<cnd> pmcgowan was pinging me saying things weren't working with his trackpad :)
<RAOF> cnd: Oh, there's another patch?  git pull --rebase it is :)
<cnd> and I realized that I hadn't fully tested trackpads
<cnd> but they should work well now too
<cnd> sorry for the run around...
<cnd> RAOF, you wouldn't happen to have one of the newer synaptics trackpads would you?
<cnd> with "semi-multitouch" capabilities?
<RAOF> How could I tell?  I have exactly two synaptics touchpads.
<cnd> if you do, then you can play too
<cnd> let me see
<cnd> can you run evtest on their device nodes?
<cnd> I find device nodes by searching for synaptics in Xorg.0.log
<cnd> /dev/input/event*
<cnd> at the beginning, it'll spit out a bunch of properties
<cnd> if you get ABS event codes >= 53, then you've got a multitouch device
<cnd> though it's probably only semi-multitouch
<RAOF> I'm guessing my 3yr old touchpad won't be semi-multitouch, so I'll only test the newer one.
<RAOF> Nope, only 28 - tool width.
<cnd> darn
<cnd> sorry :(
<JanC> what does semi-multitouch mean?
<RAOF> cnd: The Xi 2.1 patches bump minor input ABI, don't they
<RAOF> ?
<RAOF> cnd: Ah, yes.  There it is.
<cnd> RAOF, is that ok?
<RAOF> Yeah, that's fine.
<cnd> btw, there technically is an abi change
<RAOF> I was just checking whether to bump serverminver.
<cnd> though it's buried in the server
<cnd> and I don't think any input drivers access it
<cnd> I'd be surprised if they did
<RAOF> Heh.
<RAOF> Well, we'll be rebuilding the world for unrelated reasons, so that won't matter :)
<cnd> :)
<RAOF> Incidentally, the Xi patch introduces a compile warning.
<RAOF> In fact, a whole bunch of compile warnings :)
<RAOF> I presume you're on them, though.
<cnd> RAOF, hmm, I haven't seen any
<cnd> can you pastebin them/
<cnd> ?
<yofel> btw, is it known that plymouth is unusable in natty with nouveau currently? I only get pixel garbage displayed and a message about conflicting vesafb and nouveaufb in dmesg
<yofel> note: X starts fine, I just can't see any messages in plymouth thanks to that
<RAOF> cnd: Will do.
<yofel> works fine if I use gfxpayload=text and remove the vt.handoff=7
#ubuntu-x 2011-02-23
<RAOF> cnd: 
<apw> bryceh, its constantly on my mind, and i am hoping to play with it one of these fine days ... its a pig to fix
<RAOF> cnd: http://paste.ubuntu.com/570833
<bryceh> apw, ok thanks.
<cnd> RAOF, the first set of warnings is from the upstream cherry pick to fix the xi 1.x keyboard events
<cnd> so not from me :)
<cnd> but the second one does look like it's from me
<cnd> I'll take a look
<RAOF> :)
<cnd> hmmm, I don't get that warning when I build here
<cnd> RAOF, what's at line 1696 in your source tree
<cnd> I just have a declaration for the client variable
<cnd> RAOF, I can say that it can't be used uninitialized
<cnd> but maybe gcc didn't pick up on it
<cnd> the patch needs to be cleaned up more, but I didn't have time to make it sparkle and shine :)
<RAOF> cnd: 1696 is just     TouchClientPtr client; here.  I'm not sure what gcc thinks it's complaining about!
<RAOF> It would be rather more instructive if it pointed out *where* it thought it was used uninitialised :)
<cnd> RAOF, that's what it usually does I think
<cnd> so I think your gcc is confused :)
<cnd> which version of gcc do you have?
<cnd> I have 4:4.5.1-1ubuntu3
<cnd> should be up to date
<cnd> unless a new one was released just today
<RAOF> 4.5.2\3umusnu2
<RAOF> cnd: Ahem.  4.5.2-3ubuntu2
<cnd> RAOF, where'd you get that version?
<cnd> I did an apt-get update
<cnd> and it's not listed
<RAOF> It's the version in my chroot.  Let me check.
<RAOF> Oh!  It's gcc-4.5
<cnd> ahh, I've got 4.5.2-ubuntu2, and 4.5.2-ubuntu3 is a candidate
<RAOF> Ah.  And you've also been running âapt-cache policy gccâ, rather than âgcc --versionâ, I'd wager ;)
<cnd> yeah
<cnd> RAOF, hope things are going well?
<RAOF> Yup.
<RAOF> Testing is going well.
<cnd> awesome
<RAOF> Synaptics seems to still work, evdev still works, the server doesn't crashâ¦ :)
<cnd> that's good :)
<RAOF> Everything rebuilds (apparently) correctlyâ¦
<RAOF> Shouldn't be long before I'm trolling for sponsors.
<cnd> RAOF, you're not a core dev?
<RAOF> No.
<cnd> I would assume you'll be shortly enough, right?
<RAOF> Yeah.
 * RAOF schedules tomorrow afternoon for finishing the bits of the process needed.
<cnd> RAOF, I was playing some community built multitouch games :)
<cnd> and I found a crasher
<cnd> I think they use sdl, and sdl is actively grabbing the pointer
<RAOF> Hey, cool!  They exist?
<cnd> and that's caused a bug
<cnd> yeah :)
<cnd> like 7 of them
<cnd> https://launchpad.net/~oxullo/+archive/libavg?field.series_filter=natty
<cnd> so I've got a patch
<RAOF> Ok.
<cnd> if you're too far down testing, you don't need to take it right now
<cnd> what would you like to do
<RAOF> How safe is the patch?
<cnd> it only affects touch event handling
<cnd> so it has no effect on non-multitouch hardware
<RAOF> I don't mind picking up a patch to fix a crasher bug :)
<cnd> and it only affects the code path where you are beginning a touch while there's an active pointer grab
<cnd> ok
<cnd> let me fix it up and push it
<RAOF> I'll check git is up to date.
<RAOF> I presume it's xserver?
<cnd> yeah
<RAOF> xserver's now up to date in git.
<cnd> k
<cnd> oh the crazy things people do with X device grabs...
<RAOF> And I'm going to go and grab some stuff from the shops while the world does its final test rebuild.
<cnd> RAOF, tis pushed
<cnd> thanks!
<cnd> and now I'm off to bed
<RAOF> Sleep well!
<RAOF> Tell me again: why am I wasting builder cycles rebuilding xserver-xorg-video-nv? :)
<RAOF> Anyone up for some X sponsoring?
<lilstevie> ?
<tjaalton> RAOF: yep
<tjaalton> downloading..
<tjaalton> RAOF: uploading
<RAOF> tjaalton: Rockit rockin.
<RAOF> Thanks muchly.
<tjaalton> ...aand done
<RAOF> Feel free to add to https://wiki.ubuntu.com/ChrisHalseRogers/CoreDevApplication ; I'll start finishing that process soon :)
<tjaalton> hehe :)
<tjaalton> wonder if there's a way to batch-debsign a bunch without having to enter the gpg passphrase a hundred times
<seb128> tjaalton, use a gpg agent?
<tjaalton> seb128: ok, didn't know of such a beast..
<seb128> tjaalton, seahorse-plugins does it
<seb128> or you can use gnupg-agent
<tjaalton> seb128: yeah, one more thing to fix on my setup, thanks.. dunno why this is the first time I actually thought about it :)
<tjaalton> tormod: hey, got my t23 reinstalled with natty. do you have problems with getty not working right, ie. the vc:s don't work?
<tormod> tjaalton, no but haven't tried natty on it for some weeks
<tormod> tjaalton, btw https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-savage/+bug/723035/comments/2
<ubot4> Launchpad bug 723035 in xserver-xorg-video-savage (Ubuntu) "please merge xserver-xorg-video-savage 1:2.3.2-3 from Debian unstable main (affects: 1) (heat: 8)" [Undecided,New]
<tormod> tjaalton, btw2 for your signing agent, see also http://bazaar.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools/view/head:/README.ppa-update
<tjaalton> tormod: thanks, I'll upload that
<tormod> tjaalton, I have verified that it builds fine on natty
<tormod> (after installing the new xserver-xorg-dev)
<tormod> (which it build-depends on :) )
<tormod> tjaalton, you're blaming getty? just flashing cursor on the consoles?
<tjaalton> tormod: yep
<tjaalton> restartin them doesn't do anything
<tjaalton> thought if it's a general issue with ums
<tormod> tjaalton, historically these have been upstart issues, upstart related I mean, there are no bugs in upstart :)
<tjaalton> yeah it's faultless
<tjaalton> getty's are running though
<tormod> and the corresponding /dev/tty? exist?
<tjaalton> yep
<tormod> can you try something like: echo yooo | sudo tee /dev/tty3
<tjaalton> nothing shows up there
<tjaalton> uhm
<tormod> and boot with "text" to see if X is possibly at fault
<tjaalton> you mean if I get something back? yes
<tjaalton> right
<tormod> back?
<tjaalton> the terminal where I ran that
<tjaalton> displayed what was echo'ed
<tormod> tee always gives back - your best friend
<tjaalton> ah right..
<tormod> next I would try reading from /dev/vcs3, too see if the kernel thinks something is there
<tjaalton> removing 'quiet splash' did nothing
<tjaalton> all the vt's have the same text printed by grub
<tjaalton> so maybe it's grub's fault
<tormod> but you see the kernel/etc messages while booting?
<tjaalton> no
<tormod> sometimes, after an X crash, my savage card is messed up and the consoles do not refresh correctly, until power cycle
<tormod> well they refresh only when switching consoles
<tormod> you could try booting a cd -> no grub
<tjaalton> ha, it's the gfxpayload-stuff
<tjaalton> removing that line fixed the console
<tormod> was there an incorrect gfxpayload line?=
<tjaalton> it doesn't seem to work right with ums
<tjaalton> hmm probably was incorrect
<tjaalton> because it had the variable, not a value in it ("set gfxpayload=$linux_gfx_mode")
<tjaalton> I'll try with =text
<tormod> google gave me this http://forums.debian.net/viewtopic.php?f=5&t=41881 same story with wrong variable names
<tormod> well if you don't see boot messages, booting with "text" will leave you with black screens
<tormod> I guess you would have had the same loss of console text with KMS *until* KMS kicks in and resets the modes
<tjaalton> perhaps
<tjaalton> with "text" i do indeed get the vt's
<tjaalton> er, vc's
<tormod> yes but now without that gfxpayload? or still with?
<tjaalton> with
<tjaalton> swapped the variable with 'test'
<tjaalton> text
<tormod> oh I see, I was thinking about the boot option "text" (for gdm)
<tjaalton> that didn't seem to work at all
<tjaalton> oh well
<tjaalton> actually yeah it did
<tjaalton> just that the console didn't :)
<tormod> this was a clean install? so grub conf is broken?
<tjaalton> yes
<cnd> bryceh, I think there's a problem with the input modules RAOF uploaded
<cnd> I think they got built against the previous xserver-xorg-dev
<cnd> which means they popped out with a dependency on xserver-input-abi-12.1 instead of xserver-input-abi-12
<cnd> tjaalton, ^^ (in case bryceh isn't up yet)
<tjaalton> gah
<tjaalton> so a rebuild?
<tjaalton> +needed
<cnd> I think so
<cnd> xorg-server is built now for all archs
<cnd> so we should be good to go now
<tormod> tjaalton, can you do the mga sync also? LP 722877
<ubot4> Launchpad bug 722877 in xserver-xorg-video-mga (Ubuntu) "please sync xserver-xorg-video-mga 1:1.4.13.dfsg-3 from Debian unstable (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/722877
<tjaalton> tormod: yes, though I'll sort the rebuilds first, to see what's needed
<tjaalton> cnd: give an example of a driver that built against the wrong version?
<cnd> I'm providing info from pmcgowan
<cnd> he saw bad deps on evdev
<tjaalton> at least joystick is good
<cnd> I don't have an i386 machine, and I haven't manually downloaded the i386 debs to check them
<cnd> and amd64 isn't built yet
<tjaalton> https://launchpad.net/ubuntu/natty/i386/xserver-xorg-input-evdev/1:2.6.0-1ubuntu7
<tjaalton> looks normal
<tjaalton> maybe he looked at the old package?
<cnd> tjaalton, ahh, didn't know you could see deps there
<cnd> it does look right
<cnd> maybe he does have some stale state
<tjaalton> *phew*
<tjaalton> so no need for rebuilds..
<cnd> he was still getting ubuntu6 evdev
<cnd> so I think his mirror was just slow to sync
<tjaalton> yep
<cnd> he was piecemeal giving me info cause he was on another computer and couldn't copy/paste
<cnd> and I just didn't check that...
<tjaalton> great, my dns is broken
<tjaalton> can't dput anything
<tjaalton> had to copy elsewhere
<tjaalton> tormod: you didn't build savage with -sa
<apw> is the threat to uninstall ubuntu-desktop a temporary thing?
<tjaalton> so it got rejected because of missing tarball
<tjaalton> apw: due to?
<tormod> tjaalton, possibly, but do you not need to debuild it again yourself?
<tjaalton> tormod: no, I'll just debsign it
<tormod> aha
<apw> tjaalton, actually how do i tell?
<tjaalton> apw: aptitude should show
<tormod> tjaalton, should I fix it?
<tjaalton> tormod: well I could rebuild it, either is fine
<apw> tormod, ahh xserver-xorg-vide-geode
<apw> which is depending on abi-0.9
<tjaalton> yeah it's missing from the rebuilds
<tormod> tjaalton, I fixed it
<apw> tjaalton, so i assume its being fixed ... and i just wait a bit
<tjaalton> apw: yep
<tjaalton> tormod: thanks
<Sarvatt> mga sync? does it have the xinerama fix in it or are we regressing https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-mga/+bug/292214 ?
<ubot4> Launchpad bug 292214 in xserver-xorg-video-mga (Ubuntu Natty) (and 2 other projects) "Xinerama broken since intrepid on MGA (affects: 14) (dups: 1) (heat: 110)" [High,Fix released]
 * Sarvatt looks
<jcristau> it's there
<Sarvatt> phew, its all good
<jcristau> xserver-xorg-video-mga (1:1.4.11.dfsg-4+squeeze1) unstable; urgency=low
<bryceh> morning
<ricotz> bryceh, hi
<bryceh> ricotz, hey
<ricotz> bryceh, i had a look at wayland
<ricotz> bryceh, i think your package will get rejected
<ricotz> lintian complains about a lot fsf copyrights
<ricotz> i packaged the latest git http://people.ubuntu.com/~ricotz/wayland/
<ricotz> it is better using debsrc3 and newer compat level
<cnd> bryceh, (or anyone else familiar with mesa), can you check out this bug: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/259219
<ubot4> Launchpad bug 259219 in mesa (Ubuntu) "Broken TLS support in libGL.so (affects: 1) (heat: 8)" [Undecided,Expired]
<cnd> one of the multitouch games developers is hitting this
<cnd> we're wanting to push them to universe, but this is causing issues
<bryceh> ricotz, thanks but aiui that won't work with the natty mesa.  Did you test it?
<ricotz> bryceh, i didnt test it, but it compiles
<ricotz> bryceh, this is only the library, the demos are in a new branch wayland-demos which would be a new source package
<bryceh> ricotz, yeah it'll probably crash when you run it
<ricotz> but as i said there are a lot copyright complains
<bryceh> ricotz, yeah probably would be too late to get wayland-demos into natty anyway, given that FF is tomorrow
<bryceh> regarding the gpl issue, I already uploaded a fixed version yesterday
<ricotz> ok, then i might be an issue with the newer source
<bryceh> well, the 'fix' was just to mention gpl in debian/copyright
<bryceh> I don't think at this point we care whether it's mit or gpl really
<ricotz> ok
<ricotz> bryceh, did you take a peek at the debian.tar.gz?
<bryceh> cnd, ironically wayland needs --enable-glx-tls (at least, the snapshot version I'm trying to get into natty needs it)
<bryceh> ricotz, no
<jcristau> whether debsrc3.0 is better is.. arguable.
<ricotz> i think it is easier to maintain
<cnd> bryceh, hrm... so does wayland need to be fixed?
<bryceh> cnd, I don't know if we needed it for anything else besides wayland, will have to check with raof
<cnd> bryceh, it's not a show stopper, we can hack around it
<Sarvatt> very very very arguable :)
<bryceh> cnd, rather than reopen such an ancient bug ;-), could you file a new bug and explain what the current breakage is in more detail?
<cnd> install wrapper scripts to export LD_PRELOAD before calling the real binary
<jcristau> can they talk to mesa upstream?
<cnd> bryceh, tbh, I'm just following what others were saying
<Sarvatt> goes well if you like the packaging workflow libxcb and cairo use I guess
<cnd> but I'll ask the people who know more to do that
<bryceh> ricotz, thanks, yeah that looks better than my cargo culted rules file ;-)
<bryceh> ricotz, btw I've contacted kibi about wayland packaging, and am planning on coordinating with him to get the packaging consistent with how debian wants it
<ricotz> bryceh, yeah ;), but the copyright needs an rewrite to fit the new specs
<ricotz> bryceh, it should be formatted this way http://paste.debian.net/108504/
<jcristau> err.  no.
<ricotz> jcristau, no?
<jcristau> it can if you're that bored.  it doesn't need to.
<jcristau> debian/copyright is free-form
<ricotz> oh, i thought it should follow these dep5 quideline
<apw> tjaalton, no sign of the archive becoming cnsistant ... does a build need a rescore?
<tjaalton> apw: at least geode is ready
<tjaalton> apw: so is it some other driver now?
<apw> tjaalton, oh you are off the hook it seems, now language-selector is to blame
<tjaalton> apw: whee :)
<apw> stupid how apt-get doesn't tell you why
<cnd> apw, if you update to the latest x bits, you'll now have multitouch through X from your dell mini trackpad :)
<cnd> though you can't easily test it with anything yet
<jcristau> xinput! :)
<apw> cnd, if the archive is every consistant again i would update ... though my mini is a little sick right now
<cnd> so the trackpad from hell has more use now
<cnd> jcristau, xinput hasn't had touch events added :(
<cnd> apw, sorry to hear that, hope she gets well soon
<cnd> RAOF, I hit this bug: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/259219
<ubot4> Launchpad bug 259219 in mesa (Ubuntu) "Broken TLS support in libGL.so (affects: 1) (heat: 8)" [Undecided,Confirmed]
<cnd> I'm going to duplicate a clean bug for it
<cnd> but I started digging into it
<cnd> I'm thinking we should be going with solution #2 as stated in the bug description
<cnd> if you want background reading: https://docs.google.com/viewer?url=http://people.redhat.com/drepper/tls.pdf
<cnd> I'm still trying to digest it myself :)
<cnd> btw, thanks for the uploads! everything seems to have gone smoothly
<jcristau> cnd: yeah reading drepper's tls paper :)
<cnd> jcristau, if I read it right, it seems like mesa has it completely wrong :)
<cnd> it's selecting the initial-exec model, which seems to only be valid if you statically link against mesa
<Sarvatt> I like option 3) ignore libavg :D
<jcristau> cnd: so your app dlopens libGL?
<jcristau> (or dlopens something linked against libGL)
<cnd> jcristau, libavg does it appears
<jcristau> ok
<cnd> I don't know if there's a difference between implicit dynamic loading or dlopen for the tls model
<jcristau> bah and docs/dispatch.html doesn't explain why it's using that tls_model
<cnd> yeah
<cnd> I'm actually about to troll through git history
<cnd> to see if there are any clues
<jcristau> it does seem wrong..
<cnd> I don't think people usually use tls models
<cnd> so I think this is really an effort to be as fast as possible
<cnd> and it's just stepping too far
<RAOF> I'm trying to remember whether I've seen that discussed upstream. I've got a vague recollection of it.
<cnd> this was the bug that started it all: https://bugs.freedesktop.org/show_bug.cgi?id=1822
<cnd> and this is the commit that resulted: https://bugs.freedesktop.org/show_bug.cgi?id=1822
<cnd> oops
<ubot4> Freedesktop bug 1822 in libGL "libGL (and DRI drivers) should support TLS" [Enhancement,Resolved: fixed]
<cnd> 25fe93f0a11e6f4c8d470441ff91b9cddf7b3023
 * jcristau just got there
<jcristau> and reading the bug it references..
<jcristau> cnd: so the initial-exec stuff was already in http://marc.info/?l=dri-devel&m=105187260618425&w=2
<jcristau> which seems to be where this stuff came from
<jcristau> silly netsplits..
<bryce_> [ubuntu/natty] wayland 0.1~git20101129.ac93a3d3-0ubuntu1 (Accepted)
#ubuntu-x 2011-02-24
<mdeslaur> have there been any reports of spurious mouse clicks?
<bryce_> mdeslaur, synaptics or evdev?
<mdeslaur> evdev...it's a usb mouse
<bryce_> I've not seen reports of spurious mouse clicks recently
<bryce_> there seem to be none open on my natty list - http://www.bryceharrington.org/Arsenal/Reports/ubuntu-x-swat/workqueue-natty.html
<mdeslaur> ok, am just wondering if it's my hardware...I'll try another mouse
<mdeslaur> thanks bryce_ 
<bryce_> there were a couple weird bugs with erratic pointers but those were synaptics-specific
<RAOF> And now would be the time for crazy pointer-based bugs.
<bryce_> oh yeah, new input stack
<bryce_> mdeslaur, just updated today and noticed it for the first time?
<mdeslaur> bryce_: I noticed it maybe a day or two ago, after an update
<mdeslaur> but, as I said, it maybe hardware
<mdeslaur> I just plugged in another mouse, we'll see
<bryce_> mdeslaur, ok, then that gets cnd and raof off the hook ;-)
<mdeslaur> hehe
<mdeslaur> although if it is hardware, I'll be sure to bring the broken mouse to UDS for a practical joke :P
<cnd> RAOF, bryce_: changing the tls type to local-dynamic didn't help any...
<cnd> so I don't really know what a good resolution is
<cnd> and it seems to have just made things worse all around
<cnd> RAOF, unless these variables are used in other libs?
<RAOF> Does it interact with the split-glapi stuff?  You're testing against natty's mesa, right?
<cnd> RAOF, I took natty's mesa package and replaced any occurrences of the initial-exec model with local-dynamic
<cnd> rebuilt
<cnd> and installed
<cnd> it doesn't look like the two headers with the occurrences are installed in any packages
<cnd> so they are confined to the library
<RAOF> Yeah, that'd be right.
<cnd> I'm going to try to make them generic
<cnd> just to see if that works
<RAOF> Is there any raw asm that's getting used?
<cnd> yeah
<cnd> do you think that means it might require rebuilding other packages, or that the variables need to be generic since they may be referenced by other libraries?
<cnd> I can't imagine the latter, since if you can't find them in a header file you can't access them
<RAOF> I'm not sure.
<cnd> I should just make a test.c to try to load the libs in different orders
<cnd> and see what happens
 * RAOF goes to find drepper's tls paper
<cnd> RAOF, well, I can't seem to trigger the bug with a simple test case
<cnd> and if I can't fix this kind of bug quickly, it moves down my priority list :)
<cnd> I gave the libavg devs a two line python workaround
<RAOF> Heh.
<RAOF> Ok.
<cnd> it just loads libstdc++ before anything else :)
<RAOF> I'll look into it.
<cnd> cheeky
<cnd> so it's not a high priority
<RAOF> Hey!  Now that I think of it, doesn't libGL *link* to libstdc++?
<RAOF> But the dri drivers do.
<RAOF> So libstdc++ is *already* being loaded by dlopen after libgl.
<cnd> RAOF, does it?
<cnd> that seems odd
<cnd> to use opengl you have to load all the c++ stuff?
<RAOF> Yup.
<RAOF> Because the glsl compiler is written in C++, so needs libstdc++
<cnd> hmm, then I have no clue :)
<RAOF> And the glsl compiler is built into the dri drivers, which are dlopened by the non-C++-using libgl
<RAOF> What's the actual problem again? :)
<cnd> RAOF, then you're beyond my comprehension now :)
<cnd> I just know that libavg dlopens libGL
<cnd> and if you don't preload libstdc++, you get a segfault
<cnd> and it's claimed that this is due to tls stuff
<RAOF> Maybe it's passing incorrect flags to dlopen?
<cnd> RTLD_NOW?
<cnd> that's all it's passing
<RAOF> Let's ask someone who understands the dynamic linker!
 * RAOF nominates Colin Watson.
<cnd> :)
<cnd> good luck finding him at this hour
<RAOF> I don't.  I plan to read about TLS circa 2001 and eat toast.
<bryce_> humber:~/ubuntu/linux/linux-2.6$ sudo lsinput
<bryce_> [sudo] password for bryce: 
<bryce_> /dev/input/event0
<bryce_> protocol version mismatch (expected 65536, got 65537)
<bryce_> wth?
<RAOF> Oh, does it need a rebuild again?
<bryce_> possibly I just haven't rebooted since updating
<bryce_> (although I'm not being prompted to reboot)
<RAOF> I think it needs to be rebuilt against newer kernel headers.
<bryce_> I'll do a upgrade and reboot and see if it still repros
<RAOF> Looks like this might be bug #723944
<ubot4> Launchpad bug 723944 in xorg (Ubuntu) "Synaptics touchpad no more working after disribution upgrade (affects: 2) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/723944
<RAOF> bryce_: A quick rebuild fixes input-utils.
<RAOF> cnd: You wouldn't happen to be awake, would you?
<bryce_> we should phone him (tee hee)
<RAOF> So, those logs on the bugs don't seem to be particularly informative.
<RAOF> Except that the X driver is loading, and thinks it's driving the devices.
<bryce_> yeah
<bryce_> nothing remarkable in dmesg either
<bryce_> RAOF, I'm dist-upgrading 3 laptops now, will try reproducing on each
<bryce_> RAOF, have you had luck reproducing it on your hw?
<RAOF> Not so far.
<RAOF> But I'll upgrade my other laptop and see.
<bryce_> the protocol mismatch thingee seems to pre-date the xserver update today
<bryce_> kernel bug maybe?
<tjaalton> the synaptics-thing?
 * bryce_ points tjaalton at #canonical
<RAOF> bryce_: That's a regular occurrence - input-utils needs to be kept in sync with the kernel evdev header, and I guess it hasn't had a rebuild recently enough.
<bryce_> ok, so that's item #1.  guessing we need a kernel guy to twiddle something?
<tjaalton> those spurious mouseclicks.. think I'm seeing those sometimes
<bryce_> can we get the same info from proc or sysfs?
<tjaalton> with thunderbird. clicking on emails open in new tabs
<tjaalton> but not always
<RAOF> bryce_: No; we just need a no-change rebuild of input-utils.
<bryce_> RAOF, ok
<RAOF> And I don't think we can get that info anywhere else; it reads the raw event stream out of the evdev nozzle.
<bryce_> RAOF, looks like input device info can be gotten at /proc/bus/input/devices
<RAOF> Yeah, that gets some.
<RAOF> Hm.  My laptop says âfailed to open grail, no gesture supportâ, and I didn't notice that in any of the other xorg.0.logs
<RAOF> Yeah.  All the affected systems seem to have utouch support.
<bryce_> interesting
<bryce_> yeah I have two laptops using synaptics, neither seems affected
<RAOF> What are the buttons reported in Xorg.0.log?
<RAOF> My unaffected laptop has âleft rightâ, my other laptop (which I predict will be affected once it's finished upgrading) has âleft right double tripleâ
<bryce_> http://paste.ubuntu.com/571563/
<RAOF> Ok.  You *also* fail to open grail.
<bryce_> http://paste.ubuntu.com/571565/
<bryce_> I installed utouch on that second one, still no repro
<RAOF> Oh, the driver links to libutouch-grail1; the âfailed to open grailâ is from the failure of grail_open(device)
<bryce_> ok, guess we can call that issue #2.  I take it it's innocuous?
<RAOF> I presume it'll happen when the touchpad doesn't support enough for grail to be all gesturiffic.
<RAOF> But given that second Xorg.0.log of yours is for a *non* reproducer, it's clearly not the (sole) issue.
<RAOF> Although we do apply some quirks to your second Xorg.0.log.
<bryce_> second box is a dell mini, I think if that had busted mouse we'd get LOTS of bug reports today
<bryce_> third box:  http://paste.ubuntu.com/571566/
<bryce_> also verified using synaptics but no repro
<RAOF> That one also has a bonus PS/2 mouse :)
<bryce_> fwiw that one's in a docking station
<bryce_> it's got a touchscreen lvds and a touchscreen external monitor and touchpad
<tjaalton> huh, we still have -input-fpit in the archive, provides -input-4 :P
<bryce_> but no ps/2 mouse
<RAOF> dev/input/event6 would care to differ :)
<bryce_> it can think what it wants
<bryce_> actually the external touchscreen functionality isn't hooked up
<bryce_> but anyway
<bryce_> well I'm running out of ideas
<bryce_> it seems not to be abi breakage else it would be universally broken
<RAOF> Right.
<RAOF> I'd like to see the raw event stream from âxinput testâ, or at least know that such a stream exists or doesn't.
<bryce_> the mouse0 / mouse1 bit seems not particularly unusual (I have that same bit my xorg log)
<RAOF> Yeah.  We don't match anything against mouse*
<RAOF> It's a symlink to somethnig more interesting, so we'll already have covered it earlier.
<bryce_> RAOF, maybe you could forward one or both of those bug reports to peter (and cnd when he comes on)?
<RAOF> I shall.
<RAOF> Well, peter?
<bryce_> hutterer
<tjaalton> this isn't upstream, if it's due to the multitouch patches
<RAOF> Yeah, I know who you meant, but it's going to be multitouch releated.
<bryce_> ok, just thought if he and cnd were in communication about this
<tjaalton> daniels and cnd are
<bryce_> ahh
<tjaalton> hmm pbuilder didn't fail on x11-utils without the old changes, so it should be sync'able
<geser> Hello, anyone an idea why my mouse scrollwheel doesn't work anymore in my natty installation?
<tjaalton> geser: does xev list any events for it? or evtest?
<tjaalton> RAOF: heh, so keithp is asking if removing randr-1.4 from 1.10 would be something people want
<RAOF> Well, I guess he could; no one's using it yet.
<RAOF> At least, I don't *think* anyone's using it yet :)
<tjaalton> it'd revert the abi as well aiui
<RAOF> Yeah, it would.
<RAOF> But that wasn't an ABI that drivers *needed* to care about IIUC
<tjaalton> right, it's just another round of rebuilds :)
<geser> tjaalton: no, xev doesn't show any events when I scroll (but pressing the scroll wheel is shown as button 2 as expected)
<RAOF> tjaalton: I'm not sure it'd even require a round of rebuilds.
<tjaalton> geser: then check if you get events from evtest on the console
<tjaalton> lunch->
<geser> tjaalton: evtest doesn't list any events either :(
<cdbs> Looks like something's broken with the Synaptics touchpad driver
<geser> trying out my other mouse (a Logitech Wireless M305) everything works as expected
<geser> hmm, re-pluging my mouse seems to work too
<tjaalton> geser: so if evtest doesn't show anything it's because of the kernel
<RAOF> cdbs: Aha!  You've got a piece of affected hardware?
<cdbs> RAOF: yes, its an old Synaptics touchpad that doesn't support multitouch
<cdbs> RAOF: Should I post evtest output to bug?
 * cdbs got the bug
<RAOF> It wouldn't hurt.  Also, working out whether âxinput testâ shows events when you do things with the touchpad would be nice.
<cdbs> RAOF: My thing doesn't have /dev/input/event7 . It has only upto 5
<cdbs> Which one should I use?
<tjaalton> xinput list
<tjaalton> pick the id for the device
<cdbs> RAOF: xinput test doesn't help
<cdbs> RAOF: no output, except when I clicked the buttons (which are working fine)
<cdbs> okay, I downgraded using the downgrade scrip
<cdbs> t
<cdbs> Hi, I did downgrade the packages, but after that I got a far less usable system
<cdbs> Every application I would open, would crash
<cdbs> EVERY
<cdbs> from nautilus, to even gnome-terminal
<tjaalton> that's not X's fault
<cdbs> well, not
<cdbs> but that opens up a possibility:
<cdbs> Why not just upload a 'revert' package of xserver-xorg-input-synaptic?
<cdbs> It appears that these applications and GTK bindings are built against the new ABI, while the downgrade script as given by RAOF takes us back to the old one
<tjaalton> lets give cnd a chance to fix it
<tjaalton> seb128: there's a new(ish) libgnomekbd (2.30.2), are there plans to update?
<seb128> tjaalton, we are on 2.32 which is a newer serie
<seb128> tjaalton, or do you mean a sru for some stable version?
<seb128> tjaalton, 2.30 is used in lucid
<tjaalton> seb128: there's 2.30.2 in debian
<seb128> but it has 2.30.2?
<seb128> tjaalton, well lucid has that
<tjaalton> grah, sorry
<seb128> tjaalton, natty has 2.32
<tjaalton> mixed up the versions
<tjaalton> debian has 2.30.2, we have 2.32.0 :)
<seb128> right
<seb128> just curious how did you run into that?
<seb128> is there any bug in natty?
<tjaalton> no, it's just listed on the versions_current.html list
<tjaalton> dunno why
<tjaalton> since it's not maintained by the x team
<tjaalton> hm, -fpit is still maintained upstream it seems..
<tjaalton> for abi changes at least
<tjaalton> and it seems to still have users..
<cnd> RAOF, if you're still up, I'm now up too :)
<cnd> I read the backscroll here and in ubuntu-devel
<cnd> taking a look at the bug now
<cnd> if I had to guess, it looks like grail is opening on non-multitouch hardware and this is throwing things off
<soreau> Hey guys I have a reproduceable crash I want to get a bt from and I install debug packages but gdb tells that /usr/bin/X has no debugging symbols
<soreau> What is the problem?
<jcristau> soreau: the real binary is /usr/bin/Xorg
<soreau> Well &%*
<cnd> soreau, it's not a big problem
<cnd> do you have a core dump?
<cnd> or are you wanting to attach to X?
<soreau> Yes I got the dump now 
<soreau> thanks jcristau 
<cnd> ok
<cnd> soreau, by any chance are you using multitouch hardware?
<cnd> :)
<soreau> nope
<soreau> It happens when trying to vncviewer into the machine
<soreau> It worked until a couple weeks ago
<cnd> ok, cool
<cnd> not my problem :)
<jcristau> fdo#30032 is a crash when using x11vnc, could be the same thing?
<cnd> tjaalton: got a few mins to upload a fix for the synaptics issue?
<cnd> or bryce_, if you happen to be up already
<tjaalton> cnd: i'm at the hw store, back home in 30min
<tjaalton> comp hw :)
<cnd> tjaalton: ok, thanks!
<bigon_> any idea what's going on https://bugs.launchpad.net/bugs/714280 (my last messages)
<ubot4> Launchpad bug 714280 in xorg-server (Ubuntu) (and 3 other projects) "The error was 'BadLength (poly request too large or internal Xlib length erro'. (affects: 5) (dups: 1) (heat: 233)" [High,Confirmed]
<jcristau> what's going on is you're mixing different bugs.
<bigon> my 2 last messages are still refering to BadLength (poly request too large or internal Xlib length error)
<jcristau> for a different request
<jcristau> changedrawableattributes is fixed in 4324d6fdfbba17e66b476cf008713d26cac83ad1
<bigon> should I open a different bug for this one?
<jcristau> dunno
<jcristau> you could just upgrade your X server
<jcristau> or your mesa.
<bigon> both machine are uptodate (with natty)
<jcristau> then natty doesn't yet have the fixes
<bigon> indeed
<jcristau> so upgrade your X server or mesa, or live with the bug until natty bumps either of them.
<jcristau> actually, natty's X server has that fixed.
<tjaalton> cnd: ok, finally home
<cnd> tjaalton, great
<cnd> tjaalton, I suppose you'll probably want a source package
<cnd> didn't think to create one...
<tjaalton> cnd: yep
<tjaalton> heh
<cnd> I'll do that right now
<tjaalton> cnd: I'll have dinner in the meantime
<tjaalton> won't take long
<cnd> tjaalton: I just uploaded
<cnd> ok
<tjaalton> oh
<tjaalton> where?
<cnd> it's at people.canonical.com/~cndougla/utouch/
<tjaalton> Checksum doesn't match for /tmp/people.canonical.com/~cndougla/utouch/utouch-frame_1.1.1-0ubuntu1.debian.tar.gz
<cnd> hmm...
<cnd> that's odd
<cnd> I'll try to reupload it
<cnd> tjaalton, try once mre
<cnd> if that doesn't work, I'll try things locally to figure out what's wrong
<tjaalton> still the same
<cnd> hmmm
<cnd> ok
<tjaalton> 4cf85322570b8ad7ce800212c582e655
<tjaalton> is the md5sum
<tjaalton> when source.changes says it should be e113aa341f8e3b4e784fdf374f4d1c02
<cnd> ummm... my version locally doesn't match either!
<cnd> https://wiki.ubuntu.com/ChaseDouglas/DeveloperApplication-uTouch
<cnd> oops
<cnd> dc9a4f63e84871a89984b1fd839d9236
<tjaalton> that's the tarball
<cnd> oh, I was looking at the wrong file
<cnd> I'll recreate the source package and see what's wrong
<cnd> I did a test build after the source package build
<cnd> maybe the test build overwrote it
<tjaalton> could be
<tjaalton> i'll eat now :)
<cnd> ok, it's reuploaded when you are ready
<tjaalton> cnd: yep, didn't complain this time
<cnd> great
<bigon> jcristau: I will open an other bug I've 1.10 rc2 installed and still have the issue X_GLXChangeDrawableAttributes request
<jcristau> installed or running?
<cnd> bryce_, RAOF, tjaalton: I'm applying for package upload rights for the utouch packages
<cnd> if you'd like to sponsor me, please do so at https://wiki.ubuntu.com/ChaseDouglas/DeveloperApplication-uTouch
<cnd> thanks!
<bigon> 17:56 < jcristau> installed or running? << running I've rebooted to be sure
<bryce_> morning
<bryce_> synaptics issue get sorted out?
<cnd> bryce_, we think so
<cnd> new utouch-frame should fix it
<cnd> the package should be synced to the mirrors by now I believe
<cnd> it is for amd64 at least
<cnd> it affected multi-finger, non-mt trackpads :)
<bryce_> cnd, excellent
<cnd> bryce_, in case you didn't see above, I'm trolling for package upload rights sponsors
<cnd> so we can fix these issues faster :)
<cnd> we waited around for about an hour before tjaalton became available
<cnd> and didrocks is our normal uploader, but he's swamped
<bryce_> cnd, right!  hitting the page now
<cnd> bryce_, thanks!
<tjaalton> i'll add my comments after bryce :)
<cnd> cool
<Sarvatt> hmmm, so I can reproduce this on my netbook by just attempting to "install ubuntu" https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/714829
<ubot4> Launchpad bug 714829 in xserver-xorg-video-intel (Ubuntu) "Xorg segfaults during LiveCD installation using preseed file (affects: 1) (heat: 201)" [High,Incomplete]
<Sarvatt> only, X never crashes
<tjaalton> nice
<Sarvatt> i get tons of the [ 194.542] (WW) intel(0): intel_uxa_prepare_access: bo map failed: Cannot allocate memory though and X is still alive and kicking but unresponsive
<tjaalton> can you get to the machine somehow?
<Sarvatt> yeah i'm using it now
<Sarvatt> gem objects look fine http://sarvatt.com/downloads/i915_gem_objects.txt
<tjaalton> hmm I bought an ssd, could pyt it in my x61
<tjaalton> put even
<Sarvatt> dont have to actually wipe anything even, just booting the livecd, going to install ubuntu then hitting next kills things
<tjaalton> hm ok
<tjaalton> so something is eating the memory, and it's not x/intel
<Sarvatt> its right when it'd be starting up partman to do all the disk partitioning that things die
<tjaalton> hm, have you checked it's logs?
<Sarvatt> i cant even see the panel at the top in unity on a 1024x600 screen
<Sarvatt> now i'm getting some aufs error spam, aufs au_new_inode:412:dbus-launch[2578]: Warning: Un-notified UDBA or repeatedly renamed dir, b0, tmpfs, ubuntu, hi1965, i273.
<Sarvatt> oh got a crash that time, went to VT immediately after hitting install ubuntu
<Sarvatt> try ubuntu is fine, looks like installing it from inside the live session works fine too..
<Sarvatt> better let it finish before I say that I guess :)
<soreau> I have an Xorg crash http://pastebin.com/Etjjzue8 when trying to vncviewer into it from another machine :)
<cnd> bryce_, btw, I'm going to ask at the DMB meeting for motu rights too, so we'll see
<cnd> thanks for the endorsement :)
<bryce_> cnd, yep, good luck!
<cnd> bryce_, because I'm not sure the best route for me, I asked cody on the dmb
<cnd> he said he'd be happy to review an application of mine before going to the dmb for core dev rights
<cnd> I just don't want to waste the dmb time
<cnd> their meetings get long and slow enough as it is
<cnd> so I'm going to create a new application page for core dev
<cnd> and ask for some endorsements
<bryce_> cnd, sounds good
<bryce_> cnd, yeah it would not be a bad idea to shoot for utouch rights in the coming meeting, then apply for motu the meeting after that, and core dev the one after that, in sequence
<cnd> something like that
<bryce_> cnd, however you do it, you got my endorsement :-)
<cnd> heh
<bryce_> Sarvatt, aha you have a lead on our elusive memory leak bug
<Sarvatt> bryce_: i'm drawing up blanks on why this is happening only when "install ubuntu" is picked, installing from inside "try ubuntu" just hangs before the disk partitioning tool comes up but X is still here and i'm still able to quit the install fine even
<bryce_> Sarvatt, yeah we've suspected it was something like the installer.  I've seen the bug reports only against use in the livecd environment
<bryce_> Sarvatt, have you found a way to view memory usage that shows what process is gobbling mem?
<Sarvatt> nothing is using an abnormally large amount of memory
<bryce_> Sarvatt, i.e. does top, cat /proc/meminfo, xrestop, or the like show something?
<bryce_> I've also wondered if it might be just video memory getting exhausted
<bryce_> but I don't know if we have a tool for measuring that... is it shown in one of the gem files in sysfs?
<Sarvatt> was playing around in the try ubuntu option there, rebooting into install ubuntu to see
<Sarvatt> it looks fine http://sarvatt.com/downloads/i915_gem_objects.txt
<Sarvatt> (thats from right before an X crash while it was spamming the bo map failed errors)
<bryce_> I wonder if the Install Ubuntu functionality can be run independently of the livecd
<Sarvatt> i can't see the menu bar on the selection screen where you pick try or install either, its above the screen so the window will fit
<Sarvatt> yeah trying to figure out how the heck to do just that at the moment
<bryce_> Sarvatt, have you talked with evand or cjwatson yet?
<bryce_> if not, maybe we should spin them up, they might have some suggestions that'd save us some time
<bryce_> I'll poke through their bug tracker and then see if I can grab evan
<bryce_> fwiw, on radeon since updating to latest stuff yesterday I've been noticing with popup menus that sometimes in the fraction of a second before the menu is displayed where what I suppose is supposed to be a black rectangle, I catch a momentary glimpse of what looks like uninitialized video memory
<cnd> bryce_, I have copied my utouch endorsement to my coredev application: https://wiki.ubuntu.com/ChaseDouglas/DeveloperApplication-CoreDev
<cnd> it has some utouch rights specific phrasing
<cnd> would you like to edit it, or do you want me to fix it up for you?
<bryce_> but it only displays for a few milliseconds so can't see it properly, and seems hard to reproduce on demand
<bryce_> cnd, I can edit it up, thanks
<cnd> ok
<bryce_> done
<bryce_> Sarvatt, ok I pinged ev on #ubuntu-devel.  guessing he's EOD'd
<bryce_> Sarvatt, gave him a rundown maybe he can help
<bryce_> Sarvatt, hrm, finding nothing interesting amongst the ubiquity bug reports
<bryce_> Sarvatt, reviewing our own bug report history with this issue, the first report (from mario) was Jan 19th, so I would guess the issue first entered the archive around Jan 17/18
<bryce_> ubiquity 2.5.6 is dated Jan 17 
<cnd> bryce_, RAOF, btw, I forgot to mention that I had been planning to fix up lsinput
<cnd> in fact, I think I'll sit down right now to do so :)
<Sarvatt> bryce_: apparently just sitting on the welcome screen is enough to trigger the bo map failed errors
 * Sarvatt is going to try reverting this force background redrawing commit from jan 17th
<bryce_> Sarvatt, quite unexpectedly just following random hunches I found some leaky C code
<bryce_> Sarvatt, going on the assumption that it was ubiquity, and that it must have happened shortly before feb 19th, I looked at the diff
<bryce_> ubiquity 2.5.6 is a huge diff but 99.9% is just python and translations stuff
<bryce_> however there is one change to one C file
<bryce_> and wouldn't you know it, that change involves adding a pointer, strduping to it, and there is no matching free
<bryce_> it's in d-i/source/netcfg/netcfg-common.c routine netcfg_write_common
<bryce_> Sarvatt, anyway I can do up a patch at this point.  need food first
<bryce_> I'm 70% certain this could be our culprit.
<bryce_> no idea how we'd test it though
<Sarvatt> bryce_: awesome
<cnd> is it just me, or are all lp related functions really slow today?
<bryce_> I've had a few timeouts but nothing out of the ordinary
<Sarvatt> bryce_: so uh.. http://sarvatt.com/downloads/patches/wtf.diff has lasted 10 minutes on the welcome screen with no bo map errors
<Sarvatt> bryce_: 204 seconds was my record before
<bryce_> Sarvatt, aha, where'd you find that?
<Sarvatt> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/ubiquity/natty/revision/380#src/panel/panel.c
<Sarvatt> something tells me it might have been queuing a redraw way more often than they wanted? :D going to attempt an install now and see what happens
<bryce_> ok
<Sarvatt> of course it wont go past the preparing to install screen because partman wont load up but still not crashing
<bryce_> rev 380 was on 2011-01-14
<Sarvatt> bryce_:  you should be able to reproduce this by just loading a liveusb on your dell mini and sitting at the welcome screen for a minute or two
<Sarvatt> can switch straight over to a vt and watch Xorg.0.log
<bryce_> patch looks like it goes with https://bugs.launchpad.net/ubuntu/+bug/693300
<ubot4> Launchpad bug 693300 in ubiquity (Ubuntu) "Top white bar in oem-config (ubiquity) when choosing CJK. (affects: 1) (heat: 64)" [Undecided,Fix released]
<bryce_> ok lemme give that a go
<bdmurray> bryce_: the package hook for X uses compiz-0.9.2 while I've been tagging everything just compiz-0.9 or compiz-0.8 - I think it'd be best if we stuck with the same convention
<bryce_> bdmurray, want to send a patch?  I'm aware of the problem but have a lot of stuff higher up in priority on my todo list at the moment
<bryce_> bdmurray, there is code that is supposed to split the string and extract just the 0.9 there, which worked when I tested, but there must be a bug in the logic
<bdmurray> bryce_: just a patch? no bzr branch or debdiff or other magic? ;-)
<bryce_> just a patch would be fine
<bdmurray> cool, I can do that
<Sarvatt> bryce_: fixed up debs are here in case you use persistent storage and want to see if it fixes it for you too, just need these 3 http://sarvatt.com/downloads/ubiquity/
<Sarvatt> bryce_: this really looks to have fixed it here
<bryce_> Sarvatt, ok, still 15 min or so left on my iso download
<bdmurray> bryce_: I also added a patch to bug 723624
<ubot4> Launchpad bug 723624 in xserver-xorg-video-intel (Ubuntu Natty) (and 1 other project) "apport-gpu-error-intel.py keep crashing after login (affects: 1) (heat: 8)" [High,Triaged] https://launchpad.net/bugs/723624
<bryce_> bdmurray, excellent, thanks
<bryce_> that's another I was wondering about, I'll get those fixes in today
<RAOF> cnd: Rocking.  Thanks for fixing that.
<cnd> RAOF, sure, np!
<cnd> RAOF, in return, please consider endorsing my applications for upload rights :)
<RAOF> Certainly!
<RAOF> Does the bug have an analysis of the situation, so I can be more informed for future breakage?
<cnd> RAOF, the bug is basically: our stack just doesn't work for multi-finger, non-mt devices
<cnd> but we let them through anyways
<cnd> so our "fix" for now is to not let them through
<cnd> RAOF, bryce_: however, you may find some helpful debugging stuff in there for the future
<cnd> the use of evemu for recording and replaying devices
<RAOF> And this manifested by grail eating all the events and not posting any to the X queue?
<cnd> RAOF, something like that
<cnd> I haven't actually worked on the underlying bug
<RAOF> Heh.  'sok.
<bryce_> cnd, looks like there was a .deb posted, it would be educational to have the patches attached (or branches linked to, or commit ids) so those of us curious could follow along at home :-)
<cnd> bryce_, branches are linked
<bryce_> ah, didn't notice
<cnd> both upstream and packaging
<cnd> :)
<bryce_> cnd, one thing we could think about, if some of those debugging tools/output are going to be always worth having with -evdev reports, or utouch, or whatnot, then we should create an apport hook
<bryce_> otoh maybe we'll never have more than a handful of bug reports so won't be worth the bother?  ;-)
<cnd> bryce_, I've thought about making it part of the standard bug template
<cnd> but not about apport hook...
<cnd> that's an interesting idea
<bryce_> bug template?
<cnd> one that would require a bit of dev work
<cnd> bryce_, isn't there something that you can set on each project/package to request certain info when you file a bug?
<cnd> I don't know if it works when you run ubuntubug
<bryce_> anyway, we got apport skillz in surplus we can throw at it if it seems like it'd help
<cnd> heh
<bryce_> cnd, yeah not really a template but some boilerplate text
<cnd> bryce_, that's probably what I'm thinking of
<bryce_> I don't know how well read that info is; seems kind of hit or miss whether users follow it
<cnd> I think it would need to be something that would prompt for a the device that is causing issues
<bryce_> at least for X...
<cnd> and then record for that device
<cnd> heh
<bryce_> apport scripts can pop up dialogs to prompt for user selection
<cnd> yeah
<bryce_> cnd, in fact it can even walk them through, like "Okay, now click the button three times and wiggle the mouse..." (sleep 10) "... ok thanks"
<cnd> yeah, that sounds good
<cnd> bryce_, so what do I need to do to make this happen?
<bdmurray> bryce_: bug 724598
<ubot4> Launchpad bug 724598 in xorg (Ubuntu) "apport package hook is too verbose with compiz version (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/724598
<cnd> assuming I don't have the bandwidth to do it myself
<cnd> I would like to do it of course, but I have too many things on my plate already...
<bryce_> cnd, well, for starters lets keep it simple, can you just make like a list of commands that would gather useful files?
<bryce_> from that, I think I can craft a basic apport hook once I've dug myself out from under my current set of tasks
<cnd> I can give that to you right now: lsinput to get a list of devices, and evemu-tools to record the one the user picks
<bryce_> fancy interactive bits can be done later as needed
<cnd> though lsinput doesn't work yet in natty
<cnd> I'm trying to get to that line on my todo list :)
<RAOF> bryce_ could just dch --rebuild "Rebuild against new kernel" and upload.
<cnd> RAOF, no, it needs to be fixed proper style
<cnd> I just need to get the package
<cnd> sync to the latest upstream
<RAOF> Oh, there's a proper style?  Ok :)
<cnd> upstream has fixed the issue once and for all :)
<cnd> and then I should push it to debian
<RAOF> Hurray!
<cnd> and sync it to ubuntu
<cnd> my biggest problem was not being able to reach lp for an hour or so...
<Sarvatt> hrm, where wer tseliot's nvidia/fglrx packaging git trees at?
<bjsnider> http://github.com/tseliot/nvidia-graphics-drivers
<Sarvatt> sweet, thanks
<bjsnider> it's in the control files
<cnd> Sarvatt, that sounds like good news :)
<Sarvatt> ;)
<Sarvatt> RAOF: unity's broken? why do I have to read you say that right after I upgrade? :D
<RAOF> Sarvatt: If the upgrade didn't offer to remove unity, maybe it's fixed? :)
<Sarvatt> oh yeah must be
<Sarvatt> it was just the compiz plugin rename that took an apt-get -f install to fix
<RAOF> Unity's still uninstallable on amd64, but that's much of a muchness.
<Sarvatt> RAOF: thanks for the heads up about isc-dhcp-client, forgot to downgrade and that would have been a head scratcher :)
<Sarvatt> http://www.nvnews.net/vbulletin/showthread.php?t=159990
<cnd> Sarvatt, what's up with isc-dhcp-client?
<cnd> I'm chatting with rydberg, and he's having dhcp problems right now
<cnd> I'm chatting with rydberg, and he's having dhcp problems right now
<cnd> I'm chatting with rydberg, and he's having dhcp problems right now
<cnd> argh
<cnd> sorry
<Sarvatt> kills your net, need to downgrade to the ubuntu3 version :)
<Sarvatt> dog fooding your input stuff there? :)
<Sarvatt> <kees> https://bugs.launchpad.net/bugs/724556
<ubot4> Launchpad bug 724556 in isc-dhcp (Ubuntu Natty) (and 1 other project) "[Natty] isc-dhcp update breaks network connection (affects: 10) (dups: 1) (heat: 56)" [Critical,Fix released]
#ubuntu-x 2011-02-25
<bjsnider> Sarvatt, add the blob for lucid/mav too, k?
<bryce_> bjsnider, he's left
<RAOF> Hah.  Just when you thought that nvidia driver would do us, we get Xserver 1.10 RC3â¦ with a video ABI bump :)
<bjsnider> RAOF, you had better be joking
<RAOF> No, not at all.  Reverting XRandR 1.4, which needs a bit more protocol & code review, which means a video ABI bump.
<bjsnider> i don't find that amusing
<bjsnider> violence must ensue
<bryce_> RAOF, at this point I think we either revert that change or hold off updating xserver and give the binary drivers a chance to catch up
<bryce_> lest we start getting pitchforks brandished our way
<bjsnider> bryce_, i think it's a good idea to wait
<bjsnider> i suppose there are no rules on how many release candidates they'll produce?
<bryce_> there's still time until release to let things shake out, and we can always do cherrypicks from the upstream tree (I imagine there won't be that many patches from here on out)
<bryce_> bjsnider, nope
<bjsnider> is there a final release date?
<RAOF> Yeah; today, from memory :)
<bjsnider> seems like they just do whatever they want and don't give a damn about their users
<kklimonda> any idea where does it come from: http://paste.ubuntu.com/572050/ ?
<kklimonda> with 270.29
<RAOF> That's a bug in the nvidia kernel module.
<RAOF> It looks like it's in an error-recovery path, too.
<RAOF> The first message is âyour card's gone crazyâ, the second is âwoah, the nvidia module did something wrongâ.
<kklimonda> I can't remember last time I've had so much fun during alpha ;)
<kklimonda> oh well, back to nouveau for now - maybe I'll manage to get some logs for the gpu lockup I''ve been encountering for the last few days
<RAOF> Oh, huh?  That's actually killing your graphics, is it?
 * RAOF thought nvidia was generally better at error-recovery than that.
<kklimonda> RAOF: it doesn't kill it
<kklimonda> RAOF: it just locks for a second or two
<RAOF> Ah.  Heh.
<kklimonda> but I've had four locks in 5 minutes ;)
<kklimonda> it does seem related to flash
<RAOF> Well, there's a nice change of pace.  Problems with flashâ½
<kklimonda> maybe the new flash which was supposed to have some kind of gpu acceleration is breaking something
<RAOF> Shocking!
<kklimonda> isn't it?
<RAOF> Flash has had gpu acceleration on nvidia for quite some time, IIUC.
<kklimonda> really? and it still sucks so much?
<RAOF> Apparently it sucks pretty much everywhere?
<kklimonda> well, it's usable on Windows
<kklimonda> (by usable I mean that you can watch 720p without boiling your laps)
<tseliot> tjaalton: did they break the ABI again??? http://www.phoronix.com/scan.php?page=news_item&px=OTEzMA
<tjaalton> yes
<tjaalton> randr-1.4 was removed
<tseliot> this is not good for fglrx and nvidia
<tjaalton> it's trivial for them to fix
<tjaalton> and aaronp was aware of that
<tseliot> I'll talk them, just in case
<tjaalton> we don't have to pull rc3 until they've released newer versions for it
<tseliot> new versions as in new open drivers?
<tseliot> or new X?
<tjaalton> new blobs
<tseliot> ok, this is good to know
<tseliot> as I'm about to upload nvidia
<ricotz> bjsnider, ftp://download.nvidia.com/XFree86/Linux-x86_64/270.29/ :)
<ricotz> tseliot, hi, you are already on update nvidia?
<ricotz> nvm, just saw the upload ;)
<tseliot> ricotz: yep, I uploaded nvidia. I'm working on nvidia-settings now
<ricotz> mhh, i think IgnoredABI might be still needed
<tseliot> have you tried the driver?
<ricotz> with 1.10rc3
<ricotz> no havent tried it, just saw the message in #nvidia
<tseliot> right, that broke the ABI again
<ricotz> yes :(
<bjsnider> ricotz, bryce said they won't be uploading rc3 to natty until amd/nvidia release updates for it
<ricotz> bjsnider, yeah that's reasonable
<bjsnider> tseliot, "#Blacklist some card ids from GRUB gfxpayload=keep" is only appropriate for natty, correct?
<tseliot> bjsnider: yes but it won't hurt since it does "which update-grub-gfxpayload" and works only if this returns true
<bjsnider> tseliot, "#DIRNAME#/libnvcuvid*.so*              #PKGLIBDIR#" is missing from the .install file
<bjsnider> how about just #DIRNAME#/libnv*.so*              #PKGLIBDIR#
<bjsnider> that would cover all of it
<tseliot> let me check
<bjsnider> plus anything else nvidia sneaks in there in the future
<yofel> can someone retry the amd64 build of nvidia 270.29 in natty please? failed with chroot problem
<bjsnider> it's in the links file though. so you're linking a file that doesn't exist
<tseliot> yofel: I might upload a new revision with some changes
<yofel> ah ok
<tseliot> bjsnider: yes, I guess I forgot to put it int the install.in file. Thanks for reporting, I'll fix it now
<bjsnider> tseliot, it looks like all you need to do is shorten line 9
<bjsnider> you could remove line 12
<tseliot> hmm... I'd rather not catch libnvidia-tls
<bjsnider> it's in a subdirectory, isn't it?
<tseliot> it seems to be in two places
<tjaalton> tseliot: "Depend on ${xinpdriver:Depends}", really?-)
<tseliot> tjaalton: no, I don't think so
<tjaalton> that's on your changelog
<tseliot> ${xviddriver:Depends}
<tseliot> so the changelog is wrong
<tjaalton> yep
<tseliot> the control file is not
<jcristau> better than the other way around
<tseliot> definitely
<tseliot> bjsnider: on a second thought, I guess I'll do as you suggested
<bjsnider> why?
<tseliot> that tls library won't hurt
<tseliot> and this saves me some work
<LLStarks> i think vsync might be broken on my machine
<LLStarks> i'm getting tearing during video
<LLStarks> all outputs and players
<cnd> bryce_, why isn't there an evdev-dbgsym package?
<jcristau> because evdev doesn't crash, basically
<jcristau> until now, that is ;)
<cnd> jcristau, but the dbgsym packages should be built automatically in ubuntu
<cnd> and uploaded to ddebs.archive.ubuntu.com
<jcristau> ah.  that.
<jcristau> no idea.
<cnd> hmmm... so the atoms array is failing to be initialized
<bryce_> cnd, yeah I'm wondering the same
<cnd> bryce_, also, that backtrace is rather odd
<bryce_> cnd, I've added to my todo list to look into adding a -dbg for evdev
<cnd> it says the address of an instantiated array is 0x11b
<cnd> which shouldn't be a valid address
<bryce_> bad pointer arith?
<bryce_> ptr = NULL + offset 
<cnd> not that I can think of
<cnd> let me paste the code
<cnd> bryce_, http://pastebin.ubuntu.com/572328/
<cnd> I don't know exactly which XIChangeDeviceProperty call is dying
<cnd> but I know it's one of these two
<cnd> and the address of atoms is wrong when it's called
<tjaalton> bryce_: re -dbg; maybe first ask around why -dbgsym isn't built? getting that fixed is less work (for you :)
<cnd> tjaalton, yeah, I don't think we need a -dbg package
<bryce_>             Atom atoms[pEvdev->num_vals];
<bryce_> is pEvdev->num_vals a variable?  If so, then is ^ valid?
<cnd> the previous line has an if for num_vals > 0
<cnd> so it must be valid
<cnd> and if it's something crazy, like a huge number
<cnd> then I would think it would die allocating it
<cnd> and using it before we get to the crashing function
<bryce_> but I mean, doesn't the C standard require arrays be allocated with const numbers not variables?
<cnd> bryce_, not c((
<cnd> C99
<bryce_> ahh
<bryce_> shows how recently I've read a C book ;-)
<cnd> bryce_, I can't say I've ever really read a C book :)
<cnd> the interwebs are my friend
<jcristau> i think i read k&r when i was 16 or something.  didn't have variable length arrays :)
<cnd> so, assuming I'm not missing something obvious
<cnd> then either he's got hardware issues
<cnd> or he's got a corrupted stack/heap
<cnd> well, the former implies the latter too I suppose :)
<bryce_> well, I'm curious what the length on atoms is
<bryce_> EvdevInitButtonLabels() appears to have some built in assumptions about the minimum length of it
<bryce_> actually no, looks like it's ok
<bryce_> cnd, yeah I don't see anything either
<cnd> bryce_, the other possibility is that maybe XIChangeDeviceProperty is modifying the "value" variable that was passed in?
<cnd> or does the backtrace give the value of the variable as it's passed in unmodified
<cnd> that seems unlikely
<bryce_> yeah I think it shows initial values
<cnd> bryce_, how would it?
<cnd> that would require two copies of the variable
<cnd> one to show the passed in value
<bryce_> hm true
<cnd> and one to be used, and maybe modified, in the function
<cnd> time to take a look at XIChangeDeviceProperty :)
<cnd> bryce_, can't see anything there
<cnd> it's used in exactly one line
<cnd> as the source of a memcpy
<bryce_>             memcpy ((char *) new_data, (char *) value, len * size_in_bytes);
<cnd> yep
<cnd> so the only thing I can think of is that there's stack corruption
<LLStarks> bryce, should i file about the tearing?
<cnd> bryce_, as fta noted in #ubuntu-desktop, this occurred with -1ubuntu6!
<cnd> though the bug occurred elsewhere
<cnd> he says
<cnd> hmmm
<cnd> I'm going to recommend running a daily iso from monday
<cnd> before the new X changes
<bryce_> ok
<cnd> RAOF, can you sync your changes to the x packages to git when you get a chance?
<cnd> I pushed up evdev for you
<cnd> bryce_, it's a bug in pkg-create-dbgsym
<cnd> debian added a new arch "linux-any"
<cnd> but it only looks for "any" and each specific architecture
<cnd> I'll get that fixed up
<bryce_> ah yes the "linux-any" bug
<cnd> is it a known bug?
<bryce_> well, something I keep running into with pbuilder
<cnd> ahh
<bryce_> see deb bug 600823
<ubot4> Launchpad bug 600823 in firefox (Ubuntu) "Flash doesn't work after Firefox 3.6.6 upgrade (affects: 2) (heat: 15)" [Undecided,Invalid] https://launchpad.net/bugs/600823
<bryce_> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=600823
<ubot4> Debian bug 600823 in pbuilder "[pbuilder] Doesnt support "any" wildcards in debian/control" [Important,Fixed]
<bryce_> but that's probably unrelated
<yofel> iirc that's debian bug 363193
<ubot4> Debian bug 363193 in pbuilder "pbuilder-satisfydepends does not support new style architecture specifications" [Important,Fixed] http://bugs.debian.org/363193
<bryce_> yofel, thanks
<cnd> bryce_, if I have a fix for a package and linked it in a bug
<cnd> but it's a package in main
<cnd> do I subscribe ubuntu-sponsors?
<cnd> or some core dev specific team?
<bryce_> ubuntu-sponsors is sufficient
<cnd> I had been wondering for a while if I was subscribing the right team :)
<cnd> I've got dbgsym packages again :)
<cnd> so you can scratch that issue off your todo list
<bryce_> awesome thanks :-)
#ubuntu-x 2011-02-26
<LLStarks> is xvba and vaapi performance equivalent to vdpau?
<LLStarks> bryce_, is shared core mesa on the horizon for ubuntu. it might be worth mentioning to the foundations team that 30mb of cd space will open up.
<LLStarks> err repo space
<DanaG> Say, is magic trackpad supposed to still not do scrolling out-of-the-box?  On Natty, that is.
<DanaG> And how do I get somebody to actually look at this bug, that is NOT a duplicate of the bug it's marked a duplicate of?  Notice the different goals:
<DanaG> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/546697
<ubot4> Launchpad bug 546697 in xserver-xorg-input-synaptics (Ubuntu) "enable multitouch support on older touchpads, as supported by driver v15.0.9.0 (dup-of: 554980)" [Medium,Confirmed]
<ubot4> Launchpad bug 554980 in xserver-xorg-input-synaptics (Ubuntu) "Two finger scroll not working on all old touchPads (emulation approach). (affects: 32) (dups: 3) (heat: 123)" [Medium,Confirmed]
<DanaG> Now, my ideal behavior for the device would be to exactly match what a Windows ClickPad does (once tweaked), minus the suckage:
<DanaG> Finger on left edge: left button.  Finger on right edge: right button.  One finger in each: middle!
<DanaG> So you can middle-drag.
<tjaalton> LLStarks: RAOF wrote the patch, so yes they are aware of it
#ubuntu-x 2011-02-27
<LLStarks> bryce_, xrender works on lucid 10.04.2
<LLStarks> want me to bisect maverick dailies and alphas?
<knittl> hi
<knittl> i cannot install nvidia-current, here's a fresh jockey.log: http://paste2.org/p/1272453
<knittl> i haven't managed to install it for at least three versions of ubuntu
<knittl> logfile was removed before starting jockey and then copied after trying (and failing) to install it
<bjsnider> looks like it did install
<knittl> bjsnider: it pops up a message box, telling me 'failed to install, see log file'
<knittl> and then jockey says 'driver was just disabled, is already in use' or something along that line
<knittl> and when i start jockey again, it says 'a different version of this driver is in use'
<bjsnider> can you pastebin glxinfo?
<bjsnider> and dkms status
<yofel> dkms seems to have built fine from the log, but:
<yofel> 2011-02-27 20:03:34,054 ERROR: update-alternatives: warning: skip creation of /usr/lib32/vdpau/libvdpau_nvidia.so.1 because associated file /usr/lib32/nvidia-current/vdpau/libvdpau_nvidia.so.1 (of link group gl_conf) doesn't exist.
<knittl> bjsnider: yeah, can do
<knittl> bjsnider: http://paste2.org/p/1272461
<bjsnider> yofel, known error message. it is inconsequential
<yofel> ah
<knittl> bjsnider: http://paste2.org/p/1272462
<bjsnider> knittl, can you start nvidia-settings without an error message?
<yofel> why would something inconsequential be logged as "ERROR" though?
<knittl> bjsnider: no, i'm running nouveau atm
<knittl> $ lsmod|grep video
<knittl> video                  18951  1 nouveau
<yofel> knittl: can you pastebin your xorg.conf?
<knittl> $ ls /etc/X11/xorg.conf
<knittl> ls: cannot access /etc/X11/xorg.conf: No such file or directory
<bjsnider> knittl, please install nvidia-current through jockey and reboot
<knittl> no xorg.conf here
<bjsnider> yofel, ask pitti
<bjsnider> it's a logging issue but it's no big deal
<yofel> k
<knittl> should i generate a new xorg.conf?
<knittl> using nvidia-xconfig?
<bjsnider> jockey will do that for you
<bjsnider> you can check before you reboot
<knittl> bjsnider: read 5 lines above
<knittl> there's no xorg.conf
<bjsnider> install nvidia-current through jockey
<knittl> (i'm using natty btw, but this issue has bugged me since nvidia-current was introduced)
<knittl> bjsnider: i did. well, i *tried*
<bjsnider> i don't care if you get an error message
<knittl> bjsnider: i start jockey. i select nvidia-current and click install
<bjsnider> knittl, have you done a wipe and reload since before lucid?
<knittl> it installs, gives an error/warning (you don't care, ok. i wouldn't care if it was a bogus message)
<knittl> i close jockey and there's still no xorg.conf
<bjsnider> it probably is a bogus message
<bjsnider> ok, you can use nvidia-xconfig
<knittl> i think i had to reinstall once, because my root file system was damaged
<knittl> knittl@kbook:~$ jockey-gtk 
<knittl> knittl@kbook:~$ # told jockey to install nvidia-current
<knittl> knittl@kbook:~$ ls /etc/X11/xorg.conf
<knittl> ls: cannot access /etc/X11/xorg.conf: No such file or directory
<knittl> i'll use -xconfig
<bjsnider> ok, create the file yourself and i'll pastebin what should be in it
 * knittl rebooting
<knittl> woohoo, i'm in X
<knittl> with -current
<knittl> but my external monitor is currently ~100 km north
<bjsnider> knittl, are you on i386 or amd64?
<knittl> 32bit
<bjsnider> of course
<knittl> jockey still tries to tell me 'a different version of this driver is in use'
<bjsnider> and can you do glxinfo again?
<knittl> bjsnider: 32bit/i386
<knittl> sure
<knittl> just a sec
<knittl> http://paste2.org/p/1272487
<knittl> nvidia-current has always worked with a single monitor here (laptop screen)
<bjsnider> and you're able to launch nvidia-settings without issue
<knittl> most of the time i had to install it manually with apt-get though
<knittl> yes
<bjsnider> well, i thought this bug had been fixed
<knittl> which bug exactly?
<bjsnider> obviously jockey exited because of meaningless warnings without setting up your xorg.conf and telling you the driver was activated
<knittl> it still believes the driver is not activated
<bjsnider> knittl, the errors on lines 340 and 341of your jockey log would only happen on an i386 system.
<bjsnider> perhaps it's been under the radar because not many people still use i386
<knittl> bjsnider: http://www.thehappy.de/neo/jockey-nvidia-current.png
<bjsnider> jockey's message to you is just a by-product of the real issue
<knittl> jockey does only recognize amd64 drivers? oO
<bjsnider> knittl, sounds like it's bug 552653
<ubot4> Launchpad bug 552653 in jockey (Ubuntu) "[Lucid] Jockey gives message that it failed to install nvidia hardware driver (affects: 49) (dups: 8) (heat: 274)" [Medium,Fix released] https://launchpad.net/bugs/552653
<knittl> i'm subscribed to that bug ^^
<bjsnider> knittl, did you use the nvidia-installer at some point?
<knittl> not since i had to reinstall ubuntu. iirc
<bjsnider> well you should talk to tseliot about this tomorrow
<bjsnider> he'll be here in the morning
<knittl> i've talked to him a lot of times already :D
<knittl> but ok. maybe the day after tomorrow, i won't have much time tomorrow
<bjsnider> about this issue?
<knittl> about jockey failing and about my second monitor not being managed
<knittl> maybe 270 fixes the monitor issue. i don't care much about jockey failing as long as the driver works :D
#ubuntu-x 2012-02-20
<Sarvatt> RAOF: pull the battery on your magic trackpad if you want some fun
<RAOF> X blows up?
<RAOF> I'd love to, if I could get the damn thing to pair.
<Sarvatt> thats "the" big bug in our xserver atm from what i can see, blows up lovely when devices are disconnected
<RAOF> Presumably only touch devices?  My USB mouse is happy to be disconnected.
<Sarvatt> guess so, lots of bugs filed about it and ripping out a magic trackpad is the easiest i've seen to reproduce it from all of them
<Sarvatt> not sure how other people are hitting it
<Sarvatt> ahhhh whot just posted a patch for this bug on xorg-devel https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/921082
<RAOF> Oh, hi!  My touchpad just needed some batteries.
<RAOF> Hey.  What happened to gestures?  Are they still broken?
<Sarvatt> RAOF: think you need cnd's clickpad ppa for now
<Sarvatt> vanhoof was saying cnd gave him his gestures back with the ppa so imagine whatever magic it needs is in there
<Sarvatt> cnd: can you add https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/921082 to your list of crap to shove in the next synaptics update with the clickpad stuff?
<Sarvatt> cnd: or is it ok to just upload synaptics with that patch? just dont want to screw up your ppa or anything you have planned, its a very obvious fix
<Sarvatt> cnd: assigned it to you, but reassign to me if its ok to just patch it and i'll push it to git and find a sponsor asap. I know you're in .cz for the fedora hackfest and aren't here now :)
<cnd> Sarvatt, rats, I just noticed your messages and the patch after uploading a new synaptics
<cnd> I'll upload a second version with the fix
<cnd> thanks!
<tjaalton> cnd: you still use ubuntu+1 branch for -synaptics? :)
<cnd> tjaalton, I never did the switching of branch names
<cnd> RAOF did it for everything
<tjaalton> ok
<cnd> so I just never bothered...
<tjaalton> :)
<cnd> I probably should switch it though
<cnd> RAOF, I believe you are an archive admin
<cnd> if so, would you be able to approve xorg-gtest for me?
<cnd> it was uploaded right before FF :)
<tjaalton> he isn't :/
<cnd> tjaalton, it looks like he is: https://launchpad.net/~ubuntu-archive/+members#active
<tjaalton> just for SRU work or so
<tjaalton> I asked about it last week
<cnd> ahh
<cnd> rats
<cnd> who is an archive admin who can approve new packages?
<tjaalton> jamie did a few reviews for me
<cnd> tjaalton, strandboge?
<tjaalton> riddell as well
<tjaalton> cnd: yup
<cnd> ok
<cnd> I just set up daily builds in a ppa, that will probably be good enough for now
<cnd> I suppose I can wait the process out
<mdeslaur> anybody ever see a mouse position offset when using FGLRX?
<tjaalton> mdeslaur: like when you hit a window against the top bar?
<mdeslaur> tjaalton: like you need to click on a link or a tab, you need to have the mouse arrow slightly over the target instead of on it
<tjaalton> mdeslaur: ah, haven't seen that, although not using fglrx either
<mdeslaur> ok, thanks
<bjsnider> mdeslaur, are you sure that's a fglrx issue?
<mdeslaur> bjsnider: no, I'm not sure it's related
<bjsnider> you could use jockey to switch to the radeon driver for one session to check
#ubuntu-x 2012-02-21
<Sarvatt> damn, forgot about the x11-apps bustage before FF
<Sarvatt> i just just distro patch the current one is the way to go now?
<Sarvatt> there's a bug where there was a typo in the recommends preventing upgrades
<Sarvatt> i updated to new versions for packages in debian git but its not released, was going to sync it but it doesn't look important enough for a freeze exception
<Sarvatt> wow, http://www.bryceharrington.org/Arsenal/Reports/ubuntu-x-swat/totals-precise-workqueue.svg
<Sarvatt> pretty sure https://bugs.launchpad.net/ubuntu/+source/unity/+bug/926379 is hiz fail that might be fixed in mesa 8.0.1, getting a lot of dupes
<RAOF> Sarvatt: Yeah.  Some of those xorg-server bugs shouldn't be on the workqueue; they're protocol requests.
<RAOF> But xorg-server's been gathering no moss :(
<Sarvatt> i'll ask the debian guys if its ok to push 8.0.1 to git in the morning and merge that over, 8.0+ needs some /etc/drirc installation that i dont see in the debian branch yet
<Sarvatt> or else unigine will be busted and our QA runs those unigine benchmarks
<Sarvatt> http://cgit.freedesktop.org/mesa/mesa/commit/?h=8.0&id=b5efe0881ed385de36fa2f4889e1dd962990420a
<RAOF> cnd: Valgrind on the server doesn't appear to point to any smoking-gun; there's some read-after-free in the intel driver, some jump-based-on-uninitialised-values that appear harmlessish, and a whole bunch of ioctl noise, but nothing that would point to memory corruption.
<Daviey> Hola, anyone noticing oddities with multi-touch trackpads?  Selecting text, and left click becoming unusable ?
<bryceh> yeah
<bryceh> Daviey, guessing it's due to the new input stack.  cnd might know more.
<Daviey> bryceh: it's making me cry.
<Daviey> cnd: please help clear my tears.. :)
<bryceh> Daviey, on my laptops when it happens, then generally desktop swapping or rebooting seems to help
<Daviey> bryceh: i find leaving it for 30 seconds resolves it, but it's making my workspeed suck :)
<bryceh> Daviey, mm
<bryceh> Daviey, tell cnd your LP bug #
<Daviey> compiz is using 35% CPU :)
<bryceh> Daviey, well compiz cpu usage != X issue
<Daviey> bryceh: I'm yet to report a bug, as currently it would be "multitouch mouse does weird things".. not even sure what package to report it against.
<Daviey> bryceh: right, i know /that/
<bryceh> Daviey, yes "weird" is an anti-report word, but if it seems specific to MT, then may well be something cnd cares about.
<bryceh> if in doubt, report against 'xorg'
<bryceh> at least that way it'll include the log files an so on we care about.  We're not at all shy about reassigning if we don't think it's an X bug.  ;-)
<bryceh> Daviey, a really useful bit of info would be if you can think back to when the behavior first _started_
<bryceh> coupled with your /var/log/dpkg.log (which 'ubuntu-bug xorg' typically includes), that can help in isolating what package regressed.
<cnd> Daviey, what is your trackpad?
<Daviey> bryceh: sadly, i didn't update granular enough, but certainly within the last 8 days of uploads :)
<bryceh> although I suspect in this case it's going to finger the X server update (which has an even newer input stack)
<Daviey> that certainly was in the apt-get update session of updates..
<bryceh> Daviey, even 8 days can at least bracket it; we don't update X *so* often.
<Daviey> bryceh: xorg was certainly in the session of updates i performed 
<Daviey> bryceh / cnd: bug 937654
<bryceh> Daviey, thanks
<cnd> Daviey, my guess is you have entered "locked drag" mode
<cnd> Daviey, do you have tap to click enabled?
<Daviey> cnd: hmm
<Daviey> cnd: forgive me, but how would i check?
<cnd> Daviey, mouse settings
<cnd> but you should know :)
<cnd> if you tap on the trackpad to perform a click
<Daviey> cnd: i think i tried to enable it last year, but not touched mouse settings since
<bryceh> Daviey, also, you have some obsolete settings in your xorg.conf; try moving aside your /etc/X11/xorg.conf, or at least commenting out the Driver "kbd" and  Driver "mouse" bits.
<cnd> Daviey, the magic trackpad is very sensitive
<cnd> it might be that you are accidentally tapping
<cnd> and when you tap in precise, it locks the mouse button down
<cnd> you have to tap again to release
<cnd> this allows for dragging longer than the size of your trackpad
<Daviey> cnd: yeah, that is the feature i wanted... but not how it was previously.. has it 'improved'?
<Daviey> bryceh: going to move it out of the way
<Daviey> brb
<cnd> Daviey, yeah, I guess it's improved :)
<bryceh> heya cnd
<cnd> bryceh, hey
<bryceh> cnd, glad to be done with the Oregon winter rain?
<Daviey> cnd: right, seems gently tapping left does break out of the mode.. but as soon as i scroll using two fingers, it re-enters the mode.
<cnd> RAOF, did you hit the crash while under valgrind?
<cnd> I have seen an invalid write out of bounds under one valgrind run
<cnd> however, I didn't have the dbg symbols and I've lost the trace and stuff
<cnd> so I'm trying to reproduce, but I haven't been able to
<cnd> bryceh, I have a fix for the random crashers and crashers on disconnect of a magic trackpad
<cnd> it's a clean fix, but it hasn't been exhaustively tested, and I'll be on flights coming home tomorrow
<cnd> I would suggest that I upload it, and if you could watch for any breakage and revert that would be good.
<cnd> what do you think?
<bryceh> cnd, sure sounds good
<cnd> k
<cnd> bryceh, btw, it's a fix in synaptics
<bryceh> cnd, alright, will keep an eye out
<RAOF> cnd: No, I haven't hit the crash under valgrind.
<RAOF> cnd: Oh, I see you've found and fixed it.  Superb!
<sforshee> would it be possible to get someone to take a look at bug 933710? At a fundamental level the problem is caused by the x video drivers not supporting the randr ConnectorType property for outputs, and I'd like to know whether it's likely for this to get fixed in x soon or if the fallback heuristic used by gnome need to be patched.
<RAOF> sforshee: I'll have a look shortly.
<sforshee> RAOF, thanks
#ubuntu-x 2012-02-22
<RAOF> sforshee: Ok.  I'm not entirely sure why libgnome-desktop is trying to use the "ConnectorType" property, because it's a filthy lie; nothing implements it, and I see no reason to expect it to be implemented in the near future (unless we want to; it couldn't be *that* hard âº)
<RAOF> sforshee: Patch libgnome-desktop away!
<jussi> tjaalton: which bot is normally here? 
<jussi> ahh looks like ubot4.
<tjaalton> jussi: can't recall, but sounds familiar-ish
<tjaalton> bug 933710
<ubottu> Launchpad bug 933710 in xserver-xorg-video-intel (Ubuntu Precise) "Laptops with eDP panels do not suspend when lid closed" [Critical,Confirmed] https://launchpad.net/bugs/933710
<tjaalton> yeah, works
<jussi> yup, of course it does :D
<jussi> but when the other one comes back it will double up on things, so one needs to be removed
<tjaalton> so how to kill it?
<jussi> grab a memeber of the irc council, mithrandir or a freenode staffer and get it quieted. or grab me or tsimpson and we will remove one.
<jussi> also, you peoples dont have operators in here - you really need to fix that.
<tjaalton> ok cool
<tjaalton> .)
<tjaalton> :)
 * jussi writes mail. 
<tjaalton> yeah don't think we've ever had
<tjaalton> my memory goes back 5y
<jussi> tjaalton: who are the people here who could do that - I assume they arent needed a lot anyway. but a few is a good idea to have.
<tjaalton> jussi: me, bryceh, RAOF, Sarvatt, cnd for instance
<jussi> ok, Ill zap one of the ircc and get things sorted. 
<tjaalton> maybe some of the more active community ones too
<tjaalton> thanks!
<jussi> tjaalton: Mithrandir isnt around anymore, correct?
<tjaalton> jussi: not working for canonical no
<jussi> ok, thanks. :)
<jussi> tjaalton: AlanBell will sort out the bits and peices (I am not on the IRCC anymore)
<tjaalton> jussi: ok great to see this happen at last..
<jussi> tjaalton: I dont know why we didnt do anything about it when I was on the ircc. :/
<AlanBell> should be all set now (unless I messed it up)
<jussi> AlanBell: any reason you missed an A on tjaalton? :P
<AlanBell> see I said I got it wrong
<tjaalton> :)
<AlanBell> fixed
<jussi> tjaalton: try /msg chanserv op #ubuntu-x tjaalton
<AlanBell> \o/
<tjaalton> whee
<jussi> tjaalton: now try /msg chanserv deop #ubuntu-x tjaalton
<tjaalton> rocks
<jussi> tjaalton: https://wiki.ubuntu.com/IRC/IrcTeam/OperatorGuide
<tjaalton> hmm I think bryceh was there already, since he has set the topic before?
<jussi> nope
<tjaalton> ok..
<jussi> tjaalton: also, "/msg chanserv access #ubuntu-x list" will give you the full list
<AlanBell> we will be doing some fun and interesting classes for new ops in #ubuntu-classroom soon, you might want to tag along with them
<AlanBell> anyhow, I am off out now, laters all o/
<tjaalton> hmm why bryce2 not bryceh?
<jussi> someone probably had the channel set -t or manually opped him
<jussi> tjaalton: /msg nickserv info bryceh
<tjaalton> ah ok :)
<jussi> :)
<tjaalton> the mysteries of irc
<jussi> tjaalton: now you can set a nice topic (the current one is a bit sparse
<tjaalton> hum :)
<tjaalton> maybe later, can't think of a better one yet
<jussi> tjaalton: also, you have ubuntulog here, and that means you need to sort out the t&c's as per here: https://wiki.ubuntu.com/IRC/Bots
<jussi> AlanBell: I dont think tjaalton can actually do that because he has no s flag. 
<jussi> the joys of getting things up to date. 
<tjaalton> t&c's?
<jussi> tjaalton: look at the link ;)
<tjaalton> looking, but what exactly?
<tjaalton> oh the disclaimer?
<jussi> basicallyn says you need to follow the coc and the channel will be logged
<tjaalton> sure
<jussi> however, as I mentioned, I dont think you can use the set command
<tjaalton> ok
<jussi> so we have to wait for AlanBell or someone else from the ircc to sort things a little more. 
<jussi> anyway, carry on, glad its mostly sorted :)
<tjaalton> yeah, thanks
<AlanBell> tjaalton: you now have a +s flag
<tjaalton> AlanBell: thanks
<apw> anyone else seeing an odd lensing or combing effect on the left edge of some characters on atom h/w on precise?
<apw> RAOF, how do i find out what sub-pixel layout is being used ?
<apw> this feels a little like the wrong layout is being used on my atom
<apw> or something odd
<cnd> bryceh, what are your thoughts on the locked drags stuff
<cnd> it's hard to discern if it's a vocal minority who have a problem with it
<cnd> at the same time, if I get the clickpad stuff landed, I can see easily reverting the behavior since it was simply to fix clickpads
<RAOF> apw: Like so many things, you've got two options.  âxrandr --verboseâ will tell you the subpixel ordering the hardware thinks it has, looking at /org/gnome/settings-daemon/plugins/xsettings/rgba-order will tell you what GTK thinks it is.
<RAOF> cnd: The locked drags stuff is the reason why alt-tab sometimes doesn't work for me, right? :)
<cnd> oh wait, I thought beta 1 was tomorrow
<cnd> I see it's quite a ways away
<cnd> RAOF, maybe?
<cnd> RAOF, no, I can alt-tab inside a locked drag
<RAOF> I think the way I use the trackpad I quite frequently hit the draglock; perhaps some apps take out grabs on drag?
<bryceh> cnd, the locked drag doesn't really do it for me, but I can imagine for some people or some use cases it may make a lot of sense
<bryceh> cnd, my druthers would be to have it as a non-default option
<cnd> bryceh, ideally it would be a setting in the mouse prefs
<cnd> unfortunately we're passed UI freeze
<cnd> that's what I wanted to do originally, but ran out of time
<cnd> I'll revert it hopefully as soon as the ffe is granted
<bryceh> cnd, ask for a UI freeze exception
<cnd> bryceh, that would require me to actually find time to develop it
<cnd> I haven't investigated at all, and I have other bugs that are higher prio
<cnd> and a revert of this + clickpad fixes is probably the best option anyways
<cnd> RAOF, were you able to easily trigger the X crash before, and if so has the update fixed it?
<RAOF> cnd: I was not, no.
<cnd> ok
<RAOF> cnd: But, then again, I wasn't actually using a multitouch synaptics device :)
<cnd> hmm...
<RAOF> Rick was hitting that, as was asac; I pointed asac at the new synaptics and it seemed to quiet him? :)
<bryceh> cnd, was this the crash fixed in 0ubuntu3?
<cnd> bryceh, yeah
<cnd> the one I told you about yesterday
<bryceh> right, so, turns out there's been a ton of different crash reports that have come in that seem to be solved with that
<cnd> oh great
<cnd> :)
<bryceh> still got a bunch I'm waiting on people testing, but it looks like it fixed a lot of the recent xserver crashes
<Sarvatt> cnd: hate to pester but do you have 0ubuntu3 locally and just forgot to push by any chance? :P
<cnd> Sarvatt, maybe?
<cnd> I did it late last night in vienna
<bryceh> mesa 8.0.1 looks like it'll solve another good chunk
<cnd> before I slept 6 hours and flew home
<cnd> Sarvatt, so I very well could have forgotten
<cnd> let me make sure
<RAOF> bryceh: Does that include the WriteToClient weirdness?
<Sarvatt> RAOF: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/925341 no synaptics being used
<ubottu> Launchpad bug 925341 in xorg-server (Ubuntu) "Xorg crashed with SIGSEGV in WriteToClient()" [High,Confirmed]
<RAOF> Sarvatt: Quite true.  Boo :(
<cnd> Sarvatt, pushed
<cnd> thanks for noticing that
<Sarvatt> cnd: appreciate it! updated today thinking the fix was in it
<bryceh> RAOF, no, we have more xserver crash bugs beyond these two :-/
<bryceh> and I think the WriteToClient bug may pre-date the synaptics changes anyway, but not sure
<RAOF> bryceh: Oh!  What version of the nvidia driver is that? DBO was seeing some corruption when using FBOs with the pre-295.20 driver that he said eventually took down the server.
<bryceh> that one was 295.10
<bryceh> I'll have them retest, good idea
<bryceh> O rhythmbox why you no love?
#ubuntu-x 2012-02-23
<bjsnider> RAOF, did he report that to nvidia?
<RAOF> bjsnider: I don't know; it's fixed in 295.20, though.
<bjsnider> i'm surprised
<Sarvatt> i think he complained to tseliot who brought it up with nvidia yeah, remember seeing that fly past
<bjsnider> oh, then that makes sense
<Sarvatt> cnd: oh synaptics works with libxtst-dev as a build-dep now?
 * Sarvatt keeps an eye out for random synclient bugs
<Sarvatt> oh whoops i was using origin/debian-experimental synaptics packaging that time
<tjaalton_> ok, so mesa 8.0.1.. I'll merge it this morning
<tjaalton_> guess we don't need an FFe for it, since it's a bugfix release
<RAOF> Indeed.
<RAOF> Mark it as such, and let the uploads fly!
<RAOF> (In the changelog, obviously)
<tjaalton_> yah
<tjaalton> oh right, wayland 0.85 needs to be merged as well..
<tjaalton> bryceh: so I uploaded the wayland 0.85 merge, fyi
<tjaalton> the mesa update is pending, I'll make sure it builds in sbuild first before uploading it..
<bryceh> tjaalton, great thanks for letting me know
<tjaalton> weston needs an FFe
<tjaalton> I'll check the mesa build later once wayland is built. officially on holiday the rest of the week :P
<bryceh> tjaalton, ok.  Anything you need me to follow up on?
 * apw has just had his X server hang in a futex call ... anyone seen anythign like that on precise
<tjaalton> bryceh: well I hope it'll fix at least some of the crashers, the master bug should get closed by the upload
<bryceh> apw, haven't seen anything about futex calls
<tjaalton> still up? :)
<bryceh> tjaalton, yeah :-/
<bryceh> too many bugz
<apw> bryceh, i have had one hang today, and colin has had two, identicle symtoms, total lockup graphically everything looking pristine
<apw> bryceh, mine i found was sitting in a futex call just ... waiting
<bryceh> apw, bugger
<apw> i tried to grab a core, its didn't like that one bit
<bryceh> apw, file bug #'s
<tjaalton> bryceh: oh, they're just bugs, it's nothing personal ;)
<bryceh> zombies eat your brainz, nothing personal ;-)
<tjaalton> ooh, looks like I'm a DM now
<bryceh> tjaalton, grat'z
<apw> bryceh, ok filing a bug is no longer possible as apport is crashing
<bryceh> bleah
<bryceh> apw, what's the error?
<apw> *** glibc detected *** /usr/bin/python: double free or corruption (fasttop): 0x000000000378bf60 ***
<apw> oops
<bryceh> hrm
<tjaalton>   pbuilder-satisfydepends-dummy: Depends: libwayland-dev (>= 0.85.0) but it is not going to be installed.
<tjaalton> wth?
<tseliot> RAOF: any ideas on bug 882916 ?
<ubottu> Launchpad bug 882916 in gnome-settings-daemon (Ubuntu) "Panning doesn't work on Ubuntu 11.10 because the gnome-setting will reset the screen size" [Undecided,Confirmed] https://launchpad.net/bugs/882916
<jcristau> i thought panning just didn't work in 1.11 period?
<jcristau> ah, but 11.10 doesn't have 1.11, nvm
<tseliot> jcristau: it doesn't work at all?
<jcristau> https://bugs.freedesktop.org/show_bug.cgi?id=39949
<ubottu> Freedesktop bug 39949 in Server/Ext/RandR "RandR panning & scaling don't work" [Major,New: ]
<tseliot> jcristau: interesting, thanks for the link
<mdeslaur> does this look like an X issue? imgpaste.com/D9vA.png
<mdeslaur> I've been getting transparent context menus every 10-20 times for the past couple of weeks
<mdeslaur> sorry, proper link: http://imgpaste.com/D9vA.png
<Sarvatt> mdeslaur: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/932813
<ubottu> Launchpad bug 931473 in Compiz Core "duplicate for #932813 Menus don't fully appear" [Medium,In progress]
<mdeslaur> Sarvatt: awesome, thanks!
<Sarvatt> https://bugs.launchpad.net/compiz-core/+bug/931473 sorry
<ubottu> Launchpad bug 931473 in Compiz Core "Menus don't fully appear" [Medium,In progress]
<ricotz> tjaalton, hello
<ricotz> while wayland 0.85 branch should be api stable it seems a good idea to drop the hard dependency creation in rules?
<Sarvatt> ricotz: yeah for sure, see #ubuntu-desktop talk right now
<ricotz> Sarvatt, exactly
<ricotz> Sarvatt, btw i push a new wayland to edgers
<ricotz> *pushed
#ubuntu-x 2012-02-24
<RAOF> Bah.  Stupid overlayfs!  Let me build mesa!
<Sarvatt> RAOF: pfft use schroot
<Sarvatt> it builds fine here
 * Sarvatt totally blames his own lack of using mk-sbuild but oh well, it works
<Sarvatt> soo, instead of blacklisting llvmpipe they will try to fix unity?
<RAOF> Yup.
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/nux/+bug/926859 noticed the responses when i was going through invalid 12.04 beta targetted bugs this morning
<ubottu> Launchpad bug 926859 in unity "llvmpipe software rendering needs blacklisting in unity-support-test" [High,Confirmed]
<RAOF> It is apparently pretty much as easy as not abusing GL.
<RAOF> ie: Actually calling GLXSwapBuffers, rather than trying to blit bits of the backbuffer on the frontbuffer.
<RAOF> Jason apparently has that already done, and it works.
<Sarvatt> works for kvm?
<tjaalton> stgraber's comment is valid
<tjaalton> indeed, it's killing kvm
<RAOF> But that can be trivially worked around by selecting an Ubuntu2D session, right?
<Sarvatt> kvm is the main consumer i would care about, thats problably higher than mgi/savage/etc consumers
<tjaalton> RAOF: yeah, but needs manual intervention :)
<RAOF> How slow is it in kvm?
 * RAOF should give it a whirlygig.
<Sarvatt> if its slow thats ok more worried about not working at all
<tjaalton> it's using 50% cpu
<tjaalton> not that nice on the host
<Sarvatt> oh cool
<tjaalton> hmm, should try it out on the t23 my parents have, but the usb image I have is probably too old..
<Sarvatt> crap but working?
<broder> is kvm enabling all the interesting SSE instructions and so forth within the guest?
 * Sarvatt has 1gb free hdd space, cant even screw with kvm atm
<broder> tjaalton: what happens if you pass, uh, -cpu host
<tjaalton> broder: dunno, stgraber? :)
<RAOF> tjaalton: I guess that depends on what the default experience should be; do we want people, by default, to have the full Unity experience in their virtualised environment at the cost of speed, or do we want people to opt-in to the full Unity for better default CPU usage.
<Sarvatt> yeah if it works its totally another question, would be good to hear from people who care
<Sarvatt> it wasnt working before
<RAOF> Blacklisting llvmpipe would result in people being basically unable to test unity3d in kvm.
<tjaalton> RAOF: true. and could be that a _fixed_ unity might not consume that much cpu when idling..
<broder> bah. my precise iso is about 2 weeks old
<Sarvatt> thats ok nithng changed besides desktop crap
<Sarvatt> nothing changed in llvmpipe at least
<broder> well, i'm having a hard time managing to start a terminal
<RAOF> On unity/llvmpipe?
<broder> yeah
<RAOF> I'm not sure if Jason's fix is in the distro yet.
<broder> i can't tell what's glitch and what's bad performance
<RAOF> But everything should basically be working, barring damage events not necessarily resulting in the screen being updated :)
<RAOF> Which is a pretty big caveat :)
<Sarvatt> good point i have no clue either, living off in the driver world but the unity/compix fixes are important to that :)
<broder> oh! right
<broder> kvm still has the idiocy to make 128M of ram the default
<broder> let's try this again, but this time actually give the VM enough RAM to do anything useful
<broder> ok. kvm -cpu host -m 2048 -cdrom Downloads/my-old-precise.iso
<broder> compiz seems to hover at about 20% CPU when i'm just running top in a gnome-terminal
<broder> but it jumps to 50% or so if i show and then hide the dash
<broder> actually, more like 80% if i do it a few times
<broder> or just drag the gnome-terminal window around a bunch
<RAOF> Yeah, don't show the dash.
<RAOF> It'll try to render a gaussian blur of your whole screen.
<RAOF> That's not fast on anything that's not massively parallel.
<broder> does SSE4.2 not count?
<broder> or whatever other fancy instructions i have in my nehalem
<ricotz> RAOF, hello
<broder> anyway, my gut is that if we'd be using llvmpipe, we should probably switch to unity-2d by default, but it'd be nice if it was still possible to run unity-3d under llvmpipe for the masochists
<broder> i'm not totally sure how i would go about swinging that if i was going to try
<broder> i guess move you could move llvmpipe back to libgl1-mesa-dri-experimental
<ricotz> RAOF, are you planning another mesa upload soon? could you drop the hard-deps-generation of wayland before that?
<RAOF> broder: You'd change the unity-greeter check to start unity2d by default when llvmpipe was present, but not override a manual unity3d selection ;)
<RAOF> ricotz: I'm not planning on another mesa upload immediately; it's beta 1 freeze.  We can certainly do that in the next upload, though.
<ricotz> RAOF, ok, while using wayland releases instead of snapshot it seems reasonable to drop this restriction from the package
<RAOF> I agree.
<tjaalton> yeah I overlooked that part
<ricotz> it only creates issues currently
<ricotz> tjaalton, hi :)
<tjaalton> ricotz: hi, I did notice your ping yesterday, but replied directly to pitti
<tjaalton> shouldn't be an issue anymore?
<ricotz> tjaalton, alright, if you update wayland it will be again
<tjaalton> ricotz: yeah, let's fix mesa first then
<ricotz> tjaalton, ok
<tjaalton> hmm, not sure what needs changing though
<tjaalton> ah it's wayland
<tjaalton>         dh_makeshlibs -V '$(PACKAGE) (= $(V))' -- -c4
<ricotz> yes
<RAOF> Dear autotools: seriously?!
<tjaalton> so they say that 0.9 will be the point where no backwards-incompatible changes will be made anymore, but after 0.85 they still might
<Sarvatt> tjaalton: oh with mesa 8.14? cool
<Sarvatt> basically never, didnt expect any better :)
<Sarvatt> intel guys, living in release+1 forever because who needs anything stable
<tjaalton> Sarvatt: huh? speaking of wayland here. mesa build-depends on wayland, not the other way around :)
<Sarvatt> tjaalton: who does wayland?
<tjaalton> so maybe we need that hard dep until wayland 0.9 is released?
<Sarvatt> dont mind me just complaining
<tjaalton> heh
<tjaalton> ok so we won't drop it ever, thanks for confirming ;)
<Sarvatt> http://paste.ubuntu.com/855094/ according to ricotz though
<Sarvatt> thats what we do in edgers then build wayland against it
<Sarvatt> err build mesa against it
<tjaalton> so build mesa every time wayland is updated?
<Sarvatt> tjaalton: what the hell are you doing here btw?
<tjaalton> writing nonsense as always :)
<tjaalton> I might ask you the same!
<Sarvatt> nah just one time and it doesnt have a hard dependency
<tjaalton> so you don't care about api issues?
<Sarvatt> if theres an api issue mesa gets updated to fix it
<Sarvatt> it wouldnt be an issue in the distro
<Sarvatt> with released versions of wayland and mesa
<Sarvatt> its an issue with mesa master for at most a week at a time
<Sarvatt> especially now that theres released versions, the hard dependecies were for when it was the same version but changing which shouldn't happen anymore
<tjaalton> yeah well we have stable mesa now, so if wayland changes incompatibly and we update it without the hard dep
<tjaalton> oh well
<Sarvatt> and "stable" wayland that wont get touched against in 12.04, we can revisit problems in 12.10 :P
<RAOF> When we're switching to wayland, amiright? :)
<Sarvatt> lol
<Sarvatt> ohyea i forgot
<tjaalton> I'll drop it now so we won't forget
<Sarvatt> it'll be fine if we dont touch it again this cycle but might come up again later, screwing up 100+ packages when we update mesa sucks
<Sarvatt> all because of wayland nothing uses or cares about except mesa
<tjaalton> yeah
<tjaalton> i was surprised that it's so tiny
<tjaalton> where's all the bloat?1!
<Sarvatt> debian/patches/500_pointer_barrier_thresholds.diff duh
<RAOF> ?
<Sarvatt> joking, nowhere near as bad as the old 500 xi2 patch
<RAOF> WE HAVE (mostly, ish) WORKING TESTS FOR 500_pointer_barrier_thresholds!  YAY!
<Sarvatt> RAOF: cool, they test twinview too where the problems always are?
<RAOF> Absolutely!
<Sarvatt> really?!
<RAOF> No, I'm lying.
<tseliot> :)
<Sarvatt> i'm just really surprised considering how much of a hack twinview is :)
<Sarvatt> (and how much dx seems to use it)
<Sarvatt> breaking twinview is like the ultimate no-go, i get guaranteed 10 pings the next morning every time someone does something i have no clue about
<Sarvatt> unity-greeter broke with twinview, ok i obviously broke that
<Sarvatt> or have any clue what happened
<Sarvatt> yeah i'm bitter, oh well :)
<jcristau> "switch to nouveau"
<jcristau> or does that answer not work? :)
<tjaalton> nouveau is seriously lacking on newer hw though :/
<tjaalton> dualhead might work though
<RAOF> Also, power management is a really nifty thing to have.
<Sarvatt> lol power management? how's that nvd0 support coming for year old laptops? 3.5 kernel maybe?
<Sarvatt> at least vesa works in 1.11 still, one benefit to not going to 1.12 in precise
<tseliot> who needs power management anyway? It's nice to have something warm beside you in the winter ;)
<jcristau> tseliot: people on the wrong side of the world
<jcristau> (hi, RAOF)
<jcristau> :)
<tseliot> :D
<RAOF> :P
<Sarvatt> tseliot: whats the weather like where you are now? 22C here in winter, ugh!
<RAOF> Sarvatt: Where are *you* that it's 22C?
<tjaalton> +-0C here
<Sarvatt> lol
<jcristau> we had -10C a couple weeks ago
<Sarvatt> RAOF: i'm in winter
<tjaalton> been kinda wet the past few days, still lot of show
<tjaalton> snow even
<tseliot> Sarvatt: wow, that's warm. It's 11-14 Â°C during the day here
<RAOF> It tops out at 22Cish *here*
<Sarvatt> this is the first winter where i didn't see snow ever
<Sarvatt> only time it snowed was when we were in budapest :)
<tseliot> :)
<Sarvatt> :)? you skipped out on budapest, bah! :)
<Sarvatt> tseliot: are you going to be in orlando?
<tseliot> yes, but at least I got hail twice here ;)
<tjaalton> oakland?
<tseliot> Sarvatt: do you mean Oakland?
<Sarvatt> tseliot: wait, are you moving back to OEM/premium? i havent even asked ya yet
<tseliot> Sarvatt: no, I'm not going anywhere
<Sarvatt> tseliot: yeah totally, i keep calling oakland orlando, whats wrong with me
<Sarvatt> really? ya like it in HWE?
<tseliot> Sarvatt: wrong coast ;). But no, unfortunately I won't be able to attend
<tseliot> Sarvatt: yes, I really like it :)
<Sarvatt> boo, thats 3 you skipped out on in a row! :)
<Sarvatt> X team dinner wont be the same
<tjaalton> oakland auckland.. only a few km apart
<Sarvatt> our crappy cuban sandwiches and guinness :)
<tjaalton> i want to witness tseliot drinking guinness
<tseliot> Sarvatt: yes, well, hopefully I'll be there in October (in Europe, I assume)
<tseliot> tjaalton: oh, you didn't in Dublin. I'll do it again, just for you ;)
<tjaalton> tseliot: :)
<Sarvatt> tseliot: wait you were in dublin? i dont even remember, they had us segreated off to another floor from the desktop guys
<Sarvatt> but we shoulda been near you because you were in OEM then
<tseliot> Sarvatt: I spent quite some time in the Desktop team's room though
<Sarvatt> lucky! you got crap done
<tseliot> Sarvatt: yep :)
<Sarvatt> i think tjaalton got the most done in hwe during that sprint because he was sitting at the boring table :)
<tjaalton> hah
<Sarvatt> updated -ati to work on llano
<tjaalton> oh I did?
<Sarvatt> yup, i remember asking you to do a git snapshot for that reason
<Sarvatt> i was uh
<Sarvatt> playing with minimodem
<RAOF> cnd: Hey, would you be planning to factor out some of the xorg testing fun in utouch-geis and utouch-frame into xorg-gtest?  I'm thinking particularly of the pump event loop thingy, which I want want want right now.
<RAOF> Because stupid async!
<tjaalton> oh I committed some wayland upstream-ubuntu branch
<Sarvatt> sending 2400 baud messages to other pcs in hopes it'd save me from having to press power thousands of times while state got shoved into the rtc
<tseliot> :)
<tjaalton> yeah I remember you playing with it.. funny stuff :)
<Sarvatt> tjaalton: before that i spent 2 months pressing power
<Sarvatt> i was really happy that things might be easier :)
<tjaalton> hm no the funny part was manjos irc msg speech synthesizer
<Sarvatt> lmao
<tjaalton> minimodem was just cool
<Sarvatt> i still screw with him now with the speech synthizer
<Sarvatt> in #hwe say, I don't like vietnamese women.
<tjaalton> rude :)
<Sarvatt> his wife hears it, yeah :)
<Sarvatt> he's rude, it's fun screwing with him
<Sarvatt> tseliot: you're realling going to update wl?
<Sarvatt> i wish we could just sync it from debian
<Sarvatt> is dkms still not used in debian?
<tseliot> Sarvatt: if it doesn't break apw's wireless, then yes
<Sarvatt> tseliot: balls, it broke his wireless in october when you tried
<tseliot> Sarvatt: I'm not sure, I haven't used debian since Etch...
<Sarvatt> probably will break it
<tseliot> (which I still have somewhere)
<tseliot> yes, this is why I asked him to test it
<Sarvatt> yea debian wl uses m-a
<Sarvatt> screw that
<tseliot> :/
<Sarvatt> they keep it up to date really often though
<apw> heh ... i have two machines now which can use wl, one now is supported by the main kernel
<tseliot> so maybe they haven already broken his wireless in Debian ;)
<apw> but this other one still needs it
<Sarvatt> "supported" or supported?
<tseliot> *have
<jcristau> Sarvatt: dkms is used in debian
<Sarvatt> is it?
<Sarvatt> hmmmmmmmmmm
<apw> Sarvatt, one i use for travel, is on the kernel driver 
<apw> and is very good
<jcristau> dunno about wl though
<jcristau> but in general, yeah
<jcristau> i haven't used an oot driver since before dkms existed though :)
<Sarvatt> brcmsmac spams my dmesg at least 1MB a day
<apw> heh that doesn't supprise me :)
<Sarvatt> -rw-r----- 1 syslog adm 9.1M Feb 24 04:50 /var/log/kern.log
<Sarvatt> its all 
<Sarvatt> [29862.537191] ieee80211 phy0: START: tid 1 is not agg'able
<Sarvatt> [29867.905498] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
<Sarvatt> repeat
<Sarvatt> means a lot, thanks broadcom
<apw> there is indeed a lot of debug level crap emitted at too high a level, thats all the sort of thing that being in staging is meant to beat it out of them
<Sarvatt> jcristau: hmm sounds like our brcmwl-kernel-source could be merged to debian to use dkms instead of m-a then
<Sarvatt> m-a is the devil
<jcristau> oot drivers are the devil ;)
<Sarvatt> im fine with it but my wife isn't
<jcristau> but, yeah.
<Sarvatt> yeah thats true too :)
<Sarvatt> automatically building with kernel updates instead of manually rebuilding though..
<jcristau> ack
<Sarvatt> theres a chunk of nics where it has to happen, brcmsmac doesn't cover some crap like macbooks
<RAOF> Dear lord?  Macbooks with poorly supported hardwar?  Now there's a pleasant change of pace.
 * apw enjoyed the juxtaposition of "crap" and "macs"
<Sarvatt> cmacs!
<Sarvatt> 4 people will know what i mean when i call them that next
<Sarvatt> (yes i picked an arbitraty number)
<Sarvatt> tseliot: brcm-wl from october works fine on my machine, where are you updating to?
 * Sarvatt has been manually recompiling against each new kernel
<apw> Sarvatt, i note that the phonetic spelling of that should be see-macs
<Sarvatt> totally x related
<tseliot> Sarvatt: 6.20.55.19
<tseliot> oh, where
<Sarvatt> tseliot: so i had a problem with your same driver in dkms form that i was compiling manually 5 months ago 
<tseliot> Sarvatt: what problem?
<Sarvatt> it didnt work
<tseliot> oh
<Sarvatt> i'll try the new one
<tseliot> thanks
<Sarvatt> they renamed the driver or something
<Sarvatt> i thing that was the issue i had at the time
<Sarvatt> think
<Sarvatt> bah
<Sarvatt> 5 am
<tseliot> unfortunately I don't have a device to test the driver any more
<Sarvatt> really? ok will absoltely test it, grabbing your source from chinstrap
<tseliot> thanks
<tseliot> my netbook died
<Sarvatt> broadcom drivers kill it?
<Lekensteyn> hi, any change that https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/931397 will be fixed before the beta?
<ubottu> Launchpad bug 931397 in xorg-server (Ubuntu) "Xorg crashes with AutoAddDevices "false"" [High,Confirmed]
<jcristau> send a patch?
 * Lekensteyn is downloading the daily image
<Lekensteyn> bryceh: ping?
<Lekensteyn> Any change that 1.11.5 is going to land in Precise?
<cnd> RAOF, yeah, I plan on xorg-gtest being expanded over time
<cnd> the tricky part is that utouch-evemu is under CLA
<cnd> and some people don't like that
<cnd> but maybe they won't notice :)
<cnd> I was at the gtk hackfest, and they said they didn't mind it
<stgraber> tjaalton: I updated bug 926859
<ubottu> Launchpad bug 926859 in unity "llvmpipe software rendering needs blacklisting in unity-support-test" [High,Confirmed] https://launchpad.net/bugs/926859
<stgraber> tjaalton: and I'll bring it up at the release meeting, will also be on the next techboard agenda if llvmpipe hasn't been blacklisted in unity-support-test by then...
<Lekensteyn> Ubuntu' 1.11.4 != Xorg 1.11.4 right?
<technoviking> RAOF: ping
<tjaalton> stgraber: ok, good to know (didn't read the bug yet)
<tjaalton> Lekensteyn: right, the input stack is from 1.12
<Lekensteyn> tjaalton: is that 1.11.99.903?
<Lekensteyn> I saw that the InputOption type has changed between 1.11.4 and 1.11.99.902
<Lekensteyn> so, carelessly copying changes breaks things
<Lekensteyn> it's not a key, value, next struct anymore
<tjaalton> merged from master, more likely
<bdmurray> RAOF: perhaps a hybrid-gfx tag, set by apport, would be useful?  I'm looking at bug 939283.
<ubottu> Launchpad bug 939283 in plymouth (Ubuntu) "[hybrid-gfx] Blank screen on boot due to failure to follow primary framebuffer" [High,New] https://launchpad.net/bugs/939283
<bryceh> Lekensteyn, yeah looks like you need cnd to look at that bug #931397
<ubottu> Launchpad bug 931397 in xorg-server (Ubuntu) "Xorg crashes with AutoAddDevices "false"" [High,Confirmed] https://launchpad.net/bugs/931397
<cnd> bryceh, yeah
<cnd> I'm subscribed or assigned
<cnd> I think it's a bug introduced by backporting
<Lekensteyn> cnd: are you chase douglas?
<cnd> Lekensteyn, yep
<cnd> Lekensteyn, you can use "/whois cnd" in the future :)
<Lekensteyn> true :)
<Lekensteyn> Xorg -configure crashes as well
<bryceh> cnd, from comment #2 wondering if it still needs the bits from that duplicateDevice call, which converts the pointer type?
<Lekensteyn> when debugging I suggest to build with DEB_BUILD_OPTIONS=noopt or gdb will behave weird when setting some breakpoints
<cnd> Lekensteyn, I usually use DEB_BUILD_OPTIONS="noopt nostrip noudev nocheck parallel=<n>"
<bryceh> Lekensteyn, thanks for doing the extra gdb legwork btw, not many do, but it helps a lot.
<cnd> yeah
<cnd> +1 :)
<Lekensteyn> your welcome, I've received some queries about it from users who have an nVidia Optimus laptop model
<Lekensteyn> that needs to be fixed ;)
<bdmurray> bryceh: bug 930004 and bug 930839 are both crashes in xcb during distribution upgrades.
<ubottu> Launchpad bug 930004 in update-manager (Ubuntu) "update-manager assert failure: python: ../../src/xcb_io.c:273: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed." [Medium,Confirmed] https://launchpad.net/bugs/930004
<ubottu> Launchpad bug 930839 in update-manager (Ubuntu) "update-manager crashed with SIGABRT in __assert_fail_base(): Assertion !xcb_xlib_unknown_req_in_deq failed in dequeue_pending_request" [Medium,Confirmed] https://launchpad.net/bugs/930839
<bryceh> bdmurray, looking
<bryceh> heh, like the description in the latter
<bdmurray> yeah, that's a gem
<bryceh> bdmurray, often xcb issues are races in threading behaviors, that can be quite challenging to sort out.  So if there's a set of steps to reproducing it, that'd likely help a good bit.
<bdmurray> bryceh: is this helpful?
<bdmurray> ERROR:root:NvidiaDetection returned a error: __init__() got an unexpected keyword argument 'datadir'
<bdmurray> MarkUpgrade() called on a non-upgrable pkg: 'brasero'
<bdmurray> ERROR:root:Upgrading 'brasero' failed
<bdmurray> [xcb] Unknown sequence number while processing queue
<bdmurray> [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
<bdmurray> [xcb] Aborting, sorry about that.
<bdmurray> python: ../../src/xcb_io.c:273: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
<bryceh> bdmurray, yeah sounding like a client error
<bdmurray> hrm
<bryceh> looking in libx11
<bryceh> "Most likely this is a multi-threaded client and XInitThreads has not been called" sounds relevant (and familiar...)
<bryceh> bdmurray, wonder if it's a protocol mismatch between client app and server?
<bdmurray> oh, like if libxcb updated and update-manager hadn't yet?
<bryceh> something like that's what I'm wondering.  
<bryceh> as you probably already gathered, this fault is happening during the client polling of the X server, and it gets some response it didn't expect
<bryceh> if we knew roughly how to trigger this bug, we could probably set up xtrace between the client and server to see  what the communication is between them
<bryceh> here's the test that seems to be failing:
<bryceh> XLIB_SEQUENCE_COMPARE(req->sequence, >=,
<bryceh>                                        dpy->xcb->pending_requests->sequence)
<bryceh> actually wait, it's not an unknown request but rather an unknown sequence number
<bryceh> not sure what a sequence number is in this context
<bryceh> so not that, but this:
<bryceh> (XLIB_SEQUENCE_COMPARE(event_sequence, >,
<bryceh>                                                   dpy->request)
<bryceh> bdmurray, ok reading further... bunch of warning text regarding threading
<bryceh> bdmurray, ok yeah so I'll paste the text into the bug report
<bryceh> bdmurray, ok I'm finally remembering.  When we first switched to xcb, we had a huge spate of these types of bugs.  libxcb is more sensitive to how it's called in threading conditions, so the client code needs to be careful to make the calls properly
<bryceh> bdmurray, so the assert that's being tripped is not a bug in X but rather is catching a bug in the client code
<bryceh> at least, I think.
<bryceh> I could be talking out of my ass.  That would hardly be new.
<bryceh> bdmurray, ah, so bug 930004 looks like the threading issue I mentioned
<ubottu> Launchpad bug 930004 in update-manager (Ubuntu) "update-manager assert failure: python: ../../src/xcb_io.c:273: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed." [Medium,Confirmed] https://launchpad.net/bugs/930004
<bryceh> bug 930839 may be the mismatched client/server issue I mentioned previously.
<ubottu> Launchpad bug 930839 in update-manager (Ubuntu) "update-manager crashed with SIGABRT in __assert_fail_base(): Assertion !xcb_xlib_unknown_req_in_deq failed in dequeue_pending_request" [Medium,Confirmed] https://launchpad.net/bugs/930839
<bryceh> again though, kinda just guessing here.  Both appear to be client errors that XCB is catching (i.e. both are assertion fails), rather than actual segfaults in X
<bryceh> bdmurray, #901675 is another similar bug in apport
<bdmurray> okay, thanks
<bryceh> another in g-s-d - 833694
<bryceh> hmm
<bryceh> bdmurray, ahh https://bugzilla.gnome.org/show_bug.cgi?id=657255#c8
<ubottu> Gnome bug 657255 in gsettings "gnome-settings-daemon assert failure: gnome-settings-daemon: ../../src/xcb_io.c:575: _XReply: Assertion `!xcb_xlib_extra_reply_data_left' failed." [Critical,Resolved: fixed]
<bdmurray> um, where does that leave us?
<bryceh> bdmurray, can you raise it with the upstream-manager folks to look into?
<bryceh> bdmurray, it's not an X bug
<bdmurray> upstream-manager?
<bryceh> (I mean, aside from the fact that libxcb is sensitive to threading issues...)
<bryceh> update-manager
<bdmurray> ah okay
<bdmurray> bryceh: but in bug 832513 they say it should be fixed in libglib2.0-0
<ubottu> Launchpad bug 832513 in GLib "gnome-settings-daemon assert failure: gnome-settings-daemon: ../../src/xcb_io.c:575: _XReply: Assertion `!xcb_xlib_extra_reply_data_left' failed." [Critical,Fix released] https://launchpad.net/bugs/832513
<bryceh> bdmurray, it's not the same bug, just different codebases making similar coding errors and hitting the same assertion
<bryceh> bdmurray, it'd be like two C applications getting the same error message from gcc; it doesn't mean they have the same bug, nor that gcc is broken, just that they both happened to have the same kind of programming error.
<bdmurray> bryceh: okay, thanks again for the help
<bryceh> bdmurray, sure thing, let me know if you need more help
#ubuntu-x 2012-02-25
<Sarvatt> hmmm, dragging with multiple fingers is insanely faster than dragging with a single finger, and the cursor position loses track of where it really is (cursor is about 1" above the menu bar i'm dragging around)
<Sarvatt> i keep loosing input until i restart unity with these newer synaptics :(
<Sarvatt> cnd: normal that i cant 2 finger click to right click anymore with the clickpad stuff? clickfinger synclient property doesn't change anything unless i disable clickpad
<cnd> Sarvatt, two finger click action is disabled for clickpads
<cnd> it interferes
<cnd> I hope to bring it back later with better heuristics
<cnd> as for the dragging with multiple fingers, are you dragging while the button is pressed?
<cnd> if so, why?
<Sarvatt> because i dont have tap to click turned on?
<Sarvatt> and urg, no right click then?
<cnd> Sarvatt, I think we'll be enabling the right button area by default
<cnd> in the lower right corner
<cnd> Sarvatt, when you are performing a press and drag, are you actually moving more than one touch?
<Sarvatt> yeah i'm sloppy with the touchpad, other fingers end up touching it :)
<cnd> ahh, I'm not sure what to do about that yet
<cnd> this is just one step on the way to really awesome trackpad support :)
<Sarvatt> argh, 5th time i stopped being able to interact with anything until restarting unity, WARNING: failed to get previous touch value
<cnd> hmmm.... still?
<cnd> I thought that was fixed in the latest stuff
<cnd> it likely means a touch grab isn't being released properly
<cnd> I haven't seen the issue, but I don't use a multitouch trackpad a lot
<cnd> Sarvatt, please file a bug about it and assign me
<cnd> I haven't seen anyone else have issues
<Sarvatt> this is with xserver 1.12
<cnd> oh
<cnd> maybe there's some skew between the servers?
<cnd> but there shouldn't be
#ubuntu-x 2012-02-26
<RAOF> bdmurray: Yeah, that's probably a good idea.
#ubuntu-x 2013-02-18
 * mlankhorst waves
<tjaalton> hrm, installing fglrx build-deps removes the lts stack
<tseliot1> tjaalton: I guess it's the build dependency on xserver-xorg-dev (>= 2:1.10.0) that does it
<tjaalton> tseliot1: yeah, not that critical imo, was just building from the upstream package
<tseliot1> tjaalton: oh, I can probably fix that quickly
<tjaalton> it built fine after reinstalling -lts-quantal
<tjaalton> +even
<tseliot1> tjaalton: the upstream installer seems to have a build dependency on libgl1-mesa-glx
<tseliot1> I'm not sure why
<tjaalton> yeah it's weird
<mlankhorst> noon
<mlankhorst> tseliot1: probably so it can override the mesa libgl1 I guess
<tseliot1> mlankhorst: that's a build dependency that was already there when I became the maintainer. We used to divert mesa's libraries at the time
<tseliot1> so, it could be
<hyperair> what are the -lts-quantal packages?
<bryceh> hyperair, that's the LTS backport stack from quantal, which will replace your X stack in precise
#ubuntu-x 2013-02-19
<MCR_> ricotz: Hi :) There is a new AMD Beta Driver out :13.2, Beta 6, to be found here: http://phoronix.com/forums/showthread.php?77884-(19-12-)-AMD-Catalyst-13-2-Beta-6-released&p=313580#post313580
<ricotz> MCR_, oh, a sneaky hidden release?
<MCR_> ricotz, yes - AMD Style release as always ;)
<ricotz> MCR_, will take a look, thanks
<MCR_> ricotz, thanx :)
<ricotz> MCR_, will be available from the ppa soon, make sure to give it a try ;)
<MCR_> ricotz, thanx a lot -> ofc I'll use it ;)
<MCR_> ricotz, upgrading...
<MCR_> ricotz, everything works (as expected). Just ran the Unigine Valley benchmark successfully. \o/ Thanx again :)
<ricotz> MCR_, great
#ubuntu-x 2013-02-20
<Sarvatt> mlankhorst: can you hold off on updating -ati in case you were going to? ppa packages aren't getting built today for some reason and wont be able to rebuild against xserver 1.14
<Sarvatt> mlankhorst: scratch that, they're working now after retrying, all the other uploads in the past 2 hours got dropped
<Sarvatt> tjaalton: oh phew you caught the raring libxi change, got nervous seeing the update :)
<tjaalton> Sarvatt: yeah pitti pinged me about it
#ubuntu-x 2013-02-21
<hyperair> Sarvatt: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1130974
<ubottu> Ubuntu bug 1130974 in mesa (Ubuntu) "mesa_8.0.4-0ubuntu0.3 fails to build on 12.04.2" [Undecided,New]
<tjaalton> ogra_: upstream installed quantal and reproduced the touch bug, hopes to fix it tomorrow :)
<ogra_> YAY !!!
<aissen> Sarvatt: am i right in assuming that cedarview-graphics-drivers was a one-shot thing, in a traditionnal poulsbo fashion ?
<bryceh> aissen, seems so
<Sarvatt> aissen: yes it was, will never be updated again :(
<aissen> ok :-(
#ubuntu-x 2013-02-22
<tjaalton> boo, bug 1131614
<ubottu> bug 1131614 in llvm-3.2 (Ubuntu Raring) "libllvm3.2 3.2-2ubuntu3 upgrade (r600-snapshot.diff) breaks ABI, makes clang emit crashing code" [Critical,New] https://launchpad.net/bugs/1131614
<bryceh> tjaalton, fun
<tjaalton> yep
<mlankhorst> >:(
<tjaalton> can't do anything to it today
<tjaalton> s/to/about/
<bryceh> need any help?
<tjaalton> not sure how urgent it is
<tjaalton> and would like to hear from tstellar first
<tjaalton> ogra_: upstream now has a test case for the touch bug, will be fixed next week
 * ogra_ dances ..... 
<tjaalton> http://cgit.freedesktop.org/~whot/xorg-integration-tests/commit/?h=touch-grab-race-condition-56578&id=51cd9dd2f55f24cbff6b270fcc479a6542bd9ea5
<ricotz> tjaalton, hi, as i said using an independent snapshot of llvm-3.3 svn trunk seems better which won't interfere with llvm-3.2
<tjaalton> ricotz: doko didn't want that..
<tjaalton> besides, -3.2 is fooked anyway
<ricotz> i see
<gema> hey, we are seeing a regression in bootspeed and xorg seems to be the culprit
<gema> from the 9th of Feb to the 13th has gone up from under 6 secs to over 25
<gema> bryce: ^^
<bryceh> gema, oh?  what's the cause?
<gema> bryceh: we seem to have correlated this problem with bug 1124330
<ubottu> bug 1124330 in whoopsie (Ubuntu) "[raring] Latest whoopsie 0.2.13 slows down boot process by 29 seconds!" [Undecided,Confirmed] https://launchpad.net/bugs/1124330
<gema> or suspect it is due to that
<gema> bryceh: but you may want to have a look and make sure
<gema> bryceh: e.g. http://reports.qa.ubuntu.com/bootspeed/machine/1/amd64/
<bryceh> gema, I would be doubtful it would be X; nothing really significant has changed on the X side.  whoopsie seems more plausible.
<gema> bryceh: ok
<bryceh> gema, the bar charts are interesting
<gema> bryceh: good, let us know if you find ways of making them more useful
<bryceh> gema, well, I wonder if the xorg chart is just xorg, or an aggregate of all gui startup.
<bryceh> gema, a link to the Xorg.0.log would be helpful as well
<gema> bryceh: we use bootchart, there are logs here: http://reports.qa.ubuntu.com/bootspeed/machine/1/amd64/raw/
<gema> bryceh: but we can definitely add Xorg.0.log to them
<gema> bryce: I will find out what is included in the xorg bundle, but I am pretty sure it is only xorg, since we have the desktop on a separate bundle
<tjaalton> gema: I've seen that authenticating the lightdm user takes ~20s
<gema> tjaalton: where?
<gema> tjaalton: in our jobs logs or in your machine?
<tjaalton> gema: on my machines
<tjaalton> check lightdm.log
<gema> tjaalton: ack
#ubuntu-x 2014-02-19
<pepee> hi. hi.  is this correct?  http://www.phoronix.com/scan.php?page=news_item&px=MTYwNzU    VDPAU will not be enabled for the radeon driver in trusty?
#ubuntu-x 2014-02-20
<mlankhorst> it was correct at the time of writing :p
#ubuntu-x 2014-02-21
<Sarvatt> RAOF: can you shove libvdpau1-drivers-mesa into universe?
<Sarvatt> its like libgl1-mesa-dri-experimental, dont want it to be supported in any way because its known to be broken (especially on nouveau)
<Sarvatt> i asked on #ubuntu-release but it was accepted into main
<RAOF> Sarvatt: I... don't think I can, actually.
<RAOF> Sarvatt: Or, at least, I'm not sure how to.
<Sarvatt> oh no worries, thought you could because its a mesa package
<RAOF> Nah; I'm not an archive admin.
<Sarvatt> it probably doesnt matter anyway, people will still install it when they read a website telling them to and file bugs when it doesnt work :P
<RAOF> I'd know how to do it if I were accepting it from the queue, but I don't know how to do it post-acceptance.
<Sarvatt> when flash stops working
<RAOF> Heh.
<RAOF> Still totally broken for flash?
<Sarvatt> on nouveau yeah, it needs firmware extracted and is still screwed up with that which is why mlankhorst didnt want to turn it on, but amd complained because it "works" there :)
<Sarvatt> by "works" i mean it advertised mpeg2 support that didnt work until a few weeks ago
<Sarvatt> RAOF: also, miss you in the other channel :)
#ubuntu-x 2015-02-16
<Noskcaj> tjaalton, How is the new documentation going to be installed for wayland 1.7?
<tjaalton> Noskcaj: what do you mean?
<tjaalton> new build-deps looks like
<tjaalton> pushed
<ricotz> tjaalton, hi, create a separate *-doc package for those
<tjaalton> the -dev already had docs
<tjaalton> separate package means NEW
<tjaalton> won't be able to upload before late wednesday
<ricotz> tjaalton, there were no docs until now
<tjaalton> so fix it in the meantime :)
<tjaalton> # Documentation
<tjaalton> usr/share/wayland/wayland.xml
<tjaalton> usr/share/wayland/wayland.dtd
<tjaalton> probably not real docs
<ricotz> dont confuse debian docs with upstream ones
<ricotz> those are dev files
<tjaalton> fine
<ricotz> api/interface definitions
<tjaalton> still needs someone on a real computer to fix those
<tjaalton> I won't do it from my phone
<ricotz> heh, i see ;)
<mdeslaur> is the lts-utopic backported stack supposed to actually work on i386?
<mdeslaur> It seems to work fine on amd64, but on i386 unity won't come up
 * mdeslaur tries on real hardware
<mlankhorst> in theory it should
<mdeslaur> mlankhorst: is the command here complete? https://wiki.ubuntu.com/Kernel/LTSEnablementStack
<mdeslaur> once I do "sudo apt-get install --install-recommends linux-generic-lts-utopic xserver-xorg-lts-utopic libgl1-mesa-glx-lts-utopic", I can't log back in
<mlankhorst> nah
<mlankhorst> can you give the output? :P
<mdeslaur> let me try on -intel
<mlankhorst> there should be some egl libs in 'recommended' that don't get installed
<mdeslaur> ok, one sec, I'll reset my vm
<mdeslaur> I'm not sure why it works on amd64 though
<mlankhorst> no idea, utopic -> trusty is slightly harder because egl is starting to be used
 * mlankhorst resets his 32-bits chroot
<mdeslaur> mlankhorst: http://paste.ubuntu.com/10256291/
<mlankhorst> oh...
<mlankhorst> where is geode?
<mlankhorst> Recommended packages:
<mlankhorst>   libegl1-mesa-drivers-lts-utopic
<mlankhorst> that one's missing :P
<mlankhorst> it's temporary, vivid shouldn't have that package any more
<mlankhorst> try to add it and most of ubuntu-desktop shouldn't get removed any more
<mdeslaur> ok, one sec
<mlankhorst> yeah, only getting the correct packages removed after
<mlankhorst> it's in Recommends, but for some reason the resolver doesn't install it...
<mdeslaur> huh, weird...why isn't the --install-recommends doing it...
<mlankhorst> because we're stressing everything hard :P
<mdeslaur> mlankhorst: hrm, I suspect people will get burned by this :P
<mdeslaur> mlankhorst: can you add it to the wiki?
<mlankhorst> sure
<mlankhorst> in theory xserver-xorg-lts-utopic libegl1-mesa-drivers-lts-utopic is enough but meh 
<mdeslaur> hrm, unity still isn't coming up
<mlankhorst> *tries*
<mdeslaur> ubuntu-desktop still wants to get removed
<mlankhorst> I'm fairly sure I at least smoke tested unity
<mlankhorst> ugh it shouldn't..
<mlankhorst> log?
<mdeslaur> http://paste.ubuntu.com/10256449/
<mlankhorst> oh xserver-xorg gets removed too
<mlankhorst> hm though xserver-xorg-lts-utopic gets installed, which should be fine
<mlankhorst> mdeslaur: apt-cache policy xorg ?
<mdeslaur> http://paste.ubuntu.com/10256464/
<mlankhorst> yeah... 
<mlankhorst> looks like xorg ubuntu8.1 is still in -proposed..
<mdeslaur> d.oh
<mdeslaur> aren't we supposed to be working on the point release today?
<mdeslaur> I'll ping infinity in #ubuntu-release
<mlankhorst> no idea, I guess xorg didn't get promoted
 * mdeslaur adds -proposed and tries again
<mlankhorst> on a positive note it shouldn't be able to crash if only xorg and ubuntu-desktop are missing
<mdeslaur> yeah, that's probably something else
<mdeslaur> let me upgrade from -proposed and try unity again
<mlankhorst> only upgrading xorg from -proposed should be enough
<mlankhorst> mdeslaur: fwiw it worksforme on intel
<mdeslaur> unity in my vm still won't come up...trying on intel now
<mdeslaur> mlankhorst: ok, works on intel for me also
<mlankhorst> mdeslaur: do you override -cpu in your vm perhaps?
<mdeslaur> I don't think so
<mdeslaur> well, it's i686 on a amd64 host
<mlankhorst> cat /proc/cpuinfo in the vm?
<mdeslaur> http://paste.ubuntu.com/10256739/
<mlankhorst> yeah thought so..
<mdeslaur> oh? what's wrong?
<mlankhorst> llvm 3.5 deprecated autodetect, it now bases it on the cpu type
<mlankhorst> but it doesn't know about QEMU Virtual CPU'
<mlankhorst> so it disables sse, sse2.
<mlankhorst> Mesa llvmpipe however uses /proc/cpuinfo
<mlankhorst> so it generates sse2 instructions that llvm doesn't support in the autodetect cpu configuration
<mdeslaur> hrm, but my utopic vms work
<mlankhorst> what's the /proc/cpuinfo in those? :P
<mdeslaur> oooooh
<mdeslaur> model name	: Intel Xeon E312xx (Sandy Bridge)
<mdeslaur> huh
<mlankhorst> native
<mdeslaur> cool, thanks for the hint
<mlankhorst> I had a patch at some point to add some flags, but it was incomplete and pitti fixed his vms so I no longer cared :P
<mdeslaur> hehe
#ubuntu-x 2015-02-17
<micahf> hi, i'm having trouble with multi-touch in chrome.  two finger gestures (sorta) work, but i can't get multiple touch events!
<micahf> i have a tablet laptop (lenovo x220)
<micahf> i used to be able to get multiple touch events in ubuntu 13.10 with an acer w700 tablet
#ubuntu-x 2015-02-18
<smallfoot-> Vivid is getting Wayland and Weston 1.7?
<smallfoot-> It is getting xserver 1.17?
<smallfoot-> I read on Phoronix that GNOME really improved Wayland support in Mutter
#ubuntu-x 2015-02-19
<tjaalton> mlankhorst: do you have mesa rc1 merged to ubuntu+1 locally? I need to test a few patches for skl
<tjaalton> and then push later if good, so would prefer the real branch for it
<tjaalton> I'll push wayland without -doc
<tjaalton> wth, so upstream only does .xz then
<tjaalton> means the source package is native
<tjaalton> oh well
<mlankhorst> tjaalton: yeah sec
<mlankhorst> oh not in ubuntu+1 yet
<tjaalton> if it'll be in vivid then maybe push straight to ubuntu
<tjaalton> branch
<mlankhorst> yeah but we'd have to upload today then :P
<mlankhorst> so could you hurry?
<tjaalton> me hurry?
<tjaalton> I can upload yes
<tjaalton> and test skl later
<mlankhorst> ok pushed to ubuntu branch
<tjaalton> don't see it
<mlankhorst> meh git push is hanging..
<tjaalton> heh
<tjaalton> alioth being slow again
<tjaalton> soon we can use lp for the ubuntu branches :)
<tjaalton> if it works any better
<mlankhorst> doubt it :P
<tjaalton> "soon", no idea
<tjaalton> when
<mlankhorst> it just adds another point of  failure, tbh..
<tjaalton> yeah could be
<tjaalton>  08:25:42 up 21 days, 20:30,  5 users,  load average: 29,76, 40,25, 33,30
<tjaalton> moszumanska..
<mlankhorst> owwie
<tjaalton> been like that for some time now
<mlankhorst> oh it pushed now
<tjaalton> good
<jcristau> alioth gets bogged down every morning due to cron.daily i think
<jcristau> so it's painful for an hour or two
<tjaalton> ah
<mlankhorst> can't it run at a lower (cpu/io) priority? like idle :P
<jcristau> dunno
<smallfoot-> Yay, Wayland 1.7 along with Weston 1.7 and Mesa 10.5 just hit the repo :)
<smallfoot-> I hope X 1.17 hits the repo too soon
<mlankhorst> we don't have fglrx yet :(
#ubuntu-x 2016-02-23
<alkisg> Hi, I have a program that broadcasts the teacher screen to students, how can I notify xorg that the students' PCs are not "idle" so that their screensaver doesn't get activated?
<alkisg> Or, in other words, is there a way to reset xorg screensaver/dkms timers?
 * alkisg checks if `xset s reset` is what he's looking for...
<alkisg> Ah, xdg-screensaver reset, nice
<marlinc> The issues I was having with NVIDIA on my laptop with hybrid graphics has been resolved
<marlinc> Not sure what exactly fixed it but I tried again yesterday and now it works
<marlinc> Of course there have been a lot of updates in between then and now :)
<tjaalton> but not using the staging ppa?
<marlinc> Nope
<marlinc> Wait
<marlinc> I haven't tested on the staging API
<tjaalton> right, it should break
<marlinc> If you want I can try to see what happens when I boot over to the install with the staging PPA
<tjaalton> no need
<tjaalton> I know it breaks
<marlinc> Okay ;)
<marlinc> Want me to close the bug report on Launchpad?
<tjaalton> go ahead
<gsedej_work> marlinc, i have laptop with hybrid graphics. Were you able to solve problem? I had to "apt-get puge nvidia-355" and install again
<ricotz> tjaalton, hi, my ironlake doesnt like your +bpo2
<tjaalton> ricotz: oh, how come?
<ricotz> tjaalton, it hard-froze on startup, reverted back to plain -7.22 (needed the laptop)
<ricotz> I assume it hang on initializing gdm (gnome-shell)
<tjaalton> ricotz: you had -extra too?
<ricotz> tjaalton, of course
<tjaalton> had to ask :)
<tjaalton> add a note to the bug
<ricotz> tjaalton, have you checked some older generations?
<tjaalton> so it won't get pulled yet
<tjaalton> bdw
<ricotz> I guess I can try 4.5rc5 (which isnt that bleeding edge compared to your build)
<tjaalton> actually i didn't try this version, but will test it soon
<ricotz> if there was a ~bpo1 I didnt got it
<ricotz> tjaalton, is support for Iris 540 (i7-6560U) already included in the official archive
<ricotz> (ironlake looks fine on 4.5rc5)
<tjaalton> ricotz: if it's one of the newest pciid's, then maybe not
<tjaalton> but it will
<tjaalton> kernel and mesa don't have it
<tjaalton> ricotz: yup, bpo2 broken on bdw too, should be easy to figure out what it was..
<tjaalton> ricotz: lol! i wonder how that kernel built without drm/i915/intel_display.c :P
<tjaalton> also, what the hell happened to it
<tjaalton> heh, git fail
<tjaalton> git usage fail to be precise
<tjaalton> if there's a merge conflict and you don't add the conflicting file, it'll get removed..
<ricotz> tjaalton, seems to be available in 11.1 already :) -- "include/pci_ids/i965_pci_ids.h:CHIPSET(0x1923, skl_gt3, "Intel(R) Iris Graphics 540 (Skylake GT3e)")
<ricotz> tjaalton, hehe. quite some fail ;P
<tjaalton> but not the only fail, it still hangs
<ricotz> tjaalton, is this suppose to get the official kernel?
<tjaalton> eventually
<ricotz> I assume you are targetting to backport the proposed 4.6 intel-stack?
<tjaalton> there are just three commits that could
<tjaalton> 've broken it
<tjaalton> something 4.6-ish
<tjaalton> like last time it was 4.2-ish
<ricotz> I see
<tjaalton> first iteration worked on bdw too, then rebase to -02-14 needed a few commits to drm core which broke it
<tjaalton> so now I'll test reverting stuff from the _bpo instead to see which one of the three it was
<ricotz> good luck!
<tjaalton> it just takes time
<ricotz> tjaalton, you should request some more space for the ppa ;)
<tjaalton> is it full?
<tjaalton> seems so
<tjaalton> kernel blew it :)
<tjaalton> makes no sense, after all reverts it still fails
<tjaalton> oh well
#ubuntu-x 2016-02-24
<mamarley> tjaalton: Your kernel somehow even manages to bust my system with an NVIDIA graphics card. ;p
<mamarley> sddm segfaults
<tjaalton> huh, i deleted it already
<mamarley> tjaalton: I installed it earlier but never got around to rebooting until later.  It is no big deal.  I break my systems all the time and this wasn't at all hard to fix.
<tjaalton> yeah i'm bisecting it now, and there's something in -7 that breaks it, -4 was fine
<tjaalton> i mean some conflict with -7 and my changes, which were fine on -4
<soee> do you plan to package: http://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-Second-Vulkan-Driver
<tseliot> yes, not today though, I'm busy with other work
<soee> ok, thank you
<tjaalton> ricotz: kernel fixed, I'll push a new version to the ppa
#ubuntu-x 2016-02-25
<tjaalton> pushed mesa 11.2.0-rc1 to ppa:tjaalton/ppa
<alkisg> Hi, is xserver-xorg-lts-wily supposed to be installable in 14.04/amd64? Its dependencies are not satisfiable here... (a long list)
<tjaalton> see the wiki on lts kernels
<tjaalton> it needs a special command to pull in all that's needed..
<alkisg> Ah, thanks, looking...
<alkisg> sudo apt-get install --install-recommends linux-generic-lts-wily xserver-xorg-core-lts-wily xserver-xorg-lts-wily xserver-xorg-video-all-lts-wily xserver-xorg-input-all-lts-wily libwayland-egl1-mesa-lts-wily 
<alkisg> ...doesn't do it for me either
<alkisg> I also removed all my custom sources.list, in case the interfered, they didn't
<tjaalton> what does it say?
<alkisg> Maybe the problem is related to me having installed the -lts-vivid ones first?
<tjaalton> likely
<alkisg> Let me paste both the apt-get and aptitude outputs, as apt-get is vague
<tjaalton> need to revert to stock packages first
<alkisg> http://paste.ubuntu.com/15197494/
<alkisg> (apt-get)
<alkisg> OK, reverting, thank you...
<alkisg> That was not the case in 12.04 btw
<alkisg> It was possible to e.g. install 12.04.3 and upgrade to 12.04.4
<tjaalton> don't think i've even tried a direct upgrade
<tjaalton> maybe wiki is missing some pkg
<alkisg> Meh downgrading also has issues :-/
<alkisg> Digging deeper...
<alkisg> My xorg-vivid installation line was: http://paste.debian.net/403581/
<tjaalton> that command works on a trusty chroot
<alkisg> I'm guessing the xorg-vivid package pulled some things that apt doesn't know how to get rid of now
<tjaalton> do you have some dev pkgs installed?
<tjaalton> guess that's not the issue here tho
<alkisg> http://paste.debian.net/403583/
<tjaalton> right
 * alkisg tries it partially, first installing linux-generic, rebooting, removing linux-*lts-vivid and then going on to xorg
<tjaalton> the error looks familiar, though I can't remember what it could be..
<tjaalton> the kernel is totally separate iirc
<tjaalton> at least there should be no conflicts
<tjaalton> oh, haha. the chroot has no X by default
<alkisg> :)
<alkisg> tjaalton: my bad, the second command (multiarch) did it
<alkisg> Maybe it's related to wine pulling wine:i386
<tjaalton> might be
<tjaalton> looks like wily installs fine over vivid, at least on the chroot
<tjaalton> so the revert to stock was just for robustness testing
<tjaalton> not actually needed
<alkisg> Got it, thanks a lot tjaalton :)
<tjaalton> I should install sudo on all chroots.. .)
<tjaalton> :)
<tjaalton> schroot rocks
<alkisg> Unrelated, will we ever be able to install the nvidia* drivers and fglrx* drivers in a system, and only have them loaded when they detect an actual nvidia or fglrx card?
<alkisg> It's been a long standing wish of ltsp users :)
<tjaalton> fglrx is gone
<tjaalton> finally
<tjaalton> 16.04 won't have it
<alkisg> Ah, that's one good thing!
<tjaalton> libglvnd will happen once redhat (ajax) makes it work
<tjaalton> then you can have nvidia and mesa installed
<tjaalton> or something like that
<alkisg> Finally! :)
 * alkisg wishes he'll see that in 18.04
<tjaalton> and vulkan was designed with this in mind
<tjaalton> I guess we can have it backported, it's just one library
<alkisg> If it goes in some lts* stack for 16.04, even better!!!
<tjaalton> yeah ajax has said he'll look into it in the coming months
<tjaalton> so maybe 16.10 timeframe, maybe not
<alkisg> Thank you tjaalton, rebooting to the newer -wily stack... :)
<tjaalton> yw
<alkisg> All good! Purging the -vivid kernel...
<marlinc> Mmm tjaalton not sure why the crashes are happening again
<marlinc> It only happens when I move my second screen from the default location on the right to the left
<marlinc> That's what happened before as well
<marlinc> This is the monitors.xml config that causes it to happen, not sure what's so special about it: https://gist.github.com/Marlinc/e4cde9f72b600ca32197
<tjaalton> marlinc: feel free to test ppa:canonical-x/x-staging now, it works with nvidia prime
<marlinc> Okay, will do that ;)
<marlinc> Okay, this might be a bit unfair as I have a ton of updates that I got to install but lets see what happens
<marlinc> It appears to work tjaalton 
<marlinc> Any time frame on the stuff arriving in main and universe?
<marlinc> Need me to do some more testing?
<tjaalton> early next week
<marlinc> Anything you'd like me to test tjaalton? If not I'll reboot, thanks a lot :)
<tjaalton> if it works then fine
<tjaalton> that's enough for me
<marlinc> Okay :)
#ubuntu-x 2016-02-26
<CapsAdmin> i'm trying to get vulkan working on a laptop with hd graphics 5500 and i tried using the ppa but when running the examples it says it's missing DRI3
<CapsAdmin> oh... nvm i see what i need to do now 
<CapsAdmin> i added an xorg conf that enables dri3 but now i'm getting undefined symbol _mesa_sha1_ when trying to run the examples from terminal
<tjaalton> CapsAdmin: hmm, i should have pushed a new version of mesa-vulkan-drivers which fixes that.. what version do you have?
<tjaalton> ..20160222-0.2
<tjaalton> should work
<caps_> are there logs for this channel? i asked about intel vulkan drivers under the nickname CapsAdmin
<tjaalton> 20:19 < tjaalton> CapsAdmin: hmm, i should have pushed a new version of mesa-vulkan-drivers which fixes that.. what version do you have?
<tjaalton> caps_: ^
<tjaalton> hmm weird, hand-built one works but ppa build does not
<tjaalton> so yes, that's broken until i have time to fix it
#ubuntu-x 2016-02-27
<CapsAdmin> tjaalton, thanks. i'll just wait for them to update from mesa
#ubuntu-x 2017-02-23
<ricotz> jcastro, hi :), did you act on the gpu ppa description change?
<ricotz> mamarley, hi ^
<mamarley> No, I haven't changed the description.
<ricotz> this change request is wrong and misleading
<ricotz> I have changed it back
<ricotz> e.g. Geforce 405 is a GT216 card and only works with nvidia-340 afaik
<ricotz> there are no GT3xx gpus
<jcastro> ricotz: I did, sorry I should have replied all
<jcastro> he sent a correction email afterwards, not sure if you saw that
<ricotz> jcastro, hi, I saw, those numbers are referring to the GPU chips, not the GeForce Series
<jcastro> oh ok
<ricotz> for the later series that would be GF1xx GK1xx GM1xx and so on
#ubuntu-x 2018-02-20
<mamarley> tseliot: What's the plan for how to handle nvidia-340 with GLVND-enabled Mesa?
<tseliot> mamarley: I think I'll use diversions for libGL.so*, and xorg.conf.d snippet for libglx.so. I haven't played with it yet. I think I'll look into it tomorrow
<mamarley> tseliot: OK, thanks!
<tseliot> np
<tseliot> mamarley: BTW hybrid switching with 390 is not going to work in bionic until this is fixed https://github.com/systemd/systemd/issues/6908
<tseliot> I need to test the new systemd in bionic, to see if it solves the problem
#ubuntu-x 2018-02-24
<ricotz> tjaalton, hi, this solves my issue with mesa multi-arch https://launchpad.net/~ricotz/+archive/ubuntu/experimental/+sourcepub/8814448/+listing-archive-extra
<tjaalton> ricotz: file a bug and i'll sponsor it
<tjaalton> better if on the debian pkg
#ubuntu-x 2019-02-22
<alkisg> Good morning everyone! The following card only works with "nomodeset" in 18.04, even with 4.20 kernel, any ways around it?
<alkisg> 38:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] [1002:15dd] (rev c6)
<alkisg> Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Vega [Radeon Vega 8 Mobile] [1002:15dd]  Kernel modules: amdgpu
<alkisg> I also tried the x-swap ppa, with no noticable changes
<alkisg> Hmm, I didn't try xserver-xorg-hwe-18.04, would that help?
<tjaalton> no, since it's a kernel bug?
<tjaalton> alkisg: what's the exact issue?
<alkisg> tjaalton: the school reports black screen with the default settings, and limited resolutions with nomodeset
<tjaalton> try amdgpu dkms from the amdgpu-pro tarball
<alkisg> I thought the card was too new and it would need a newer kernel or something, so I tried -hwe first and 4.20 after, with no changes
<tjaalton> i have a laptop with vega 8 mobile and it works fine
<tjaalton> so it's not a generic failure
<alkisg> Thank you, will do when the school contacts me again
<alkisg> Gotcha
<tjaalton> works with stock bionic too
<tjaalton> if the dkms is still busted, it's best to file a bug upstream too
<tjaalton> or you can build the kernel using https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-18.50
<tjaalton> q
<tjaalton> uh
