| eruditehermit | is there an input channel for ubuntu-x? | 01:48 |
|---|---|---|
| RAOF | What do you mean? | 01:49 |
| eruditehermit | for touchpad and keyboard questions | 01:49 |
| RAOF | Yes; #ubuntu-x :) | 01:49 |
| eruditehermit | I read that multitouch touchpads might work | 01:49 |
| eruditehermit | in 12.04 | 01:49 |
| eruditehermit | I tried letting ubuntu do the right thing but then my mouse doesn't work at all | 01:50 |
| eruditehermit | so I had to revert back to psmouse proto=exps | 01:50 |
| RAOF | What's your touchpad? | 01:51 |
| eruditehermit | well it appears as AlpsPS/2 ALPS DualPoint TouchPad in xinput list | 01:51 |
| eruditehermit | I am using a Sony VIAO SA 2011 model | 01:51 |
| RAOF | Is there a launchpad bug about this? | 01:52 |
| RAOF | cnd is the person most likely to be helpful with touchpads. | 01:52 |
| cnd | actually, sforshee may be the best first line of defense :) | 01:52 |
| cnd | sforshee wrote the multitouch patches for the ALPS touchpads for Linux | 01:53 |
| RAOF | Yeah, I guess he *was* doing the actual re work :) | 01:53 |
| cnd | the more people who do input stuff, the more I can shove off onto others | 01:53 |
| cnd | RAOF, would you like to work on input stuff :) | 01:54 |
| RAOF | Not particularly :) | 01:54 |
| RAOF | Actually - you can have me on input, but only as long as you ensure I never need to touch the SIGIO context. | 01:55 |
| cnd | RAOF, meh, I can live with that :) | 01:55 |
| eruditehermit | what does it mean if the mouse pointer doesn't even appear | 01:55 |
| cnd | eruditehermit, what did you try doing? | 01:55 |
| cnd | eruditehermit, the mouse pointer hides when you don't move it | 01:55 |
| cnd | so it likely means that you aren't moving it :) | 01:56 |
| RAOF | cnd: You know that basically every line of the input stack gets called from the gorram SIGIO context, right? :) | 01:56 |
| eruditehermit | cnd, Running 12.04 if I boot without kernel params for psmouse I cannot see or use my mouse at all | 01:56 |
| cnd | RAOF, no, only the input modules basically | 01:56 |
| eruditehermit | even if I move it no mouse pointer appears | 01:56 |
| cnd | most of the xserver input stack is run in normal context | 01:56 |
| cnd | eruditehermit, that's odd | 01:56 |
| eruditehermit | however if I boot with psmouse proto=exps, I can use my mouse but with limited functionality | 01:57 |
| * RAOF is just bitter that his pointer barrier work *is* unexpectedly called in the SIGIO context. | 01:57 | |
| cnd | RAOF, ewww | 01:57 |
| RAOF | Indeed. | 01:57 |
| RAOF | This is why people report "sometimes the X server freezes when I try to reveal the launcher" - because I'm sending events from SIGIO. | 01:58 |
| eruditehermit | cnd, xinput list-props says Device Enabled 1 | 01:58 |
| eruditehermit | what should I try? | 01:58 |
| cnd | eruditehermit, it sounds like you have a kernel driver issue | 01:58 |
| cnd | eruditehermit, are you able to ping sforshee earlier in the day? | 01:59 |
| eruditehermit | I can try | 01:59 |
| cnd | eruditehermit, actually, the best thing would be to file a bug | 01:59 |
| cnd | ubuntu-bug linux | 01:59 |
| cnd | then subscribe seth forshee | 01:59 |
| eruditehermit | cnd, is there a way to determine the actual hardware in the touchpad? | 02:00 |
| cnd | eruditehermit, if it's not detecting the make and model automatically, then there's no easy way | 02:01 |
| cnd | eruditehermit, do you know that it's an ALPS trackpad? | 02:01 |
| eruditehermit | not sure | 02:01 |
| eruditehermit | It is telling me | 02:01 |
| eruditehermit | AlpsPS/2 ALPS DualPoint TouchPad | 02:02 |
| eruditehermit | however I wanted to confirm that it is actually true | 02:02 |
| cnd | eruditehermit, then it probably is ALPS | 02:02 |
| cnd | I've not heard of accidental identifications | 02:03 |
| eruditehermit | ok | 02:03 |
| cnd | it would require a device to almost purposefully look like a different one | 02:03 |
| eruditehermit | well in that case | 02:03 |
| eruditehermit | that is what I have | 02:03 |
| eruditehermit | I have a Sony VPCSA-290X | 02:03 |
| cnd | eruditehermit, sforshee should know best then, he's worked on the ALPS driver quite a bit | 02:04 |
| eruditehermit | ok | 02:04 |
| eruditehermit | I will talk to him and file a bug report tomorrow | 02:06 |
| eruditehermit | is there a way to check that any events are even being picked up by the driver? | 02:07 |
| cnd | eruditehermit, there are lots of diagnostic tools :) | 02:17 |
| cnd | when you file a bug report, a utouch-evemu recording would be helpful | 02:17 |
| cnd | https://wiki.ubuntu.com/Multitouch/Testing/uTouchEvEmu#Debugging | 02:17 |
| eruditehermit | cnd, ok will do | 02:27 |
| eruditehermit | thanks! | 02:27 |
| cnd | np :) | 02:27 |
| RAOF | Dear X: I hate you, and your asynchronicity. No love, Chris. | 05:30 |
| Sarvatt | why the heck do I get flooded with this just closing my lid and reopening it http://kernel.ubuntu.com/~sarvatt/evtest.txt | 05:36 |
| RAOF | That's a lot of events for closing+opening :) | 05:37 |
| Sarvatt | i always come back to tons of new windows opened these days | 05:37 |
| RAOF | Too sensitive touchpad? Is it reading the screen or something? :) | 05:37 |
| RAOF | Good. That seems to now dependably pass the tests. Will it do so in a chroot, though. That is the question! | 06:00 |
| RAOF | New question: Do these passing tests mean that the server (a) works, and (b) won't crash on me? Tune in next time to find out! | 06:09 |
| RAOF | Hm. Well, that *has* fixed both the crashes and the potential deadlocking. Now, about that runaway memory usage… | 06:45 |
| seb128 | does anyone here know if cnd got anywhere with the gtk mouse wheel scrolling issue | 09:46 |
| seb128 | or with the scroll increment being buggy on i386 rather | 09:47 |
| seb128 | ? | 09:47 |
| FernandoMiguel | I only have buggy scrool with mouthpad... usb mouse is fine.... but I'm on x64 | 09:49 |
| tjaalton | seb128: no idea | 09:50 |
| eruditehermit | sforshee, please ping me when you are awake | 09:54 |
| eruditehermit | thank you in advance | 09:55 |
| === chrisccoulson_ is now known as chrisccoulson | ||
| === yofel_ is now known as yofel | ||
| FernandoMiguel | evening | 22:19 |
| cnd | RAOF, did your pointer barrier stuff get into ubuntu, and is it being used? | 22:26 |
| cnd | I'm curious to know what new functionality exists on my desktop :) | 22:26 |
| RAOF | cnd: It is in Ubuntu, and it is being used. | 22:32 |
| RAOF | It's how the launcher reveal works. | 22:33 |
| RAOF | So it's only really being used if you've got the launcher to autohide. | 22:33 |
| cnd | ahh | 22:33 |
| cnd | RAOF, so what is the algorithm that we settled on? | 22:33 |
| cnd | do you have to move a certain distance? | 22:33 |
| cnd | or with a certain speed? | 22:34 |
| RAOF | To parts: | 22:34 |
| RAOF | The barrier is entirely transparent if you hit it above a certain speed. | 22:34 |
| RAOF | Once you hit it, it generates events, and the client can then release the barrier at it's will. | 22:35 |
| RAOF | You *may* be able to correlate “generates events” with me bitching about stuff being called in the sigio context :) | 22:35 |
| cnd | heh | 22:36 |
| cnd | I hope you aren't trying to generate events on the heap in SIGIO :) | 22:36 |
| RAOF | No. I was blissfully unaware that I was being *called* from SIGIO, and so was sending events to clients from the handler. | 22:37 |
| RAOF | This works amazingly often. | 22:38 |
| cnd | ahh | 22:38 |
| cnd | yeah, SIGIO almost always works | 22:38 |
| cnd | sounds like we need to fix SIGIO :) | 22:38 |
| RAOF | As in: it didn't fail once on *my* machine. | 22:38 |
| RAOF | By ‘fix’ do you mean ‘use a real input handling thread, like nature intended’? | 22:40 |
| cnd | heh | 22:40 |
| cnd | RAOF, do you remember how someone at nokia was attempting to do that? | 22:40 |
| RAOF | Signals: 100% of the pain of multithreading, plus a whole lot of stupid restrictions! | 22:40 |
| cnd | apparently they hit some nasty problems the further they dug | 22:40 |
| RAOF | Yeah, tiago, right? | 22:41 |
| cnd | maybe | 22:41 |
| cnd | so I guess the work has been abandoned, sadly | 22:41 |
| cnd | I think they hit issues when they would update the pointer sprite and/or sprint rendering from the input thread | 22:41 |
| seb128 | cnd, stop chatting and fixing scrolling ;-) | 22:41 |
| cnd | seb128, I am just about to upload! | 22:43 |
| seb128 | \o/ | 22:43 |
| seb128 | cnd, thanks | 22:43 |
| cnd | seb128, did you see my bug? | 22:43 |
| seb128 | cnd, I just got dobey asking about it :p | 22:43 |
| cnd | I subscribed you | 22:43 |
| cnd | heh | 22:43 |
| seb128 | cnd, no ... | 22:43 |
| cnd | seb128, I just created it an subscribed you about 10 mins ago | 22:43 |
| seb128 | let me check emails | 22:44 |
| cnd | seb128, I just uploaded | 22:45 |
| seb128 | cnd, ok, great, https://bugs.launchpad.net/ubuntu/+source/libxi/+bug/949465 right? | 22:45 |
| ubottu | Launchpad bug 949465 in libxi (Ubuntu) "XIScrollClass increment value incorrectly handled on 32-bit machines" [High,In progress] | 22:45 |
| seb128 | cnd, thanks a lot for fixing it, and sorry for being pingy about it ;-) | 22:46 |
| cnd | seb128, nah, np :) | 22:46 |
| cnd | seb128, I'm going to send the patch to xorg-devel now | 22:47 |
| cnd | who should I Cc so gtk devs are aware? | 22:47 |
| seb128 | gtk-devel-list@gnome.org | 22:47 |
| seb128 | if you want to Cc them | 22:48 |
| cnd | seb128, I'm wary of cross subscribing | 22:48 |
| cnd | an entire list | 22:48 |
| cnd | but if you think that's the best way, it's not a big deal | 22:48 |
| seb128 | cnd, mclasen@redhat.com then | 22:48 |
| seb128 | should be enough | 22:48 |
| cnd | ok | 22:49 |
| cnd | RAOF, bryceh: I'm about to upload a new xserver with updated input stack from 1.12 and a fix for bug 929408 | 23:36 |
| ubottu | Launchpad bug 929408 in xorg-server (Ubuntu) "X does not send multitouch touch end events properly" [High,In progress] https://launchpad.net/bugs/929408 | 23:36 |
| cnd | anything you need me to add in? | 23:37 |
| bryceh | cnd, I notice there's a couple patches on the upstream xserver that look worth including | 23:37 |
| cnd | bryceh, input related, or otherwise? | 23:37 |
| * RAOF would *like* to include a fix for barriers, but that's not yet baked. | 23:38 | |
| bryceh | input, yes | 23:38 |
| bryceh | hang on | 23:38 |
| bryceh | 2416ee4a015068359807a10f433e8c54192c78a9 and 38000e7d1f958f5944e641de3e716944a5876d41 | 23:39 |
| bryceh | fixes for bug fdo #38313, which afaict doesn't affect us, but hard to say for sure | 23:39 |
| bryceh | or I should say, s/doesn't affect us/hasn't been reported to us/ | 23:39 |
| cnd | bryceh, already got them | 23:40 |
| cnd | locally in the branch I'm cooking at least | 23:40 |
| bryceh | cnd, RAOF, we seem to have a slew of xserver crashes amongst inputty stuff | 23:40 |
| bryceh | cnd, excellent | 23:40 |
| cnd | bryceh, do they look like one or two bugs? | 23:40 |
| cnd | or many? | 23:40 |
| cnd | btw, there's currently a memory leak in the server when using gestures | 23:41 |
| cnd | which is what I'm fixing for bug 929408 | 23:41 |
| bryceh | cnd, it sort of feels like there's invalid memory and bad pointers floating about | 23:41 |
| ubottu | Launchpad bug 929408 in xorg-server (Ubuntu) "X does not send multitouch touch end events properly" [High,In progress] https://launchpad.net/bugs/929408 | 23:41 |
| bryceh | i.e., they're not simple NULL pointer deref issues, but oddball stacktraces | 23:42 |
| cnd | hmmm | 23:42 |
| cnd | RAOF, could they be because of your SIGIO issue? | 23:42 |
| cnd | or has that already been fixed? | 23:42 |
| RAOF | Some of that *might* be me, yes. | 23:42 |
| bryceh | I *suspect* that a lot of these are dupes of the same underlying issue | 23:42 |
| cnd | I think we should assume they are due to the SIGIO issue until it's fixed and we still see it | 23:43 |
| cnd | because the signature of a SIGIO issue is random corruption :) | 23:43 |
| bryceh | RAOF, bug #948858 might be yours? | 23:43 |
| ubottu | Launchpad bug 948858 in xorg-server (Ubuntu) "Xorg crashed with SIGSEGV in WriteToClient()" [Medium,New] https://launchpad.net/bugs/948858 | 23:43 |
| bryceh | RAOF, "Unity crashed when moving the cursor to the top left corner" | 23:43 |
| RAOF | Yup, entirely possible. | 23:44 |
| bryceh | separate from these crashes, we're also seeing a bunch of SIGABRT bugs, that have crap for traces. Anyone have a clue on those? | 23:44 |
| cnd | bryceh, why are the traces bad? | 23:44 |
| bryceh | bug #948733 for example | 23:44 |
| ubottu | Error: Launchpad bug 948733 could not be found | 23:44 |
| bryceh | cnd, they are all like this: | 23:44 |
| bryceh | Stacktrace: | 23:44 |
| bryceh | #0 0x00a20416 in ?? () | 23:44 |
| bryceh | No symbol table info available. | 23:44 |
| bryceh | Cannot access memory at address 0xbfc714f0 | 23:44 |
| cnd | hmmm | 23:45 |
| cnd | could be memory corruption again? | 23:45 |
| RAOF | Maybe? | 23:46 |
| bryceh | I haven't seen bug reports with stacktraces like those since maybe a few weeks ago, and there's probably a dozen or so since, if that helps scope things | 23:46 |
| cnd | RAOF, if it makes you feel any better, our first implementation of the X gesture extension had the same problem :) | 23:47 |
| RAOF | I guess a stacktrace like that could be calling off into random memory... | 23:47 |
| cnd | we were emitting gesture events from within the sigio context | 23:48 |
| RAOF | cnd: Yeah, I think it's a fairly common thing to want to do. | 23:48 |
| * RAOF has fixed the WorkQueue to make this possible. | 23:48 | |
| bryceh | should I just close them out (assuming there's not something obvious in the traces) and have them re-report after your upload(s)? Or think they're worth keeping around for further study? | 23:48 |
| cnd | perhaps we should add a check in WriteToClient for whether we are in SIGIO context or not | 23:48 |
| RAOF | cnd: Not a terrible idea; add a flag to something, hidden behind DEBUG? | 23:49 |
| cnd | bryceh, by close them out do you mean ask for confirmation in latest xserver and moving to incomplete? | 23:49 |
| cnd | so they autoexpire after 60 days? | 23:49 |
| cnd | RAOF, I wouldn't even hide it behind a flag | 23:49 |
| bryceh | cnd, I could do that, but I meant close out as in mark fixed and tell them to file new bugs if they still get crashes | 23:49 |
| cnd | RAOF, it's not like a check would be heavy weight right? | 23:50 |
| cnd | bryceh, it irks me to think about bugs that are marked as fixed when we don't really know they are | 23:50 |
| cnd | or at least don't have the submitters verifying | 23:50 |
| RAOF | cnd: True. | 23:50 |
| cnd | but waiting for the expiration will entail 60 days of bugs hanging around that are probably fixed | 23:51 |
| cnd | I don't know how much that factors into your bug wrangling :) | 23:51 |
| bryceh | nah if they're incomplete without response they're excluded from my view | 23:52 |
| bryceh | I suspect a lot of these crashes are one-time one-off things though, mostly without reproduction steps, so hard to definitively know they're fixed | 23:52 |
| cnd | yeah, even if you're sure | 23:53 |
| cnd | as in, think you're sure | 23:53 |
| bryceh | on the plus side, apport seems to be catching these crashes ok, so if they're not fixed, people will be able to easily file new ones | 23:53 |
| bryceh | anyway, setting to incomplete is fine by me, I'll make it so | 23:54 |
| cnd | perhaps with a boilerplate message of: We think your bug has been fixed, but it is not possible to verify based on the information in this bug report. We are moving this bug to fix released. Please re-open if you encounter the bug again." | 23:54 |
| * bryceh nods | 23:54 | |
| cnd | hooray! | 23:56 |
| cnd | my integration test passes on the server I'm about to upload | 23:56 |
| cnd | bryceh, RAOF: just double checking, you don't have anything else to consider for the upload? | 23:56 |
| bryceh | nope | 23:56 |
| bryceh | hmm, I could also dupe the bugs up. that might be tidier | 23:57 |
| cnd | yeah | 23:58 |
| cnd | though it makes it harder for someone to reopen their specific bug if they hit it | 23:59 |
| cnd | if they hit it again, that is | 23:59 |
| cnd | they have to undupe, and then reopen | 23:59 |
| cnd | but maybe we want them to file a new bug anyways? | 23:59 |
| bryceh | they wouldn't need to reopen, just undupe | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!