| racarr | not today! | 00:05 |
|---|---|---|
| desrt | RAOF: hi | 01:04 |
| 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:05 |
| desrt | what sort as in what different types or as in what sort of delivery mechanism? | 01:06 |
| 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:07 |
| desrt | for compose sequences... | 01:08 |
| RAOF | For keyboard(ish) events. | 01:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| desrt | yes. | 01:16 |
| RAOF | Hm. What about shortcut-highlighting on holding <Alt>? | 01:17 |
| desrt | that's just a modifier watch | 01:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| desrt | should it show, or not? | 01:26 |
| desrt | same question applies to showing underline on alt | 01:26 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:32 |
| 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:33 |
| 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:34 |
| desrt | where the press and release are just two different events | 01:35 |
| desrt | anyway.... beer o'clock :) | 01:36 |
| RAOF | Heh. Have fun! | 01:36 |
| desrt | g'night | 01:36 |
| === tux is now known as Guest21807 | ||
| 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:18 |
| RAOF | I've not taken a look at it, no. | 05:19 |
| 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:20 |
| RAOF | Sounds like it's not _currently_ interesting though, as it doesn't actually do any 3D :) | 05:21 |
| 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:22 |
| 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:25 |
| tvoss | RAOF, :) okay, I got that impression, too | 05:26 |
| === jono is now known as Guest52708 | ||
| tvoss | jono, good morning? | 05:26 |
| * RAOF goes to test the mesa in-process-egl changes | 05:31 | |
| alf_ | RAOF: Are you ready (i.e. mesa) for ~raof/mir/use-dma-buf to land? | 05:32 |
| RAOF | alf_: Yes* | 05:36 |
| RAOF | *For intel. | 05:36 |
| 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:37 |
| 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:38 |
| RAOF | Fair enough. I'll have fixes for radeon and nouveau prepared before marking it as approved. | 05:42 |
| alf_ | RAOF: ok, I have marked the branch as needs fixing to discourage others from merging | 05:43 |
| alf_ | RAOF: feel free to ignore it and Approve when the mesa side has been fixed | 05:44 |
| RAOF | Hm. | 06:09 |
| RAOF | Why doesn't in-process-egl work for me. | 06:09 |
| 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. | 06:12 |
| RAOF | BigWhale: You wanted to annoy some Mir developers? :) | 07:08 |
| BigWhale | RAOF, indeed! :) | 07:10 |
| BigWhale | ;) | 07:10 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:16 |
| RAOF | tvoss: Eh, just export the framebuffer as an EGLImage. | 07:17 |
| tvoss | RAOF, yeah, that was the idea then :) iirc | 07:17 |
| BigWhale | Ideally, I'd like to have something that I'll be able to feed into GStreamer. | 07:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| RAOF | Yeah, that'd be great. | 07:22 |
| BigWhale | RAOF, offering my help with this, was the next step, yes. :) | 07:22 |
| 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:25 |
| 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:26 |
| RAOF | You have such modern affordances as lambdas! | 07:27 |
| BigWhale | Now you gave me two heart attacks ... :> | 07:27 |
| BigWhale | C++11 actually makes C++ good. Well, better... :) | 07:28 |
| 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 :) | 07:29 |
| 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:53 |
| 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" | 13:55 |
| 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 | 14:38 |
| kdub | goood morning folks, still plowing ahead towards that fb native window type | 15:04 |
| alf_ | status: working on introducing the mir main loop | 15:35 |
| thiagoandrade | kdub, Can you help me with running Mir? | 15:43 |
| kdub | thiagoandrade, on android i can | 15:43 |
| thiagoandrade | kdub, Unfortunately I'm running on raring inside VirtualBox | 15:47 |
| thiagoandrade | Thanks anyway ;) | 15:47 |
| === thiagoandrade is now known as thiagoandrade|af | ||
| racarr | and ask for comment :/win goto 10 | 16:02 |
| racarr | ...woah what was that | 16:02 |
| racarr | good morning | 16:02 |
| 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:22 |
| racarr | thiagoandrade|af: Did not realize you were in virtual box...-.- | 16:25 |
| racarr | would not expect it to work inside VB atm. | 16:25 |
| === francisco is now known as Guest49443 | ||
| === tvoss is now known as tvoss|dinner | ||
| === thiagoandrade|af is now known as thiagoandrade | ||
| 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:14 |
| kgunn | thiagoandrade: partition & dual boot | 17:20 |
| kgunn | ? | 17:20 |
| 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:22 |
| 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:23 |
| kgunn | mmm | 17:26 |
| kgunn | i may have just bricked my galaxy s3 :-/ | 19:11 |
| kdub | my poor nexus4 spends its entire life panicking about not being able to find surfaceflinger | 19:23 |
| kdub | kgunn, how so? | 19:24 |
| kgunn | back | 19:52 |
| 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:53 |
| kdub | sounds like its at least loading the kernel though, thats a good sign | 19:55 |
| kgunn | kdub: freaky as all get out....loaded a recovery.img....it rebooted a couple of times from the CWM screen...but now stable | 20:11 |
| === bschaefer_ is now known as bschaefer | ||
| kgunn | kdub: do you know if Thomi got glmark2 up on jenkins? | 21:56 |
| kdub | kgunn, don't know | 21:56 |
| kgunn | racarr: just checking...should someone else take on [robertcarr] Client focus notification (likely depends of notifcation work vanvugt is doing): TODO | 22:54 |
| kgunn | racarr: can you also move (not copy) | 23:16 |
| 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 :) | 23:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!