[00:05] not today! [01:04] RAOF: hi [01:05] desrt: Yo! [01:05] racarr and I were just talking about what sort of input events would make clients most happy, and we thought you'd have useful input. [01:06] what sort as in what different types or as in what sort of delivery mechanism? [01:07] Specifically - what type of key events. Whether you want something like "down, up, down, up, down, <'>down, <'>up, up" or "ë" [01:08] for compose sequences... [01:08] For keyboard(ish) events. [01:09] that's sort of tricky [01:09] Compose sequences being an obvious edge case. [01:09] because there are things like games that are basically going to want the keyboard in raw mode [01:09] Yeah, I'm thinking that there are actually two modes here. [01:09] so here's a more interesting question then: how do you imagine input methods will work? [01:09] so here's a more interesting question then: how do you imagine input methods will work? [01:10] because the compose key is basically like the ultimate poormans input method, really [01:10] Indeed [01:10] is the IM in the display server? separate process? plugin-based? [01:10] figure out the answer to these questions and the rest will be pretty obvious... [01:11] The IM is a problem for the shell. Which means the IM does *not* need to consume these events. [01:11] what i mean is that the interface between the display server and the toolkit needs to be designed with attention given to where the IM is [01:12] if the IM is in the shell then you want the toolkit seeing what happens _after_ the IM [01:12] ie: send unicode [01:12] and then i see compose as just a special case of that [01:12] keeping in mind, of course, some clients will want a bypass [01:13] Yeah. But the common case is just seeing a stream of characters. [01:13] No, that's not quite true; things care about more than the character stream (hello, keyboard shortcuts!) [01:14] i think keyboard shortcuts should probably work by way of explicit registration [01:14] although a lot of toolkits would probably get quite annoyed by that [01:14] since they don't internally work that way [01:14] That would be particularly pleasant. [01:15] Right. [01:15] but when you really think about it, it would solve a lot of annoying issues [01:15] *Global* keyboard shortcuts have to be explicitly registered; you think that app-local shortcuts should be too? It doesn't seem unreasonable to me. [01:16] yes. [01:17] Hm. What about shortcut-highlighting on holding ? [01:17] that's just a modifier watch [01:18] (again, you'd want an explicit subscribe to receive those) [01:18] i guess an interesting question is what happens to ctrl+s when nothing at all is watching for it [01:18] do you drop it? do you deliver it to the focused window as a last resort? [01:18] ie: do we emit an 's'? [01:18] no. never that. [01:18] at least not without the modifier also being on it [01:19] this would also be kinda convenient for toolkits that want to handle this stuff themselves [01:19] maybe explicit (local) shortcut registration is dumb [01:20] but i think i prefer viewing the input stream more as a sequence of user intents rather than raw hardware events [01:20] Yeah, that would be great. [01:20] the extreme example of this is receiving touch gestures [01:20] which we obviously plan on doing.... [01:21] from my gaction-based world i think it would be kinda neat to tell the system that s means 'win.save' [01:21] Right. (In addition to allowing clients access to raw touch sequences if they want,) We need to emit some form of intent event there. [01:21] and have that action invoked [01:22] that's how you do it now in gtk apps, but it's gtk that's doing the decoding of s [01:22] i dunno [01:22] obviously the API is more important than the interaction of the toolkit with the display server [01:23] and following existing paradigms will make your life easier for obvious reasons [01:23] the question is: are there any truly nasty edge cases caused by the way things are handled now? [01:24] fun case to imagine: save is Å [01:24] You need to replay some events on window focus? [01:24] That's kinda annoying (but not exactly terrible) [01:24] you mean like how the WM intercept the click events for click-to-focus and needs to retransmit them? [01:25] here's an interesting thought experiment, meanwhile [01:25] I mean: you need to synthesise a keypress for any key that's down when the window is focused. [01:25] the unity menubar shows when the user holds down alt, right? [01:25] This is currently the case, yes. [01:25] what should happen the user holds down alt when a popup menu is open? [01:26] should it show, or not? [01:26] same question applies to showing underline on alt [01:28] I think the expectation is that the menubar *should* show when a popup menu is open. [01:28] Or, at least, I can't think of a situation when that would be an incorrect behaviour. [01:29] it seems weird to me for the menu to show when a popup menu is open [01:29] because that implies that if i add an 'f' to my already-held-down-alt that the file menu might open [01:29] which i would find quite odd if a popup was already up [01:30] Really? [01:30] That would seem to be natural behaviour to me - the old popup is dismissed, the file menu opens. [01:30] i might expect the mnemonic 'f' from the popup to fire [01:30] like, maybe i'm pressing alt to get the underlines showing in that menu [01:32] Incidentally, I'm playing around with this right now in GTK. What the hell is it doing? [01:32] Hm, fair point. [01:32] anyway [01:32] This is actually a special case of a more general problem, really. [01:32] that's a bit of an argument for delivering alt to windows with respect paid to focus [01:33] and not just using some global modifier monitor [01:33] but.... [01:33] the way it works now is also very crappy [01:33] because even to this day i find myself getting into stupid situations where somehow a modifier gets stuck on an app [01:34] and i have to tap alt or ctrl or whatever to turn it off again [01:34] Right. [01:34] so it should not be a simple press/release type of thing [01:34] or rather: the release should always be reliably delivered, even if the window no longer has focus when the release occurs [01:34] That's one way of doing it, yes. [01:34] which suggests more statefulness than i think we have now [01:35] where the press and release are just two different events [01:36] anyway.... beer o'clock :) [01:36] Heh. Have fun! [01:36] g'night === tux is now known as Guest21807 [05:18] RAOF, ping [05:18] tvoss: Pong [05:18] RAOF, just stumbled across http://www.phoronix.com/scan.php?page=article&item=nvidia_tegra_3d&num=1 [05:18] RAOF, did you have a chance to take a look at it? [05:19] I've not taken a look at it, no. [05:20] I actually *do* have a Tegra device, don't I! The N7 is a tegra, right? [05:20] RAOF, might be interesting, especially as we have a lot of nexus 7 hw lying around [05:20] yup [05:21] Sounds like it's not _currently_ interesting though, as it doesn't actually do any 3D :) [05:22] RAOF, hmmm, I thought I read that NVIDIA open-sourced the 2D drivers, too [05:22] They did; the 2D driver + kms has been open-sourced for... a while? A year or so? [05:22] RAOF, s/2D/3D/g [05:25] Oh, yeah. The operative part of that phoronix article however is “…is basically a stub driver” and “…is enough to get Wayland running with the Weston compositor, but not with any actual output”. [05:26] RAOF, :) okay, I got that impression, too === jono is now known as Guest52708 [05:26] jono, good morning? [05:31] * RAOF goes to test the mesa in-process-egl changes [05:32] RAOF: Are you ready (i.e. mesa) for ~raof/mir/use-dma-buf to land? [05:36] alf_: Yes* [05:36] *For intel. [05:37] RAOF: Do you mean you have just checked on intel, or that you know that e.g. radeon doesn't work? [05:37] radeon and nouveau will require additional patching, which shouldn't take long, but I haven't yet done. [05:38] I should probably fix them before we land dma-buf, I guess :/ [05:38] RAOF: ok, since this will break things for me, I vote for postponing the final approval [05:42] Fair enough. I'll have fixes for radeon and nouveau prepared before marking it as approved. [05:43] RAOF: ok, I have marked the branch as needs fixing to discourage others from merging [05:44] RAOF: feel free to ignore it and Approve when the mesa side has been fixed [06:09] Hm. [06:09] Why doesn't in-process-egl work for me. [06:12] It doesn't _seem_ to be a bug mesa-side; mir_egl_native_display_is_valid(nativeDisplay) is being called on something when valid_displays is an empty unordered_set. [07:08] BigWhale: You wanted to annoy some Mir developers? :) [07:10] RAOF, indeed! :) [07:10] ;) [07:12] RAOF, I'm working on Kazam screencaster which is used for capturing screen. Surprisingly. ;) Now, because I am using GStreamer and ximagesrc which is a plugin that takes care of capturing, I know already that this will not work in Mir. :) I am looking for alternatives. :) [07:13] If I got Mir specs, correctly, this will not be a trivial thing to do. With all the security restrictions. [07:13] BigWhale: That's going to be the province of the Shell (ie UnityNext); I don't think we'll be offering a generic way to do that. [07:14] Once everything's done it probably shouldn't be too hard; you'll just need to include MIR_CAPTURE_OUTPUT or whatever we call the requisite permission in your app manifest. [07:14] Wherever those app manifests go :) [07:16] Ok. [07:16] It shouldn't be terribly difficult to write a mirimagesrc once the requisite infrastructure is in place, but I've no idea when we intend to put that infrastructure in place. [07:16] BigWhale, RAOF when we talked about this last time, we basically thought about the ability to add custom post processors to mir Displays (server side) [07:17] tvoss: Eh, just export the framebuffer as an EGLImage. [07:17] RAOF, yeah, that was the idea then :) iirc [07:18] Ideally, I'd like to have something that I'll be able to feed into GStreamer. [07:19] RAOF, makes sense to file a bug at least? [07:19] BigWhale: You'll likely get a dma-bufish interface, maybe an EGL stream interface; it'll be pretty easy to feed that into GStreamer. [07:20] tvoss: It's probably a blueprint/series of work items. [07:20] RAOF, sure, just to make sure that we have it tracked somewhere [07:20] RAOF, if I ask about an estimate, when I'll be able to start playing with this stuff, I'd be pushing it, right? :) [07:21] Maybe :) [07:21] BigWhale: Actually, you could probably do this yourself if you wanted. I don't think it's going to be a high priority for the Mir team. [07:21] I'd love to have Kazam ready when Mir is ready. So that people can capture the awesomeness of Mir and Unity Next. ;) [07:22] Yeah, that'd be great. [07:22] RAOF, offering my help with this, was the next step, yes. :) [07:25] I think it'd probably make more sense to do after the Big Display Refactor that I want to do, but I don't have an ETA for that. [07:26] I'll start with setting up the dev environment and brushing up my C skills... :> [07:26] C++, actually. [07:26] C++11, specifically. Much more expressive. [07:27] You have such modern affordances as lambdas! [07:27] Now you gave me two heart attacks ... :> [07:28] C++11 actually makes C++ good. Well, better... :) [07:29] It suffers from adding yet another mechanism for doing things to the plethora of mechanisms already available, but at least the new mechanisms are really quite nice :) [13:53] racarr, Spent the rest of the day yesterday downloading & compiling Mesa and then Mir. Done it and now it gives me a different error. [13:55] In function open_drm_device() line 118 of file gbm_display_helpers.cpp it throws an exception saying "Problem opening DRM device" and then "Operation not permitted" [14:38] racarr, "sudo pmap `pidof X` | grep dri.so" gives me back 4 times /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so . Does it means I need to change anything n the configure process of Mesa? [14:38] racarr, Used this command ./configure --disable-gallium-egl --enable-gles2 --with-egl-platforms=x11,drm,mir,wayland --enable-gbm --enable-shared-glapi --with-gallium-drivers=r300,r600 [15:04] goood morning folks, still plowing ahead towards that fb native window type [15:35] status: working on introducing the mir main loop [15:43] kdub, Can you help me with running Mir? [15:43] thiagoandrade, on android i can [15:47] kdub, Unfortunately I'm running on raring inside VirtualBox [15:47] Thanks anyway ;) === thiagoandrade is now known as thiagoandrade|af [16:02] and ask for comment :/win goto 10 [16:02] ...woah what was that [16:02] good morning [16:22] the keymapping interfaces I am coming up with look laughably incorrect [16:22] due to the duplication of droidinput::InputEvent and MirEvent [16:22] so I am going to rip out droidinput::InputEvent and synthesize MirEvent directly [16:25] thiagoandrade|af: Did not realize you were in virtual box...-.- [16:25] would not expect it to work inside VB atm. === francisco is now known as Guest49443 === tvoss is now known as tvoss|dinner === thiagoandrade|af is now known as thiagoandrade [17:14] racarr, That's a shame. I don't have a machine to spare and I'm not willing install raring and run possible unsafe code on my desktop ;( [17:20] thiagoandrade: partition & dual boot [17:20] ? [17:22] kgunn, I already have a lot of troubles with Win8 and 12.04 on dual boot. It seems like I have an ability to attract problems ;p [17:23] kgunn, But I'll think about it. The only downside is that I'll not be able to play with Mir on work. [17:26] mmm [19:11] i may have just bricked my galaxy s3 :-/ [19:23] my poor nexus4 spends its entire life panicking about not being able to find surfaceflinger [19:24] kgunn, how so? [19:52] back [19:53] kdub: well...i loaded the CM recovery kernel...but now rebooting endlessly at splash screen [19:53] kdub: i'm seeing lots of complaints about the same [19:55] sounds like its at least loading the kernel though, thats a good sign [20:11] kdub: freaky as all get out....loaded a recovery.img....it rebooted a couple of times from the CWM screen...but now stable === bschaefer_ is now known as bschaefer [21:56] kdub: do you know if Thomi got glmark2 up on jenkins? [21:56] kgunn, don't know [22:54] racarr: just checking...should someone else take on [robertcarr] Client focus notification (likely depends of notifcation work vanvugt is doing): TODO [23:16] racarr: can you also move (not copy) [23:17] racarr: your items in the iteration-0-mir blueprint ? [23:17] racarr: and mark them as INPROGRESS rather than POSTPONED [23:17] racarr: ....or...even DONE if you can land :)