[09:09] <slvn> Hello !
[09:09] <slvn> I am developping an application for Ubuntu Touch that is native
[09:09] <slvn> it talks directly to mir, and use open gl
[09:09] <slvn> I would like to get it fullscreen
[09:10] <slvn> it works correctly in fullscreen with MIR-only
[09:10] <slvn> but with the launcher (.click package), there is the "appmenu" (status bar with clock, battery, wifi)
[09:10] <slvn> how to hide this AppMenu ?
[09:11] <slvn> I was told that CameraApp was totally fullscreen ... it seems, (though it also reboot my Nexus10)
[09:20] <greyback> slvn: are you using Qt?
[09:20] <slvn> greyback, no !
[09:20] <greyback> slvn: mirclient?
[09:20] <slvn> C/C++ + MIR Client
[09:20] <slvn> yes, through SDL
[09:23] <greyback> ah ok. I'm not sure if SDK wraps this correctly, but mirclient has a mir_surface_set_state(MirSurface *surface, MirSurfaceState state) method where you can set the state to mir_surface_state_fullscreen - and that will make it fullscreen
[09:23] <greyback> slvn: ^
[09:23] <greyback> s/SDK/SDL/
[09:25] <slvn> yes, mir/sdl works correctly
[09:25] <slvn> it sets the surface to fullscreen
[09:25] <slvn> it actually works when I run the application with mir only
[09:25] <slvn> ( I did that a few month ago)
[09:26] <slvn> but, when the app is package with click
[09:26] <slvn> and started with the launcher (upstart?)
[09:26] <slvn> there is this status bar
[09:26] <slvn> so my "fullscreen" windows is shifted
[09:26] <slvn> I need : either to hide the status bar, or to have it sizes
[09:26] <greyback> I don't know of any reason why it being packaged in a click package would stop it being fullscreen. This Mir API is the only way to do it
[09:27] <greyback> if the surface has the fullscreen property set, then unity8 will hide the status bar at the top (camera app & gallery succeed in doing this)
[09:28] <slvn> Hmm, maybe this property has then so be set before some transaction with unity
[09:29] <alan_g> slvn: as a way of narrowing the problem: have you checked with "mir only" recently?
[09:30] <slvn> alan_g, after reflexion, "mir only" needs me to do "initctl stop unity8" + start mir_demo_server_shell
[09:30] <slvn> I haven't tried it recently
[09:30] <slvn> but that's almost sure ...
[09:30] <slvn> before it just start mir
[09:32] <alan_g> slvn: there are three bits of software that may have the problem mir, unity and your program. If we can eliminate unity...
[09:37] <slvn> I fine to try !
[09:37] <slvn> my "mir only" configuration is in fact with the "mir_demo_server_shell"
[09:38] <slvn> but I can find this tool anymore
[09:38] <slvn> can't
[09:40] <alan_g> slvn: mir_demo_server_basic should suffice
[09:44] <slvn> how can I turn on the "apt-get" packages system ? and which package should I get ?
[09:46] <alan_g> slvn: don't bother. After a quick grep there's no code in Mir that cares about the mir_surface_state_fullscreen attribute - it is passed on to unity.
[09:47] <slvn> And as you said "Gallery"  is correctly hiding the status bar
[09:47] <slvn> reading the headers files
[09:48] <slvn> I might have to call "mir_wait_for"
[09:48] <slvn> after "mir_surface_set_type
[09:49] <alan_g> greyback said that. (But it looks like it works to me)
[09:50] <alan_g> slvn: yes, that's an async call
[10:06] <duflu> slvn_: FYI: the state and type attributes are not implemented in mir_demo_server_*
[10:06] <duflu> they won't do anything there
[10:06] <duflu> yet
[10:06] <duflu> Which is why our demo clients fake fullscreen by just sizing themselves
[10:06] <duflu> It's on the list of things to do :)
[10:07]  * duflu -> weekend
[10:46] <slvn_> alan_g, greyback : So I have found :)
[10:46] <slvn_> this is a typo error : calling mir_set_type() on a "State" wont work ..
[10:47] <slvn_> I will report the bug + path to SDL
[10:49] <greyback> slvn_: aha, good catch!
[10:53] <alan_g> slvn_: excellent!
[10:54] <slvn_> :) SDL has macros to load the shared library. and then is may "skip" the type. so there was no warning from the compiled
[10:55] <slvn_> compiler.
[10:55] <slvn_> then I have my issue :o)
[10:55] <slvn_> I want to use the mir surface
[10:56] <slvn_> in landscape or portrait
[10:57] <slvn_> I don't really to how to explain that, but here it is.
[10:58] <slvn_> I have a game that always plays in *vertical*. (like  a tetris ! you need to play in portrait, not in landscape)
[10:58] <slvn_> If I use a tablet Nexus10 for instance,  I want the game to be display in the portrait direction
[11:00] <slvn_> both ios and android has a way to do that
[11:11] <alan_g> slvn_: as things are right now Mir doesn't really deal with orientation beyond mir_surface_get_orientation() - and that's under the control of unity. greyback may know if apps can lock the orientation
[11:12] <greyback> slvn_: on your portrait/landscape issue - I suggest you read the width & height of the surface you get from Mir, and orient your view to always be portrait
[11:13] <greyback> slvn_: so on phones, you'll have height > width, so that's portrait by default
[11:13] <greyback> on tablet, it'll be width > height, so you'd need to rotate your game view somehow to suit
[11:14] <slvn_> yep but how to rotate my game view ?
[11:14] <greyback> slvn_: we've not fully implemented the proper way for an app to specify orientations
[11:14] <greyback> that I can't answer, I don't know SDK at all
[11:15] <greyback> SDL
[11:15] <greyback> grr, muscle memory
[11:16] <slvn_> hmm, I will see what can I do with the internals of SDL
[11:54] <slvn_> I think I would need a "mir_surface_SET_orientation", like the "get" that exists...
[12:15] <greyback> slvn_: that won't happen. It's not the application's decision to say what it's orientation should be. Instead the shell dictates that.
[12:15] <greyback> you're right though, shell should rotate and resize the surface to suit the app
[12:15] <greyback> we're just not there yet
[12:16] <greyback> so the plan is for app to specify what orientations it supports, in the desktop file probably
[12:16] <greyback> and shell will respect that
[12:29] <slvn_> greyback,  but in the end, this is the application that choose :) either by a .desktop, or a call to mir api
[12:30] <greyback> slvn_: yep in the end, the app chooses what it prefers
[12:32] <slvn_> you say the plan is to specify the orientation in the desktop file for instance. Is there a Ticket issue ?
[12:46] <greyback> slvn_: I've failed to locate one, so I made one https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1379777
[12:49] <slvn_> greyback, great, perfect, you make it understandable !
[12:49] <kdub> jenkins has a mystical ability to generate strange errors: "virtual memory exhausted"?
[12:50] <greyback> slvn_: I've no idea of time-scale when we can deliver that. But I'll update that bug when we start working on it
[12:51] <slvn_> I believe this important when creating an application that cannot react to all orientation, and that require a specific orientation
[12:54] <greyback> totally
[15:24] <anpok> alf__: regarind the vt switching issues..
[15:24] <anpok> regarding
[15:24] <anpok> hmm what is causing the failure?
[15:32] <alf__> anpok: In the nested case we create an auth fd, get the magic cookie in the nested server and ask the host to auth it. However, the magic cookie that is returned by drmGetMagic is tied to the currently active drm master, but in this particular use case, there is no active master ([1]), so the cookie is useless, the host server can't auth it.
[15:33] <alf__> anpok: [1] That's not exactly true, it could be that the master is the auth fd created by the nested server, but that's another bug
[15:33] <alf__> anpok: in any case, things fail
[15:34] <anpok> oh
[15:36] <alf__> anpok: one solution is to introduce a new client function mir_connection_drm_get_auth_fd() so that the host server can perform the GetMagic/AuthMagic calls in one place
[15:59] <anpok> alf__: why would that solve the issue?
[16:00] <anpok> ah
[16:21] <mterry> Does https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1379848 look like anything people have seen before?
[16:23] <anpok> on a closing application? could this be https://bugs.launchpad.net/bugs/1376324
[16:24] <anpok> ^ mterry
[16:26] <mterry> anpok, the crash seems to be happening between two pages of the wizard.  But the indicators and maliit-server are being restarted when this crash happens.  So clients are closing and reconnecting, yeah