| * robert_ancell -> lunch | 00:13 | |
| racarr | back | 01:16 |
|---|---|---|
| racarr | traffic was destroyed by the bridge >< | 01:16 |
| RAOF | Did the bridge transform in to a huge humanoid robot and crush cars underfoot? | 01:22 |
| duflu | A dyslexic German deceptacon bridge?... "Die Autos" | 01:23 |
| * duflu clearly needs more coffee | 01:23 | |
| duflu | Woo, I have an N4 again. Apparently the battery "was faulty" and eventually just stopped charging | 01:24 |
| kgunn | racarr: curious...did the hwcomposer blank call work ? | 01:30 |
| racarr | kgunn: Havent tried yet needed to make an interface then got distracted by other things then went out for a bit | 01:51 |
| racarr | will be trying very soon | 01:51 |
| * RAOF lunches | 01:54 | |
| === chihchun_afk is now known as chihchun | ||
| duflu | Ah, source control. Finally I can hack and run XMir within the safety of git | 02:45 |
| robert_ancell | duflu, how? | 02:46 |
| duflu | robert_ancell: Just build it the traditional way, and drop the resulting libxmir.so into my saucy filesystem | 02:47 |
| duflu | Also, not having to re(de)build each time will be awesome | 02:47 |
| duflu | robert_ancell: Hangout? Or something? | 02:52 |
| robert_ancell | duflu, yep, in 5 | 02:53 |
| Mirv | hah, finally it makes sense, retitled bug #1220652 | 04:04 |
| ubot5 | bug 1220652 in unity-system-compositor (Ubuntu) "Input devices unusable if booting with two monitors attached" [Undecided,New] https://launchpad.net/bugs/1220652 | 04:04 |
| Mirv | so it was just that I killed unity-system-compositor because I had just upgraded to the multi-monitor supporting mir last week, and I thought the problem was because of the forceful killing, and not because of the upgrade.. | 04:05 |
| * Mirv now back at using XMir | 04:05 | |
| * duflu -> lunch | 04:48 | |
| tvoss_ | good morning :) | 05:22 |
| alf_ | tvoss_: good morning :) | 05:30 |
| robert_ancell | bbl | 05:46 |
| dholbach | good morning | 06:50 |
| === tkamppeter_ is now known as tkamppeter | ||
| duflu | RAOF: This is driving me nuts... The frame misordering thing only happens on frames where we have decided that the damage doesn't touch all outputs. Skipping sna_xmir_copy_to_mir for any output on any frame causes the problem. I still don't know why... | 07:32 |
| RAOF | duflu: That's... hm. | 07:43 |
| RAOF | duflu: I wonder if we're clearing incorrect damage areas, then. | 07:45 |
| duflu | Which leads me to another idea... hmm | 07:46 |
| duflu | RAOF: It suggests that the intel DDX multibuffers for each output are not allowed to get out of sync... or that there is only one... ? | 07:47 |
| mlankhorst | duflu: oh oh maybe because of EGL lifetime ? :P | 07:49 |
| mlankhorst | they would get out of sync | 07:49 |
| duflu | mlankhorst: There is no GL-anything here | 07:49 |
| mlankhorst | buffer age | 07:49 |
| duflu | mlankhorst: I have ripped out and removed all aging logic AFAIK. Still same problem | 07:50 |
| mlankhorst | duflu: interesting, do you have a testcase? | 07:50 |
| duflu | mlankhorst: bug 1216472 | 07:51 |
| ubot5 | bug 1216472 in XMir "[xmir] [multimonitor] Frames eventually get slightly out of order, look like glitches or typing will feel slow" [Critical,In progress] https://launchpad.net/bugs/1216472 | 07:51 |
| RAOF | ...ooh! Semi-overlapping outputs might be broken like that, though... | 07:53 |
| mlankhorst | RAOF: :P | 07:54 |
| RAOF | But who has semi-overlapping outputs :P | 07:54 |
| mlankhorst | << | 07:54 |
| RAOF | Just to be different, or for noble purpose? | 07:55 |
| mlankhorst | for perfectionism | 07:55 |
| mlankhorst | and it's the default case if you have multimonitor in ubuntu with different resolutions | 07:55 |
| mlankhorst | RAOF: my simple testcase is attaching my 2 monitors, one is 1280x1024, other is 1440x900, they both have a big shared area only visible on 1 screen, and a small band that is only shown on 1 screen in the default setup. :P | 08:00 |
| RAOF | I thought we should be actually cloning in that case. | 08:01 |
| RAOF | But indeed, I think that's a bit broken. | 08:01 |
| mlankhorst | RAOF: yeah, but with some xrandr forcing it can be changed :) | 08:08 |
| tvoss_ | RAOF, ping | 08:10 |
| duflu | RAOF: Testing the bleeding edge git xf86-video-intel, I just get a black screen. Can you confirm? | 09:22 |
| duflu | .. that's with XMir of course | 09:23 |
| * duflu gives up | 10:17 | |
| alan_g | alf_: are you happy with the latest version of https://code.launchpad.net/~alan-griffiths/mir/init-native-gbm/+merge/183441? | 10:36 |
| alf_ | alan_g: yes, approved | 10:42 |
| alan_g | alf_: thanks | 10:47 |
| katie | tvoss_, mpt is there anythign we need to discuss today? | 11:02 |
| mpt | I'm hungry | 11:03 |
| mpt | But other than that, no | 11:03 |
| tvoss_ | mpt, katie nope, not from my side | 11:06 |
| === alan_g is now known as alan_g|lunch | ||
| === hikiko is now known as hikiko|lunch | ||
| === chihchun is now known as chihchun_afk | ||
| === alan_g|lunch is now known as alan_g | ||
| === pete-woods is now known as pete-woods-lunch | ||
| === hikiko|lunch is now known as hikiko | ||
| === chihchun_afk is now known as chihchun | ||
| kgunn | alf_: welcome back | 12:28 |
| === chihchun is now known as chihchun_afk | ||
| alf_ | kgunn: hi | 13:20 |
| alf_ | kgunn: thanks@ | 13:20 |
| alf_ | kgunn: s/@/!/ | 13:20 |
| racarr | Morning | 13:23 |
| alan_g | racarr: Afternoon | 13:28 |
| alan_g | racarr: I was wondering if you'd have time to help me get the nested input stack wired up? | 13:29 |
| racarr | alan_g: I think so | 13:29 |
| racarr | alan_g: I am in a meeting right now, so want to sync on it after that? | 13:30 |
| alan_g | racarr: sure | 13:31 |
| racarr | alan_g: Ok will ping you :) | 13:34 |
| === pete-woods-lunch is now known as pete-woods | ||
| racarr | alan_g: Hey meetinged+breakfasted | 14:20 |
| racarr | want to explain nested input to me? | 14:21 |
| kgunn | racarr: can i be a complete manager and ask...did blanking work via hwc after all ? (knowing this'll get hot tomorrow or monday) | 14:21 |
| alan_g | racarr: The theory is really simple - we get input events from the host Mir (as seen in p:~alan-griffiths/mir/spike-nested-input) | 14:22 |
| alan_g | But there's a whole load of setup needed in NestedInputConfiguration to hook it up | 14:22 |
| alan_g | And I don't have a good grasp on all the roles there | 14:23 |
| pete-woods | tvoss: hi! I have a dbus security problem I thought you might have ideas on. If you have any free time at some point to talk about it, it would be very much appreciated. | 14:23 |
| racarr | kgunn: No XD sorry. I realized it was 7:30 pm last night and decided to stop working ill get to it before lunch today | 14:23 |
| pete-woods | tvoss_: ^ | 14:23 |
| kgunn | racarr: np | 14:24 |
| racarr | alan_g: Ok, starting to think out loud | 14:25 |
| racarr | How much of the android input stack do we use in the nested mir? It seems like we need to reuuse a lot of our input infrastructure because for example the nested mir might be using a different keymapping, or have different pointer acceleration configuration | 14:26 |
| racarr | or such | 14:26 |
| racarr | so its not enough to just modify and forward the events. | 14:27 |
| alan_g | racarr: Hmm | 14:27 |
| racarr | so I think instead, we should extract the raw events out of the events (By raw I event I specifically mean, android::RawEvent that EventHub deals with) | 14:27 |
| racarr | then we use a pretty normal input stack in the nested mir, but don't probe devices, and instead inject events from the host mir in to the nested event hub | 14:29 |
| alan_g | racarr: that's more complex than my initial thoughts (but more correct) | 14:29 |
| * alan_g wonders how to disentangle the bits we want to reuse from the spaghetti | 14:30 | |
| racarr | alan_g: There is a series of issues with it too though in that | 14:30 |
| racarr | the eventhub needs to be told about input device added, removed, etc, which we don't send over IPC now | 14:30 |
| racarr | that can be quickly worked around by using the built in cursor/mouse but has to be fixed quickly | 14:31 |
| racarr | alan_g: Perhaps even, the nested mir implements | 14:31 |
| racarr | the EventHub | 14:31 |
| racarr | eh its hard to do without inheritance of implementation | 14:33 |
| racarr | EventHub has two roles biw (calling it only two is generous...). One is to read the raw events from the kernel and track device info in the case of device appearing/dissapearing. | 14:34 |
| racarr | the second part, is stateful on top of that, i.e...is scan code 7 pressed | 14:35 |
| alan_g | I saw an "and" in that. Don't be sneaky! | 14:35 |
| racarr | Yes I thought of splitting it in to three there XD | 14:35 |
| racarr | it probably is, but for the purpose of this idea | 14:35 |
| racarr | if those first two responsibilities were held in one interface, and the second moved to a common implementation | 14:36 |
| racarr | the first interface is good for nested mir to replace | 14:36 |
| racarr | alan_g: I think this is likely too involved to finish within the week, but perhaps not. I have an easier idea though | 14:38 |
| alan_g | the refactoring? I guess there are inadequate tests around here? | 14:39 |
| racarr | nested mir, uses null impls/disabled objects/whatever for everything below the InputDispatcher (i.e. the EventHub and InputReader) | 14:39 |
| alan_g | ack | 14:39 |
| racarr | and injects the events with InputDispatcher::injectEvent | 14:39 |
| racarr | this expects droidinput::InputEvent which lines up to MirEvent | 14:39 |
| racarr | it wont work properly with device configuration, etc | 14:40 |
| racarr | but it can get things going | 14:40 |
| racarr | and yeah, inadequate tests around the pure android code...also just the interfaces are difficult. | 14:41 |
| racarr | There are like 30-40 member methods of EventHub | 14:41 |
| alan_g | racarr: I can remember that from when I hacked out stuff we didn't need | 14:41 |
| alan_g | It also doesn't sound like much wasted work. The reconfig work could fit in if the MirEvent -> InputEvent "mapping" took place in the stubbed EventHub | 14:45 |
| racarr | No. Not wasted work. | 14:46 |
| racarr | Not sure I understand that last bit though | 14:46 |
| alan_g | Maybe I'm not making sense | 14:46 |
| racarr | (also, I guess you mean RawEvent?) | 14:46 |
| alan_g | "InputDispatcher::injectEvent expects droidinput::InputEvent which lines up to MirEvent" | 14:47 |
| racarr | Oh! ok I see, inject in to the InputDspatcher from the stubbed event hub | 14:48 |
| racarr | like you said :p | 14:48 |
| racarr | I replaced stubbed with reimplemented in my mind | 14:48 |
| alan_g | racarr: it will then grow from a little stub to handle device configuration, etc | 14:49 |
| racarr | yeah. | 14:50 |
| alan_g | And we have a stable intermediate form that might work | 14:50 |
| racarr | perhaps though instead of using InputDispatcher::injectEvent | 14:50 |
| racarr | well maybe we should be stubbing out and doing this in the InputReader | 14:51 |
| * alan_g wishes he understood the roles of these classes | 14:52 | |
| racarr | or, not have an input reader, and use the InputListenerInterface from the INputDispatcher as the reader does | 14:52 |
| racarr | where you have like, notifyConfigurationChanged, notifyKey, notifyMotion, notifySwitch, notifyDeviceReset | 14:52 |
| racarr | basically, I am thinking, stub out the input reader, ignore the event hub (don't need it if we aren't constructing the real input reader) | 14:53 |
| alan_g | That sounds like we don't need a hub | 14:53 |
| racarr | yep no hub | 14:53 |
| alan_g | duh, you jsut said it | 14:54 |
| racarr | then just make some object like uh | 14:54 |
| racarr | NestedInputReaderWithABetterNameThanInputReader | 14:54 |
| racarr | that takes the InputListenerInterface (implemented by dispatcher) | 14:54 |
| alan_g | NestedInputRelay | 14:54 |
| racarr | receives events and calls notifyKey, Motion, etc | 14:54 |
| racarr | yes relay is good | 14:54 |
| racarr | alan_g: If you look in fake_event_hub.cpp there is some stuff about synthesize_builtin_keyboard_added and synthesize_builtin_cursor_added | 14:55 |
| racarr | To get started, I think we will have to replicate that at the notifyConfigurationChanged level | 14:55 |
| racarr | and then force all device ids to builtin keyboard or cursor in the relay | 14:56 |
| racarr | then we have to start sending input configuration info over the wire | 14:56 |
| racarr | before we can get any further | 14:56 |
| alan_g | But we should be able to route some input without the config messages as a POC. | 14:58 |
| racarr | yes by | 14:58 |
| racarr | forcing them all on to synthetic devices | 14:58 |
| racarr | but if we just route them straight away I think the InputDispatcher will be like | 14:58 |
| racarr | device Id 7? You just made that up, stop it. | 14:59 |
| * alan_g hates code that knows too much | 15:00 | |
| racarr | that might not be true the input reader will definitely choke | 15:00 |
| racarr | the InputDispatcher might not. | 15:00 |
| racarr | a quick grep through for "Device" in InputDispatcher is more promising than I expected | 15:01 |
| racarr | it may just be happy to pass it through | 15:01 |
| * alan_g hears demands for tea | 15:01 | |
| alan_g | I think I have some ideas to work with | 15:01 |
| alan_g | BRB | 15:01 |
| === alan_g is now known as alan_g|tea | ||
| racarr | Ok | 15:02 |
| hikiko | hey :) I am alone at the hangout | 15:02 |
| racarr | hikiko: Oh! I forgot I was awake | 15:03 |
| racarr | :p | 15:03 |
| === alan_g|tea is now known as alan_g | ||
| === alan_g is now known as alan_g|EOD | ||
| racarr | whats the sane way to stop unity8-mir on the phone now so I can run mir | 17:51 |
| racarr | without it restarting itself :p | 17:51 |
| racarr | just compiling a build now where I expect screen blanking to work | 17:52 |
| racarr | kgunn: ok it basically works I think but I need to stop the compositor from continuing to try and post to the fb (or make that blocking or something) | 18:25 |
| kgunn | racarr: cool...that makes sense | 18:25 |
| kgunn | in fact the DSS has probably cut the clocks...and might get pissed if you try to send data | 18:26 |
| kgunn | see dss2 kernel code | 18:26 |
| racarr | oi | 18:28 |
| racarr | ok lunch! | 18:28 |
| bschaefer | kgunn, thanks for that email! Ill poke one of them when ever I get a chance to look back at this radeon problem... | 18:30 |
| kgunn | you bet...thanks bschaefer ! | 18:30 |
| bschaefer | kgunn, did all that packaging stuff get sorted with the xserver radeon stuff? | 18:31 |
| greyback | racarr: "stop unity8" | 18:54 |
| greyback | just shout out. nice and loud. It'll get the hint. | 18:54 |
| greyback | :D | 18:54 |
| olli_ | this is probably old news for you guys | 19:06 |
| olli_ | but AWESOME! | 19:06 |
| olli_ | http://www.phoronix.com/scan.php?page=news_item&px=MTQ1MzU | 19:06 |
| racarr | greyback: Aha thanks. | 19:14 |
| racarr | greyback: mv /usr/bin/unity8.lol /usr/bin/unity8 | 19:15 |
| racarr | I ended up using the insane way | 19:15 |
| greyback | racarr: insane, but works :) | 19:16 |
| tvoss_ | bschaefer, ping | 19:38 |
| bschaefer | tvoss_, pong | 19:38 |
| racarr | Whee | 19:41 |
| racarr | screen blanking works on nexus 4 :) | 19:41 |
| tvoss_ | racarr, \o/ | 19:41 |
| racarr | ok I am going to be late for the dentist brb | 19:41 |
| kdub | racarr, yay | 19:43 |
| racarr | kdub: There are some complications about pausing things | 19:43 |
| kdub | yeah, although | 19:43 |
| racarr | noticeably the most naieve method doesnt work because then you can stall the client that wants to unblank the screen | 19:43 |
| kdub | we do that already, don't we? | 19:43 |
| racarr | in buffer hand out | 19:44 |
| racarr | and it will never be able | 19:44 |
| racarr | to send the message to unblank the screen | 19:44 |
| racarr | well it will send it but the server side machinery will be locked up (we do one message at a time) | 19:44 |
| racarr | so there is a bit of a dance to do | 19:44 |
| racarr | ill tell you about it when I get back XD | 19:44 |
| kdub | are clients able to request a blank? o.O i thought the shell would be the one that would do that | 19:45 |
| kdub | anyways, have fun at the dentist :P | 19:45 |
| racarr | xmir needs to | 19:46 |
| racarr | as usual XD | 19:46 |
| kgunn | robotfuel: so is the latest radeon build still an issue ? (stripes?) | 21:26 |
| kgunn | and if so, is it stripes only on xmir and not X | 21:26 |
| robotfuel | kgunn: yes on the latest xmir in main | 21:28 |
| robotfuel | kgunn: I'll double check x | 21:28 |
| robotfuel | kgunn: I just kicked off a test run on, we will know in 7 minutes | 21:29 |
| kgunn | robert_ancell: something to watch ^ | 21:30 |
| robert_ancell | yep | 21:31 |
| robotfuel | robert_ancell: are there any changes in xmir in proposed that you know about? (should I test proposed today?) | 21:31 |
| robert_ancell | robotfuel, not that I know of specifically, will have to ask RAOF | 21:31 |
| robert_ancell | robotfuel, which pacakge? xorg-server doesn't seem to be in proposed | 21:32 |
| robotfuel | robert_ancell: I didn't know if there were any packages | 21:32 |
| robert_ancell | robotfuel, ok, there don't seem to be any xmir changes | 21:32 |
| robert_ancell | racarr, hey | 21:35 |
| racarr | robert_ancell: Hey | 21:35 |
| robert_ancell | racarr, I thought our meeting was an hour later - free now? | 21:35 |
| racarr | robert_ancell: Can we delay 1 hour? or at least 30 min or so | 21:36 |
| robert_ancell | sure | 21:36 |
| racarr | face is too numb to talk right now really | 21:36 |
| robert_ancell | more dental work!! | 21:36 |
| racarr | Yes. It's not actually that much its just the root canal took 4 visits | 21:36 |
| racarr | I got 1 half cleaned, then a root canal, then now I just finally got the other half cleaned | 21:36 |
| racarr | it was inclusive of inside of the gums though, and kind of involved an intense about of local anaesthetic XD | 21:37 |
| rsalveti | racarr: have the blank/unblank patch in hands so we can test with maguro as well? | 21:49 |
| robotfuel | kgunn: regular x does not have black bars | 21:56 |
| kdub | rsalveti, from what I've heard, i think its a pretty preliminary patch at the moment | 21:58 |
| robert_ancell | RAOF, can you have a look at https://code.launchpad.net/~robert-ancell/unity-system-compositor/reboot-on-install/+merge/184204 when you are here | 22:23 |
| robert_ancell | out with an errand for ~1hr | 22:26 |
| rsalveti | kdub: yeah, but just wanted to know if it'd work with the hwcomposer used with maguro | 22:42 |
| rsalveti | guess I'll have to wait :-) | 22:42 |
| kdub | it should | 22:42 |
| racarr | rsalveti: There is a not yet proposable (build will fail on tests :p) branch you can try out | 22:43 |
| racarr | but its pretty preliminary :p | 22:43 |
| racarr | lp:~robertcarr/mir/test-android-screen-blanking | 22:43 |
| racarr | you can run mir-demo-server-shell then mir-demo-client-display-config | 22:44 |
| racarr | and press any hardware key to toggle the screen on and off | 22:44 |
| racarr | poatch should be finished soon | 22:44 |
| racarr | Had to run out for the afternoon | 22:44 |
| rsalveti | cool | 22:49 |
| kgunn | RAOF: ^ robotfuel's comment on radeon xmir has black stripes and regular x doesn't....wasn't sure if you were aware | 23:02 |
| RAOF | kgunn: Yeah, I sees it. | 23:11 |
| RAOF | Not the bug, just the comment ☹ | 23:11 |
| robert_ancell | thomi, hey, do we have coverity and CI integration? | 23:28 |
| racarr | Ok so the hardware part of DPMS android is working and It hink I can clear it up pretty quickly. I think also the IPC issue I found was my real issue with GBM | 23:31 |
| racarr | essentially, imagine a dumb client like demo-client-display-config | 23:31 |
| racarr | which turns off the display then tries to advance its buffer | 23:31 |
| racarr | which blocks on the server side waiting for the display to turn back on (hey the display is off! Stop swapping buffers) | 23:31 |
| racarr | but because we process messages in-order | 23:31 |
| robert_ancell | racarr, anesthetic worn off? | 23:32 |
| racarr | you can't send a message ot turn the screen back on | 23:32 |
| racarr | robert_ancell: Yes! | 23:32 |
| TheDrums | I'd assume http://paste.progval.net/show/530/ hasn't been fixed? Last tested in 0.0.6, though. | 23:45 |
| kdub | what device? | 23:56 |
| TheDrums | Pad says intel 82845G/GL[Brookdale-G]/GE | 23:57 |
| kdub | TheDrums, not sure if it would work now... intel cards should work though | 23:59 |
| TheDrums | It was a different error than they were used to, because it didn't handle alpha. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!