l70: the in-process client registers sigint/sigterm handlers to stop the render loop. this is what fixes one of the bugs I noticed in this branch.
l86/87: mg::InternalClient is the current way that the platform constructs an internal (in-process-egl) client. It is constructed in mg::Platform via an mf::Surface. I'd expect mg::InternalClient to expand in the future (say, so the internal clients can get at size/pixelformat/etc info about the surface they were granted). A full example is in the integration test in line 1546.
I rolled src/graphics/egl into src/graphics/gbm like I was talking about at the sprint. This involved a bit of refactoring of ShellMesaEGLNativeDisplay, which is now called mgg::InternalNativeDisplay. what used to be in src/graphics/egl is really just gbm-specific code for a different sort of EGLNativeWindowType, (very analagous to mga::ServerRenderWindow and mga::InternalClientWindow) so it should be in the gbm directory.
Here are some places to zone in:
l70: the in-process client registers sigint/sigterm handlers to stop the render loop. this is what fixes one of the bugs I noticed in this branch.
l86/87: mg::InternalClient is the current way that the platform constructs an internal (in-process-egl) client. It is constructed in mg::Platform via an mf::Surface. I'd expect mg::InternalClient to expand in the future (say, so the internal clients can get at size/pixelforma t/etc info about the surface they were granted). A full example is in the integration test in line 1546.
I rolled src/graphics/egl into src/graphics/gbm like I was talking about at the sprint. This involved a bit of refactoring of ShellMesaEGLNat iveDisplay, which is now called mgg::InternalNa tiveDisplay. what used to be in src/graphics/egl is really just gbm-specific code for a different sort of EGLNativeWindow Type, (very analagous to mga::ServerRend erWindow and mga::InternalCl ientWindow) so it should be in the gbm directory.