[00:00] <bryceh> RAOF, offhand I'm thinking stick with debian even though it'd cause a mass rebuild
[00:01] <RAOF> That was my thinking.
[00:01] <bryceh> just on the thought that doing that pre-FF is probably going to be easier than having to do it post-FF
[00:01] <RAOF> Yup!
[00:01] <cnd> RAOF, bryceh: is the input-abi like that too?
[00:02] <RAOF> cnd: Yes.
[00:02] <bryceh> plus we gotta test the script we did last time ;-)
[00:02] <Prf_Jakob> Oh X people here, how do I disable the unhelp full restart X server after the GPU has crash feature in Ubuntu?
[00:02] <cnd> that could be annoying if we need to change the xi 2.1 abi
[00:02] <bryceh> Prf_Jakob, huh?
[00:03] <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
[00:04] <bryceh> "The thing" == "gdm"
[00:04] <Prf_Jakob> I would guess so yes.
[00:04] <bryceh> "helperscreen" == "failsafex" which is in /etc/gdm
[00:04] <Prf_Jakob> cool thanks!
[00:05] <Prf_Jakob> btw any of you guys in London?
[00:10] <RAOF> None who are awake now, I think :)
[00:10] <Prf_Jakob> heh :)
=== solarion_ is now known as Solarion
[00:51] <cnd> RAOF, bryceh: what do you do when debian git has a new version of package, but it's unreleased
[00:52] <cnd> do you rebase onto the last released package commit?
[00:52] <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.
[00:52] <cnd> well, it's just a lintian standards bump :)
[00:52] <cnd> so I think that's a no :)
[00:54] <RAOF> Then merge from whatever the tag is; Debian's ususally pretty good at tagging the uploads.
[00:54] <cnd> yeah
[01:02] <bjsnider> is it true that the x-server 1.10 abi didn't stabilize until after rc2?
[01:08] <RAOF> After RC1, yes.
[01:08] <RAOF> I don't believe there have been any ABI breaks post-rc2
[01:09] <bjsnider> well, i find that very difficult to understand
[01:10] <bjsnider> shouldn't a release candidate be considered stable?
[01:10] <bjsnider> just maybe with the odd bug here and there, kind of thing?
[01:12] <cnd> bjsnider, x.org bends the definition of rc really
[01:12] <cnd> instead of having alpha, beta, rc, release
[01:12] <cnd> they just have a series of rc's and then a release
[01:13] <cnd> to x.org, rc seems to be just an arbitrary abbreviation
[01:13] <bryceh> unfortunately
[01:13] <bjsnider> well, let me register this for the record: i think that stinks.
[01:26] <cnd> bjsnider, I had thought the abi freeze was at the merge window closure
[01:26] <cnd> but apparently that wasn't the case
[01:26] <cnd> I think the window needs to be slammed harder next time :)
[01:27] <cnd> the release manager needs to be like torvalds :)
[01:27] <bjsnider> i suppose
[01:37] <cnd> almost done...
[01:41] <cnd> RAOF, I've got stuff ready
[01:42] <cnd> do you want me to push to git.debian.org?
[01:42] <RAOF> Yes please.
[01:42] <RAOF> Oh, actually!
[01:42] <cnd> I'm still here :)
[01:42] <RAOF> Now.
[01:42] <RAOF> Just pushing up a local commit.
[01:42] <cnd> commit to what?
[01:43] <RAOF> xorg-server
[01:43] <cnd> ok, let me know when you're done
[01:43] <RAOF> It's done.
[01:43] <cnd> ok
[01:43] <RAOF> I guess the other option would have been to pull --rebase it.  Eh.
[01:43] <cnd> well, that's what I'll be doing :)
[01:43] <cnd> one of us had to do it
[01:46] <cnd> ok, I'm going to push now
[01:46] <cnd> oh wait, I should test rebuild the server just to be sure...
[01:46] <cnd> since you added a patch
[01:46] <cnd> it'll only take 15 mins
[01:48] <RAOF> K.
[01:50] <cnd> RAOF, do you have any mt devices?
[01:50] <RAOF> No.
[01:50] <cnd> I was hoping I could get one more tester before the push :)
[01:50] <RAOF> unless a synaptics touchpad counts :)
[01:51] <cnd> but please, smoke test it to ensure pointing continues to work well
[01:51] <cnd> I only publicly made the packages available today
[01:51] <cnd> and I think only myself and henrik tested them :(
[01:52] <cnd> and he found a bug that I spend half of today fixing
[01:52] <cnd> but it wasn't a crasher
[01:54] <cnd> anyways, build looks good
[01:54] <cnd> I'm going to push stuff to git now
[01:54] <RAOF> K.
[01:56] <cnd> RAOF, it's alright if I overwrite an old stale ubuntu branch
[01:56] <cnd> like in x11proto-input
[01:56] <cnd> ?
[01:56] <RAOF> Yup.
[01:56] <cnd> ok
[01:57] <cnd> no need to rename it to something else?
[01:57] <cnd> I guess it still has a git tag
[01:57] <cnd> or should have a git tag
[01:57] <bryceh> cnd, some of those stale branches got abandoned once the package reached a state where we could sync it
[01:57] <cnd> yeah
[01:58] <cnd> RAOF, git is updated
[01:59] <RAOF> Awww, coordinations to windows is gone :)
[01:59] <cnd> xorg-server, x11proto-input, xserver-xorg-input-evdev, xserver-xorg-synaptics, and libxi
[01:59] <cnd> :)
[01:59] <cnd> I think you'll find a way to live without
[02:01] <cnd> RAOF, stuff is officially handed off to you :)
[02:01] <cnd> I am going to go have a life for the rest of the night :)
[02:08] <bryceh> yay, wayland good to go
[02:09] <bryceh> even works on radeon :-)
[02:29] <RAOF> Yay natty-tmpfs-local schroot.
[03:23] <bryceh> \p/ wayland now uploaded to natty universe
[03:27] <RAOF> Sweet!
[03:34] <bryceh> subject: [ubuntu/natty] wayland 0.1~git20101129.ac93a3d3-0ubuntu1 (New)
[03:36] <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.
[03:36] <bryceh> something to keep me busy tomorrow ;-)
[03:36] <bryceh> bbl
[03:51] <RAOF> :)
[04:02] <RAOF> Aha!  *That's* why the udeb build fails (sometimes‽)
[06:02] <RAOF> Woot.  rebuild-all-drivers fixed to add appropriate build-depends.
[06:33] <tjaalton> cnd: ok, should be easy to fix
[07:23] <bryceh> RAOF, nice!
[09:56] <RAOF> Oh, wow.  virtualbox pulls in >800MB worth of build depends.
[09:56] <tjaalton> :)
[09:57] <tjaalton> RAOF: hey, you identified the n-trig wacom crasher?
[09:57] <RAOF> Yeah.
[09:57] <tjaalton> where was it?
[09:57] <RAOF> tjaalton: Want to upload the new wacom?
[09:57] <tjaalton> sure
[09:57] <tjaalton> it should fix it?
[09:57] <RAOF> Yeah.
[09:57] <tjaalton> cool
[09:58] <tjaalton> I've had a personal git repo for it, but haven't been keeping it up
[09:59] <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…
[09:59] <RAOF> cooperteam.net/Packages has the new wacom, which doesn't free in the cleanup path :)
[10:00] <tjaalton> I'll test it with my intuos4 that it doesn't break anything :)
[10:00] <tjaalton> though i doubt it would
[10:07] <tjaalton> works, ship it
[10:07] <tjaalton> uploaded
[10:12] <tjaalton> tormod: re savage merge; just put the source package somewhere and I'll sponsor it
[10:13] <tjaalton> debdiffs are so passé :)
[10:15] <tormod> tjaalton, thanks. just that I think it needs RAOF's new xserver because the packaging uses dh_xsf_substvars
[10:15] <RAOF> Isn't that from a Dandy Warhols song? :)
[10:15] <tjaalton> tormod: ah, ok then
[10:16] <tormod> tjaalton, that's why it's only a debdiff, wouldn't build on my system :)
[10:16] <tjaalton> RAOF: debdiffs, heroin, what's the difference :)
[10:17] <RAOF> tormod: You can check it builds if you like; xserver is in git.
[10:17] <tjaalton> so it needs xorg merge?
[10:17] <tjaalton> +d
[10:18] <RAOF> The xserver merge includes dh_xsf_substvars
[10:18] <tormod> tjaalton, I think it needs xorg-server-dev 2:1.9.99.902-2ubuntu1
[10:18] <RAOF> Right.
[10:18] <tjaalton> oh thaat
[10:18] <tjaalton> -a
[10:18] <tjaalton> damn kbd
[10:22]  * 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.
[10:25] <RAOF> Whoops.  Don't try building virtualbox on a tmpfs.
[10:29] <tjaalton> heh
=== ara_ is now known as ara
[11:24] <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.
[11:25] <RAOF> And now, to sleep!
=== yofel_ is now known as yofel
[17:25] <tjaalton> duh, didn't check the patch still applies to the new x11-apps
[17:27] <Sarvatt> yeah all of those patches need refreshing, most shouldn't be needed anymore even
[17:27] <Sarvatt> turned out a lot of the apps ones were because of some debian specific .pc changes that got reverted
[17:27] <tjaalton> ah, ok
[17:27] <tjaalton> so if it builds in pbuilder it should be good?
[17:29] <Sarvatt> should be, lessee..
[17:29]  * Sarvatt always gets confused which apps are in which of the -apps packages
[17:31] <tjaalton> could've tried it myself, but whatever :)
[17:32] <Sarvatt> 5K/second from ftp.debian.org :D
[17:34] <Sarvatt> lets see, oclock fails still
[17:34] <Sarvatt> /usr/bin/ld.bfd.real: oclock.o: undefined reference to symbol 'XtAddEventHandler'
[17:34] <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
[17:34] <Sarvatt> /usr/lib/libXt.so.6: could not read symbols: Invalid operation
[17:38] <Sarvatt> not done yet but looks like the oclock hunk is the only one needed still
[17:42] <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
[17:43] <tjaalton> Sarvatt: cool, can you push it? I'll upload it then (unless you were core-dev too?)
[17:43] <Sarvatt> okie one sec
[18:31] <tjaalton> Sarvatt: thanks, uploaded with the new patch
[18:59] <ricotz> bryceh, hi, did you want to upload wayload to natty?
[19:00] <ricotz> ... wayland
[19:03] <bryceh> ricotz, yes
[19:03] <ricotz> bryceh, nice, but why didnt you use the latest git?
[19:04] <bryceh> ricotz, I plan to, but had this snapshot ready to go right now
[19:05] <ricotz> bryceh, ok, i see
[19:05] <bryceh> also, dunno yet if newer wayland has changed dependency requirements or needs packaging rejiggered
[19:05] <ricotz> yes the demos are splitted into a separate tree
[19:05] <bryceh> ricotz, interested in helping work on it?
[19:06] <ricotz> perhaps, if i find a moment ;)
[19:07] <ricotz> i am able to upload to the wayland ppa
[19:07] <Sarvatt> ubuntu too no? no way thats going in main I'm sure
[19:07] <bryceh> yeah worst case if newer wayland requires git mesa or some such, I'll refresh the ppa
[19:07] <bryceh> Sarvatt, universe
[19:08] <ricotz> bryceh, i think it would be better to put it in edgers where mesa git is up2date ;)
[19:08] <bryceh> true
[19:08] <Sarvatt> speaking of which, need to redo mesa packaging in there *yet again* :(
[19:09] <ricotz> Sarvatt, dont forget to keep the nouveau nvc0 patch ;)
[19:09] <Sarvatt> ricotz: oh crap, I might have overwritten that already
[19:09] <ricotz> Sarvatt, i was desperately searching for the problem until i noticed it
[19:09] <Sarvatt> i'm about to drop lucid/maverick in there, updating all drivers with the new dropped xsfbs stuff isn't gonna happen
[19:10] <ricotz> i updated it on the we to fix it
[19:10] <Sarvatt> ricotz: did I screw it up already? it's an automated script so I probably did, lets see
[19:10] <Sarvatt> oh cool
[19:10] <Sarvatt> adding the patch in a hook so i wont drop it again
[19:10] <ricotz> good :)
[19:19] <cnd> RAOF, found two bugs in the xi 2.1 work
[19:19] <cnd> I'm testing fixes right now
[19:20] <cnd> would you be able to wait for them before pushing to ubuntu?
[19:20] <ricotz> bryceh, could you upload a package to the natty new queue for me?
[19:23] <ricotz> tjaalton, ^ do you mind?
[19:26] <bryceh> cnd, I think he's asleep.  But I can wait for you.
[19:26] <bryceh> ricotz, if you have the packaging all ready to go, sure
[19:26] <cnd> bryceh, ahh, ok, whoever is pushing
[19:26] <cnd> I've got the patch ready
[19:26] <cnd> just slogging through pushing it out
[19:26] <ricotz> bryceh, thank you, http://people.ubuntu.com/~ricotz/libbluray/
[19:27] <ricotz> bryceh, i will ping an archive-admin to look at it if it is up
[19:31] <bryceh> ricotz, ok looks good.
[19:31] <bryceh> ricotz, uploaded
[19:31] <ricotz> bryceh, thanks!
[19:32] <bryceh> dunno if there are any special new package requirements for java stuff, but presumably if there are the archive admins will know
[19:33] <cnd> bryceh, I've pushed a new commit to git
[19:33] <cnd> we should be ready for upload now
[19:34] <bryceh> cnd, hey I only signed up for waiting!
[19:34] <bryceh> ;-)
[19:34] <cnd> oh :)
[19:34] <cnd> heh
[19:34] <cnd> I got ya
[19:34] <bryceh> cnd, fill me in... what packages/git repos should I pull?
[19:34] <cnd> you don't have to push if RAOF was going to :)
[19:35] <cnd> but in case you are interested, xorg-server, x11proto-input, xserver-xorg-input-evdev, xserver-xorg-input-synaptics, libxi
[19:35] <bryceh> if you can wait 3 hours he should be on then, but I can push if it's an emergency
[19:35] <cnd> nah, no need for you to push
[19:36] <bryceh> ok cool, yeah if RAOF has been your primary xorgician probably best if he tends to it
[19:37] <cnd> he's also been getting rc2 ready for upload
[19:37] <cnd> so I think he'd rather do it
[19:37] <cnd> when you chimed in, I thought you and he had decided that you would be pushing it instead
[19:38] <cnd> that's what you get for being sly over irc :)
[19:46] <bryceh> [ubuntu/natty] libbluray 0.2~git20110213.20739ed-0ubuntu1 (New)
[19:46] <bryceh> heh, yeah I knew I was taking a risk given how many days you've operated without a weekend reboot ;-)
[19:53] <jcristau> Sarvatt: is that oclock patch upstream? (too lazy to check..)
[19:56] <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
[19:56] <Sarvatt> oh we aren't patching the .pc in libxt, hmm
[19:57] <jcristau> we might be removing xt from Requires somewhere
[19:58] <Sarvatt> yeah pretty darn sure I double checked them all and none were appropriate upstream back then.. 
[20:12] <trinikrono> tormod: ping i would like to ask you about that drawpix utility you mentioned in bug 579071
[20:12] <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
[20:28] <tormod> trinikrono, hi, you've this bug too?
[20:29] <trinikrono> tormod: you asked in bug 705464 to look this bug
[20:29] <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
[20:29] <trinikrono> and i am wondering how to run drawpix
[20:31] <tormod> trinikrono, ok I see. drawpix should be in mesa-demos
[20:31] <trinikrono> tormod: is that a package to install?
[20:32] <tormod> trinikrono, hmm it does not exist in maverick
[20:32] <trinikrono> tormod: i use lucid
[20:39] <tormod> trinikrono, I put a drawpix binary here: http://alioth.debian.org/~tormod-guest/libdrm/
[20:39] <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
[20:40] <trinikrono> it says error loading libglut.so.3
[20:40] <tormod> trinikrono, you need to install the freeglut3 package
[20:40] <tormod> trinikrono, but you should also see the bug simply by running /usr/lib/xscreensaver/antspotlight
[20:40] <trinikrono> :D i get the black screen also
[20:40] <trinikrono> tormod: and the ant looks really strange
[20:41] <tormod> trinikrono, the ant looks strange, that's another separate bug. but do you get small dots/patches all over the screen
[20:57] <tormod> trinikrono, I will try to make a lucid package for my PPA
[20:58] <trinikrono> tormod: can i speak to you also about bug 705464
[20:58] <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
[20:58] <tormod> trinikrono, sure
[20:58] <trinikrono> you saw my latest comment, is it a bug really?
[20:58] <tormod> trinikrono, I consider it a bug in Ubuntu if you have to fiddle with xorg.conf to get things up and running
[20:59] <tormod> trinikrono, do you know what in your xorg.conf makes DRI work?
[21:03] <trinikrono> tormod: in the Module section it has : dri, dbe, dri2, glx and record
[21:03] <tormod> trinikrono, I have uploaded the lucid savage package to my PPA, but it will take some time before it is built
[21:03] <tormod> trinikrono, and if you remove the Module section, there is no DRI?
[21:04] <trinikrono> tormod: i can try that for you
[21:08] <trinikrono> tormod: going to restart x wish me luck
[21:19] <trinikrono> tormod: you know if i delete the xorg.conf it works fine
[21:20] <tormod> trinikrono, so you never needed any xorg.conf?
[21:20] <trinikrono> tormod: thats the thing i did
[21:21] <trinikrono> thats why i created a xorg.conf in the first place
[21:21] <trinikrono> but when i delete it now it is fine
[21:24] <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?
[22:06] <tormod> trinikrono, I do not think reinstall is necessary
[22:06] <cnd> RAOF, ping me when you get on
[22:06] <RAOF> cnd: Pong.
[22:06] <RAOF> (But in a desktop team meeting, so low bandwidth)
[22:06] <tormod> trinikrono, maybe your xorg.conf was needed in an earlier version, but no longer in lucid
[22:07] <cnd> RAOF, just wanted to say I've got one more small patch
[22:07] <cnd> I'm testing right now
[22:07] <trinikrono> tormod: well maybe we can close that bug because it does seem to reproducible and the reporter is happy
[22:07] <cnd> so if you haven't pushed, it would be good to get this in
[22:07] <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.
[22:08] <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 :)
[22:09] <tormod> trinikrono, I'll wait a bit longer for feedback from David before closing that report
[22:09] <cnd> seb128, do you know who I should talk to about pushing a patch to enable multitouch in qt?
[22:09] <cnd> I'm readying it now, and I want to push before feature freeze
[22:09] <tormod> RAOF, which patches? weren't they cherry-picked from upstream?
[22:10] <seb128> cnd, Riddell
[22:10] <RAOF> I'm pretty sure the patches adding ARGB visuals aren't upstream.
[22:10] <cnd> seb128, thanks!
[22:10] <seb128> you're welcome
[22:11] <tormod> RAOF, oh I see, 03_savage-expose_fbmodes_with_nonzero_alpha.patch
[22:11] <RAOF> Yeah.
[22:12] <tormod> RAOF, I know nothing about it, where it came from or what it really does
[22:13] <tormod> RAOF, it is from "knarf". maybe you can ask him
[22:14] <tormod> for reference it was bug 467474
[22:14] <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
[22:19] <trinikrono> tormod: installed from ppa, result is the same and attaching xorg to bug report
[22:19] <tormod> trinikrono, thanks! disappointing the ppa package didn't help though
[22:22] <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
[22:22] <RAOF> tormod: I take it you've *got* a savage card?  That would let you piglit-test that patch :)
[22:23] <RAOF> You'll need to add the ugly build-depends anyway, at least for a merge?
[22:23] <tormod> RAOF, I am the privileged owner of a savage card
[22:23] <RAOF> And, yeah.  It should be ready before lunchtime.
[22:23] <RAOF> I've just got a niggle to fix, and then some more testing.
[22:24] <tormod> RAOF, why would I need build-depends for a merge? if the Debian packaging requires e.g. 1.9.4
[22:25] <RAOF> Because the packaging requires dh_xsf_substvars, which only appeared in 1.9.99.902-2ubuntu1?
[22:26] <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 :)
[22:26] <bryceh> apw, do you have plans for bug #702090?  We've been accumulating dupes at a pretty good rate.
[22:27] <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
[22:27] <tormod> RAOF, hmm strictly speaking yes
[22:28] <tormod> but for a sync we rely on such things all the time right
[22:28] <RAOF> Right.
[22:29] <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.
[22:30] <tormod> anyway have a nice lunch while I sleep :)
[22:30] <RAOF> Sleep well :)
[22:53] <cnd> RAOF, ok, I'm done now
[22:53] <cnd> pmcgowan was pinging me saying things weren't working with his trackpad :)
[22:53] <RAOF> cnd: Oh, there's another patch?  git pull --rebase it is :)
[22:54] <cnd> and I realized that I hadn't fully tested trackpads
[22:54] <cnd> but they should work well now too
[22:54] <cnd> sorry for the run around...
[22:54] <cnd> RAOF, you wouldn't happen to have one of the newer synaptics trackpads would you?
[22:54] <cnd> with "semi-multitouch" capabilities?
[22:55] <RAOF> How could I tell?  I have exactly two synaptics touchpads.
[22:55] <cnd> if you do, then you can play too
[22:55] <cnd> let me see
[22:55] <cnd> can you run evtest on their device nodes?
[22:55] <cnd> I find device nodes by searching for synaptics in Xorg.0.log
[22:55] <cnd> /dev/input/event*
[22:56] <cnd> at the beginning, it'll spit out a bunch of properties
[22:56] <cnd> if you get ABS event codes >= 53, then you've got a multitouch device
[22:57] <cnd> though it's probably only semi-multitouch
[22:57] <RAOF> I'm guessing my 3yr old touchpad won't be semi-multitouch, so I'll only test the newer one.
[22:58] <RAOF> Nope, only 28 - tool width.
[22:58] <cnd> darn
[22:59] <cnd> sorry :(
[23:20] <JanC> what does semi-multitouch mean?
[23:24] <RAOF> cnd: The Xi 2.1 patches bump minor input ABI, don't they
[23:24] <RAOF> ?
[23:26] <RAOF> cnd: Ah, yes.  There it is.
[23:40] <cnd> RAOF, is that ok?
[23:40] <RAOF> Yeah, that's fine.
[23:41] <cnd> btw, there technically is an abi change
[23:41] <RAOF> I was just checking whether to bump serverminver.
[23:41] <cnd> though it's buried in the server
[23:41] <cnd> and I don't think any input drivers access it
[23:41] <cnd> I'd be surprised if they did
[23:41] <RAOF> Heh.
[23:41] <RAOF> Well, we'll be rebuilding the world for unrelated reasons, so that won't matter :)
[23:41] <cnd> :)
[23:50] <RAOF> Incidentally, the Xi patch introduces a compile warning.
[23:50] <RAOF> In fact, a whole bunch of compile warnings :)
[23:50] <RAOF> I presume you're on them, though.
[23:51] <cnd> RAOF, hmm, I haven't seen any
[23:51] <cnd> can you pastebin them/
[23:51] <cnd> ?
[23:52] <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
[23:52] <yofel> note: X starts fine, I just can't see any messages in plymouth thanks to that
[23:53] <RAOF> cnd: Will do.
[23:53] <yofel> works fine if I use gfxpayload=text and remove the vt.handoff=7