=== |usr|bin|nice| is now known as |usr|bin|nice [07:23] * apw yaws [07:23] * apw pitches [07:24] * apw rolls [07:24] * amitk pulls back the rudder [07:24] * apw hears "pull up, pull up" [07:25] * amitk sucks at flight simulator and promptly crashes the plane [07:25] * apw was ok on the bbc back in the day... flying under the bridge upside down was tricky [07:38] heh, I learnt my flying skills in Elite [07:40] cking, :) that bbc flightsim had a lot of hours of my time [07:42] the wonders of 3d wireframe graphics on the 6502... [07:43] yeah amazing [07:43] and their GPU was a dac [07:44] I hacked up a 6502 line drawing routine that could pop out pixels in 98 cycles [07:45] those were the days... [07:45] sigh [07:45] heh yeah :) old bugger [07:55] <_ruben> 6502 .. that's c64'ish? [07:56] <_ruben> been too long, and am not too old yet :p [07:56] _ruben, that era yes. when computing hit the home for the very first time [07:58] when one could get a lot done in 1K of assembler.. [07:59] a scarey thought indeed, when your logout button takes up more RAM than you had space on all of your disk media [08:01] * apw is pretty sure his first hard drive in his PC was 15MB, and the OS and something useful fit on it === smb` is now known as smb [08:01] * gema thinks this is starting to feel like a kernel channel now :D [08:01] <_ruben> i recall picking up our first pc with my dad .. a laser xt .. the question was to go witha 20MB hdd or no hdd [08:02] <_ruben> and my dad upgrading our PET from 64KB to 128KB ram orso .. for 500 bucks .. hadda solder out the old mem chips and replace 'em with new ones :) [08:03] heh, the days when you could see the pins on chips [08:50] <_ruben> apw: fair point :) [08:50] <_ruben> the good ol' .1" spacing === arun__ is now known as arun [09:57] can i have a faster kernel.ubuntu.com for christmas? [09:57] ppisati, heh ... she a little reticent to do what you want ? [09:58] ppisati, Depends on how many times your sudo attempts fail [10:02] ppisati: how's your speed to k.u.c [10:02] ppisati: for me, sometimes 3k [10:04] Sounds as fast as from the hotel last week... [10:06] That's impossible. It's git, so it doesn't care about bandwidth. It just sprinkles more pixie dust on the bits and bytes and then magically makes everything faster. [10:06] i'm not talking about network, it's jst that gitweb is so slow... [10:07] btw, in the last few days since i upgraded to the latest kernel, after 3/4 hours of work. my trusty ps/2 dies [10:07] and i've to reboot to make it work again [10:07] did anyone experience this before? [10:07] ppisati, nope all stable here [10:07] Neither before nor after... [10:07] :( [10:07] ppisati, but what release you running on it [10:08] Linux newluxor 3.0.0-8-generic #11-Ubuntu SMP Fri Aug 12 20:23:58 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux [10:08] oneiric [10:08] i update it every morning [10:08] adventourous [10:08] :) [10:09] in fact half of the desktop is broken [10:09] btw, this usb eyboard sucks [10:09] Seems to have lost its k... :) [10:18] ppisati, well there is known death in the archive right now, see ubuntu-devel@ for details [10:21] shoot, and I just upgrade a test system... [10:22] smb, kiss it goodbye [10:22] apw, Definitely should not try to reboot it... :-P [10:23] * smb wonders whether it is Friday already... [10:23] the end of something :) [10:27] heh, I updated my lap-top 10 mins ago and it's working OK [10:28] cking, For me, apport seems to be one of those packages not really happy [10:29] however, typing seems really laggy on the desktop - it's as if something is getting in the way [10:32] cking, i think you should show that to colin king he is great at fixing those toughies [10:33] apw, that's just a rumour, anyhow colin king is busy at the mo [10:34] * cking double checks his US visa paperwork. gah, I dislike paperwork [10:35] VISA? [10:36] the ESTA stuff [10:36] ah ok [10:36] it's just a faff remembering my number, putting in hotel and flight info. [10:36] Isn't that supposed to be no *paper* work? [10:37] it's paperwork in electronic form IMHO [10:37] * smb never does update the thing. somehow I got in anyways... [10:38] Maybe its the reason they ask for the hotel and stuff again after putting the same information into the online checkin (which of course gives you no boarding passes because you could be lying) [10:39] cking, putting in what ? [10:40] cking, you do know you don't have to do that right ? [10:40] apw, In theory you have to update your esta thingy everytime you travel to the us [10:40] smb, thats not what it said when i applied. it said the info was optional (hotel) [10:40] well, I like to update it because they may do something nasty to be if I don't. being paranoid as usual [10:40] and i've never updated mine [10:40] maybe i am meant to. bah [10:41] Me neither, but the travel agency brought it up last time [10:41] Apparently its optional for the allowance [10:41] for the allowance ? [10:41] but you should (if you are nice) update it when you know [10:41] apw, wrong work maybe [10:41] allowing you in [10:41] word [10:41] they allow apw in? [10:41] ahh i see, for the permission perhaps [10:41] not if i am with _you_ no [10:42] ha [10:42] ahh gads, i've just realised, you and scott will be in the same place [10:42] cking has done every bit required, of course he *must* be a terrorist [10:42] yep, but we won't be travelling on the same plane, therefore it's OK [10:43] things only go pear shaped when scott and myself travel on the same plane/train/taxi/etc [10:46] cking, you claim ... [10:49] assert(trip_cking == trip_scott); [10:50] not !=? [10:51] yeah [10:51] * smb thinks there should be a tripit travel warning if that happens [10:51] though cking hides from tripit [10:52] Even more reason to get him some glove treatment (apart from acting suspiciously unsuspicious) [10:53] very funny [10:53] smb, you saying if I act weird then I'm OK? [10:54] cking, Of course, only people that want to do evil would not want to stick out, wouldn't they? ;) [10:54] smb, I'm doomed [10:55] cking, Too normal for the world. But I guess travelling with apw cancels out that a bit... :-P [10:56] quite a bit [10:58] only another 34 fwts tests to document.. sigh [11:03] * ppisati -> lunch [11:03] ppisati, A sec [11:04] smb: what? [11:04] ppisati, Just to confirm (since I got some mails about subscriptions to those) you got the tracking bugs for arm topic branch prepeartions too? [11:07] bug 800234 and 8000235 just in case not [11:07] Launchpad bug 800234 in gwibber "gwibber-accounts crashed with URLError in do_open(): (dup-of: 728844)" [Undecided,New] https://launchpad.net/bugs/800234 [11:07] Launchpad bug 728844 in gwibber "gwibber-accounts crashed with URLError in do_open(): " [Medium,Invalid] https://launchpad.net/bugs/728844 [11:07] errr [11:08] heh those are not even close specially the second on [11:08] forget it... there seems to be something with wastagin in it... [11:08] one [11:08] apw, Yeah, I think I got some test runs [11:08] bug #8000235 [11:08] But did not realize [11:08] bug 800235 [11:08] Launchpad bug 800235 in firefox "firefox addons web page is not opening just it keep loading" [Undecided,New] https://launchpad.net/bugs/800235 [11:09] oh i see its actually reading its _own _ output [11:09] See [11:09] apw, Well the numbers I saw are not valid in the "real lp world" [11:09] bug 800234 [11:09] Launchpad bug 800234 in gwibber "gwibber-accounts crashed with URLError in do_open(): (dup-of: 728844)" [Undecided,New] https://launchpad.net/bugs/800234 [11:09] Launchpad bug 728844 in gwibber "gwibber-accounts crashed with URLError in do_open(): " [Medium,Invalid] https://launchpad.net/bugs/728844 [11:10] Oh you mean that [11:10] Yeah [11:10] * smb wonders what would happen if a bug title contained its own number again... [11:11] smb: actually no [11:11] smb: did yu receive just now? [11:11] ppisati, No, I saw some but there were done in the staging system. I got one for ec2 for real, but maybe they just did not get that far for the fsl et al [11:12] dunn [11:12] i had some emails about the tracking bugs for the different arm topic branches [11:13] but didn't receive it right now [11:13] Those would be the ones. With "version to be filled". Those would have come yesterday [11:13] ah ok [11:13] yes, got them [11:13] I just got confused by the test ones [11:14] bt i didn't have anything to push [11:15] For ec2 it was at least the rebase (and actually needed one upstream patch to be brought into the file clones) [11:21] ppisati, do you not do the mvl-dove rebases when they are needed [11:22] apw: last time they did it [11:22] apw: uhmmm... [11:23] ppisati, You saw that email about passing of things to us, did you? :) [11:23] ppisati, ok then they may be happy doing so, probabally worth asking who is responsible in case they fall through the cracks [11:23] apw: maybe i did the rebase, and they closed the release... don't remember exactly... [11:23] ok [11:23] smb: you mean the "Updates on topic branches" mail, right? [11:24] yep [11:24] smb: yes, but i think i forgot it... :) [11:24] * ppisati goes to reread it... [11:25] ppisati, thanks for your feedback on those arm patches ... they have been hangin about for a while. am happy to carry them if we need to but we don't "know" anything about they at the moment [11:25] apw, On related topic, was I able to clarify the libbfd confusion? [11:26] not seen your reply yet, i am "better" at my email now, but not great [11:26] apw: ye, let's see what sakoman says [11:26] * smb was hoping... :-P [11:33] ogasawara, on burndown, we seem to have two sets now, the pitti ones we've used for sometime, and now the new status.ubuntu.com ones. There hwe is split out and on the kernel ones we are: http://status.ubuntu.com/ubuntu-oneiric/group/topic-oneiric-kernel-tasks.html [11:33] ogasawara, and there we are below the line! [11:36] Reset the trend line, simples. [11:36] Daviey, no they are genuine trend lines, its whats included and whats not that gets us there [11:37] the status ones split kernel into kernel and hwe and its hwe who are behind :) [11:37] but nothing they are doing is release critical so we don't really care if they are behind [11:52] ppisati, uploaded the meta package for linux-ti-omap4 3.0.0-1202.6 and sent announcement. [12:07] tgardner: ok, thanks [12:15] smb: it's still in demo-mode, right? i mean the new trackign bug etcetc [12:16] ppisati, The ec2 one was real. Have not looked out for any other. [12:17] i've 2 mvl-dove tracking bugs, bt they say "Ignore this bug" [12:18] and one on bugs.qastaging.launchpad.net [12:18] ok, i'll ask the SRU when they apper [12:18] *SRU people [12:18] Hm, one of the ec2 ones went to ignore as well [12:19] yeah, they should know [12:19] ppisati, smb: yep, they were closed because we are respinning today lucid and maverick kernels [12:19] ah ok [12:19] btw, in case i've noting to push, wat do i have to do? [12:19] so just ignore them for now, you will get new bugs after the new kernels are built again [12:19] herton, Seems only one. I've done a rebase to what was in lucid-master [12:21] ppisati: if you don't have anything to release, I think you can just close the bug, invalidating everything (you can do with check-release-tracking-bugs --bug= --invalidate) [12:22] smb: if you rebased that's fine, but you will have to rebase again, I'll push to master a fix to a CVE patch that brought a regression [12:23] herton, Not a problem just more work. Would have been good then to have both tracking bugs marked as, please ignore... :-) [12:25] smb: you mean the master lucid bug? it could be done, I just set it as a duplicate of the new tracking bug [12:26] herton, No I mean the two ec2 tracking bugs [12:26] bug 800236 [12:26] i've to disappear for half an hour [12:26] brb [12:26] smb, luckily the second rebase should be a slam dunk :) [12:27] apw, yeah [12:28] Argh [12:28] smb: 800236 doesn't find any bug here [12:28] herton, You really confuse people with those qastaging versions [12:29] smb: ah... I used qastaging for testing, everything on qastaging should be ignored :) [12:29] herton, Tell that the bug mailer... :-P [12:31] smb: hmm, I don't know how qastaging is setup, I thought it shouldn't sent any emails, weird. Never received emails from it, pehaps it's broken for direct people assignments, who knows [12:31] herton, It seems so. And unfortunately the mails look completely like real ones. Just with qastaging in the link. :/ [12:38] ppisati, smb: so just wait for new tracking bugs, they will be opened when the packages are built, nothing to do until then. I'm going to get sconklin review the new releases today and then do the upload, the bot will open the tracking bugs when everything is built. [12:39] herton, ack [12:40] apw: \o/, I'll update our status wiki's to point to the status.u.c burn downs [12:41] ogasawara, :) [12:44] ogasawara, what did we decide about SECCOMP (mode 2) in the end [12:45] apw: I'm waiting for an updated pull request as it currently breaks the build on arm [12:45] ahh yes, i remember now. cool [12:47] ogasawara, apw: I'm thinking it won't make the cut since its gonna take a major revamp to get it working on ARM [12:47] tgardner, might there be value to having it availabe on x86. it sounded like chromium was committed to using it [12:48] apw, perhaps. in that case we should use it as is and disable for armel ? [12:49] tgardner, that was kinda my thinking. arm is marjinal for users right now [12:49] apw, don't say that too loud. you'll have ogra_ crawling all over you. [12:50] :0 [12:51] back [13:18] ogasawara, we normally say EXPERIMENTAL =n, but for filesystems, sensors, etc we tend to say "but they are opt-in and we want them enabled for testing" ... does that sound about right? [13:18] apw: yep [13:19] ok so i am going to code that in, i am thinking filesystems, sensors, hid, netfilter things [13:19] as a first set of exceptions [13:22] cking, I now see what you meant with lagging. Seems every keystroke ponders about something. And trying to move a window my mouse pointer is at the target before the window even considers to move... [13:22] cking, Have you reported that already? [13:23] smb, see if you have kworker threads eating your machine [13:23] that sounds liek the symptoms i had when that was occuring [13:23] apw, Now compiz is using 8%cpu even when idling [13:24] apw, Only have a few kworkers and they do not show up prominently in top [13:26] smb, 2-3% on my netbook on oneiric [13:27] apw, consistently between 8 and 10 on a dual core dell... [13:27] smb, not yet [13:27] apw, Its ati gfx [13:27] smb, slightly more when there are stupid OSDs on the screen [13:28] smb, ok, i don't have those [13:28] apw, btw bug 828737 [13:28] Launchpad bug 828737 in ubuntu "The iconify and de-fullsize buttons are barely noticable" [Undecided,New] https://launchpad.net/bugs/828737 [13:29] * apw confirms it [13:30] wow, just moving a window makes compiz consume 12% of my CPU [13:30] cking, it must be falling back to doing something by hand [13:31] cking, What gfx card do you have? [13:31] does unity 2d work any better [13:31] smb, an old ATI Radeon X1300 [13:32] cking, May be a pattern as apw does not see it. I got some ati card as well [13:32] An X1200 [13:32] smb, since pulling in some updates this morning it feels less laggy [13:32] Hm, I just pulled the latest stuff [13:32] * smb does not want to know haw it was [13:34] * cking tries 2d [13:35] yep, 2d much snappier [13:35] still, moving a window gives 10% CPU loading [13:36] and terminal feels more responsive when typing - although the is a tad subjective [13:38] terminal resizing is a pain when you have wobbly touchpad input [13:39] cking, bug 828752 [13:39] Launchpad bug 828752 in compiz "Very slow responding system (compiz/ati?)" [Undecided,New] https://launchpad.net/bugs/828752 [13:39] smb, you verified this with 2d to see if it does the same? [13:40] cking, not yet. doing now [13:42] cking, Hm so compiz is not right... its the same in 2d but without any process to blame directly [13:42] though the typing is quicker [13:44] so it looks to me like the keyboard is being read in a timely manner, but rendering it is taking a while [13:44] do you see a lay when you switch to a text console? [13:44] s/lay/lag/ [13:44] doh [13:44] or s/lay/delay/ [13:45] cking, no, just on the way backl [13:46] cking, But actually typing text is rather normal in 2d (I had a one sec delay before a key typed would appear) [13:47] Just dragging windows feels like they are unwilling [13:47] Btu maybe that is a new feature... [13:48] sluggish windows a good feature?! [13:49] * smb did not say good [13:53] It feels as "good" as that for a restart you now have to click shutdown and then restart... === Guest67514 is now known as lag === lag is now known as Guest3769 [13:58] apw, do you remember how to change the I/O scheduler ? I'm thinking a HW RAID controller doesn't need any kind of elevator sorting. [13:59] tgardner: system wide, elevator= in grub, believe on a per fs basis somewhere in sys [14:00] vanhoof, I remember that there is a sysfs knob, but can't remember the name [14:01] tgardner: /sys/block/sda/queue/scheduler [14:01] tgardner, i think its per device in sysfs [14:01] tgardner, i will be supprised if no elevator is going to be better unless its to IO merging [14:01] but i assume you are going to measure [14:02] apw, how can it know if its talking to a HW RAID controller with 8 spindles ? [14:03] tgardner, it can't know, but sending lots of small IO's may not be an improvement over at least merging things nearby [14:03] tgardner, but i am all for trying it [14:04] apw, I'm just watching this Emerald idle along with 10-15 processes running and 1350 sleeping. wtf ? [14:04] cking: Nope, no lag here! [14:04] tgardner, i would very supprised if that much CPU couldn't kill almost any ammount of disk you add [14:04] Guest3769, very droll [14:05] apw, but only 10 processes running? I'd think a high end RAID controller could keep things busier then that. [14:06] tgardner i am keen to see if changing it helps any, try the others if not too [14:06] tgardner, my experience is if there isn't battery backed front end cache on the controller then its not going to like random IO [14:07] apw, I'm only seing write speeds in the 5M/s range, well below what its capable of. [14:07] I actually think even noop does merging. But I am not sure that the other elevators still take any geometry assumptions [14:07] and bear in mind this is a write heavy pattern, which is usually hindered by any sort of raid 5 type raid [14:08] as we have to write more than one sector for each sector, and often have to cut up the IO into smaller chunks [14:08] I wonder if there are any white papers on how to tune for HW RAID [14:08] cking: :D [14:08] cking: lag is in Africa [14:08] that is a goog question [14:08] good [14:09] apw, I think 'goog' is apropos :) [14:09] tgardner, heh i did chuckle at my own typo [14:09] * ogasawara back in 20 [14:16] Hi all. Are there any plans to include utrace support in onerick? [14:17] if that is extra kernel patches then its not in now, and unlikely to be [14:51] ogasawara, ok i've done the bulk of the annotations for the P config review we should ahve far fewer oddnesses in the session now [14:52] apw: awesome, thanks [14:57] * tgardner disappears into his server room [15:09] ogasawara, i have just found an NETFILTER match which is inconsistant on O, it really should have been caught in the review, so i am proposing to just fix it and push it up, that ok ? [15:09] apw: go for it [15:10] now that there are not 1000s of inconsistant entries its easier to find the ones one should worry on [15:11] ogasawara, done [15:12] ogasawara, also pushed it to u-p, i note that uses master not master-next ... which is a little odd [15:14] apw: yah, I didn't make master-next yet since I didn't think there'd be much conflict in pushing [15:14] apw: but will do so now [15:15] ogasawara, i more think of master as 'whats released' and master-next as 'next stuff' [15:15] so we almost could not have a master in there [15:23] * ogasawara migrates back to the office [15:26] Can someone take a look at https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/795823 ? [15:26] Ubuntu bug 795823 in alsa-driver "Dell Studio XPS - Internal Microphone not Working " [Undecided,Triaged] [15:26] I can confirm that the model= workaround works. [15:27] /whois jpds [15:28] apw: Oh hi. [15:28] hi, i've pushed it over to the kernel, as it will need a quirk [15:28] jpds, you do need to confirm that abolutly everything all the holes and jack detection etc works with that model= [15:29] if you can do that and report it in the bug [15:29] (not just the one mic you are trying to fix) [15:29] apw: I'll test it and see. [15:31] jpds and your machine isn't the one listed on that bug [15:32] (or is it) [15:33] jpds, can you please file a new bug for your issue with "ubuntu-bug audio"? (As hw might not be the same) [15:34] jpds, and do so in a state where you're trying to record from the internal mic [15:34] SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x02fe, [15:34] "Dell Studio XPS 1645", STAC_DELL_M6_BOTH), [15:34] it seems there is already a quirk to a different setting for that machine [15:34] aha [15:34] * apw hands over this one over to diwic :) [15:35] we had the same problem with dell studio 1558 [15:35] SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x0413, [15:35] "Dell Studio 1558", STAC_DELL_M6_DMIC), [15:35] SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x0413, [15:35] "Dell Studio 1558", STAC_DELL_M6_DMIC), [15:35] yeah we have _two_ entries for that puppy [15:36] oh, anybody want to have their name in the kernel? Some low-hanging fruit here :-) [15:37] oh no that is my incompetance, i'd copied it to add the new one before i dicovered it was already there [15:38] diwic, ok this 1645 was only set to STAC_DELL_M6_BOTH cause a reporter said it worked, they may have never tested the mic [15:39] apw, m6_both creates two mics whereof one does not work, and so user gets confused [15:40] apw, it would be good to have jpds alsa-info or apport info to see if that's the case [15:41] * apw pokes jpds [16:04] ogasawara, can you make " [16:04] UBUNTU: Stop ARM boards crashing when CUPS is loaded" (no-up) on your next rebase please [16:04] apw: yep [16:05] ogasawara, then thats lag's patched done and dusted, i've closed that WI [16:05] apw: sweet [16:08] tjaalton, hey you have a patch hanging around on our tree, and we are wondering if it is going upstream or ... "UBUNTU: SAUCE: Added quirk to recognize GE0301 3G modem as an interface" [16:10] apw: yeah I got a ping about it while on vacation, and actually refreshed my tree to create a patch for upstream, but didn't finish it yet :) [16:11] tjaalton, so can i say "its upstreamable and timo is sorting it out as time allows" ? [16:12] as i think from the review point of view that means keep it till it collides on rebase which is fine [16:12] apw: yeah, I believe it's still a valid patch [16:12] tjaalton, thanks :) i call that reviewed [16:12] cool :) [16:14] ogasawara, we should look a lot better in a few [16:14] apw: indeed. I think we only have one work item left for the delta review now. [16:16] ogasawara, two i think, both inprogress [16:16] apw: heh, I overlooked yours [16:17] apw: so I'm going to rip out master from P for now [16:19] ogasawara, yeah always me, sigh [16:19] ogasawara, works for me [16:25] * apw bails === JanC_ is now known as JanC [16:31] mdeslaur: building a kernel now with what jbarnes posted on the fdo bug [16:34] Sarvatt: cool, thanks [16:34] mdeslaur: amd64 or i386? [16:34] Sarvatt: please build it for oneiric, I'm on oneiric now [16:34] oh, ok [16:35] Sarvatt: I couldn't postpone updating any longer :) [16:52] mdeslaur: http://kernel.ubuntu.com/~sarvatt/fdo40172/ [16:53] Sarvatt: cool, thanks, give me a few minutes [16:57] * tgardner is off to buy a house. [16:57] cnd, you around? [17:01] yep [17:02] more touchpad questions for you :) [17:02] ok [17:03] in reference to this: http://pastebin.ubuntu.com/669405/ [17:03] it seems like the ABS_[XY] report in the last packet is making utouch's drag or flick detection get confused [17:03] since their 0, it detects an upward flick [17:04] but the buttons are being released [17:04] hmmm, our stack doesn't look at ABS_{X,Y} [17:04] so is that a driver problem (the driver shouldn't send the position) or a utouch problem? [17:04] really? [17:04] it looks at ABS_MT_POSITION_{X,Y} [17:05] because if I modify the driver so that those aren't sent, there's no upward flick at the end of my downward drag [17:05] hmm, maybe for semi-mt devices it looks at ABS_{X,Y} [17:05] we should check out the code of utouch-frame [17:05] (which I'm currently rewriting :) [17:05] I'd think since BTN_TOUCH and BTN_DOUBLETAP are released in that frame, it should ignore the position [17:06] this is something I'm encountering in testing the driver changes elantech sent earlier [17:07] ahh [17:07] what are you using to test touch? [17:08] to test utouch* that is [17:08] I have an oneiric install, and I'm just testing drag-to-scroll in various application windows [17:08] sforshee: is ginn running? [17:08] ps aux | grep ginn [17:09] nope [17:09] ok, good [17:09] so outside of a development version of ginn, we don't do scrolling through utouch (yet) [17:09] so this is an issue in xserver-xorg-input-synaptics [17:09] oh, okay [17:10] though it's in the code that I added [17:10] :) [17:10] at least I'm asking the right person then :) [17:10] well, actually, maybe not [17:10] let me try to remember [17:10] yeah, I don't think I touch scrolling [17:10] that's still handled through ABS_{X,Y} and BTN_TOOL_DOUBLETAP [17:10] which would explain why this is throwing things off [17:11] really, the driver shouldn't be emitting ABS_{X,Y} of any value when BTN_TOUCH is released [17:11] that's what I was thinking [17:11] so I would consider that a bug [17:11] but [17:12] it's pretty trivial to not send them from the driver too, so I'll probably suggest they make that change [17:12] not that the bug shouldn't be fixed :) [17:12] hmm? [17:12] I think we're talking about the same bug [17:12] the driver should be fixed [17:12] sorry, didn't read carefully enough (trying to multitask...) [17:13] if you mean that synaptics shouldn't be using an X and Y event when BTN_TOUCH is released [17:13] well, that would be great too :) [17:13] but it shouldn't have to check that [17:13] sforshee: thanks for testing it out! [17:13] either way, I'll just tell them to fix it in the driver [17:14] cnd, thanks! [17:16] Sarvatt: unfortunately, I can still reproduce [17:17] mdeslaur: darn.. mind commenting that on https://bugs.freedesktop.org/show_bug.cgi?id=40172 ? [17:17] Freedesktop bug 40172 in DRM/Intel "[arrandale] Fuzzy screen after dpms cycles on lenovo t510 [bisected, 3.0+]" [Normal,New] [17:17] Sarvatt: just did [17:17] thanks a ton! [17:18] np [17:25] sforshee: in return you can help jog my memory [17:25] how do I build the generic kernel from git [17:25]