[PATCH weston] compositor-drm: handle vblanks on secondary crtc

[Rob Clark]

From: Rob Clark 

Signed-off-by: Rob Clark 
---
 src/compositor-drm.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 8ea4965..80dccfc 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -100,6 +100,7 @@ struct drm_output {
struct weston_output   base;
 
uint32_t crtc_id;
+   int pipe;
uint32_t connector_id;
drmModeCrtcPtr original_crtc;
 
@@ -374,6 +375,9 @@ drm_output_repaint(struct weston_output *output_base,
weston_log("setplane failed: %d: %s\n",
ret, strerror(errno));
 
+   if (output->pipe > 0)
+   vbl.request.type |= DRM_VBLANK_SECONDARY;
+
/*
 * Queue a vblank signal so we know when the surface
 * becomes active on the display or has been replaced.
@@ -1285,6 +1289,7 @@ create_output_for_connector(struct drm_compositor *ec,
wl_list_init(&output->base.mode_list);
 
output->crtc_id = resources->crtcs[i];
+   output->pipe = i;
ec->crtc_allocator |= (1 << output->crtc_id);
output->connector_id = connector->connector_id;
ec->connector_allocator |= (1 << output->connector_id);
-- 
1.7.9.5

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH wayland] test: remove memory leak checks

[U. Artie Eoff]

From: "U. Artie Eoff" 

Wrapping dynamic memory functions (malloc, realloc, free, calloc)
can be problematic, for instance, when instrumenting code with
coverage hooks.
In general, the community consensus is to avoid writing your own
memory leak checking and to use an existing tool such as valgrind
to do this job for you.  The same could probably be said for
fd leak checks, but will leave that for a separate exercise.

Signed-off-by: U. Artie Eoff 
---
 tests/sanity-test.c | 22 --
 tests/test-runner.c | 51 ---
 2 files changed, 73 deletions(-)

diff --git a/tests/sanity-test.c b/tests/sanity-test.c
index 67ca663..03044af 100644
--- a/tests/sanity-test.c
+++ b/tests/sanity-test.c
@@ -64,28 +64,6 @@ FAIL_TEST(sanity_assert)
assert(0);
 }
 
-FAIL_TEST(sanity_malloc_direct)
-{
-   void *p;
-
-   p = malloc(10); /* memory leak */
-   assert(p);  /* assert that we got memory, also prevents
-* the malloc from getting optimized away. */
-   free(NULL); /* NULL must not be counted */
-}
-
-FAIL_TEST(sanity_malloc_indirect)
-{
-   struct wl_array array;
-
-   wl_array_init(&array);
-
-   /* call into library that calls malloc */
-   wl_array_add(&array, 14);
-
-   /* not freeing array, must leak */
-}
-
 FAIL_TEST(sanity_fd_leak)
 {
int fd[2];
diff --git a/tests/test-runner.c b/tests/test-runner.c
index 63ce384..354091d 100644
--- a/tests/test-runner.c
+++ b/tests/test-runner.c
@@ -20,8 +20,6 @@
  * OF THIS SOFTWARE.
  */
 
-#define _GNU_SOURCE
-
 #include 
 #include 
 #include 
@@ -29,52 +27,11 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include "test-runner.h"
 
-static int num_alloc;
-static void* (*sys_malloc)(size_t);
-static void (*sys_free)(void*);
-static void* (*sys_realloc)(void*, size_t);
-static void* (*sys_calloc)(size_t, size_t);
-
 extern const struct test __start_test_section, __stop_test_section;
 
-__attribute__ ((visibility("default"))) void *
-malloc(size_t size)
-{
-   num_alloc++;
-   return sys_malloc(size);
-}
-
-__attribute__ ((visibility("default"))) void
-free(void* mem)
-{
-   if (mem != NULL)
-   num_alloc--;
-   sys_free(mem);
-}
-
-__attribute__ ((visibility("default"))) void *
-realloc(void* mem, size_t size)
-{
-   if (mem == NULL)
-   num_alloc++;
-   return sys_realloc(mem, size);
-}
-
-__attribute__ ((visibility("default"))) void *
-calloc(size_t nmemb, size_t size)
-{
-   if (sys_calloc == NULL)
-   return NULL;
-
-   num_alloc++;
-
-   return sys_calloc(nmemb, size);
-}
-
 static const struct test *
 find_test(const char *name)
 {
@@ -90,12 +47,10 @@ find_test(const char *name)
 static void
 run_test(const struct test *t)
 {
-   int cur_alloc = num_alloc;
int cur_fds;
 
cur_fds = count_open_fds();
t->run();
-   assert(cur_alloc == num_alloc && "memory leak detected in test.");
assert(cur_fds == count_open_fds() && "fd leak detected");
exit(EXIT_SUCCESS);
 }
@@ -107,12 +62,6 @@ int main(int argc, char *argv[])
int total, pass;
siginfo_t info;
 
-   /* Load system malloc, free, and realloc */
-   sys_calloc = dlsym(RTLD_NEXT, "calloc");
-   sys_realloc = dlsym(RTLD_NEXT, "realloc");
-   sys_malloc = dlsym(RTLD_NEXT, "malloc");
-   sys_free = dlsym(RTLD_NEXT, "free");
-
if (argc == 2) {
t = find_test(argv[1]);
if (t == NULL) {
-- 
1.7.11.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC PATCH 06/12] tablet-shell: Applications can run on tablet

[Juan Zhao]

On Wed, 2012-08-08 at 12:18 +0300, Pekka Paalanen wrote:
> 
> The applications, i.e. the normal clients, are yet another thing.
> 
> What I meant was that the two different protocol extensions were not
> separated properly in tablet shell. In the desktop shell, the public
> protocol extension is wl_shell, and the private protocol extension is
> desktop_shell.
> 
> > > When a client initialises, the set of advertised global interfaces
> > > will
> > > contain either wl_shell or tablet_generic, or at least the client
> > > should
> > > bind to only one of the two. If it binds to tablet_generic, if
> knows
> > > it
> > > has to be full-screen always, it doesn't need an event to tell it
> > > that.
> > > How does it know what size to make its surface, I don't know.
> Looking
> > > at outputs or add a configure event?
> > 
> > Do you mean the client itself should know it was working for
> > tablet-shell and need some modification?
> 
> Yes, exactly. As the very first thing, it needs to know to expect the
> global interface "tablet_shell" instead of "wl_shell".
> 
> If the server indeed advertises only tablet_shell, and not wl_shell,
> the application cannot use any of the window management or other
> features offered by wl_shell (or by wl_shell_surface).
> 
> Right now, if the application does not know how to use "wl_shell", it
> will never get its window shown in a desktop-shell environment. That
> is
> intentional.
> 
> > I think the client should not have to know that, or take some
> action.
> > If the client response to the the event tablet-shell send, then it
> could
> > do some configuration to it. 
> > If the client doesn't response, then it could work usually, then
> > tablet-shell will add a black surface under it, to make it looks
> like
> > fullscreen.
> > In this way, tablet-shell could easy to support the toolkits who
> don't
> > add support to tablet-shell, for example efl applications.
> > Then the application development will feel easy to support both
> > desktop-shell and tablet-shell.
> 
> No, the application cannot work "as usual", if there is no wl_shell
> advertised. Applications (read: toolkits) have to explicitly support
> the
> different basic shells. Your use case is just one special case, and
> such "fallbacks" are not generally acceptable. Yes, the toytoolkit
> does
> not support tablet_shell, it simply tries to not crash if there is no
> wl_shell.
> 
> Tablet_shell is not simply a desktop adaptation for a tablet. It is
> supposed to be a completely different environment. A smartphone might
> be a better example, since tablets just might work with a desktop-like
> environment.
> 
> Now, this does *not* mean that toolkits need to explicitly encode
> support for all the possible shells out there. I expect Gnome,
> KDE, Xfce, Enlightenment, etc. to provide their own desktop
> environments with their own "shells", but the difference to
> tablet_shell is, that they are all desktop shells. Therefore they all
> will support the basic desktop shell protocol extensions (that is
> wl_shell), and they can add more for their special needs. None of the
> special needs will conflict with the basic desktop shell concepts.
> Tablet_shell on the other hand does conflict, and cannot support all
> the basic desktop shell operations.
> 
> That is the idea, at least.
> 
> As a summary to everyone considering the above tl;dr and wanting to
> write a WM:
> 
> Tablet_shell is *not* the example to base your own "desktop window
> managers" on. Instead, you want to fork the desktop-shell plugin,
> the special client, and the private desktop_shell protocol, and keep
> the public wl_shell protocol.
> 
> Also note, that the wl_shell protocol extension can still be developed
> further, inspite of the freeze, in a backwards compatible manner.
> wl_shell is not complete yet in any sense. 

The window manager could run on desktop environment and can also run on
embeded environment. For example, when in embeded environment, it would
set all clients fullscreen by setting WM state.  And the client don't
need to know where it is. 
And any of the client don't need to know which compositor it works
against. For example, efl and gtk clients could run on any window
manager. efl and gtk for Xorg only differenciate Wayland/Xorg, but not
pay attention to which window manager the platform would be.

To make the application writer easier, I suggest to make clients running
on tablet-shell easier.

I'm still open on this point, welcome to add any further comments.

Thanks,
Juan

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] shell: Don't draw shadows for maximized windows.

[Andreas Ericsson]

On 08/08/2012 12:52 PM, Scott Moreau wrote:
>>
>> This is definitely not right. It is not the compositor's job to cut out
>> and not show an arbitrary part of the surface. It is the client's job
>> to not render anything it does not want to show.
>>
>> You also break the protocol by lying to client about the dimensions,
>> and in doing so, you make assumptions that are not based on any
>> specification, just like you mentioned yourself.
>>
>> This must be done in toytoolkit, not here.
>>
>>
>> Sorry,
>> pq
>>
> 
> The problem I'm having is trying to work out how to do snapping for resize
> or move requests on maximized surfaces. The patch that works in toytoolkit
> would require even more dancing in shell to implement snapping. The problem
> is that the shell doesn't know some specifics about the surface such as
> input region and/or theme margin, in this case the shadow margin.

Personally, I've always felt it's really weird when ethereal entities such as
shadows interact with physical entities such as the plastic edge framing the
LCD part of my screen. In any sane faking of the real world that plastic edge
would simply cover the shadow, so it makes perfect sense to ignore it
completely when snapping windows.

-- 
Andreas Ericsson   andreas.erics...@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] shell: Don't draw shadows for maximized windows.

[Pekka Paalanen]

On Wed, 8 Aug 2012 04:52:41 -0600
Scott Moreau  wrote:

> >
> > This is definitely not right. It is not the compositor's job to cut out
> > and not show an arbitrary part of the surface. It is the client's job
> > to not render anything it does not want to show.
> >
> > You also break the protocol by lying to client about the dimensions,
> > and in doing so, you make assumptions that are not based on any
> > specification, just like you mentioned yourself.
> >
> > This must be done in toytoolkit, not here.
> >
> >
> > Sorry,
> > pq
> >
> 
> The problem I'm having is trying to work out how to do snapping for resize
> or move requests on maximized surfaces. The patch that works in toytoolkit
> would require even more dancing in shell to implement snapping. The problem
> is that the shell doesn't know some specifics about the surface such as
> input region and/or theme margin, in this case the shadow margin. I think
> ideally you'd be able to request these specifics from the client. It would
> also be nice to be able to know the titlebar height so in the snap-off case
> we can place the surface to where the middle of the titlebar is under the
> grab cursor. Would it make sense to be able to request certain (theme)
> attributes such as these from the client?

Snapping must happen in the server, since the server does all about
moving surfaces. This is completely different to shadows, which must
remain a purely client feature.

I don't think you should need such things as "theme margin" or
whatever. At most, you could add a snapping region, similar to input
region, in the protocol. That would be more logical: "this region will
be used for snapping" instead of "if I set shadow region like this, it
usually snaps there...".

Snapping could use the input region, since it is always up-to-date
with the latest buffer the server has. Except that seems to be a lie,
because surface::attach resets the input region. Looks like we have
some protocol to fix here.

The current protocol works like this, AFAIU:
1. wl_surface::attach - input region may get reset
2. wl_surface::set_input_region - input region gets properly defined
again

This means, that between steps 1 and 2, the server will composite using
bad data (undefined input region). No, we cannot rely on the
set_input_region request coming right after the attach, nothing
guarantees that it will be processed during the current frame.

This makes snapping on resize to likely fail, since the snapping code
will be working with an undefined input region, and hence it can only
ever snap to the surface edge, which due to the shadow will fall far
off from the "real" window edge.

Krh, was the the idea of first sending all new surface attributes, and
then committing those at once on wl_surface::attach rejected, or was
this part of the protocol just not fixed yet? Or is there some other
clever mechanism to make this atomic?


Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] shell: Don't draw shadows for maximized windows.

[Scott Moreau]

>
> This is definitely not right. It is not the compositor's job to cut out
> and not show an arbitrary part of the surface. It is the client's job
> to not render anything it does not want to show.
>
> You also break the protocol by lying to client about the dimensions,
> and in doing so, you make assumptions that are not based on any
> specification, just like you mentioned yourself.
>
> This must be done in toytoolkit, not here.
>
>
> Sorry,
> pq
>

The problem I'm having is trying to work out how to do snapping for resize
or move requests on maximized surfaces. The patch that works in toytoolkit
would require even more dancing in shell to implement snapping. The problem
is that the shell doesn't know some specifics about the surface such as
input region and/or theme margin, in this case the shadow margin. I think
ideally you'd be able to request these specifics from the client. It would
also be nice to be able to know the titlebar height so in the snap-off case
we can place the surface to where the middle of the titlebar is under the
grab cursor. Would it make sense to be able to request certain (theme)
attributes such as these from the client?


Regards,

Scott
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

New Wayland live CD

[nerdopolis]

Hello.

For anyone who is interested in testing Wayland, I created a new version of my 
Wayland Live CD: (which is still named after my favorite celebrity)

Project page: https://sourceforge.net/projects/rebeccablackos/
Direct Download Link: 
http://sourceforge.net/projects/rebeccablackos/files/RebeccaBlackLinux.iso/download

As this CD now leverages the latest with Xwayland, the updates in the toolkits 
for Wayland, and Wayland itself, I feel this version might actually somewhat 
usable.

I added some launchers on the panel for to make it easier for the user, such as 
a one for a dialog about Weston key bindings, as well as one for a network 
manager, and program menu.

It contains the Wayland version for every toolkit (QT, SDL, GTK, EFL) except 
Clutter, as Clutter hasn't been ported to the Wayland 0.95 protocol yet, and I 
couldn't find any out of tree ports either.
 
I also integrated with weston-launch, so now it prompts upon every login 
(instead of in GRUB) for selecting Wayland or X, so that Wayland even running 
as a native display server runs as the user account, it no longer needs to run 
as root. 
The login manager is still X based though, and if Wayland fails it falls back 
to an KDE session in X.


In this CD I also added an option for "xorg backed wayland", which calls up 
Weston with the X11 backend full screen on an Xserver. This is for hardware 
that does not have "proper" drivers that would allow Weston to run as the main 
display server.
The problems with this is that there is no way to manage the screens (such as 
the resolution and the orientation of the monitors, but it still emulates a 
Wayland experience as best as possible, and I don't really think there is a 
performance penalty.

This is based on Ubuntu Quantal, so it might be unstable. If you do want to 
install it, you will need to browse to the Desktop, and open Ubiquity I don't 
recommend using it for production yet. 

enjoy.



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] shell: Don't draw shadows for maximized windows.

[Pekka Paalanen]

On Tue,  7 Aug 2012 21:39:37 -0600
Scott Moreau  wrote:

> This effectively fixes a bug where maximized windows appear to not maximize
> fully bacause of the shadow margin. Instead, we now maximize the window to
> the understood input region.
> ---
> 
> This problem is much more easily and appropriately fixed in shell.c but it 
> makes
> the assumption that the input_region is the same for top/bottom and 
> left/right.
> We can't calulate bottom or right margin in shell_surface_set_maximized()
> because the input region hasn't been updated and there's no way to know in
> advance before the configure event. So we have the client resize its surface
> accounting for the (shadow) margin, which in this case, is a constant margin 
> for
> all sides, derived from the theme margin. We then position the surface taking
> into consideration the same.
> 
>  src/shell.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/src/shell.c b/src/shell.c
> index 6c810ff..0580aeb 100644
> --- a/src/shell.c
> +++ b/src/shell.c
> @@ -1362,8 +1362,11 @@ shell_surface_set_maximized(struct wl_client *client,
>   edges = WL_SHELL_SURFACE_RESIZE_TOP|WL_SHELL_SURFACE_RESIZE_LEFT;
>  
>   shsurf->client->send_configure(shsurf->surface, edges,
> -shsurf->output->current->width,
> -shsurf->output->current->height - 
> panel_height);
> +shsurf->output->current->width +
> +shsurf->surface->input.extents.x1 * 2,
> +shsurf->output->current->height -
> +panel_height +
> +shsurf->surface->input.extents.y1 * 2);
>  
>   shsurf->next_type = SHELL_SURFACE_MAXIMIZED;
>  }
> @@ -2673,9 +2676,10 @@ configure(struct desktop_shell *shell, struct 
> weston_surface *surface,
>   break;
>   case SHELL_SURFACE_MAXIMIZED:
>   /* setting x, y and using configure to change that geometry */
> - surface->geometry.x = surface->output->x;
> + surface->geometry.x = surface->output->x - 
> surface->input.extents.x1;
>   surface->geometry.y = surface->output->y +
> - get_output_panel_height(shell,surface->output);
> + get_output_panel_height(shell,surface->output -
> + surface->input.extents.y1);
>   break;
>   case SHELL_SURFACE_TOPLEVEL:
>   break;

This is definitely not right. It is not the compositor's job to cut out
and not show an arbitrary part of the surface. It is the client's job
to not render anything it does not want to show.

You also break the protocol by lying to client about the dimensions,
and in doing so, you make assumptions that are not based on any
specification, just like you mentioned yourself.

This must be done in toytoolkit, not here.


Sorry,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC PATCH 06/12] tablet-shell: Applications can run on tablet

[Pekka Paalanen]

On Wed, 08 Aug 2012 13:40:33 +0800
Juan Zhao  wrote:

> 
> On Tue, 2012-08-07 at 09:36 +0300, Pekka Paalanen wrote:
> > 
> > Looking at the tablet-shell.xml protocol, I wonder if it is missing an
> > interface. The interface tablet_shell seems to be private for the
> > ux-daemon (tablet-shell client), but there is no interface for normal
> > clients. 
> 
> I think tablet-shell is used for embeded systems, like ivi/handset/tv.
> Not only ux-daemon. 

ux-daemon, i.e. the tablet-shell client, is an essential part of the
tablet-shell environment. In summary, the tablet-shell environment
consists of:
- the tablet-shell weston plugin
- the tablet-shell client (a special client spawned by the plugin)
- the private tablet-shell protocol extension for the special client
  only
- the public tablet-shell protocol extension for normal clients

When we talk about these, we should try to be explicit on which part we
mean.

The applications, i.e. the normal clients, are yet another thing.

What I meant was that the two different protocol extensions were not
separated properly in tablet shell. In the desktop shell, the public
protocol extension is wl_shell, and the private protocol extension is
desktop_shell.

> > When a client initialises, the set of advertised global interfaces
> > will
> > contain either wl_shell or tablet_generic, or at least the client
> > should
> > bind to only one of the two. If it binds to tablet_generic, if knows
> > it
> > has to be full-screen always, it doesn't need an event to tell it
> > that.
> > How does it know what size to make its surface, I don't know. Looking
> > at outputs or add a configure event?
> 
> Do you mean the client itself should know it was working for
> tablet-shell and need some modification?

Yes, exactly. As the very first thing, it needs to know to expect the
global interface "tablet_shell" instead of "wl_shell".

If the server indeed advertises only tablet_shell, and not wl_shell,
the application cannot use any of the window management or other
features offered by wl_shell (or by wl_shell_surface).

Right now, if the application does not know how to use "wl_shell", it
will never get its window shown in a desktop-shell environment. That is
intentional.

> I think the client should not have to know that, or take some action.
> If the client response to the the event tablet-shell send, then it could
> do some configuration to it. 
> If the client doesn't response, then it could work usually, then
> tablet-shell will add a black surface under it, to make it looks like
> fullscreen.
> In this way, tablet-shell could easy to support the toolkits who don't
> add support to tablet-shell, for example efl applications.
> Then the application development will feel easy to support both
> desktop-shell and tablet-shell.

No, the application cannot work "as usual", if there is no wl_shell
advertised. Applications (read: toolkits) have to explicitly support the
different basic shells. Your use case is just one special case, and
such "fallbacks" are not generally acceptable. Yes, the toytoolkit does
not support tablet_shell, it simply tries to not crash if there is no
wl_shell.

Tablet_shell is not simply a desktop adaptation for a tablet. It is
supposed to be a completely different environment. A smartphone might
be a better example, since tablets just might work with a desktop-like
environment.

Now, this does *not* mean that toolkits need to explicitly encode
support for all the possible shells out there. I expect Gnome,
KDE, Xfce, Enlightenment, etc. to provide their own desktop
environments with their own "shells", but the difference to
tablet_shell is, that they are all desktop shells. Therefore they all
will support the basic desktop shell protocol extensions (that is
wl_shell), and they can add more for their special needs. None of the
special needs will conflict with the basic desktop shell concepts.
Tablet_shell on the other hand does conflict, and cannot support all
the basic desktop shell operations.

That is the idea, at least.

As a summary to everyone considering the above tl;dr and wanting to
write a WM:

Tablet_shell is *not* the example to base your own "desktop window
managers" on. Instead, you want to fork the desktop-shell plugin,
the special client, and the private desktop_shell protocol, and keep
the public wl_shell protocol.

Also note, that the wl_shell protocol extension can still be developed
further, inspite of the freeze, in a backwards compatible manner.
wl_shell is not complete yet in any sense.


Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC PATCH 06/12] tablet-shell: Applications can run on tablet

[Juan Zhao]

On Tue, 2012-08-07 at 09:36 +0300, Pekka Paalanen wrote:
> Hi,
> 
> I didn't quite understand Tiago's reply, but maybe the following
> helps.

Thanks, pq, sure, it helps. :)
> 
> Looking at the tablet-shell.xml protocol, I wonder if it is missing an
> interface. The interface tablet_shell seems to be private for the
> ux-daemon (tablet-shell client), but there is no interface for normal
> clients. 

I think tablet-shell is used for embeded systems, like ivi/handset/tv.
Not only ux-daemon. 

> I doubt that any normal client should be able to set e.g.
> lockscreen - or maybe access control is per-request? This will
> probably
> cause some confusion.

Oh, yes, that's a good part to consider. I feels only tablet-shell this
process could show lockscreen.

> 
> src/tablet-shell.c actually has this comment on creating the
> tablet_shell global object:
> /* FIXME: This will make the object available to all clients. */
> 
> Let's call the generic tablet shell client interface tablet_generic
> for
> this discussion. (All the shell interface names seem to be a little
> out
> of place, starting with wl_shell and desktop_shell.)

We will refine the code structure.

> 
> When a client initialises, the set of advertised global interfaces
> will
> contain either wl_shell or tablet_generic, or at least the client
> should
> bind to only one of the two. If it binds to tablet_generic, if knows
> it
> has to be full-screen always, it doesn't need an event to tell it
> that.
> How does it know what size to make its surface, I don't know. Looking
> at outputs or add a configure event?

Do you mean the client itself should know it was working for
tablet-shell and need some modification?

I think the client should not have to know that, or take some action.
If the client response to the the event tablet-shell send, then it could
do some configuration to it. 
If the client doesn't response, then it could work usually, then
tablet-shell will add a black surface under it, to make it looks like
fullscreen.
In this way, tablet-shell could easy to support the toolkits who don't
add support to tablet-shell, for example efl applications.
Then the application development will feel easy to support both
desktop-shell and tablet-shell.

> 
> The last real changes to the tablet protocol are from May 2011, so I
> think it needs an overhaul.

Agree, let's make it step by step. :)
> 
Thanks,
Juan
> 
> HTH,
> pq 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel