[00:05] <racarr> not today!
[01:04] <desrt> RAOF: hi
[01:05] <RAOF> desrt: Yo!
[01:05] <RAOF> 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] <desrt> what sort as in what different types or as in what sort of delivery mechanism?
[01:07] <RAOF> Specifically - what type of key events. Whether you want something like "<menu>down, <menu>up, <e>down, <e>up, <shift>down, <'>down, <'>up, <shift>up" or "ë"
[01:08] <desrt> for compose sequences...
[01:08] <RAOF> For keyboard(ish) events.
[01:09] <desrt> that's sort of tricky
[01:09] <RAOF> Compose sequences being an obvious edge case.
[01:09] <desrt> because there are things like games that are basically going to want the keyboard in raw mode
[01:09] <RAOF> Yeah, I'm thinking that there are actually two modes here.
[01:09] <desrt> so here's a more interesting question then: how do you imagine input methods will work?
[01:09] <desrt> so here's a more interesting question then: how do you imagine input methods will work?
[01:10] <desrt> because the compose key is basically like the ultimate poormans input method, really
[01:10] <RAOF> Indeed
[01:10] <desrt> is the IM in the display server?  separate process?  plugin-based?
[01:10] <desrt> figure out the answer to these questions and the rest will be pretty obvious...
[01:11] <RAOF> The IM is a problem for the shell. Which means the IM does *not* need to consume these events.
[01:11] <desrt> 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] <desrt> if the IM is in the shell then you want the toolkit seeing what happens _after_ the IM
[01:12] <desrt> ie: send unicode
[01:12] <desrt> and then i see compose as just a special case of that
[01:12] <desrt> keeping in mind, of course, some clients will want a bypass
[01:13] <RAOF> Yeah. But the common case is just seeing a stream of characters.
[01:13] <RAOF> No, that's not quite true; things care about more than the character stream (hello, keyboard shortcuts!)
[01:14] <desrt> i think keyboard shortcuts should probably work by way of explicit registration
[01:14] <desrt> although a lot of toolkits would probably get quite annoyed by that
[01:14] <desrt> since they don't internally work that way
[01:14] <RAOF> That would be particularly pleasant.
[01:15] <RAOF> Right.
[01:15] <desrt> but when you really think about it, it would solve a lot of annoying issues
[01:15] <RAOF> *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] <desrt> yes.
[01:17] <RAOF> Hm. What about shortcut-highlighting on holding <Alt>?
[01:17] <desrt> that's just a modifier watch
[01:18] <desrt> (again, you'd want an explicit subscribe to receive those)
[01:18] <desrt> i guess an interesting question is what happens to ctrl+s when nothing at all is watching for it
[01:18] <desrt> do you drop it?  do you deliver it to the focused window as a last resort?
[01:18] <RAOF> ie: do we emit an 's'?
[01:18] <desrt> no.  never that.
[01:18] <desrt> at least not without the modifier also being on it
[01:19] <desrt> this would also be kinda convenient for toolkits that want to handle this stuff themselves
[01:19] <desrt> maybe explicit (local) shortcut registration is dumb
[01:20] <desrt> but i think i prefer viewing the input stream more as a sequence of user intents rather than raw hardware events
[01:20] <RAOF> Yeah, that would be great.
[01:20] <desrt> the extreme example of this is receiving touch gestures
[01:20] <desrt> which we obviously plan on doing....
[01:21] <desrt> from my gaction-based world i think it would be kinda neat to tell the system that <ctrl>s means 'win.save'
[01:21] <RAOF> 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] <desrt> and have that action invoked
[01:22] <desrt> that's how you do it now in gtk apps, but it's gtk that's doing the decoding of <ctrl>s
[01:22] <desrt> i dunno
[01:22] <desrt> obviously the API is more important than the interaction of the toolkit with the display server
[01:23] <desrt> and following existing paradigms will make your life easier for obvious reasons
[01:23] <desrt> the question is: are there any truly nasty edge cases caused by the way things are handled now?
[01:24] <desrt> fun case to imagine: save is <ctrl>Å
[01:24] <RAOF> You need to replay some events on window focus?
[01:24] <RAOF> That's kinda annoying (but not exactly terrible)
[01:24] <desrt> you mean like how the WM intercept the click events for click-to-focus and needs to retransmit them?
[01:25] <desrt> here's an interesting thought experiment, meanwhile
[01:25] <RAOF> I mean: you need to synthesise a keypress for any key that's down when the window is focused.
[01:25] <desrt> the unity menubar shows when the user holds down alt, right?
[01:25] <RAOF> This is currently the case, yes.
[01:25] <desrt> what should happen the user holds down alt when a popup menu is open?
[01:26] <desrt> should it show, or not?
[01:26] <desrt> same question applies to showing underline on alt
[01:28] <RAOF> I think the expectation is that the menubar *should* show when a popup menu is open.
[01:28] <RAOF> Or, at least, I can't think of a situation when that would be an incorrect behaviour.
[01:29] <desrt> it seems weird to me for the menu to show when a popup menu is open
[01:29] <desrt> because that implies that if i add an 'f' to my already-held-down-alt that the file menu might open
[01:29] <desrt> which i would find quite odd if a popup was already up
[01:30] <RAOF> Really?
[01:30] <RAOF> That would seem to be natural behaviour to me - the old popup is dismissed, the file menu opens.
[01:30] <desrt> i might expect the mnemonic 'f' from the popup to fire
[01:30] <desrt> like, maybe i'm pressing alt to get the underlines showing in that menu
[01:32] <RAOF> Incidentally, I'm playing around with this right now in GTK. What the hell is it doing?
[01:32] <RAOF> Hm, fair point.
[01:32] <desrt> anyway
[01:32] <RAOF> This is actually a special case of a more general problem, really.
[01:32] <desrt> that's a bit of an argument for delivering alt to windows with respect paid to focus
[01:33] <desrt> and not just using some global modifier monitor
[01:33] <desrt> but....
[01:33] <desrt> the way it works now is also very crappy
[01:33] <desrt> because even to this day i find myself getting into stupid situations where somehow a modifier gets stuck on an app
[01:34] <desrt> and i have to tap alt or ctrl or whatever to turn it off again
[01:34] <RAOF> Right.
[01:34] <desrt> so it should not be a simple press/release type of thing
[01:34] <desrt> or rather: the release should always be reliably delivered, even if the window no longer has focus when the release occurs
[01:34] <RAOF> That's one way of doing it, yes.
[01:34] <desrt> which suggests more statefulness than i think we have now
[01:35] <desrt> where the press and release are just two different events
[01:36] <desrt> anyway.... beer o'clock :)
[01:36] <RAOF> Heh. Have fun!
[01:36] <desrt> g'night
[05:18] <tvoss> RAOF, ping
[05:18] <RAOF> tvoss: Pong
[05:18] <tvoss> RAOF, just stumbled across http://www.phoronix.com/scan.php?page=article&item=nvidia_tegra_3d&num=1
[05:18] <tvoss> RAOF, did you have a chance to take a look at it?
[05:19] <RAOF> I've not taken a look at it, no.
[05:20] <RAOF> I actually *do* have a Tegra device, don't I! The N7 is a tegra, right?
[05:20] <tvoss> RAOF, might be interesting, especially as we have a lot of nexus 7 hw lying around
[05:20] <tvoss> yup
[05:21] <RAOF> Sounds like it's not _currently_ interesting though, as it doesn't actually do any 3D :)
[05:22] <tvoss> RAOF, hmmm, I thought I read that NVIDIA open-sourced the 2D drivers, too
[05:22] <RAOF> They did; the 2D driver + kms has been open-sourced for... a while? A year or so?
[05:22] <tvoss> RAOF, s/2D/3D/g
[05:25] <RAOF> 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] <tvoss> RAOF, :) okay, I got that impression, too
[05:26] <tvoss> jono, good morning?
[05:31]  * RAOF goes to test the mesa in-process-egl changes
[05:32] <alf_> RAOF: Are you ready (i.e. mesa) for ~raof/mir/use-dma-buf to land?
[05:36] <RAOF> alf_: Yes*
[05:36] <RAOF> *For intel.
[05:37] <alf_> RAOF: Do you mean you have just checked on intel, or that you know that e.g. radeon doesn't work?
[05:37] <RAOF> radeon and nouveau will require additional patching, which shouldn't take long, but I haven't yet done.
[05:38] <RAOF> I should probably fix them before we land dma-buf, I guess :/
[05:38] <alf_> RAOF: ok, since this will break things for me, I vote for postponing the final approval
[05:42] <RAOF> Fair enough. I'll have fixes for radeon and nouveau prepared before marking it as approved.
[05:43] <alf_> RAOF: ok, I have marked the branch as needs fixing to discourage others from merging
[05:44] <alf_> RAOF: feel free to ignore it and Approve when the mesa side has been fixed
[06:09] <RAOF> Hm.
[06:09] <RAOF> Why doesn't in-process-egl work for me.
[06:12] <RAOF> 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] <RAOF> BigWhale: You wanted to annoy some Mir developers? :)
[07:10] <BigWhale> RAOF, indeed! :)
[07:10] <BigWhale> ;)
[07:12] <BigWhale> 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] <BigWhale> If I got Mir specs, correctly, this will not be a trivial thing to do. With all the security restrictions.
[07:13] <RAOF> 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] <RAOF> 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] <RAOF> Wherever those app manifests go :)
[07:16] <BigWhale> Ok.
[07:16] <RAOF> 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] <tvoss> 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] <RAOF> tvoss: Eh, just export the framebuffer as an EGLImage.
[07:17] <tvoss> RAOF, yeah, that was the idea then :) iirc
[07:18] <BigWhale> Ideally, I'd like to have something that I'll be able to feed into GStreamer.
[07:19] <tvoss> RAOF, makes sense to file a bug at least?
[07:19] <RAOF> 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] <RAOF> tvoss: It's probably a blueprint/series of work items.
[07:20] <tvoss> RAOF, sure, just to make sure that we have it tracked somewhere
[07:20] <BigWhale> 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] <RAOF> Maybe :)
[07:21] <RAOF> 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] <BigWhale> 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] <RAOF> Yeah, that'd be great.
[07:22] <BigWhale> RAOF, offering my help with this, was the next step, yes. :)
[07:25] <RAOF> 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] <BigWhale> I'll start with setting up the dev environment and brushing up my C skills... :>
[07:26] <RAOF> C++, actually.
[07:26] <RAOF> C++11, specifically. Much more expressive.
[07:27] <RAOF> You have such modern affordances as lambdas!
[07:27] <BigWhale> Now you gave me two heart attacks ... :>
[07:28] <BigWhale> C++11 actually makes C++ good. Well, better... :)
[07:29] <RAOF> 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] <thiagoandrade> 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] <thiagoandrade> 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] <thiagoandrade> 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] <thiagoandrade> 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] <kdub> goood morning folks, still plowing ahead towards that fb native window type
[15:35] <alf_> status: working on introducing the mir main loop
[15:43] <thiagoandrade> kdub, Can you help  me with running Mir?
[15:43] <kdub> thiagoandrade, on android i can
[15:47] <thiagoandrade> kdub, Unfortunately I'm running on raring inside VirtualBox
[15:47] <thiagoandrade> Thanks anyway ;)
[16:02] <racarr> and ask for comment :/win goto 10
[16:02] <racarr> ...woah what was that
[16:02] <racarr> good morning
[16:22] <racarr> the keymapping interfaces I am coming up with look laughably incorrect
[16:22] <racarr> due to the duplication of droidinput::InputEvent and MirEvent
[16:22] <racarr> so I am going to rip out droidinput::InputEvent and synthesize MirEvent directly
[16:25] <racarr> thiagoandrade|af: Did not realize you were in virtual box...-.-
[16:25] <racarr> would not expect it to work inside VB atm.
[17:14] <thiagoandrade> 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] <kgunn> thiagoandrade: partition & dual boot
[17:20] <kgunn> ?
[17:22] <thiagoandrade> 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] <thiagoandrade> 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] <kgunn> mmm
[19:11] <kgunn> i may have just bricked my galaxy s3 :-/
[19:23] <kdub> my poor nexus4 spends its entire life panicking about not being able to find surfaceflinger
[19:24] <kdub> kgunn, how so?
[19:52] <kgunn> back
[19:53] <kgunn> kdub: well...i loaded the CM recovery kernel...but now rebooting endlessly at splash screen
[19:53] <kgunn> kdub: i'm seeing lots of complaints about the same
[19:55] <kdub> sounds like its at least loading the kernel though, thats a good sign
[20:11] <kgunn> kdub: freaky as all get out....loaded a recovery.img....it rebooted a couple of times from the CWM screen...but now stable
[21:56] <kgunn> kdub: do you know if Thomi got glmark2 up on jenkins?
[21:56] <kdub> kgunn, don't know
[22:54] <kgunn> racarr: just checking...should someone else take on [robertcarr] Client focus notification (likely depends of notifcation work vanvugt is doing): TODO
[23:16] <kgunn> racarr: can you also move (not copy)
[23:17] <kgunn> racarr: your items in the iteration-0-mir blueprint ?
[23:17] <kgunn> racarr: and mark them as INPROGRESS rather than POSTPONED
[23:17] <kgunn> racarr: ....or...even DONE if you can land :)