| === tmpRAOF is now known as RAOF | ||
| === ara is now known as Guest58945 | ||
| === chihchun_afk is now known as chihchun | ||
| alan_g | anpok: duflu_ any last reviews? https://code.launchpad.net/~alan-griffiths/mir/make-window-management-configurable/+merge/253725 | 09:45 |
|---|---|---|
| === duflu_ is now known as duflu | ||
| duflu | alan_g: Adding a comment, but not blocking | 09:47 |
| === marcusto_ is now known as marcustomlinson | ||
| anpok | alan_g: interesting side note on clang compilation error, gcc only allows it when the constructor is a constructor template | 10:12 |
| alan_g | Weird. I'd be very surprised if a using directive for the constructor doesn't determine the access. Almost worth posting a test case to the standards reflector. | 10:15 |
| alan_g | I'd have to look at the wording, but I naively(?) expect it to work the same as with member functions. | 10:17 |
| anpok | filed a bug report at llvm | 10:18 |
| anpok | https://llvm.org/bugs/show_bug.cgi?id=23018 | 10:23 |
| ubot5 | llvm.org bug 23018 in C++ "clang claims an inherited constructor protected when declared public with using" [Normal,New] | 10:23 |
| anpok | oh what a curious bot | 10:23 |
| anpok | alan_g: do you prefer 2014-2015 or 2015 for new files (I (inconsistently) used the former for files that I already proposed in december) | 10:26 |
| alan_g | I think it is all silly. But it should reflect the date the intellectual property was created. | 10:27 |
| alan_g | "silly" is these comments, not IP rights. | 10:27 |
| anpok | :) | 10:31 |
| alan_g | /rant=on The only reason I know of for such comments is that in the USA before 1966(ish) one had to assert the rights to be able to enforce them. And even in those days, in that jurisdiction you could put them at the bottom of the file where they are not in the way. | 10:33 |
| tsdgeos | guys | 11:10 |
| tsdgeos | i'm having issues with an autopilot injected keypress not being detected by the event dispatcher | 11:11 |
| tsdgeos | any iea what may be wrong? | 11:11 |
| tsdgeos | it's the first one | 11:11 |
| tsdgeos | i..e it injects p a s s w o r d | 11:11 |
| tsdgeos | and sometimes p is lost | 11:11 |
| anpok | surface is not yet focused? | 11:11 |
| tsdgeos | it should | 11:11 |
| anpok | or where do you track the loss of the p? | 11:12 |
| tsdgeos | at least the qml side says it is | 11:12 |
| tsdgeos | at the mir level | 11:12 |
| tsdgeos | well qtmir | 11:12 |
| tsdgeos | i.e. on a dispatch() implementation | 11:12 |
| anpok | hm | 11:12 |
| tsdgeos | funny thing | 11:12 |
| tsdgeos | is that if i add a wait in the test | 11:12 |
| tsdgeos | then it seems to not fail | 11:12 |
| anpok | where does that injection happen? at usc? | 11:12 |
| tsdgeos | but i can't find what isn't yet settled | 11:13 |
| tsdgeos | since it all seems to have been created ages ago | 11:13 |
| tsdgeos | the surface, the event feeder, etc | 11:13 |
| tsdgeos | anpok: it's written to uiput device | 11:13 |
| anpok | evdev emulation? | 11:13 |
| tsdgeos | i guess my next step would be adding some debug somewhere in mir | 11:13 |
| tsdgeos | but recompiling mir not cool :D | 11:14 |
| anpok | hm then you could enable input reports at usc/u8 | 11:14 |
| tsdgeos | how do i do that? | 11:14 |
| anpok | http://unity.ubuntu.com/mir/component_reports.html | 11:14 |
| anpok | brb | 11:14 |
| tsdgeos | i have a feeling of having asked that question before | 11:15 |
| anpok | :) | 11:15 |
| tsdgeos | and having got that url and could get it to work :D | 11:15 |
| anpok | note that u8 is both server and client | 11:15 |
| tsdgeos | but let me see if i'm better now | 11:15 |
| alan_g | tsdgeos: you're going through USC + U8 + app? Note that USC waits for the second posted frame before granting focus to u8 (which IIUC) waits for the first frame before giving focus to the app - that can add up to a delay. | 11:19 |
| tsdgeos | alan_g: the app and surface have been on screw "for ages" | 11:20 |
| tsdgeos | that's what's puzzling me | 11:20 |
| tsdgeos | i wonder if it's even the evdev device eating the write() to it | 11:20 |
| alan_g | Weird. | 11:22 |
| tsdgeos | i'm using those env vars | 11:26 |
| tsdgeos | and see nothing | 11:26 |
| tsdgeos | where should MIR_SERVER_INPUT_REPORT=log | 11:26 |
| tsdgeos | write that log? | 11:26 |
| tsdgeos | stdoutput? | 11:26 |
| alan_g | tsdgeos: yes, but I think that's redirected to a log file somewhere | 11:29 |
| tsdgeos | you mean ~/.cache/upstart/unity8.log ? | 11:29 |
| tsdgeos | i can't see it in there | 11:29 |
| alan_g | greyback: you know where the logs go? ^^ | 11:30 |
| greyback | unity8's logs? yeah, tsdgeos has it | 11:31 |
| tsdgeos | and it should end up in there if started with MIR_SERVER_INPUT_REPORT=log ? | 11:33 |
| tsdgeos | is there anything else i need to enable? | 11:33 |
| greyback | not that I'm aware of. But by your tone, I'm guessing it's not working ;) | 11:33 |
| greyback | alan_g: that does work for a nested server too? | 11:34 |
| alan_g | it always has. I can double check... | 11:35 |
| tsdgeos | MIR_SERVER_NAME=session-0 MIR_SOCKET=/run/mir_socket QT_QPA_PLATFORM=mirserver MIR_SERVER_INPUT_REPORT=log /usr/bin/unity8 | 11:38 |
| tsdgeos | doesn't seem to give me much | 11:38 |
| anpok | and MIR_CLIENT_INPUT_REPORT=log | 11:39 |
| tsdgeos | went with | 11:39 |
| tsdgeos | MIR_SERVER_NAME=session-0 MIR_SOCKET=/run/mir_socket QT_QPA_PLATFORM=mirserver MIR_SERVER_INPUT_REPORT=log MIR_CLIENT_INPUT_REPORT=log MIR_CLIENT_INPUT_RECEIVER=log /usr/bin/unity8 | 11:39 |
| anpok | maybe that log file is just a reopened std out? then maybe also redirect std out.. | 11:39 |
| tsdgeos | nothing either | 11:39 |
| anpok | oops | 11:39 |
| anpok | yes input receiver .. | 11:39 |
| tsdgeos | that should give me touch events too, right= | 11:39 |
| alan_g | tsdgeos: greyback - yes, reports are working from a nested server | 11:44 |
| tsdgeos | they don't from unity8 :/ | 11:47 |
| greyback | MIR_CLIENT_INPUT_RECEIVER_REPORT is in the mir sources | 11:47 |
| tsdgeos | ok | 11:48 |
| tsdgeos | that gave me stuff | 11:48 |
| tsdgeos | so yeah | 11:50 |
| tsdgeos | according to that | 11:50 |
| tsdgeos | doesn't get whatever prints | 11:50 |
| tsdgeos | [1427284176.481447] <DEBUG> input-receiver: Received event: | 11:50 |
| tsdgeos | only get the a there | 11:50 |
| anpok | tsdgeos: so u8s surface is not yet focused/hasnt submitted buffers/been created yet...? | 12:06 |
| tsdgeos | anpok: don't think so | 12:06 |
| tsdgeos | usc is not getting the key event either | 12:07 |
| anpok | oh | 12:07 |
| anpok | but there is no client report in usc | 12:07 |
| tsdgeos | well there is the server one | 12:07 |
| tsdgeos | http://paste.ubuntu.com/10677149/ | 12:08 |
| tsdgeos | 14 events | 12:08 |
| tsdgeos | which should be 16 | 12:08 |
| anpok | yeah but thats the sending part | 12:08 |
| anpok | so there is still a lot that can go wrong (or right) within usc before this report is generated | 12:09 |
| anpok | if you enable the MIR_SERVER_LEGACY_INPUT_REPORT=log on usc you see the part that reads the event from the evdev devices | 12:10 |
| tsdgeos | oki | 12:12 |
| * tsdgeos does | 12:12 | |
| tsdgeos | [1427285878.408333] android-input: [InputReader]Dropping key up from device py-evdev-uinput because the key was not down. keyCode=44, scanCode=25 | 12:18 |
| tsdgeos | that's good | 12:18 |
| tsdgeos | so it seems that autopilot creates device /dev/input/event8 | 12:18 |
| tsdgeos | then mir says | 12:18 |
| tsdgeos | [1427285878.342107] android-input: [EventHub]New device: id=18, fd=66, path='/dev/input/event8', name='py-evdev-uinput', classes=0x80000063, configuration='', keyLayout='Generic.kl', keyCharacterMap='Generic.kcm', builtinKeyboard=false, usingSuspendBlockIoctl=true, usingClockIoctl=true | 12:18 |
| tsdgeos | [1427285878.342351] android-input: [InputReader]Device added: id=18, name='py-evdev-uinput', sources=0x00000701 | 12:18 |
| tsdgeos | and i guess sometimes something goes too slow | 12:19 |
| tsdgeos | and the first key down fails? | 12:19 |
| tsdgeos | right | 12:20 |
| tsdgeos | so that's what happens | 12:20 |
| tsdgeos | mir is not seeing the new device until | 12:21 |
| tsdgeos | [1427285878.342107 | 12:21 |
| tsdgeos | but the keypress is on | 12:21 |
| tsdgeos | 12:17:58.305 DEBUG _uinput:60 - Pressing p (25). | 12:21 |
| tsdgeos | that is 1427285878.305 | 12:21 |
| tsdgeos | i.e. 40 msec before | 12:21 |
| tsdgeos | ok i kind of know what's wrong now | 12:22 |
| tsdgeos | no idea how to fix it though :D | 12:22 |
| tsdgeos | other than blindly adding a sleep | 12:22 |
| greyback | tsdgeos: log a mir bug anyway | 12:41 |
| greyback | tho it's probably a race that's hard to fix | 12:42 |
| === dandrader is now known as dandrader|afk | ||
| kdub | greyback, seems like with qt 5.5, you can split the qtgui and the renderloop thread | 12:47 |
| greyback | kdub: yeah | 12:48 |
| greyback | there was work to enable threaded rendering with a custom qquickrendercontrol for qt5.5 | 12:48 |
| kdub | yay, neat | 12:48 |
| greyback | sadly that's not in 5.4 | 12:48 |
| greyback | which I expect will slow down your work a bit? | 12:49 |
| kdub | it might, i'm having a hard time convincing the qtgui thread not to try to run | 12:49 |
| greyback | :) the "Gui" thread does lots of other stuff too, from processing input events and managing the qml scene | 12:50 |
| kdub | yeah, its good that it can be split in qt 5.5, although its still disconcerting how the threading works so rigidly (imo) | 12:51 |
| greyback | kdub: "rigidly" is an interesting term, what do you mean? | 12:53 |
| greyback | like 1 thread per qquickwindow, or 1 thread for all windows, and nothing else? | 12:54 |
| kdub | yeah, its just strange that i have to set affinity of objects with certain threads, and mind which thread calls certain functions (just an empty complaint, really :) ) | 12:56 |
| === chihchun is now known as chihchun_afk | ||
| kdub | greyback, the problem i'm running into now (with 5.4) is that the QQuickRenderControl seems to need a QQuickWindow with a fb target (QOffscreenSurface) associated with it... and trying to QQuickWindow::create() the window associated with the QQuickRenderControl seems to start the QtGui thread | 12:59 |
| === marcusto_ is now known as marcustomlinson_ | ||
| === dandrader|afk is now known as dandrader | ||
| mpt | The menu bar doesn’t cast a shadow on a window touching it, therefore the window is not lower than the menu bar. | 15:03 |
| mpt | A window can slide underneath the Launcher, therefore a window is lower than the Launcher. | 15:03 |
| mpt | A window is lower than the Launcher, but not lower than the menu bar, therefore the Launcher is higher than the menu bar. | 15:05 |
| mpt | Therefore shell components are on multiple layers. | 15:06 |
| mpt | Which is … inconvenient. | 15:08 |
| greyback | mpt: you're testing unity8 desktop mode I'm assuming? Yes we've plenty of work to do there yet. We've inherited those layers from the phone/tablet | 15:32 |
| mpt | greyback, no, I was talking about shells in general. What I said was true for Unity 7 and for OS X, and probably (though I haven’t tried) for Gnome Shell as well. | 15:33 |
| greyback | mpt: ah I see, apologies | 15:34 |
| greyback | mpt: mind if I ask what you find inconvenient about shell components on layers though? You could consider each window as being in it's own layer (except for our desired case of windows being snapped together, so in same layer) | 15:35 |
| mpt | greyback, it’s inconvenient for defining exactly what order surfaces are in, layer-wise | 15:36 |
| mpt | At the moment I think the answer is “the topmost dialog/freestyle/regular/floating regular window, in the topmost window tree, should be level with the bottommost shell surface” | 15:41 |
| mpt | but that seems like a bit of a hack | 15:41 |
| mpt | A much simpler version of the problem is: When the frontmost regular window has a dialog, and the title bars of both are flush with the bottom of the menu bar, what is the layering of the menu bar? Is it (a) above both, (b) level with the dialog, (c) level with the parent, like it would be if it didn’t have a dialog, or (d) below them both? | 15:43 |
| mpt | In Unity 7, the answer is (b) | 15:44 |
| mpt | (i.e. as soon as the dialog opens, its parent sinks down below the menu bar) | 15:47 |
| mpt | In OS X, the answer is (e) magically level with both, even though one is above the other | 15:47 |
| === chihchun_afk is now known as chihchun | ||
| * alan_g was just thinking about how to better manage the z-order of related surfaces in Mir. | 15:53 | |
| greyback | mpt: ok problem is clear, no obvious solution strikes me however | 16:03 |
| greyback | thanks for elaborating | 16:03 |
| greyback | only thing I can suggest is not having menubar part of the stack of window layers, but in a separate layer whose bottom z-order matches the top window's layer z-order | 16:06 |
| greyback | less elegant but gives more power to choose how menubar's shadow falls | 16:07 |
| === dandrader is now known as dandrader|afk | ||
| mpt | Several subtleties about window position and size depend on knowing what is a “shell surface” | 16:44 |
| mpt | For example, if you have the Dash open, a new window can happily open with its title bar entirely covered by the Dash, but we mustn’t let its title bar be entirely covered by the menu bar or the Launcher | 16:45 |
| mpt | The menu bar and Launcher are “shell surfaces” under this definition, while the Dash is not (and nor are indicator menus, session dialogs, Launcher tooltips, etc) | 16:46 |
| mpt | So, it’s useful for a shell to be able to say “this surface here is of type SHELL_SURFACE” (a.k.a. _NET_WM_WINDOW_TYPE_DOCK) and let Mir handle the subtleties | 16:49 |
| mpt | But, greyback, that doesn’t work if the menu bar is a magical surface that layers differently from the other shell surfaces :-) | 16:50 |
| greyback | mpt: it's not necessarily magical, we're just not confined to the laws of physics here :) It's very possible to have menubar at same z-order as the top-most window in the stack of windows | 16:59 |
| mpt | Sure, the magical part is the detail where OS X’s menu bar is level with all windows at the same time <http://en.wikipedia.org/wiki/Waterfall_%28M._C._Escher%29> | 17:07 |
| === alan_g is now known as alan_g|EOD | ||
| === chihchun is now known as chihchun_afk | ||
| racarr | *deletes 2000 lines of code from PAPI* | 22:50 |
| racarr | delicious delicious deletion | 22:51 |
| racarr | 3285 lines (+34/-2861) 40 files modified | 23:22 |
| racarr | oh yeah | 23:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!