| RAOF | :) | 00:08 |
|---|---|---|
| bschaefer | racarr__, hey, are you still around? Weird problem im seeing with mir(sdl)/finger events | 01:24 |
| bschaefer | racarr__, i get the first finger down, the motion events, but when i left my finger up, not finger up action? | 01:24 |
| RAOF | Odd. | 01:26 |
| bschaefer | yeah, i think ill have to dig into mir/android input stack... not sure where its going missing from | 01:27 |
| bschaefer | android doesn't handle mouse up/down very well either (up is just an empty event with no state) | 01:28 |
| bschaefer | ish | 01:28 |
| bschaefer | RAOF, im assuming the finger events are working just fine on unity8, so im assuming im handling things incorrectly in SDL | 01:28 |
| duflu | Speaking of which, I discovered last night that Android-input converts two-finger drags on my ThinkPad to what appears to be 3-finger events. Weird. | 01:29 |
| bschaefer | very strange | 01:29 |
| bschaefer | the fun part, if i do a second finger down, i get a finger up event | 01:30 |
| duflu | Either that or there's a tool type demo-shell is supporting by accident :) | 01:30 |
| RAOF | duflu: Yeah, the android input stack does _weird_ things to touchpads. | 01:30 |
| duflu | RAOF: Also "click" is not button 1 :) | 01:31 |
| RAOF | bschaefer: Huh. My input acceptance tests don't check for any finger-up events. I should probably add that. | 01:31 |
| RAOF | duflu: It should be if you have exactly one finger down? | 01:31 |
| RAOF | duflu: At least, it was for me. | 01:31 |
| bschaefer | RAOF, well im assuming they are working, as with unity8 you can press icons :) | 01:31 |
| duflu | RAOF: Yeah it varies significantly between laptops :S | 01:31 |
| duflu | RAOF: Oh my memory failed me... it's different: https://bugs.launchpad.net/mir/+bug/1194057 | 01:32 |
| ubot5 | Ubuntu bug 1194057 in Mir "mir_motion_action_move not received for thinkpad buttons (only for the clickpad)" [Low,Triaged] | 01:32 |
| racarr__ | bschaefer: Are you looking in to silvns issue? | 01:36 |
| racarr__ | I was looking in to his touchscreen issue and now he | 01:36 |
| bschaefer | racarr__, no my own now :( | 01:36 |
| racarr__ | is on a similar issue | 01:36 |
| racarr__ | oh | 01:36 |
| bschaefer | yeah | 01:36 |
| racarr__ | he has the same issue | 01:36 |
| bschaefer | he poked me about it, but i swear he had up/down fine | 01:36 |
| bschaefer | with 1 finger | 01:36 |
| bschaefer | racarr__, also demo finger paint doesn't seem to want to work | 01:37 |
| bschaefer | o also... im using an N7 | 01:37 |
| bschaefer | killing unity8, and using the mir server on its own (not sure what "unsupported" with the N7) | 01:37 |
| duflu | bschaefer: https://bugs.launchpad.net/mir/+bug/1239501 | 01:37 |
| ubot5 | Ubuntu bug 1239501 in Mir "Nexus 7 does not respond to touch" [High,Expired] | 01:37 |
| bschaefer | well | 01:37 |
| bschaefer | that could explain a few things | 01:38 |
| * bschaefer needs to get a supported touch N<number> | 01:38 | |
| duflu | bschaefer: Reopen? | 01:38 |
| bschaefer | duflu, well the N7 is an unsupported device | 01:38 |
| bschaefer | duflu, but yeah i can reproduce these issues | 01:38 |
| bschaefer | 3 finger touch isn't moving windows | 01:39 |
| duflu | bschaefer: Sure, but Mir is open source. All real bugs are valid just lower priority if not official :) | 01:39 |
| bschaefer | duflu, let me double check by getting trunk dev mir | 01:39 |
| bschaefer | duflu, as im using whats in main 14.04? or 14.10 | 01:39 |
| duflu | bschaefer: Your Ubuntu release presently won't matter if you're compiling Mir from source | 01:43 |
| duflu | Let's see how long that lasts... hopefully a while | 01:43 |
| bschaefer | duflu, right, but i was using main mir-demos for my testing | 01:43 |
| bschaefer | so i wanted to double check it was still happening on trunk mir | 01:43 |
| duflu | bschaefer: trusty is only one point release behind utopic: https://launchpad.net/ubuntu/+source/mir | 01:44 |
| bschaefer | yeah im on trusty: 0.1.8+14.04.20140411-0ubuntu1 | 01:44 |
| bschaefer | for libmirclient7 | 01:44 |
| bschaefer | duflu, that bug was closed a bit ago :), soo yeah | 01:45 |
| duflu | bschaefer: Not closed. Only expired because it stopped happening for no apparent reason :) | 01:45 |
| bschaefer | duflu, yeah, i mean it stopped happing for no apparent reason a bit ago, and i would have had that fix | 01:45 |
| bschaefer | using mir-demos, soo mir trunk wont do much :( | 01:46 |
| duflu | bschaefer: There was no fix. The bug came and went even before it expired | 01:46 |
| duflu | So I guess it's come again | 01:46 |
| bschaefer | duflu, hmm i wonder if its because everyone stopped using the N7? | 01:46 |
| bschaefer | yeah | 01:46 |
| bschaefer | duflu, o and thanks for the bug link :), i should have attempted to check bugs | 01:47 |
| === chihchun_afk is now known as chihchun | ||
| duflu | RAOF: Oh the two-finger window Alt+dragging on my touchpad looks like it might be an accidental feature. And one I might make use of :) | 03:11 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| RAOF | Grr. You can't actually change an interface at all and preserve ABI, can you? | 08:25 |
| RAOF | Oh, well. EOD. | 08:25 |
| === dandrader is now known as dandrader|afk | ||
| duflu | alf_: I'm off to make dinner then back later. In the mean time, consider this problem: https://bugs.launchpad.net/mir/+bug/1317370/comments/9 | 10:02 |
| ubot5 | Ubuntu bug 1317370 in Mir "[regression] [BufferQueue] BufferQueueTest.compositor_never_owns_client_buffers is very slow (up to 30 seconds) on fast machines" [High,Triaged] | 10:02 |
| duflu | It's an interesting case. I hope I missed something. | 10:02 |
| alan_g | dednick: AIUI a helper can only have one active trust session the session mediator? So why does it need a client side handle to a trust session? Isn't the connection a sufficient identifier? | 10:04 |
| dednick | alan_g: when i originally wrote it, there wasn't actually that limitation, and the handle hung about. I'm not exactly sure if we want that limitation either, at the moment. | 10:10 |
| dednick | alan_g: but anyway, i think it adds a bit of separation of "ideas". | 10:11 |
| dednick | alan_g: i mean that i'm not sure we want the one-to-one limitation in the long run. | 10:14 |
| alan_g | dednick: Ack | 10:14 |
| alan_g | tvoss: opinion? ^^ | 10:15 |
| tvoss | alan_g, dednick we want one helper to be able to handle multiple trust sessions | 10:16 |
| tvoss | for example: multiple content picking operations | 10:16 |
| dednick | tvoss: at the same time? | 10:18 |
| tvoss | dednick, yup, they are stateful | 10:18 |
| dednick | tvoss: ok. phase 2? | 10:18 |
| alan_g | tvoss: from the same connection? Or can it use a connection for each? | 10:19 |
| tvoss | dednick, yup | 10:19 |
| tvoss | alan_g, connection as in ordinary Mir connection? | 10:19 |
| alan_g | tvoss: Yes. But I'm starting to wonder if it is a new type of connection and not the same thing we have to manage surfaces. | 10:20 |
| tvoss | alan_g, that's why we introduce trusted sessions as I understand it | 10:20 |
| === dandrader|afk is now known as dandrader | ||
| alan_g | tvoss: but the proposed API implies it is owned by a connection (in the same way that surfaces are). Not that it is a different type of connection. | 10:22 |
| tvoss | alan_g, why would it need to be owned by something different than a connection? | 10:22 |
| alan_g | tvoss: currently we have one type of connection. It manages surfaces. The proposed API says it manages surfaces and an optional trust session. Why can't we have one connection type for surfaces and one connection type for a trust session? | 10:25 |
| tvoss | alan_g, why would adding another type of child (surfaces and trust sessions) require a new type of parent? | 10:27 |
| tvoss | alan_g, also: a trust helper might want to have surfaces as well | 10:27 |
| tvoss | alan_g, which have to be added to trust sessions | 10:27 |
| alan_g | What is the relationship between any surfaces and any trust session(s)? | 10:27 |
| alan_g | but trust sessions don't know about surfaces - only processes | 10:28 |
| tvoss | well, they should know about surfaces ultimately | 10:28 |
| tvoss | alan_g, a surface belongs to a connection but can be referenced by a trust session | 10:29 |
| alan_g | Should a trust helper surface be associated with a specific trust session or all (or some)? | 10:29 |
| tvoss | alan_g, at most by one | 10:29 |
| alan_g | tvoss: at one time or over the duration of the connection? | 10:34 |
| dednick | alan_g: this is all "ultimately". not for this iteration. | 10:35 |
| dednick | just to remind :) | 10:35 |
| alan_g | dednick: I know - but I'd like the conceptual model to be right before we publish APIs | 10:36 |
| tvoss | alan_g, at any point in time, a surface can be referenced by at most one trust session | 10:39 |
| alan_g | But it can be removed from one and added to a different one? | 10:40 |
| tvoss | alan_g, yup, that's certainly possible | 10:40 |
| dednick | alan_g: can you take a look at: https://code.launchpad.net/~nick-dedekind/mir/test_new_fds_for_trusted_clients when you get a chance? | 11:29 |
| dednick | Was taking a look at the problem with child sessions not stopping. The test creates a server and client. the client creates some fds, which another client connects with. | 11:29 |
| dednick | The child that connected to the fd is crashing when shutting down, and the server is not getting a disconnect for it. | 11:29 |
| dednick | stack for the client crash: http://pastebin.ubuntu.com/7467385/ | 11:31 |
| alan_g | dednick: ack. Was taking a first look at ~nick-dedekind/mir/trusted_sessions/+merge/218975 before getting into the issue you mentioned yesterday | 11:31 |
| dednick | alan_g: ok. thanks | 11:32 |
| dednick | i'm taking a guess, but i think the server may be closing the fd's which were opened by the parent client. | 11:34 |
| dednick | when the parent client connection is released | 11:35 |
| alan_g | dednick: Hmm. The server closes FDs once it has sent them (but they're open in the other process). I don't think it tracks them after that. | 11:37 |
| dednick | alan_g: sent them? over to the parent client over ipc? | 11:37 |
| alan_g | ack | 11:38 |
| dednick | alan_g: hm. but they won't be open in the other process by then. | 11:38 |
| alan_g | dednick: Oh yes they are. (The FDs not the connections) | 11:39 |
| alan_g | we've been doing it for years. | 11:39 |
| dednick | alan_g: i think i'm getting confused. but we only start the child client process after we've got the response from the server for the new_fds_for_trusted_clients. | 11:41 |
| alan_g | Yes, but you already have the FD in your process. | 11:41 |
| * alan_g has to go make lunch - BIAB | 11:42 | |
| === alan_g is now known as alan_g|lunch | ||
| === dednick is now known as dednick|lunch | ||
| dandrader | when a surface is resized ( mir::scene:surface::resize() ) should the client recreate his eglSurface or do anything at all? | 12:24 |
| alf_ | dandrader: no, unless you need to draw differently somehow (otherwise everything will just be scaled) | 12:33 |
| dandrader | alf_, ok | 12:33 |
| alf_ | dandrader: scaled => assuming you are drawing using relative sizes (e.g. using the -1,1 coordinate system of GL) | 12:34 |
| === greyback is now known as greyback|food | ||
| === dandrader is now known as dandrader|lunch | ||
| === tedg is now known as ted | ||
| === alan_g|lunch is now known as alan_g | ||
| === ted is now known as tedg | ||
| alan_g | dednick: @https://code.launchpad.net/~nick-dedekind/mir/test_new_fds_for_trusted_clients - I don't understand what's going on with SharedRegion. Are you using shared memory to copy the FD ids from one process to another without migrating the FDs themselves? | 13:15 |
| === greyback|food is now known as greyback | ||
| dednick | alan_g: ah crap. forgot that the other clients need to be created by the parent client in order to get the FDs | 13:17 |
| dednick | i mean the processes need to be spawed from the parent client. | 13:17 |
| alan_g | That's certainly the easiest way. | 13:17 |
| alan_g | Should I stop looking? | 13:18 |
| dednick | the shared mem was just to get the fds across process. but being used incorrectly. | 13:18 |
| alan_g | I mean is the problem you mentioned yesterday likely the same thing? | 13:18 |
| dednick | alan_g: hm. the problem yesterday was with the child processes being created by the helper, so probably not... | 13:19 |
| alan_g | OK. I'll start by writing a test for what should be happening. | 13:20 |
| dednick | alan_g: thanks. easier than me stabbing in the dark about what's supposed to happen :) I don't know much about fds apparently | 13:22 |
| alan_g | np | 13:23 |
| === dandrader|lunch is now known as dandrader | ||
| dandrader | alf_, is there a significant overhead in resizing a surface? | 13:25 |
| alf_ | dandrader: we need to allocate new graphics buffers, so yes in a sense, but it all depends on your particular scenario | 13:27 |
| dandrader | alf_, flipping the dimensions. e.g. from 768x1280 to 1280x768 | 13:28 |
| alf_ | dandrader: it depends on the device and your requirements whether its ok, so I guess you need to try it out and see if it's acceptable | 13:33 |
| alf_ | dandrader: do you have alternatives to flipping the dimensions (flipping rendering instead?) | 13:34 |
| dandrader | alf_, yes I do | 13:34 |
| dandrader | alf_, so overall you think it's better to flip rendering than to flip the dimentions (surface resize)? | 13:34 |
| alf_ | dandrader: flipping rendering should be near cost free for the GPU (just a different transformation matrix) | 13:36 |
| greyback | alf_: so right now there's no support for properly resizing a Qt app in Mir (and platform-api & qtubuntu)? | 13:51 |
| === pete-woods is now known as pete-woods-lunch | ||
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| alf_ | greyback: mir supports resizes | 14:39 |
| greyback | alf_: ok, so the qtubuntu just needs to support it | 14:40 |
| greyback | which is probably doesn't right now | 14:40 |
| alf_ | greyback: (you can play with resizes using mir_demo_server_shell) | 14:40 |
| === pete-woods-lunch is now known as pete-woods | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === alan_g is now known as alan_g|EOD | ||
| greyback | mterry: ping | 16:42 |
| mterry | greyback, heyo | 16:42 |
| greyback | mterry: hey, can you explain me how unity-system-compostor starts. Lightdm starts it right? Is there a configuration applied (i.e. env vars set for USC) | 16:43 |
| mterry | greyback, it is started by lightdm. With some env vars it sets yeah. And also, the configuration can change the command line used (and in fact ubuntu-touch-session does install a usc-wrapper file that sets a little more env for touch stuff) | 16:44 |
| greyback | mterry: are any of those env vars critical for USC to start by any chance? | 16:45 |
| mterry | greyback, probs? What's the problem? | 16:45 |
| greyback | mterry: http://pastebin.ubuntu.com/7468671/ | 16:46 |
| greyback | note it's with a custom build of mir | 16:46 |
| mterry | greyback, oh yeah, you can't really start manually | 16:46 |
| mterry | greyback, lightdm passes it a couple fd's for communicating with it | 16:46 |
| greyback | aha | 16:46 |
| mterry | greyback, specified on command line | 16:46 |
| greyback | mterry: so "start lightdm" is the right way to start it? | 16:47 |
| mterry | greyback, yeah | 16:47 |
| mterry | greyback, lightdm loves its private fds | 16:47 |
| greyback | how friendly | 16:47 |
| greyback | mterry: so I get: http://pastebin.ubuntu.com/7468684/ <- I'm missing the "ubuntu" session somehow. Where should that file be? | 16:49 |
| mterry | greyback, hm, what env are you running in? I think you're missing ubuntu-session (or ubuntu-touch-session) | 16:50 |
| greyback | mterry: on the phone. Some packages might have been removed (major surgery and all) | 16:50 |
| mterry | greyback, yeah install ubuntu-touch-session | 16:50 |
| mterry | greyback, it will change the default session to "ubuntu-touch" and install the .desktop file for it | 16:51 |
| greyback | ack | 16:51 |
| greyback | mterry: there we go, that fixed it, thanks | 16:51 |
| mterry | nice | 16:51 |
| greyback | slightly worrying how easily that broke... | 16:52 |
| mterry | greyback, well stop removing packages! :) | 16:52 |
| greyback | :P | 16:54 |
| kdub_ | any more reviewers on https://code.launchpad.net/~kdub/mir/post-if-optimizable/+merge/217991 | 17:17 |
| === beidl_ is now known as beidl | ||
| === tedg is now known as ted | ||
| racarr__ | This is where all the fun is | 19:49 |
| racarr__ | kdub_: Ill review! | 19:49 |
| racarr__ | just saw backlog lol | 19:49 |
| racarr__ | p.s. looking for reviewers on cursor-spike-phase-3 | 19:49 |
| racarr__ | ok I swear I have seen so many diffs that are exactly 1334 line | 19:50 |
| racarr__ | s | 19:50 |
| racarr__ | it seems to be a common stopping point | 19:50 |
| racarr__ | anpok: BECAUSE ON FREENODE THE PEOPLE MAY FINALLY CONTROL THE MEANS OF PRODUCTION | 19:57 |
| racarr__ | *waves flags* | 19:57 |
| anpok | :) | 19:58 |
| === beidl_ is now known as beidl | ||
| racarr__ | https://code.launchpad.net/~mir-team/mir/cursor-spike-bonus-phase-correct-gbm-cursor-hide/+merge/219764 | 22:00 |
| racarr__ | easy review | 22:00 |
| racarr__ | with no dependencies :) | 22:00 |
| RAOF | racarr__: I hope there's going to be a cursor-spike-lightning-round at some point. | 23:30 |
| racarr__ | RAOF: Lol | 23:35 |
| racarr__ | ill use that for the cleanup branch at the end | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!