[00:00] <kdub> ah, because right now the focus is tied to the z-order?
[00:00] <AlbertA> right
[00:00] <kdub> let me poke around...
[00:01]  * mterry wasn't able to find something appropriate
[00:01] <kdub> mir::DefaultServerConfiguration::the_shell_focus_setter maybe
[00:02] <kdub> but that might be something to fix in msh::DefaultFocusMechanism too
[00:02] <kdub> racarr_ ^^?
[00:05] <mterry> kdub, well.  I mean, sure.  I'm using focus to get at z-order (it's actually convenient that they're tied together now). But my goal is not to futz with the focus subsystem, but to avoid the flash of session1 when I'm trying to adjust z-order of sessions
[00:05] <AlbertA> does the focus change force show on the session?
[00:06] <AlbertA> meaning have you tried session1->hide()
[00:07] <AlbertA> just from poking at the source it doesn't look like it "unhides" it
[00:07] <mterry> oh hm, maybe...  let me try clever hiding/showing
[00:08] <mterry> AlbertA, unhides?
[00:08] <AlbertA> shows
[00:08] <mterry> AlbertA, ah the focus you mean
[00:08] <AlbertA> heh
[00:08] <AlbertA> right
[00:08] <mterry> AlbertA, let me play with hiding, good idea
[00:08] <AlbertA> the focus change in DefaultFocusMechanism doesn't look like it messes with the show/hide state
[00:22] <racarr_> woah things happened
[00:22] <racarr_> *reads*
[00:23] <racarr_> I see.
[00:23] <racarr_> oh
[00:23] <racarr_> mterry left
[00:24] <racarr_> I think the answer is to overrride the focus setter...I dont understand
[00:24] <racarr_> exactly why
[00:24] <racarr_> you would focus 1 session then another but not want the 1st session to show up
[00:24] <racarr_> if it ust needs keyboard focus or something like that there is the mir::shell::InputTargeter
[00:25] <racarr_> Iunno.
[00:25] <racarr_> oh I see using focus to adjust the z order
[00:26] <racarr_> I think the answer is to use surface->raise ;)
[00:41] <RAOF> Heh.
[00:41] <RAOF> racarr_: Yo!
[00:41] <RAOF> You in the mood for some cursory stuff?
[00:41] <RAOF> I Have Opinions!
[02:09] <duflu> AlbertA: Can you remember to set the Milestone and other details on bugs when you're working on them? Otherwise I have to play catch up and fix them every day :)
[02:57] <AlbertA> duflu: sure
[03:20] <duflu> AlbertA: Thanks. Don't be afraid to do project management stuff in Launchpad. It's really just a matter of whoever-notices-what-needs-fixing-first
[07:33] <duflu> RAOF: Any tips on my comment to https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor/+bug/1294507
[07:33] <duflu> ?
[08:08] <anpok_> resize events hmm
[08:10] <anpok_> they never seem to happen for the surface of a nested server
[08:25] <anpok_> duflu: can you give me a hint - when finger paint runs in nested, and the nested surface gets resized.. the finger paint surface is aligned bottom left..
[08:26] <anpok_> another thing I saw is that the gl_renderer in the nested server still assumes the same view port size
[08:26] <duflu> anpok_: Not sure. I suggest checking that you haven't accidentally dragged/moved the whole nested server surface inside demo-shell
[08:26] <anpok_> to circumveit that I injected a resize event to the client side surface when a different sized buffer arrives..
[08:26] <anpok_> checked that
[08:27] <anpok_> i do exactly that
[08:27] <anpok_> only move the nested server
[08:27] <duflu> anpok_: Still don't know :(
[08:27] <anpok_> I am verifing that co-ordinate transforms are now correct
[08:27] <anpok_> thats just a side issue now..
[08:27] <anpok_> I mean.. co-ordinates are correct, but mismatch with visaual placements..
[08:27] <anpok_> k
[08:28] <anpok_> will dig further..
[08:28] <duflu> anpok_: Obviously, test with development-branch and see if it has the same bug :)
[08:28] <anpok_> it has
[08:28] <anpok_> and other things
[08:29] <anpok_> now that I made the gl_renderer get the right view port rectangle the top left alignment is correct..
[08:30] <duflu> anpok_: That doesn't sound right. How is the viewport rectangle wrong?
[08:30] <anpok_> but the displayed finger paint surface seems to have increased in scale by the fraction the nested surface got resized..
[08:30] <duflu> anpok_: Sounds like you resized the nested server
[08:30] <anpok_> Yeah thats what I do
[08:30] <anpok_> (not supported?)
[08:31] <duflu> Never considered really
[08:31] <duflu> I guess coordinates could be wrong
[08:31] <anpok_> I resize the nested server surface to lik 50x50 .. and gl_renderer::set_view_port gets no call.. still assumes 0,0 1600x2560
[08:31] <anpok_> or rtahter 2560x1600 or something..
[08:31] <duflu> anpok_: I was playing with set_viewport yesterday. It doesn't (yet) get called after construction. Sounds like we need to call it more/
[08:31] <duflu> ?
[08:32] <duflu> For the nesting case
[08:32] <anpok_> It gets called at construction.. but a resize of the nested server does not cause another renderer reconstruction
[08:32] <duflu> anpok_: If you can please isolate any fix for that bug from your other work
[08:32] <anpok_> hence it stays at initial size
[08:32] <duflu> Yeah, sounds like a nesting-specific bug
[08:33] <anpok_> but I can pass the information from the resized surface through the nested output down to the renderer object
[08:33] <anpok_> that change enough for a MP?
[08:33] <duflu> anpok_: As small as possible is always best. If you can separate things then do
[08:33] <anpok_> k .. will check for scaling later
[08:34] <duflu> anpok_: And a bug report to describe the problem :)
[08:34] <anpok_> hehe
[08:34] <anpok_> thats the hardest part
[08:34] <anpok_> can you have a brief look at my branch .. hmm
[08:34] <anpok_> wait
[08:35] <anpok_> http://bazaar.launchpad.net/~andreas-pokorny/mir/add-geometry-transformation/view/head:/include/shared/mir/geometry/transformation.h
[08:35] <anpok_> It is lacking a better name..
[08:36] <anpok_> In a later MP I want to use that to do the co-ordinate transformations
[08:36] <anpok_> it allows us to avoid any calculations and still supports rotations scaling and so on..
[08:36] <anpok_> and makes it simple to make run time changes to them..
[08:37] <anpok_> brb
[08:37] <anpok_> I am no longer sure about the name..
[08:38] <anpok_> as I was about to add something like rectangle hit testing as a free standing function or method..
[08:39] <duflu> anpok_: Transformations are arbitrary so we should stop mentioning "rotate" or "scale" completely. Instead the code that needs those (render_surfaces) should just surface->set_transformation(some_matrix)
[08:40] <duflu> It might be a good idea to replace set_rotation in our existing classes with set_transformation(). Now we can
[08:57] <duflu> anpok_: I was going to do it, but it would be awesome if you could generalize set_rotation() to set_transformation() and move the responsibility for creating the rotation matrix into render_surfaces
[09:14] <duflu> Woo... multi-monitor frame sync without framenos, on the way
[09:36] <anpok_> duflu: I wanted to do that with the help of transformation ..
[09:37] <anpok_> which I meant to become a generalization of surface positioning and transformation.. + the inverse ..
[09:38] <anpok_> doing the inverse on a matrix does take some more time and it does add some floating point error..
[09:38] <duflu> anpok_: Oh, I see now. The generic name confused me. It's more than just a transformation. Regardless, we need to remove all mentions of rotation and scaling from the existing surface classes. They should only know a single  "transformation" matrix
[09:39] <duflu> anpok_: We should also *never* need to invert. Matrices should be arranged such that you only try to invert orthonormal matrices (whose inverses are just transpose)
[09:40] <anpok_> yes, thats what I have been doing internally
[09:42] <anpok_> the intersting part will be to which surface interface the change should happen
[09:43] <duflu> anpok_: I'm running out of time before I have a family dinner to run to. But is the meaning of Transformation to join transformation() and size+position into one? If so then I get it but "Transformation" is a bad name
[09:45] <anpok_> sure
[09:45] <anpok_> I try to change my bio rythm
[09:45] <anpok_> go!
[09:48] <duflu> anpok_: I still suspect the whole exercise is a bad idea. You would have to integrate the whole display transformation into the input logic to get it right. Not just surface transformations. The display transformation will change at the Renderer level during some effects (in future)
[09:49] <anpok_> hm as you already said .. those changes are temporal
[09:50] <anpok_> thus .. if the effect is going to be persistent.. the input system needs to know about it..
[09:50] <duflu> anpok_: Yeah good memory. We could just block all input during such transformations because "we can't calculate it"
[09:50] <duflu> Compiz solves the problem by only supporting relative movement. It never needs or uses absolute coordinates
[09:50] <anpok_> i suspect shells would only use reasonable transformations in a persistent manner.. and thats the use case here..
[09:51] <anpok_> I dont think that solve anything.. since a relative movement on a transformed surface still needs to be transformed..
[09:52] <duflu> It would be a lot less work. But also couldn't support touch
[09:53] <anpok_> i took care to not impose unnecessary calculations when dispatching input
[09:53] <anpok_> but measurements on n4 showed that the worst case isnt that bad either
[09:55] <duflu> anpok_: I suspect your super "Transformation" might not need to be a class. Maybe just a new function - surface::transformation_with_size_and_position()
[09:57] <duflu> And then I ran out of time
[10:10] <mlankhorst> RAOF: ping?
[10:35] <RAOF> mlankhorst: Pong?
[10:37] <mlankhorst> RAOF: oh less relevant now that I did the work myself, did you update mir for 10.2 snapshot-ish?
[10:38] <RAOF> mlankhorst: No, not since 10.1.
[10:38] <RAOF> That area of the code shouldn't churn much, though?
[10:38] <mlankhorst> yeah I did some work in ubuntu+1, I'll push it soon :P
[10:38] <mlankhorst> it moved some crap to a vtable
[10:38] <RAOF> Oh.
[10:39] <RAOF> We should really get around to sticking the whole EGL platform stuff into loadable modules.
[10:40] <mlankhorst> or upstream it already
[10:47] <RAOF> Well, both, ideally.
[10:51] <mlankhorst> stuffed it in ppa:canonical-x/x-staging
[11:29] <anpok_> alan_g: the issue from yesterday https://bugs.launchpad.net/mir/+bug/1294610
[11:30] <alan_g> anpok_: I remember you asking about it
[11:30] <anpok_> no news.. so far.. I could not dig further. It is no issue on android
[11:31] <anpok_> I first have to improve my second terminal for debugging - that means replacing a hard disk..
[11:32] <alan_g> Yeah, I usually ssh in from another box for this stuff. (And VT is only relevant to mesa)
[12:18] <anpok_> alan_g: not sure if you noticed from the scroll back I try to resolve a window placement issue with nested clients being resized.
[12:18] <anpok_> hm it might be a reasonable rare use case but we have it in the demos
[12:20] <alan_g> anpok_: I didn't. So that's with a client of a server_shell that's a client of a server_basic?
[12:20] <anpok_> two server shells and fingerpaint
[12:20] <anpok_> with a minimal change I made the nested shell become aware of a resolution change
[12:20] <alan_g> But the hose server_shell will process the resize
[12:20] <anpok_> yes
[12:20] <alan_g> *hist
[12:20] <anpok_> means nested surface gets smaller..
[12:20] <alan_g> **host
[12:21] <alan_g> ack
[12:21] <anpok_> but nested server still renders like full screen
[12:21] <anpok_> and also has view port set up like that ..
[12:21] <alan_g> I understand
[12:22] <anpok_> due to the way gl writes to the buffer it gets bottom left aligned and hence touched pixels do not match drawn pixels
[12:22] <anpok_> or rather touch co-ordinates that get proper transformed..
[12:22] <anpok_> maybe I just provide my change as a MP and we discuss that there
[12:23] <anpok_> i mean .. I think I need to do more .. like announce that the display output changed ..
[12:27] <alan_g> that makes sense - but is this the most urgent thing to fix?
[12:48] <anpok_> alan_g: what is urgent?
[12:51] <alan_g> anpok_: The stuff needed for 14.04 touch
[13:38] <greyback> alf__: hey, I'm running in multimonitor (MM) setup (just 2, not mirrored). But when I bring up mir_demo_server_shell, I get mirrored output. Is there a demo to test Mir's MM abilities?
[13:38] <greyback> alf__: never mind, found the CLI switch
[13:39] <alf__> greyback: mir_demo_server_shell --display-config sidebyside and you can try mir_demo_client_display_config to change config on the fly (see help for handled key events)
[13:39] <alf__> greyback: ok
[13:40] <greyback> alf__: thanks :)
[13:42] <kgunn> greyback: mterry alan_g|lunch ... so i'm following up on a request to think about making mir/unity-mir/usc one source tree, for the obvious reason it makes build/release life simple...but i think it's a bad idea (e.g. hard to quick release a unity-mir fix for instance)...thots ?
[13:42] <greyback> alf__: sorry, am idiot, but where do I see the mir_demo_client_display_config help? The --help switch (or -h) is ignored
[13:43] <mterry> kgunn, yeah, both unity-mir and usc often have feature/bug fix releases unrelated to mir
[13:44] <kgunn> ..and the real answer is live with the release pain in order to drive us to a stable server i/f
[13:44] <kgunn> imho
[13:44] <alf__> greyback: it works for me :/
[13:45] <greyback> alf__: ah, I'm running it with sudo (since mir server root), and the --help switch seemed to be ignored
[13:45] <alf__> greyback: hmm...
[13:50] <greyback> kgunn: I'm against it. While yeah I do see the benefit for distro releases, I fear it'll give the appearance that Mir is Qt only. For nonQt users, do we add configure time switch to disable Qt (and thus unity-mir) at build time then? What if I want to make a unity-mir clone in GTK, where does my code best go?
[13:50] <kgunn> ah nice point
[13:51] <greyback> kgunn: also, long term ambition is to get large chunks of unity-mir into Qt. The Qt guys were interested in supporting Mir, like it supports Wayland
[13:51] <greyback> so shoving that code directly into Mir just complicates that transition path
[13:51] <kgunn> ack
[13:52] <greyback> kgunn: I was of the impression that the whole silo infrastructure was designed explicitly for this very problem anyway
[13:53] <kgunn> greyback: it is, altho only 1/2 way there...what's missing is a "dedicated silo" for us which is in the plans (e.g. what they call "airline" vs "train")
[13:55] <greyback> kgunn: I see. Then the airline sounds like the right way to go IMO
[13:58] <alan_g> +1
[13:59] <kgunn> they've also taken one step closer...you can get around the "silo-ck" allowing you to build at will (but not land) when another person is trying to build/land in the same project
[14:00] <kgunn> cause the silock is really where the pain (time delay) has been
[14:01]  * alan_g wonders where we can find hosting to set up our own build system
[14:11] <greyback> alf__: I guess changing display resolution/refresh rate with xrandr doesn't impact the resolution Mir chooses
[14:13] <alf__> greyback: the display configuration is per VT so they act independently
[14:13] <greyback> alf__: aha
[14:13] <alf__> greyback: (assuming you mean mir in a VT and normal X in another, not talking about XMir)
[14:15] <greyback> alf__: correct assumption. Essentially I'm trying to set up my env so I can see the impact of the MultiThreadedCompositor, i.e. when the outputs have different resolutions. I guess I should see frame drops on the slower display
[14:16] <greyback> alf__: but xrandr depends on X. Know any way I can configure a display without X?
[14:16] <ogra_> fbset ?
[14:20] <alf__> greyback: Why do you want to configure a display manually? In any case, mir should be able to set the display configuration you want (perhaps need to hack the example code to do so).
[14:22] <greyback> alf__: both my displays run at about 60Hz, but my monitor can run at 75Hz with a lower resolution, so want to select that resolution for MIr.
[14:22] <greyback> I'll see what I can hack in
[14:23] <alf__> greyback: ok, that's possible, but it's not provided by default by mir_demo_client_display_config.
[14:23] <greyback> ok
[14:25] <alf__> greyback: you need to set MirDisplayOutput::mode to the value you want (index of one of the modes available in ::modes[])
[14:25] <greyback> alf__: that's useful, thank you
[14:26] <alf__> greyback: sorry, that's MirDisplayOutput::current_mode
[15:58] <kdub> anyone else want to weigh in on https://code.launchpad.net/~kdub/mir/platform-specific-options/+merge/210500 ?
[15:59]  * alan_g has said enough
[16:00] <kdub> alan_g, yeah, thanks for the reviews :)
[16:00] <alan_g> kdub: try alf__
[16:04] <anpok_> hm alan_g said that it only works if we ignore unknown options in mir server, is that still true?
[16:05] <anpok_> I thought this change now just exposes the underlying boost program options to combine them with the platform graphics options?
[16:06] <kdub> we have to parse the options twice, once to get the right platform library name
[16:06] <kdub> and the first parse just scans for the platform library name, so it ignores any other specified options
[16:06]  * alan_g said that it only works *because* we ignore unknown command-line options
[16:09] <anpok_> ah because during the first scan we have those only supported by the platform.. and the then on second scan with the options from platform graphics we get could fail on unknown ones..
[16:09] <anpok_> do we care that about frequency of ABI breaks when we expose boost program options to the server<->platfrom graphics interface?
[16:10] <kdub> server/platform abi moves in lockstep
[16:17] <alf__> kdub: looking
[16:17] <kdub> thanks!
[20:10] <racarr_> mterry: Btw I saw your question yesterday after you left...you should be able to use surface->raise to set the Z orders
[20:10] <racarr_> so then you can use hide
[20:11] <racarr_> (which using focus to set z order will undo for you)
[20:11] <mterry> racarr_, well, I want to do it on a session level, but I suppose I could do it to each surface in session, and try to keep existing order internal of the session
[20:12] <mterry> racarr_, is that right, that focus calls show?
[20:21] <racarr_> mterry: Yes focus calls show
[20:22] <mterry> racarr_, ok, that would explain some flicker
[20:22] <racarr_> Is it possible for you to ust place them in depth appropriately as they are created
[20:22] <racarr_> you can set depth in PlacementStrategy
[20:56] <racarr_> bregma: So cursor fix is going to be a little longer probably so going to do the quick and dirty solution
[20:57] <racarr_> need to understnad a few details of the configuration for desktop preview
[20:57] <racarr_> what else is running under USC? I mean.
[20:57] <racarr_> IS greeter under USC? What about xmir?
[20:57] <racarr_> greeter isnt under USC presumably but does that happen if they install xmir?
[20:57] <racarr_> is that supported
[20:57] <racarr_> etc
[20:58] <racarr_> kgunn: ^
[20:59] <kgunn> robert_ancell: ^ you know ?...in the context of unity8 desktop preview
[21:00] <robert_ancell> racarr_, kgunn, greeter is not running under u-s-c. LightDM launches a u-s-c for each Unity8 desktop session and it only runs the shell inside that
[21:02] <racarr_> hi robert_ancell!
[21:02] <racarr_> ok perfect
[21:02] <robert_ancell> racarr_, hey :)
[21:03] <robert_ancell> I don't know of the support status of xmir - we still have all the code in LightDM but you'd have to install the packages to enable it
[21:03] <racarr_> err hey wait
[21:03] <racarr_> if we launch a usc for each Unity8 desktop session
[21:03] <racarr_> and only run the shell
[21:03] <racarr_> why are we launching
[21:03] <racarr_> USC
[21:03] <robert_ancell> racarr_, because we need u-s-c as root and the shell as non-root
[21:03] <racarr_> oh of course lol
[21:03] <racarr_> Ok :D
[21:03] <robert_ancell> it's basically u-s-c "pretending to be an X server"
[21:04] <racarr_> (dealing with enabling cursor in desktop preview for context)
[21:04] <robert_ancell> yep
[21:04] <racarr_> Where does the bit that tells lightdm how to launch USC for the desktop preview
[21:04] <racarr_> look?
[21:04] <racarr_> will need to add a command line option there
[21:05] <racarr_> s/look/live/
[21:05] <robert_ancell> racarr_, the usc command line?  Or the bit that tells lightdm that a session should run in Mir?
[21:06] <racarr_> robert_ancell: the usc command line
[21:06] <racarr_> I mean the situation is ust we disabled the hardware cursor in USC for xmir so
[21:06] <racarr_> need to add a --enable-cursor to USC and
[21:06] <racarr_> have lightdm pass it
[21:06] <racarr_> for desktop preview
[21:06] <robert_ancell> racarr_, ah, ok. You need to edit src/unity-system-compositor.[ch] and add that as a property
[21:07] <robert_ancell> and set that property in src/seat-xlocal.c in create_unity_system_compositor()
[21:07] <robert_ancell> and then update in tests/src/unity-system-compositor.c to report that flag and then tests/scripts/*.conf to check for it
[21:08] <racarr_> err is this for desktop preview only though? dont want to pass --enable-cursor to XMir
[21:08] <robert_ancell> racarr_, is this the long term solution? Or should the shell be triggering / rendering the cursor?
[21:08] <racarr_> robert_ancell: Perhaps in the long term just the shell renders the cursor
[21:08] <robert_ancell> racarr_, we use src/seat-unity.c for "proper" Mir sessions
[21:08] <racarr_> perhaps as early as next week
[21:09] <robert_ancell> src/seat-xlocal.c is the traditional VT switched sessions
[21:09] <racarr_> xmir just disables it via cursor client API
[21:09] <robert_ancell> xlocal is a legacy name, we should really name it to seat-vt.c now
[21:09] <racarr_> but things are getting close on desktop release so just trying to take care of it...didnt realize it would involve
[21:09] <racarr_> so many changes to lightdm though...I was expecting some like
[21:09] <racarr_> u8-desktop-session.conf or something and I would just add an argument there
[21:10] <robert_ancell> racarr_, you can do that too
[21:10] <robert_ancell> by setting unity-compositor-command in the config
[21:10] <robert_ancell> it might interact with xmir seats though because that config is shared between the two
[21:10] <robert_ancell> racarr_, I can do the lightdm change if you want, it wont take long
[21:12] <robert_ancell> racarr_, but if you have this cursor client API, why not just enable it through that?
[21:12] <racarr_> robert_ancell: Ok if you dont mind that would be great :D Ill do the USC changes now...option will be --enable-hardware-cursor=on/off (default: off)
[21:13] <racarr_> robert_ancell: Oh because its not going to be finished until the next day or perhaps the day after that then
[21:13] <robert_ancell> ok
[21:13] <racarr_> its gotten kind of large so will take a while to review
[21:13] <racarr_> then there is the whole landing cycle...
[21:13] <racarr_> and it could easily be 2 weeks before anything could use it I guess
[21:13] <racarr_> so starting to get concerned about desktop freeze
[21:17] <racarr_> robert_ancell: I guess just --enable-hardware-cursor to enable it
[21:17] <racarr_> omit to disable it is better
[21:17] <racarr_> no on/off aha
[21:17] <robert_ancell> yeah, I was worried about breaking older versions
[21:17] <robert_ancell> will do
[21:29] <racarr_> robert_ancell: nvm I forgot how boost::option works it has to be --enable-hardwarecursor=on/1/true/whatever (I guess pass true)
[21:29] <robert_ancell> racarr_, lp:~robert-ancell/lightdm/usc-hardware-cursor
[21:29] <racarr_> but alse will still be the default so can still omit it
[21:29] <robert_ancell> oh, so I have to send --enable-hardware-cursor=true?
[21:30] <racarr_> yes...sorry
[21:33] <racarr_> https://code.launchpad.net/~robertcarr/unity-system-compositor/add-cursor-option
[21:33] <racarr_> bregma: kgunn: ^ these two branches should do it I guess
[21:33] <racarr_> maybe this is an appropriate situation for distro patching?
[21:35] <bregma> I can't test anything until I figure out why Qt5.2 doesn't work on the desktop
[21:35] <racarr_> Ah of course
[21:36] <racarr_> any progress on that end?
[21:37] <bregma> racarr_, nope, except I get it on all my machines :( and when running apps over ssh but not when I run apps from unity7, so I suspect it may have to do with Mir after all
[21:40] <kgunn> racarr_: robert_ancell ...thanks for sorting that out (and so freakin' quick :)
[21:40] <kgunn> robert_ancell: btw, how the heck are you ?
[21:40] <robert_ancell> kgunn, doing well, yourself?
[21:40] <robert_ancell> nice location for the next sprint :) Will be good to catch up with all
[21:40] <racarr_> yes thanks for help robert_ancell  :)
[21:41] <racarr_> I know right? When kgunn said it might be something exciting
[21:41] <racarr_> I kind of assumed that was a oke and we were going to Boston
[21:41] <racarr_> :p
[21:41] <kgunn> robert_ancell: good, if we could just get the spring weather to stick in texas...it keeps freezing every few days
[21:41] <kgunn> i know...its cool enough i'm gonna have my wife join for some time after the sprint
[21:43] <robert_ancell> I have a feeling a lot of the company will be taking holidays around this sprint
[22:12] <racarr_> RAOF: Ping?
[22:13] <racarr_>  or perhaps pong technically
[22:20] <racarr_> brb in 10.
[22:35] <racarr_> back
[22:37] <RAOF> racarr_: Pong!
[22:41] <RAOF> racarr_: You're thinking cursors?
[22:43] <racarr_> RAOF: Yes. and wondering wwhat you were thinking
[22:44] <RAOF> Cool.
[22:44] <racarr_> as to the small bits that were on launchpad...uh
[22:44] <racarr_> it was a mild hallucination that doing it per connection was going to be easier and also a useful step towards per surface so I ust imagined doing that first
[22:44] <RAOF> Hah!
[22:44] <racarr_> but have now decided it was silly and am on to mir_surface_set_cursor
[22:44] <racarr_> and um...
[22:44] <RAOF> It probably _would_ be easier to do per-connection :)
[22:44] <racarr_> well but you have to write code that ends up not being useful
[22:44] <racarr_> so its pretty pointless
[22:45] <RAOF> Yeah.
[22:45] <RAOF> It's not a step towards per-surface cursors, which is what you need.
[22:45] <racarr_> Also re:create_hardware_cursor
[22:45] <racarr_> and unique/shared here it actually is shared
[22:45] <racarr_> with the GBM::Display which manipulates it in case of pause/stop, etc.
[22:45] <racarr_> which is mostly why it hasnt been moved to some more appropriate place of allocation yet
[22:46] <RAOF> Urgh.
[22:46] <racarr_> err pause/resume
[22:46] <racarr_> to restore the position iirc
[22:47] <RAOF> Yeah, because it's all wrong! :)
[22:47] <racarr_> lol
[22:47] <racarr_> what are your thoughts :D
[22:48] <RAOF> So, what I think should be the final state is: The cursor is a renderable in the scene, and the compositor is responsible for getting it on the screen.
[22:49] <RAOF> Under GBM the compositor will check if the topmost renderable in the scene is (a) the existing hardware cursor or (b) usable as a HW cursor, and do the API twiddling necessary.
[22:49] <racarr_> ok
[22:50] <RAOF> Under Android the HWC machinery will translate into basically a HW cursor anyway
[22:50] <racarr_> Yes
[22:50] <RAOF> So I think all the Cursor API wants to be is basically a pointer at a specific renderable.
[22:50] <racarr_> hmm well I mean
[22:51] <RAOF> If we want a server cursor API at all, I guess?
[22:51] <racarr_> it seems like it still needs to be promoted to the server configuration and
[22:51] <racarr_> from the perspective of mg::Cursor
[22:51] <racarr_> RAOF: Well we are baking window management in to mir
[22:51] <racarr_> so the surface cursor selection has to work by default
[22:52] <racarr_> and input should be hooked up to the cursor, etc
[22:52] <RAOF> Oh, yeah.
[22:52] <RAOF> That was just rambling as to what extent we need a Mir-private Cursor API.
[22:52] <RAOF> Or whether the various bits could just prod the relevant Renderable.
[22:53] <RAOF> It's probably cleaner to have an actual interface to prod, though.
[22:54] <racarr_> hmm
[22:54] <racarr_> yes it is for tests
[22:54] <racarr_> at least
[22:54] <RAOF> Right.
[22:54] <racarr_> its nice for example in the tests im doing to ust mock the_cursor on the server side
[22:54] <racarr_> and expect that set_image is called various ways as
[22:54] <racarr_> I generate motion events
[22:54] <racarr_> etc
[22:54] <RAOF> Yeah.
[22:55] <racarr_> so, it should also be a renderable though
[22:55] <racarr_> and rather than this whole weird bit where
[22:55] <racarr_> the GBMDisplay holds on to it and
[22:55] <racarr_> such
[22:55] <racarr_> the default shell becomes responsible for putting it in the scene I guess?
[22:55] <RAOF> Right.
[22:55] <RAOF> I think so, yes.
[22:56] <RAOF> Unless we want to bake in ‘the cursor is always on top of everything’.
[22:56] <RAOF> Which I'm ambivalent about.
[22:56] <racarr_> mm I mean maybe its the deault shell, deault server configuration
[22:56] <racarr_> somewhere there is a line that is like hey take the_cursor and put it on the_top_of_everything
[22:56] <racarr_> lol Mir::DefaultServerConfiguration::the_top_of_everything
[22:57] <racarr_> that seems like a good interface
[22:57] <RAOF> :)
[22:57] <RAOF> I think having it default to on top but overridable in the same way we let everything be overridable is correct.
[22:58] <racarr_> ok  I think that makes sense. I think I can do that when I implement a software cursor
[22:58] <racarr_> I want to finish this client API/theme loader stuff first
[22:58] <racarr_> its gotten kind of large diffish lol
[22:59] <RAOF> Yeah, theme loader stuff is a reasonable first step.
[22:59] <RAOF> That way we can actually load different cursors :)
[23:01] <racarr_> Im hoping to finish the client API bits and the cursor changer response to input thingamawidget tomorroww so thatw
[23:02] <racarr_> we can at least enable/disable cursor and use that for xmir/desktop preview
[23:02] <racarr_> then will finish the theme loader branch by friday
[23:07] <RAOF> Yeah, would be nice.