| === MacSlow is now known as MacSlow|lunch | ||
| === MacSlow|lunch is now known as MacSlow | ||
| * bregma fills his cup from the water cooler | 14:14 | |
| xerent | hello! I'm implementing an USB multi-touch microcontroller and am looking for info about which drivers on the linux side I should be working with | 14:14 |
|---|---|---|
| bregma | cnd, any suggestion? ^^^ | 14:16 |
| cnd | xerent, are you asking about kernel drivers, or X drivers, or something else? | 14:16 |
| cnd | dandrader, tvoss, bregma: standups! | 14:16 |
| bregma | I finished off the geis branch for grail property settings, I'm not completely | 14:17 |
| xerent | well, both! | 14:17 |
| bregma | pleased so I'm buffing it, I'll post a merge request in a bit | 14:17 |
| tvoss | working on generic backend and putting some final touches on a huge iteration of the chromium patch | 14:17 |
| cnd | I'm going to try to figure out why behemoth touchscreen window motion is slower than expected | 14:17 |
| cnd | xerent, what is your end goal? | 14:17 |
| xerent | cnd: we've previously built our apps with Qt, using generic HID kernel and X drivers | 14:17 |
| xerent | and now we're looking to moving from single touch to multi touch | 14:18 |
| cnd | for general purposes, you want to provide multitouch through the kernel evdev interface | 14:18 |
| cnd | the rest of the X stack will take care of things | 14:18 |
| cnd | so either you need to create a linux driver, or you need to take the raw events in userspace and reinject them as a new input device using uinput | 14:19 |
| xerent | is there some driver for hid multi-touch digitizers floating around we could use? | 14:20 |
| dandrader | I am frustrated with the brittleness, slowness and unreliability of utouch-* integration tests. Thus I want to make a unit test for geis bug https://bugs.launchpad.net/bugs/984069 instead of an integration test. So right now I'm evaluating the best approach (and feasibility) to isolate the grail backend of utouch-geis, that is, where to draw the lines between live code and mocked code. I believe it should be straightforward to unit test utouch stu | 14:20 |
| dandrader | ff. After all, there's a good number of layers and interfaces around (frame, grail, geis, frontend/backends abstractions) that must help with the isolation. | 14:20 |
| cnd | there's documentation on the evdev protocol in Documentation/input/multi-touch-protocol.txt and Documentation/input/event-codes.txt | 14:20 |
| xerent | cnd: thank you | 14:20 |
| cnd | xerent, the generic hid-multitouch driver may work | 14:20 |
| cnd | if your device is win7 hid-multitouch compliant | 14:21 |
| cnd | dandrader, it would be good if we could fix some of the brittleness too | 14:21 |
| cnd | what issues were you hitting after we fixed dummy.conf | 14:22 |
| bregma | dandrader, for better unit testing in geis, you'd want to refactor the grail back end for geis to allow for mocking Xlib | 14:23 |
| bregma | or, at least, someone would want to do that | 14:24 |
| bregma | hmmm, maybe I'll look in to that later today | 14:24 |
| xerent | cnd: we might want to make it compliant in case our customers insist on installing windows on our devices, so :) | 14:24 |
| cnd | also, some of the long waits in the unit tests aren't really necessary if we properly code the tests to look for things like X input event addition events | 14:25 |
| xerent | or, at least, tricking Windows into thinking it's compliant. | 14:25 |
| bregma | I'm going to want to do a little refactoring to improve unit testing for the upcoming plugin-architecture changes to geis | 14:25 |
| xerent | cnd: anyways, thank you. | 14:27 |
| cnd | xerent, np :) | 14:27 |
| xerent | we're looking into bringing linux-based multi-touch into industrial vehicle controls. my job is awesome. | 14:30 |
| bregma | how well does multi-touch function in industrial environments? Does the dust and grim cause problems? | 14:34 |
| dandrader | cnd, the dummy xserver keeps hanging around instead of dying. In some tests sometimes there are protocol errors for XIQueryDevice. sometimes no device added events come at all from grail in tests | 14:35 |
| dandrader | they probably all have the same cause | 14:35 |
| cnd | hmm | 14:35 |
| xerent | well the main problems has been with grounding the PCAP screens and isolating them from EM interference | 14:35 |
| cnd | I'm guessing there is a mechanism to be sure that child processes die when parents die, we just need to find it | 14:36 |
| xerent | as for dust, the controls are often placed inside the vehicle (closed space) | 14:36 |
| xerent | though they are rugged to prevent dust and water etc. | 14:37 |
| xerent | also temperature might be an issue with some touch screens, but we havn't tested that much yet | 14:37 |
| bregma | cnd: setsid()? | 14:37 |
| xerent | we usually heat the devices from -40 degrees C to -20 using internal heaters before turning on power | 14:37 |
| cnd | bregma, why setsid? | 14:37 |
| bregma | when the session group leader dies, all its children should die | 14:39 |
| bregma | at least, that's the way it used to be, seems things keep changing under me these days | 14:39 |
| === dandrader is now known as dandrader|afk | ||
| cnd | hmm | 14:40 |
| bregma | you turn your back on these linux guys for a minute and they reinvent everything yet again | 14:40 |
| cnd | bregma, how are children killed? | 14:41 |
| cnd | are they sent a signal? | 14:41 |
| cnd | looks like the child gets SIGHUP? | 14:42 |
| bregma | I suspect the xorg server may be doing a setsid(), which may be the cause of the problem | 14:42 |
| bregma | I'm not sure what mechanism is used to kill the children, but sending a HUP followed by a KILL after a timeout rings a bell | 14:44 |
| bregma | or, no, TERM followed by KILL sounds better | 14:45 |
| cnd | bregma, I *think* because we are using the dummy driver setsid() isn't called | 14:45 |
| bregma | yes, and the captive server _usually_ gets shut down | 14:46 |
| bregma | the fact that it sometimes doesn't smells like some sort of race | 14:46 |
| cnd | bregma, well, xorg-gtest isn't calling setsid() | 14:46 |
| cnd | so the pgid is left as the pgid of the shell | 14:46 |
| bregma | that much is certain | 14:47 |
| cnd | right? | 14:47 |
| bregma | yes | 14:47 |
| cnd | so if we call setsid() we may be able to resolve the issue | 14:47 |
| bregma | it would be awkward to call setsid() in a foreground program, I think | 14:47 |
| cnd | hmm | 14:47 |
| cnd | bregma, maybe setpgid() for the child process? | 14:47 |
| cnd | would that have the effect we want? | 14:48 |
| bregma | maybe we just need to have an atexit call that explicitly kills the child.... we shouldn't need to, though, because child processes should die with their parent unless they take special action | 14:50 |
| bregma | we just need to find out why the captive server is not shutting down | 14:51 |
| bregma | I shall turn some attention to this, it needs some | 14:52 |
| cnd | bregma, dandrader|afk: I don't know off the top of my head under what circumstances the dummy x server will continue to live | 14:52 |
| cnd | do you? | 14:52 |
| bregma | no | 14:52 |
| bregma | that's why I suspect a race somewhere | 14:53 |
| === dandrader|afk is now known as dandrader | ||
| cnd | when I run sudo ./check-grail, the sudo process becomes the process group leader for both check-grail and the X server, and bash remains the session leader | 15:01 |
| cnd | if I run check-grail and then suspend it with ctrl-shift-z, then I kill the check-grail process, the x server lives on | 15:03 |
| cnd | I gdb'd the server process and I got SIGCONT when I killed check-grail | 15:07 |
| cnd | oh wait, that was probably because I had stopped it | 15:08 |
| cnd | it got SIGPIPE when I killed check-grail while it was running | 15:10 |
| cnd | but it just continues on | 15:10 |
| cnd | I'm beginning to think the best we can do is catch all fatal signals in xorg-gtest and terminate the X server | 15:21 |
| cnd | obviously we can't catch SIGTERM | 15:21 |
| cnd | but c'est la vie? | 15:21 |
| cnd | I mean we can't catch SIGKILL | 15:22 |
| cnd | biab | 15:29 |
| === dandrader is now known as dandrader|lunch | ||
| === dandrader|lunch is now known as dandrader | ||
| cnd | bregma, metres? | 17:39 |
| cnd | really? | 17:40 |
| bregma | aren't the values in metres? | 17:42 |
| cnd | bregma, they are in meters! | 17:48 |
| cnd | I have no idea what a metre is :) | 17:49 |
| * bregma considers bitter remarks on cultural hegemony regarding a measurement system not even use use by the hegemon | 17:49 | |
| bregma | http://en.wikipedia.org/wiki/Metre#Spelling | 17:53 |
| bregma | I think the threshold properties should have been in furlongs anyway | 17:54 |
| cnd | I think it's clear that the US has things correct, and everyone else is stuck in their ways since they use meter for devices but the two terms have the same etymology :) | 17:55 |
| bregma | the Ubuntu documentation style guide says to use U.S. spellings where there are alternatives, so I will change the comments | 18:03 |
| bregma | I believe the U.S. spelling is also 'the', so I will change that | 18:03 |
| cnd | bregma, I was just joking about metre, but I guess if the ubuntu doc style guide says so... | 18:21 |
| cnd | man, where does the time go? | 19:25 |
| cnd | it's already lunch time | 19:25 |
| === dandrader is now known as dandrader|biab | ||
| cnd | bregma, dandrader|biab: I have xorg-gtest daily builds working again | 21:14 |
| === dandrader|biab is now known as dandrader | ||
| cnd | I have to manually push the packaging branch | 21:14 |
| cnd | but now you can use ppa:utouch-team/daily to get the latest fixes | 21:15 |
| dandrader | hmm, opk | 21:15 |
| dandrader | ok | 21:15 |
| cnd | i.e. please review the patches I sent out and then you can have them too :) | 21:15 |
| dandrader | btw, the mocking is coming along nicely. I'm mocking all Xlib and XInput calls. Seems that only a very small subset is used by frame+grail+geis | 21:16 |
| cnd | dandrader, if you're mocking up X, I would poke robert ancel | 21:16 |
| cnd | he has been mocking up other parts of X for lightdm | 21:16 |
| cnd | and has extended an invitation for us to mock up the input stack in his X mock project | 21:17 |
| cnd | I just can't remember what the project is called off the top of my head | 21:17 |
| dandrader | ah, good to know | 21:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!