[08:52] <tjaalton> bryceh: the fix for bug 778758 is already in oneiric
[08:52] <ubot4> Launchpad bug 778758 in xorg (Ubuntu Oneiric) (and 2 other projects) "The apport hook discourages new bug reports (affects: 3) (dups: 1) (heat: 88)" [Undecided,Fix released] https://launchpad.net/bugs/778758
[08:52] <tjaalton> or did you mean natty
[08:54] <bryceh> tjaalton, yes, natty
[08:54] <tjaalton> ah, yes it's fine
[09:01] <tjaalton> hrm, so reverting to the broken crtc confinement patch made the build pass again
[09:08] <tjaalton> ..and it really doesn't make sense comparing build logs generated with -j2
[09:21] <tjaalton> something wrong with the xserver rules file, need to run debuild clean twice
[09:21] <tjaalton> or oneiric, the error:
[09:21] <tjaalton> No patches applied
[09:21] <tjaalton> rm -rf .pc stampdir/patch
[09:21] <tjaalton> debuild: fatal error at line 1322:
[09:21] <tjaalton> couldn't exec fakeroot debian/rules: 
[09:22] <tjaalton> at the end of the first run
[09:55] <tjaalton> RAOF: think I found the bug in the patch
[10:05] <RAOF> tjaalton: Cool.  My build failed with a missing list.c, but I hadn't actually looked back in at it to make sense of it.
[10:05] <tjaalton> yeah
[10:05] <bryceh> heya RAOF
[10:06] <tjaalton> RAOF: it's just a test, I've disabled building it and checking if it's enough to "fix" it
[10:07] <tjaalton> nope :)
[10:07] <tjaalton> fixes.c missing as well
[10:07] <tjaalton> duh
[10:08] <RAOF> bryceh: Good $TIME_OF_DAY :)
[10:11] <tjaalton> hmm, maybe just pull what got upstream
[10:12] <RAOF> I started doing that, but I'm not sure that all of it actually made it upstream.
[10:14] <tjaalton> part of it was merged in february
[10:15] <RAOF> Yeah, but that was some setup work.
[10:15] <RAOF> It didn't include (a) actually calling ConfineCursorHarder, or (b) any ConfineCursorHarder implementations ;)
[10:16] <tjaalton> details..
[10:16] <RAOF> I'm going to backport the Xi 2.1 raw-events-delivery patches so that DX can implement proximity animations sanely…
[10:18] <RAOF> Hm.  Have they not made it off the list yet?
[10:21] <tjaalton> seems like it
[10:22] <tjaalton> at least no reply from keithp about merging them
[10:22] <tjaalton> I'll probably split the pointer barrier patch in two, the v3 patch in its own file and the rest in the other
[10:23] <tjaalton> it needs some changes, to not build missing tests
[10:27] <tjaalton> hmm or just update the current one, meh
[10:46] <Amaranth> RAOF: By sanely do you mean without polling for the mouse position?
[10:46] <RAOF> Amaranth: Indeed.
[10:47] <RAOF> tjaalton: Do you want to finish fixing the crtc patch, or do you want to hand over to me?
[10:48] <tjaalton> RAOF: I'm done, test-building next
[10:49] <tjaalton> I just diff'ed the changes to cursor.c in v3 and ported the changes over
[10:49] <tjaalton> and dropped the change to test/Makefile.am
[11:07] <tjaalton> built
[11:22] <tjaalton> ok, maybe should test this sucker then
[11:23] <RAOF> Woot!
[11:24] <tjaalton> ..right after these updates :)
[11:27] <RAOF> Messages from our sponsor!
[11:28] <tjaalton> bah, cking took the stage :)
[12:20] <tjaalton> the projector is still reserved, need to find another one
[12:38] <tjaalton> works!
[14:43] <tjaalton> fixing bug 554984
[14:43] <ubot4> Launchpad bug 554984 in xserver-xorg-input-evdev (Ubuntu) "[lucid] enable trackpoint scroll emulation by default (affects: 17) (dups: 6) (heat: 68)" [Wishlist,In progress] https://launchpad.net/bugs/554984
[14:44] <tjaalton> and enabling middlemouse emulation for those, to allow dragging with the emulation
[14:44] <tjaalton> i guess it's a compromise I'm willing to live with :)
[14:54] <lilstevie> tjaalton: you good with finding what is causing bugs in evdev? :p
[14:54] <tjaalton> lilstevie: there are none, silly you..
[14:55] <lilstevie> tjaalton: hah
[14:56] <lilstevie> tjaalton: I am having a weird issue with a touchscreen and either evdev or xorg tripping on it
[14:56] <lilstevie> touch frame is correctly implemented :)
[14:57] <lilstevie> but I need to bash 2 fingers to some random tune to get it to detect the click event
[14:58] <tjaalton> hmm not sure, those are usually kernel bugs if evdev is used
[14:58] <lilstevie> kernel is not the bug here :)
[14:58] <lilstevie> kernel is about 3 months worth of hard work to make perfect :)
[14:58] <lilstevie> and it is fine to maverick
[14:59] <tjaalton> maybe something to do with the multitouch patches
[15:00] <lilstevie> hmm
[15:00] <lilstevie> i see
[15:00] <tjaalton> just guessing
[15:00] <lilstevie> it is weird cause the mouse cursor doesn't follow my finger but x is tracking the location the pointer should be at
[15:01] <lilstevie> and the weird tappy pattern is just a strange quirk, the touch frames are identical for each tap
[15:01] <tjaalton> hmm, cnd ^ ?
[15:01] <lilstevie> I have been logging the kernel output to make sure it wasnt that
[15:01] <lilstevie> heh cnd said it was time to start looking at evdev
[15:03] <cnd> lilstevie, it could be something where to get a tap you need to physically press down and up within a certain amount of time, but you must also move one pixel for it to register
[15:03] <cnd> maybe that's the bug?
[15:03] <lilstevie> cnd: hmm that would be difficult to confirm
[15:03] <cnd> yeah :)
[15:05] <lilstevie> cnd: it is also hard to reliably trigger a full click
[15:05] <lilstevie> cnd: but that at least 1px movement is something that could certainly be an issue
[15:06] <lilstevie> in none of the successful cases has there not been +px
[15:06] <cnd> you could use evemu-record to record good and bad clicks to see what is different
[15:06] <lilstevie> oh dear god :p
[15:06] <cnd> :)
[15:08] <lilstevie> going to do that now
[15:15] <lilstevie> cnd: I forgot the syntax for evemu, what did I need to do again
[15:15] <cnd> lilstevie, https://wiki.ubuntu.com/Multitouch/Testing/uTouchEvEmu#Debugging
[15:15] <lilstevie> ty
[15:17] <lilstevie> ok got then
[15:17] <lilstevie> them :D
[15:26] <lilstevie> cnd: http://lilstevie.geek.nz/touch/device.prop and http://lilstevie.geek.nz/touch/device.record
[15:34] <cnd> lilstevie, I won't be able to look at them for a while :(
[15:35] <cnd> you can read more legible output if you run evtest on the device node and then play the recording back
[15:35] <cnd> comparing the good and bad taps may give you an idea
[15:36] <lilstevie> hm ok
[15:41] <lilstevie> cnd: ok I am seeing a theme here
[15:43] <lilstevie> cnd: only one of X/Y are reported on touches that work
[15:43] <cnd> on touches that work?
[15:43] <cnd> I'd expect touches not to work if X and Y aren't both provided
[15:45] <lilstevie> the touches that register, as in those that follow the click action report only 2 of the 3 params
[15:45] <lilstevie> either X+Y, X+BTN_TOUCH, or Y+BTN_TOUCH
[15:47] <lilstevie> cnd: http://pastie.org/2134438 for instance is a touch that worked
[15:51] <cnd> lilstevie, that's weird
[15:51] <cnd> it shouldn't handle a touch unless both X and Y are provided
[15:51] <cnd> oh wait
[15:51] <cnd> evdev takes care of that
[15:52] <lilstevie> hm
[15:52] <cnd> so the problem is when BTN_TOUCH goes down but X and Y are not provided?
[15:52] <cnd> either X and Y are not provided, that is
[15:52] <cnd> shoot, that's not right
[15:52] <cnd> when both X and Y are not provided
[15:52] <cnd> if (!X && !Y)
[15:52] <cnd> :)
[15:53] <lilstevie> no the problem occurs when both X and Y are provided
[16:01] <lilstevie> actually nvm I phail that is the second fingers dummy data
[16:01] <lilstevie> cnd: the touch that works is showing btn_touch, X, and Y on finger being lifted as well
[16:02] <lilstevie> but the kernel driver only reports if movement has occured
[16:03] <cnd> lilstevie, so the kernel doesn't report BTN_TOUCH unless there's motion?
[16:03] <lilstevie> no btn_touch is reported when it changes
[16:03] <lilstevie> the kernel driver doesn't report ABS_X if ABS_X has not changed since last report
[16:04] <lilstevie> so when I lift my finger BTN_REPORT changes to 0, but X/Y haven't changed so no report
[16:04] <cnd> so it sounds like a kernel driver bug
[16:05] <cnd> do you understand how to fix it up at this point?
[16:05] <lilstevie> I think I have an idea,
[16:05] <cnd> cool
[16:06] <lilstevie> but it means using those cheap tricks I was hoping to not use, part of my cleaning up the driver for release is probably the one thing that will fux
[16:06] <lilstevie> fix this
[16:51] <tjaalton> lilstevie: is bug 637874 related?
[16:51] <ubot4> Launchpad bug 637874 in xserver-xorg-input-evdev (Ubuntu) "Ubuntu Patches in evdev cause regressions on touchscreen (affects: 8) (dups: 1) (heat: 46)" [Undecided,Confirmed] https://launchpad.net/bugs/637874
[16:52] <lilstevie> tjaalton: nah it is different
[16:52] <tjaalton> ok
[16:53] <lilstevie> tjaalton: this one has touch register in xorg core, but the mouse pointer doesn't move
[16:53] <lilstevie> I still get stuff like tooltips for where I touched
[16:53] <lilstevie> the "pointer" ends up where I touch
[17:18] <tjaalton> hmm, was the "hide a cursor after a few seconds" a change in the xserver or elsewhere?
[17:24] <bryceh> tjaalton, I recall the Dx team talking about something like that last sprint
[17:25] <bryceh> (think it was for removing 'clutter' from the screen)
[17:26] <tjaalton> i remember tseliot pointing out the change at some point
[17:26] <tjaalton> isn't the first time I'm asking :)
[17:29] <tseliot> tjaalton, bryceh: unclutter does it but I guess gtk applications do it now too
[17:30] <tseliot> there's no such thing in qt apps AFAIK
[17:32] <tjaalton> ok, so where do I throw bug 774434?
[17:32] <ubot4> Launchpad bug 774434 in xserver-xorg-input-evdev (Ubuntu) "mouse pointer disappears in ubuntu 11.04 (affects: 12) (dups: 2) (heat: 124)" [Undecided,Confirmed] https://launchpad.net/bugs/774434
[17:32] <bryceh> RAOF, what's the low down from that kernel graphics bug process meeting?
[17:32] <tjaalton> I could just close it
[17:33] <tjaalton> nah, tossed it over
[17:35] <RAOF> bryceh: Oh!  Basically that JFo's on a leave of absence and so we shouldn't be subscribing/assigning things to him and expecting that to do anything; we should just be tagging kernel-handoff-graphics to get things on their radar.
[17:35] <tjaalton> bug 796325 is fun
[17:35] <ubot4> Launchpad bug 796325 in xserver-xorg-input-evdev (Ubuntu) "USB HD used as pointer input dev (affects: 1) (heat: 254)" [Undecided,New] https://launchpad.net/bugs/796325
[17:35] <tseliot> tjaalton: but we don't install unclutter by default. I guess it's gnome/gtk/etc. that does it
[17:36] <tseliot> I can reproduce it here without unclutter
[17:36] <tjaalton> tseliot: ah ok
[17:36] <tjaalton> I have it installed in oneiric
[17:39] <tseliot> tjaalton: it turns out that I was right: https://bugzilla.gnome.org/show_bug.cgi?id=328516#c6
[17:39] <ubot4> Gnome bug 328516 in general "Hide mouse cursor when keyboard is in use and mouse isn't" [Enhancement,Unconfirmed]
[17:39] <bryceh> RAOF, ok
[17:40] <tjaalton> tseliot: yeah, thanks
[17:40] <tseliot> np
[17:40] <bryceh> RAOF, I re-tagged all the 'xorg-needs-kernel-fix' tagged bugs to 'kernel-handoff-graphics' yesterday
[17:41] <RAOF> bryceh: Great; we're therefore doing what we should be doing :)
[17:42] <bryceh> RAOF, did they indicate who on their end will be reviewing that list?
[17:42] <tjaalton> uh, cursor up key not working if xserver is not restarted (kubuntu)??
[17:42] <tjaalton> on logout
[17:43] <RAOF> bryceh: No; they no longer have a dedicated triager so I assume they're all scanning that list.
[17:50] <bryceh> ok, touched base with ogasawara
[17:51] <bryceh> sounds like they'll be scanning that list weekly, but for critical items we should ping them on #ubuntu-kernel
[17:59] <RAOF> Ok.  That sounds easy enough.
=== yofel_ is now known as yofel
[23:05] <horstle> does anybody know what this means "NVRM: Xid (0000:03:00): 6, PE0001"? 
[23:05] <horstle> seen at dmesg