[00:00] <cnd> I can push in the stuff for non-semi-mt devices
[00:00] <RAOF> It also depends on how bad the bad behaviour is.
[00:00] <cnd> though I guess I don't know that synaptics non-semi-mt don't do the same
[00:00] <cnd> it's not that bad of behavior
[00:00] <bryceh> xorg-edgers?
[00:00] <cnd> it's just a little faster than expected
[00:00] <cnd> if I had to guess, somewhere between 1.5 and 2 times faster
[00:00] <cnd> and only when you hold the button down
[00:00] <cnd> so click+drag
[00:01] <bryceh> hmm, that ratio sounds familiar
[00:01] <cnd> in fact, it's hardly a regression since click+drag didn't really work at all before :)
[00:01] <cnd> before this, clickpads would try to scroll if you did click+drag
[00:02] <cnd> which isn't really what the user wants
[00:02] <bryceh> oh, there was an input bug with touchpads when used on HD monitors that the X speed would be different from Y by the aspect ratio of the HD monitor
[00:03] <RAOF> bryceh: Yeah, that's the intended behaviour :)
[00:06] <bryceh> RAOF, no, there was a period where it was mis-calculated.
[00:06] <RAOF> Oh.  I didn't notice that :)
[00:08] <RAOF> cnd: Given its not a regression, the main concern would be that changing to the correct behaviour might be susprising.
[00:08] <cnd> heh, I don't think that's really a concern
[00:08] <cnd> clickpads are just broken broken broken on ubuntu right now
[00:08] <cnd> and this makes them not be :)
[00:14] <cnd> so it doesn't have anything to do with the X server's acceleration profile
[00:14] <cnd> whew
[00:15] <cnd> phew*
[00:18] <cnd> aha, I found the culprit
[00:19] <cnd> the estimate_delta function in synaptics
[00:20] <cnd> tbh, I think there's way too many independent acceleration, dampening, etc. functionalities through synaptics + xserver
[00:20] <cnd> and commenting out estimate_delta makes things behave normally
[00:23] <jschall> I have an nvidia gtx 560m... i get video tearing in all video players (incl. flash, mplayer) with compositing on, flash still tears with compositing off, mplayer is also seemingly dropping frames with compositing on, which is a lot more noticable when on battery (gpu clocks down to 202MHz gpu/324MHz ram)
[00:24] <jschall> and i NEVER had problems with the 8800gts on my desktop. what an insane regression.
[00:25] <jschall> any help? i've spent a lot of time trying to fix this... at the moment i'm running xorg-edgers, nvidia-current 295.17.
[00:29] <RAOF> jschall: You've got the relevant “sync to vblank” things flipped? (In Compiz, in nvidia-settings)
[00:29] <jschall> RAOF: kubuntu... i have vsync on in kwin, in nvidia-settings
[00:31] <jschall> wonder if noveau will ever be as good as the nvidia drivers
[00:32] <jschall> nouveau*
[00:35] <RAOF> Depends on what you mean by “as good”
[00:37] <jschall> well, doesn't seem to even allow kwin compositing to work
[00:37] <jschall> but maybe i didn't have a package i needed or something
[00:37] <RAOF> The 560m is, I think, too new to get acceleration support.
[00:37] <RAOF> At least in an Ubuntu release.
[00:38] <jschall> well, anyway, i'm happy with this laptop apart from this stupid video tearing thing... love to get it fixed
[00:38] <jschall> RAOF: any ideas at all?
[00:38] <jschall> RAOF: other than vsync switches?
[00:39] <RAOF> Not really, sorry.
[00:40] <jschall> maybe it'll be fixed in a new nvidia driver some day...
[00:41] <RAOF> Possibly ;)
[00:41] <jschall> RAOF: the juddering thing just seems weird, though... why wouldn't a modern video card be able to decode some video without dropping frames?
[00:41] <jschall> RAOF: the cpu can do it no problem...
[00:42] <jschall> RAOF: even though it's avc
[00:45] <RAOF> Shrug.
[00:45] <RAOF> It's not like we have much insight into the driver ;)
[00:49] <bjsnider> RAOF isn't the one to ask because he's a nouveau partisan
[00:49]  * RAOF prefers drivers we can fix, sure :)
[00:49] <Sarvatt> is it just fullscreen thats tearing? there was a change recently in kde to stop unredirecting fullscreen windows which might be why it changed for you that you might be able to undo with a setting somewhere but yeah KDE, dont use or know anything about it
[00:49] <RAOF> I also don't spend much time using the nvidia binary driver, so I'm particularly good at fixing problems with it.
[00:51] <jschall> Sarvatt: it does tear in fullscreen with or without compositing on.
[00:51] <Sarvatt> i was going to suggest reporting it but apparently you did and they told you to come here, it really sounds like a kde/kwin specific problem though
[00:51] <Sarvatt> err reporting it at nvnews.net forums
[00:51] <bjsnider> i don't think the 560m is too new
[00:51] <bjsnider> if the blob supports it it should get compositing and whatnot
[00:51] <jschall> bjsnider: will it run games with nouveau?
[00:52] <Sarvatt> probably not as good as you want if you cared enough to get a good GPU :)
[00:53] <jschall> Sarvatt: does it have support for all the opengl extensions that the proprietary drivers provide?
[00:53] <RAOF> No.
[00:53] <Sarvatt> nowhere near it :)
[00:53] <jschall> Sarvatt: honestly the only game i really ever run any more is heroes of newerth... that's going to change when d3 comes out.
[00:53] <bjsnider> that's a laugh
[00:54] <Sarvatt> you really dont want nouveau
[00:54] <jschall> hmm. k
[00:54] <jschall> i just don't want screen tearing
[00:54] <bjsnider> have you tried gnome?
[00:54] <jschall> there is an option in kwin to unredirect fullscreen
[00:54] <bjsnider> it's pretty good
[00:54]  * RAOF still contends that it's probably too new for acceleration under nouveau.
[00:54] <Sarvatt> RAOF: it should be fine in precise
[00:55] <jschall> bjsnider: you know, i haven't tried gnome but i really just don't want to use it. i did run a livecd to check for tearing
[00:55] <Sarvatt> did that have tearing too?
[00:55] <Sarvatt> then again that was nouveau :)
[00:55] <bjsnider> yes but i think it would be interesting to see if there was tearing in gnome
[00:55] <jschall> it didn't seem to have tearing
[00:56] <jschall> but yeah, i guess it would've been nouveau
[00:56] <bjsnider> there's no tearing by design in mutter, so i would try gnome-shell
[00:56] <jschall> i can't remember if i installed the nvidia drivers
[00:56] <jschall> i guess i couldn't have in a live usb
[00:57] <RAOF> Of course, there's no tearing by design in compiz either; that doesn't prevent tearing :)
[00:57] <bjsnider> sure there's tearing in compiz
[00:58] <bjsnider> you can turn off vsync and screw up the frame rate
[00:59] <bjsnider> but i'm an evil gnome-shell partisan so of course i'm going to recommend that
[00:59] <Sarvatt> jschall: have you tried disabling gpu acceleration to see if its any different?
[01:00] <Sarvatt> in whatever playback apps you're using
[01:00] <jschall> Sarvatt: well, mainly its flash
[01:00] <RAOF> bjsnider: I just meant that vsyncing in the compositor is insufficient to ensure tear-free. (Indeed, I don't think it's possible to ensure tear-free)
[01:01] <jschall> Sarvatt: and it does have that option but it makes no difference
[01:01] <jschall> Sarvatt: i don't even think it does anything
[01:01] <Sarvatt> ah gotcha
[01:01] <bjsnider> jschall, in which playre?
[01:01] <Sarvatt> how about in smplayer?
[01:02] <jschall> bjsnider: that's flash
[01:02] <Sarvatt> switching to gl, or xv, or x11
[01:02] <bjsnider> jschall, are you talking about right-clicking?
[01:02] <jschall> Sarvatt: let me try it again
[01:02] <jschall> bjsnider: yes
[01:02] <bjsnider> it doesn't do anything
[01:02] <jschall> ah
[01:03] <bjsnider> that has been disabled in linux because it causes minor aggravations like taking down x
[01:03] <bjsnider> smplayer was abandoned
[01:04] <jschall> bjsnider: with xv if there's any tearing its unnoticeable in smplayer
[01:04] <jschall> bjsnider: only issue is decoding avc EATS cpu
[01:04] <bjsnider> xv is useless
[01:04] <jschall> bjsnider: why?
[01:04] <bjsnider> which version of ubuntu is this?
[01:05] <jschall> gl has tearing
[01:05] <jschall> and is kinda slowish
[01:05] <jschall> juddery
[01:05] <jschall> its not a lot of tearing though
[01:06] <jschall> gl (fast) seems better
[01:06] <bjsnider> go ask uau in #mplayer2 which output driver you should use
[01:06] <jschall> gl2 also juddery
[01:06] <bjsnider> what version of ubuntu?
[01:06] <jschall> and tearing
[01:06] <jschall> kubuntu 11.10
[01:07] <jschall> -vo caca is perfect.
[01:07] <bjsnider> ok, well, there shouldn't be more than 30% cpu usage decoding avc, because we have ffmpeg-mt now
[01:07] <bjsnider> unless you're doing that 3d crap
[01:08] <jschall> 3d crap?
[01:10] <jschall> bjsnider: mplayer using 75% cpu decoding 1080p avc. cpu clocking to 2000mhz ish
[01:10] <jschall> bjsnider: with kwin compositing ("3d crap") disabled
[01:10] <jschall> bjsnider: that's with xv out
[01:10] <bjsnider> no, 3d video i meant
[01:10] <bjsnider> 10-bit video
[01:10] <jschall> bjsnider: oh
[01:10] <bjsnider> i'm assuming this is standard 1080p
[01:11] <bjsnider> what cpu?
[01:11] <jschall> bjsnider: vdpau out clocks the cpu down to 1200 and mplayer uses 10-25%
[01:11] <jschall> bjsnider: i7 2670qm
[01:11] <bjsnider> are you kidding me?
[01:11] <jschall> bjsnider: no
[01:11] <bjsnider> this is absurd
[01:11] <bjsnider> these numbers can't be correct
[01:12] <jschall> bjsnider: they are
[01:12] <bjsnider> you should get 5% with vdpau, and around 30% with ffmpeg-mt
[01:12] <jschall> bjsnider: as reported by i7z and top
[01:12] <bjsnider> is this just kde suckage?
[01:12] <jschall> bjsnider: no.
[01:12] <jschall> bjsnider: that's how much cpu it takes to decode avc
[01:12] <bjsnider> i've got an nvidia card that's crap compared to yours and i do much better
[01:13] <bjsnider> what about 1080p x264?
[01:13] <jschall> bjsnider: dunno if i have any
[01:13] <jschall> bjsnider: i can run mplayer with no output i assume
[01:14] <bjsnider> that's alright, just search for and download big buck bunny
[01:14] <bjsnider> what is the mplayer command you're using?
[01:16] <jschall> bjsnider: mplayer -vo null filename
[01:16] <jschall> bjsnider: 80% usage at 1.8-2.4ghz
[01:16] <jschall> bjsnider: kde not being used at all
[01:16] <jschall> bjsnider: compositing still off
[01:17] <bjsnider> mplayer -vo vdpau -vc ffvc1 -ao pulse file
[01:18] <jschall> Cannot find codec matching selected -vo and video format 0x31637661.
[01:18] <jschall> and then just the audio plays
[01:18] <bjsnider> mplayer -vo vdpau -vc ffh264 -ao pulse file
[01:19] <jschall> that's the one it uses normally
[01:19] <jschall> maybe i have an h264 file and not an avc file
[01:19] <bjsnider> no, it's the same thing
[01:19] <bjsnider> what's the cpu at?
[01:20] <jschall> bjsnider: 80%
[01:20] <bjsnider> are these actual blurays?
[01:21] <jschall> bjsnider: no
[01:21] <jschall> bjsnider: probably ripped from them though
[01:21] <bjsnider> alright, download big buck bunny and play that
[01:22] <bjsnider> give me the url and i will play it too
[01:22] <bjsnider> then we can compare
[01:22] <jschall> bjsnider: mmm firefly bluray rips
[01:23] <jschall> big buck bunny won't be avc so won't eat cpu
[01:23] <jschall> which version of bbb should i download?
[01:23] <jschall> mp4, h264, ogg?
[01:24] <bjsnider> h264 1080p
[01:26] <jschall> yeah, 40-60% and 1500-1800mhz
[01:26] <jschall> which comes out to like 20% at 3400mhz
[01:26] <jschall> which is what it can clock up to if it wants
[01:27] <jschall> what i should really be doing is power consumption tests
[01:27] <jschall> because that's what i care about if i'm going to watch on battery
[01:27] <jschall> anyway, something i noticed with mplayer -vo vdpau is that it didn't tear with compositing on...
[01:27] <jschall> so maybe its an smplayer thing
[01:28] <bjsnider> ok, try -vc ffh264vdpau
[01:28] <jschall> oh
[01:29] <jschall> bjsnider: yeah usual slowness and tearing
[01:29] <jschall> bjsnider: but low cpu usage!
[01:29] <bjsnider> how low?
[01:29] <bjsnider> 5%?
[01:31] <jschall> bjsnider: 15
[01:31] <jschall> bjsnider: oh and...
[01:32] <bjsnider> it should be around 5% maximum, so i expect this is a kwin issue
[01:32] <bjsnider> and watching it that way is the way to get around power issues
[01:32] <jschall> bjsnider: and like 1ghz
[01:32] <jschall> bjsnider: so at 3ghz it'd be 5%
[01:32] <bjsnider> ok
[01:32] <jschall> bjsnider: well lets find out watts up
[01:33] <jschall> bjsnider: =P
[01:33] <jschall> bjsnider: pulled battery, plugged into watt meter
[01:33] <jschall> bjsnider: 66.5 watts with this
[01:33] <bjsnider> with vdpau?
[01:33] <jschall> bjsnider: 78w with no vdpau on -vc
[01:34] <jschall> 66.5 with vdpau
[01:34] <jschall> with no vdpau can jump to 80
[01:34] <bjsnider> to be fair you'd have to run the cpu to full throttle
[01:34] <jschall> bjsnider: 72 with -vo xv and no vdpau in the codec
[01:36] <jschall> bjsnider: vdpau is the way to go for watts
[01:36] <jschall> bjsnider: for sure
[01:36] <bjsnider> we've known that for years
[01:36] <bjsnider> it's no surprise
[01:36] <bjsnider> but playback should be smooth and relatively judder-free
[01:37] <bjsnider> what's your screen's refresh rate?
[01:37] <jschall> bjsnider: but wait, different results with compositing off: vdpau uses MORE power than xv
[01:37] <jschall> bjsnider: wait, no
[01:37] <bjsnider> vdpau is superior to xv though
[01:37] <jschall> bjsnider: ran the test again, didn't give the meter enough time i guess
[01:38] <jschall> bjsnider: and now akonadi is doing something that uses 40% cpu...
[01:38] <jschall> bjsnider: oop, it just stopped
[01:38] <jschall> bjsnider: time to put battery back so i don't forget it's not there
[01:39] <jschall> bjsnider: anyway, interesting experiment
[01:39] <jschall> bjsnider: vdpau just sucks with compositing
[01:39] <bjsnider> constantly throttling the cpu down to the level of an old pentium isn't going to help performance
[01:39] <jschall> bjsnider: and flash just always sucks no matter what
[01:39] <jschall> bjsnider: umm, it works great...
[01:40] <jschall> bjsnider: it throttles it when it needs to
[01:40] <jschall> bjsnider: its a laptop
[01:40] <bjsnider> keep in mind that vdpau and compositing both use the gpu, at the same time
[01:40] <jschall> bjsnider: if i turned throttling off it'd eat a solid 40 more watts
[01:40] <jschall> bjsnider: yeah, but so does running heroes of newerth (should use a LOT more gpu than vdpau)
[01:40] <jschall> bjsnider: and heroes of newerth runs like 200fps if i turn vsync off
[01:41] <bjsnider> i doubt it
[01:41] <bjsnider> h264 is awfully hard on any cpu/gpu
[01:41] <jschall> bjsnider: why can my phone play it then?
[01:41] <bjsnider> if we didn't have ffmpeg-mt your sandybridge cpu couldn't play it
[01:41] <jschall> bjsnider: my phone plays sintel on youtube with no tearing just fine, but my $1400 laptop can't, apparently
[01:42] <jschall> bjsnider: but then, my phone isn't playing it at 1080p
[01:42] <jschall> bjsnider: and my phone has hardware decoding
[01:43] <bjsnider> my q6600 kentsfield cannot play 1080p consistently without multithreading
[01:43] <jschall> bjsnider: my q6600/8800gts played all the content i wanted to consistently, but i had it clocked at 3.4ghz...
[01:44] <jschall> bjsnider: 2.8ghz was the lowest i ever had it clocked to over a long period of time...
[01:44] <jschall> bjsnider: and it played anything i wanted perfectly with kwin compositing on
[01:45] <jschall> bjsnider: and i don't think the 8800gts was doing vdpau... if so i wasn't using it because i always used vlc
[01:46] <jschall> anyway i have to do my precalc homework for tomorrow
[01:47] <jschall> wonder if i can sell a netbook with linux on it on craigslist
[01:47] <jschall> because there's basically no way to reload win7 starter on it...
[02:25] <cnd> bryceh, RAOF: I ran out of time to get to the X uploads today
[02:26] <cnd> I don't have anything big planned tomorrow, so I should be able to get to them
[02:26] <bryceh> cnd, ok
[02:27] <bryceh> heh, I had a system with two dual head monitors, hot swapped them for two new monitors (different brand but same resolution), rebooted and it came up mirrored.  Obviously.
[02:53] <cnd> bryceh, RAOF, tjaalton, Sarvatt: I just sent a couple patch series out to xorg-devel
[02:53] <cnd> they enable proper clickpad support
[02:54] <cnd> I want to get this into precise
[02:54] <cnd> I would suggest putting everything up through the first series (the synaptics touch handling) into precise asap (i.e. tomorrow)
[02:55] <cnd> I can put the second series into a ppa and put out a CFT
[02:55] <bryceh> cnd, you sound a lot more confident than earlier!  :-)
[02:55] <cnd> bryceh, I was afraid the motion issue was unresolvable
[02:55] <cnd> but it turns out to just be a bad algo
[02:56]  * bryceh nods
[02:56] <cnd> before I put out a CFT, if you could smoke test it I would appreciate it
[02:56] <cnd> git://people.freedesktop.org/~cndougla/xf86-input-synaptics branch clickpad-synaptics-ubuntu
[02:57] <cnd> bryceh, it should help your netbook
[02:57] <bryceh> heh, the one computer I *haven't* updated so far today
[02:57] <cnd> and I bet the four of you have a few clickpads around
[02:57] <cnd> heh
[02:57] <bryceh> cnd, ok will do
[02:58] <bryceh> seriously my fibre has been on fire today
[02:58] <cnd> note that you will need to manually set the "Synaptics ClickPad" property to 1
[02:58] <cnd> in most cases
[03:01] <RAOF> It's not possible to detect that easily?  Bah.
[03:02] <cnd> RAOF, it is, if the kernel driver tells us
[03:02] <cnd> I need to add it to the magic trackpad driver
[03:02] <RAOF> Fair enough.
[03:02] <cnd> but I don't know what the state of it all is for synaptics
[03:02] <cnd> the detection logic is in the synaptics patch set
[03:03] <cnd> it's just not likely that people will have drivers that tell us they're clickpads
[03:04] <cnd> RAOF, actually, maybe most synaptics clickpads will work OOTB
[03:04] <cnd> I see support for setting the clickpad property in the kernel driver
[03:04] <cnd> I think it's just my specific trackpad on my older dell netbook that doesn't appear to the driver to be a clickpad
[03:05] <cnd> ok, off to get dinner
[03:14] <bryceh> cnd, make check fails
[03:14] <bryceh> make[2]: Entering directory `/home/bryce/ubuntu/xserver-xorg-input-synaptics/clickpad-synaptics-ubuntu/test'
[03:14] <bryceh> /bin/bash: line 5: 28107 Segmentation fault      (core dumped) ${dir}$tst
[03:14] <bryceh> FAIL: eventcomm-test
[03:31] <cnd> bryceh, hmm. interesting
[03:32] <RAOF> That's a symbol-mismatch, right?
[03:33] <cnd> RAOF, bryceh, no, it's an issue with the new mechanism for instantiating SynapticsHwState
[03:33] <cnd> I missed that the test program needs to be updated
[03:35] <cnd> bryceh, thanks for catching it, I'll fix it tomorrow
[03:35] <cnd> it's not hard to fix, but not something I can fix in 30 seconds
[03:36] <bryceh> no prob, I worked around it (just hacked out the test)
[03:36] <bryceh> I've got it installed and will play with it this evening while watching Dexter
[03:37] <bryceh> cnd, are there any lp#'s associated with this work?
[03:38] <bryceh> well I already see a problem
[03:39] <bryceh> cnd, with one finger moving, if a second finger happens to touch the touchpad, the pointer stops dead
[03:40] <bryceh> hmm, including if second finger is just carefully touching the left mouse button.  IOW drag and drop becomes impossible.
[03:40] <bryceh> so.. no dexter for the netbook
[03:41] <cnd> bryceh, no lp#s
[03:41] <cnd> bryceh, drag and drop should work...
[03:41] <cnd> that's the point of the clickpad support
[03:42] <cnd> check to make sure the "Synaptics ClickPad" property is set to 1
[03:42] <bryceh> oh, right!
[03:44] <cnd> bryceh: testing to see if I'm connected on my iPad
[03:45] <cnd> do you see this?
[03:45] <RAOF> Yes.
[03:45] <cnd> k
[03:49] <cnd> bryceh: did setting the property fix things?
[03:52] <bryceh> cnd, no, mouse cursor doesn't work at all
[03:52] <bryceh> cnd, after setting the property in xorg.conf.d
[03:53] <cnd> bryceh: how did you set the property?
[03:54] <cnd> I suggest using xinput as it's faster to test
[03:54] <bryceh> ah
[03:54] <bryceh> well, wife's calling me to dinner so I'm out of time
[03:54] <cnd> if you do xinput list-props <device id> it will show it
[03:54] <cnd> and set-prop to change it
[03:55] <cnd> thanks for trying though... I hope it works better when you try again
[03:57] <bryceh> cnd, alright lets try
[03:57] <bryceh>         Synaptics ClickPad (266)       1
[03:57] <bryceh> still, same behavior
[04:00] <cnd> hmmm...
[04:00] <cnd> so when you put two touches down, the pointer stops moving
[04:00] <bryceh> right
[04:01] <cnd> when you press a button, it still doesn't move?
[04:01] <bryceh> I've put packages up of what I used at https://launchpad.net/~bryce/+archive/clickpad-synaptics-ubuntu
[04:01] <cnd> when two touches are down but the button isn't pressed, it will emit scroll events (if enabled) or do nothing
[04:01] <bryceh> cnd, yes if I depress the button it will begin moving again
[04:02] <bryceh> if I just touch the button, it stops
[04:02] <cnd> bryceh, ahh, so click and drag works, right?
[04:02] <bryceh> anyway, gotta go
[04:02] <cnd> k
[07:27] <tjaalton> syncing pixman
[07:27] <tjaalton> ..later
[07:27] <tjaalton> not possible yet it seems
[08:07] <tjaalton> whoa, xorg dev position open?
[08:11] <tjaalton> not one but two..
[09:50] <tjaalton> amazing what a piece of hair in front of the mouse laser does to it's accuracy..
[11:30] <jschall> RAOF: btw, flash 11.2 beta fixed my screen tearing
[12:32] <tjaalton> checking for glXCreateContext in -lGL... no
[12:33] <tjaalton> why the #&%#¤ does it fail on sbuild but not pbuilder
[12:45] <tjaalton> don't care anymore, ship it
[12:45] <tjaalton> (gstreamer-vaapi)
[15:37] <tjaalton> whee, patch to fix scrolling from whot.. will test asap
[15:50] <tjaalton> cnd: whot posted a patch to fix bug 925785 and I verified it works
[15:50] <ubot4`> Launchpad bug 925785 in xorg-server (Ubuntu) (and 1 other project) "Starting to scroll is erratic with edge scrolling on touchpad or mouse scrollwheels (affects: 10) (heat: 50)" [Critical,Triaged] https://launchpad.net/bugs/925785
[15:50] <cnd> tjaalton, ok, I'll be sure it's folded into the packages I upload today
[15:51] <tjaalton> cnd: I can add the patch, have it locally
[15:52] <cnd> tjaalton, if you don't mind, I'd rather add it
[15:52] <tjaalton> ok
[15:52] <tjaalton> sure :)
[15:52] <cnd> so I can keep track of what are patches vs what are merged from upstream
[15:52] <tjaalton> yeah this is pretty fresh (posted 20min ago), so probably not upstream yet
[15:53] <cnd> hasn't come across xorg-devel yet even :)
[15:54] <tjaalton> nope, took it from bugzilla
[15:55] <tjaalton> now to see if a newer kernel fixes nouveau on my laptop..
[15:56] <tjaalton> it's failing to use nouveau dri, falling back on swrast
[15:56] <tjaalton> promising, plymouth splash
[15:57] <tjaalton> nah, "error creating GPU channel: -19"
[15:58] <tjaalton> ok, accel disabled by default
[15:59] <cnd> tjaalton, do you have a clickpad?
[15:59] <cnd> Sarvatt, you too?
[15:59] <tjaalton> cnd: no, just the thinkpad
[15:59] <cnd> ok
[15:59] <tjaalton> Sarvatt does
[15:59] <tjaalton> macbook air
[16:11] <Sarvatt> this isnt a clickpad
[16:11] <tjaalton> oh
[16:11] <Sarvatt> broadcom BCM5974 touchpad
[16:11] <tjaalton> what's a clickpad then?
[16:11] <Sarvatt> actual synaptics touchpads that click
[16:12] <Sarvatt> this just uses the synaptics driver
[16:12] <tjaalton> ok
[16:12] <Sarvatt> i dont even have any systems with real synaptics touchpads in them anymore, crazy
[17:13] <cnd> Sarvatt, no, I'm meaning clickpad in the functional sense
[17:14] <cnd> so macbook trackpad counts
[17:14] <cnd> not in the Synaptics ClickPad (R) sense
[17:14] <Sarvatt> oh! let me read the scrollback and see what ya asked
[17:14] <cnd> Sarvatt, install the package from https://launchpad.net/~bryce/+archive/clickpad-synaptics-ubuntu
[17:15] <cnd> then, use xinput to set the "Synaptics ClickPad" property to 1 if it's not already
[17:15] <cnd> then see if you can drag and drop with two fingers
[17:15] <cnd> and if everything else seems sane
[17:16] <bryce> cnd, from last night, yes click and drag worked.  Anything else need tested?
[17:16] <Sarvatt> cnd: going to invalidate any testing if i use it against 1.12?
[17:16] <Sarvatt> ah it doesn't even build against 1.12
[17:16] <Sarvatt> damn, gonna take me about 45 minutes to remove edgers
[17:16] <cnd> Sarvatt, you can fetch from git and build from sources
[17:16] <cnd> http://cgit.freedesktop.org/~cndougla/xf86-input-synaptics
[17:17] <Sarvatt> i did last night and it failed the same way
[17:17] <cnd> branch clickpad-synaptics
[17:17] <Sarvatt> oh clickpad-synaptics, i used the ubuntu one
[17:17] <cnd> yeah, the ubuntu one has two patches for the 1.11 backport
[17:17] <bryce> cnd, what's the cleanest way to install (and uninstall) it if you build from source?
[17:17] <cnd> bryce, I usually use --prefix=/usr
[17:17] <cnd> that way when I reinstall the dpkg everything is overwritten
[17:18] <cnd> bryce, does the trackpad now behave as you expect?
[17:18] <cnd> any issues?
[17:18] <cnd> my hope is this makes these devices much saner
[17:19] <bryce> cnd, well there's the issue that when both fingers are on the pad, the pointer does not move
[17:19] <cnd> bryce, that's expected
[17:19] <cnd> it will either perform scrolling or do nothing
[17:19] <cnd> depending on your scroll options
[17:19] <cnd> or send touch events
[17:19] <bryce> cnd, ah, there's a way to configure that?
[17:20] <bryce> like, a way to get it to just ignore the second mouse touch?
[17:20] <cnd> bryce, in gtk mouse settings you can enable two-touch scrolling
[17:20] <cnd> bryce, are you asking if there's a way to make the cursor move when you have two touches on the device?
[17:20] <Sarvatt> override_dh_auto_test:
[17:20] <Sarvatt>         dh_auto_test || echo "Test suite failure, but keeping on anyway"
[17:20] <Sarvatt>  ftw
[17:20] <bryce> cnd, that's correct
[17:21] <cnd> bryce, no, that's not possible anymore
[17:21] <cnd> it would interfere with sending touch events
[17:21] <cnd> Sarvatt, yeah, I'm going to fix that today
[17:21] <cnd> bryce, did you often do that?
[17:21] <cnd> move the cursor with two touches?
[17:22] <bryce> cnd, yes, typically when I'm going to click something I'll rest my finger momentarily on the button without pressing it while I finish moving the pointer with my other finger
[17:23] <bryce> with this setting, I find the cursor halting suddenly
[17:23] <cnd> bryce, hmmm... do you think it's a problem if that's not possible anymore?
[17:23] <cnd> or will people get used to it?
[17:24] <bryce> also, the way the netbook works I often have stray touches while cursoring, but I'd have to examine my usage more
[17:24] <bryce> it does not feel to me like something people would get used to, it feels more like a severe bug
[17:25] <cnd> hmm...
[17:25] <bryce> I do have to say I haven't seen the weird random go-to-0,0 problem that it had before
[17:25] <cnd> I don't think I ever used my trackpad like that
[17:26] <cnd> I always hover my button finger above the trackpad
[17:26] <cnd> and then press when I'm in the right spot
[17:26] <cnd> maybe that's because I always have two-touch scrolling enabled
[17:26] <cnd> in previous versions, if you had two-touch scrolling enabled you'd have the same issue
[17:27] <cnd> the pointer would stop as soon as you touch with the second finger
[17:29] <Sarvatt> first really annoying thing is i can't move while clicking when clickpad is enabled
[17:29] <Sarvatt> so no highlighting text
[17:30] <bryce> Sarvatt, did you set the xinput setting?
[17:30] <Sarvatt> yeah
[17:30] <Sarvatt> it was fine without it set
[17:30] <bryce> hmm
[17:30] <bryce> I had that problem before I changed the setting, but it worked (more or less) after
[17:30] <Sarvatt> two finger click doesn't right click
[17:30] <Sarvatt> so cant right click at all
[17:31] <cnd> Sarvatt, can you press with one finger and drag?
[17:31] <Sarvatt> no, pointer doesn't move
[17:31] <cnd> what about pressing with one finger and dragging with a second?
[17:31] <Sarvatt> nothing
[17:32] <bryce> two finger click works here for bringing up the context menu
[17:32] <Sarvatt> it all works properly on the mac trackpads without clickpad turned on
[17:32] <cnd> Sarvatt, hmm... I'll play around some more here
[17:32] <cnd> it works fine on the magic trackpad
[17:33] <cnd> I haven't tested on my macbook
[17:33] <cnd> I assumed it would work
[17:37] <Sarvatt> http://ubuntuone.com/1uzkRjwx0x4JtGpM30pm47
[17:47] <Sarvatt> why are we changing the default speed in a patch?
[17:47] <Sarvatt> had to adjust it because it was way too slow
[19:02] <cnd> Sarvatt, it's likely a side effect of a change, which we had patched in a speed change for a month ago
[19:02] <cnd> I think when I package stuff up it will be resolved
[21:22] <Sarvatt> err, whats the deal with xbitmap and xbitmaps?
[21:23] <Sarvatt> hmm
[21:23] <Sarvatt> x11-apps in debian recommends: xbitmap but the package is xbitmaps it looks like
[21:23] <bryce> bug #930176
[21:23] <ubot4`> Launchpad bug 930176 in x11-apps (Ubuntu) "x11-apps recommends xbitmap but it doesn't exist (xbitmaps is in the archive) (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/930176
[21:23] <Sarvatt> yeah
[21:23] <Sarvatt> was just looking at that
[21:24] <bryce> I think we dropped it a while back
[21:24] <Sarvatt> was xbitmap a separate package from xbitmaps?
[21:25] <Sarvatt> it looks like just a typo
[21:25] <bryce> maybe
[21:25] <bryce> when I first joined the X apps were all packaged individually
[21:26] <bryce> tbh I don't remember there ever being an 'xbitmap' tho
[21:27] <Sarvatt> asking in debian-x
[21:47] <jschall> if i run xset -q, i see dpms is randomly getting reset to 180 270 360. How can i fix this? It's really annoying, I've set my distro's power management to not blank the screen when power is connected.  i've grepped /usr and /etc for dpms and come up with nothing that seemed relevant. I can probably fix it by just setting up a cron job to xset -dpms every minute but I'd like to find the source of the problem. on kubuntu, btw
[22:01] <jschall> how can i set nvidia's nologo option in 11.10? isn't xorg.conf deprecated?
[22:05] <broder> jschall: no, it's just not needed by default. you can still create an /etc/X11/xorg.conf file
[23:42] <bryceh> I'm going to delete the canonical-xorg team, since we have canonical-x for the same purpose
[23:43] <bryceh> I vaguely recall canonical-xorg was set up so I could be included in dell hardware bug reports
[23:43] <bryceh> however these days those issues are handled by hwe and oem groups
[23:44] <bryceh> if there's value to having us on that, might want to have the dell team sub canonical-x instead
[23:53] <cnd> argh... the allowevents struct stuff seems to be broken...
[23:55] <bryceh> boom, canonical-xorg gone.