Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood

2013-03-25 Thread Casey Dahlin 
On Mon, Mar 25, 2013 at 02:14:23PM -0600, Scott Moreau wrote:
> Sorry, I misspoke here. What I meant was, "This isn't about the
> wayland core protocol, the core wayland developers have this part
> covered. This is about raising the bar on the effects users expect to
> see in a wayland compositor and thus, forwarding wayland indirectly as
> Beryl did with Compiz."

I'm not questioning your intentions. The effects they might have is what's
worrying.

--CJD


pgpYxfof_a3FY.pgp
Description: PGP signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood

2013-03-25 Thread Casey Dahlin 
On Mon, Mar 25, 2013 at 12:59:22PM -0600, Scott Moreau wrote:
> Hi Casey,
> 
> On Mon, Mar 25, 2013 at 12:53 PM, Casey Dahlin  wrote:
> > On Mon, Mar 25, 2013 at 12:51:07PM -0600, Scott Moreau wrote:
> >> Yes, there is no reason to fork libwayland. And I don't feel this is a
> >> true fork, just a temporary rename to avoid the confusion it might
> >> otherwise cause, remaining under the 'wayland' name. Wayland has been
> >> in my github repo since I've uploaded it there. The only difference
> >> now is, the name has been changed and an official fork announcement
> >> has been made by request.
> >
> > ...ok. I'll leave how exactly that's less confusing as an exercise to the
> > reader.
> >
> > Seriously, if you'd just forked Weston and left Wayland alone I'd be on your
> > side. Even happy. This, however, is just making a political mess.
> >
> > --CJD
> 
> I'm not sure where the confusion is. Northfield == Wayland but with a
> few changes to wl_shell_surface interface for minimize/maximize/close
> stuff. These changes are actually being discussed on the mailing list
> for possible review and inclusion. Once these basic events/requests go
> upstream, there will not be a need for northfield as a patched version
> of wayland. In reality, this is just a project name that !wayland. The
> need for this custom libwayland is only necessary until the new
> protocol is pushed upstream at which point, this need should be
> eliminated.
> 

Shell surface was in weston for awhile. Why not just wl_new_shell_surface in
your forked weston's protocol extensions?

--CJD


pgp0mCjWYAYf8.pgp
Description: PGP signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood

2013-03-25 Thread Casey Dahlin 
On Mon, Mar 25, 2013 at 12:51:07PM -0600, Scott Moreau wrote:
> Yes, there is no reason to fork libwayland. And I don't feel this is a
> true fork, just a temporary rename to avoid the confusion it might
> otherwise cause, remaining under the 'wayland' name. Wayland has been
> in my github repo since I've uploaded it there. The only difference
> now is, the name has been changed and an official fork announcement
> has been made by request.

...ok. I'll leave how exactly that's less confusing as an exercise to the
reader.

Seriously, if you'd just forked Weston and left Wayland alone I'd be on your
side. Even happy. This, however, is just making a political mess.

--CJD


pgpoQatfjKE24.pgp
Description: PGP signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood

2013-03-25 Thread Casey Dahlin 
On Mon, Mar 25, 2013 at 12:41:59PM -0600, Scott Moreau wrote:
> "The key point to understand is, that this is not a new protocol in its
> own right. It *is* the wayland protocol, with a few minor additions
> that make it possible to do new interesting things."

Then don't fork the library.

"A few minor additions" can exist outside the codebase. Hell, all of the shell
protocol exists outside the wayland codebase. All of THE DRM CODE exists
outside of the wayland codebase.

If what you say is true about not forking the protocol then there is NO reason
to fork libwayland.

--CJD


pgpvJG6pcKOvX.pgp
Description: PGP signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood

2013-03-25 Thread Casey Dahlin 
On Mon, Mar 25, 2013 at 02:43:27AM -0600, Scott Moreau wrote:
> What Northfield *is not*
> - A fork that will change protocol in fundamental ways that diverts
> from the wayland EGL spec
> - A project that aims to cause divisions in the community or the Linux
> Desktop code
> - A project that breaks core wayland protocol in unrepairable ways
> - Diverting significantly from wayland
> - An unfriendly 'takeover'
> - Unnecessary
> 
> The key point to understand is, that this is not a new protocol in its
> own right. It *is* the wayland protocol, with a few minor additions
> that make it possible to do new interesting things. It uses the same
> EGL drivers in Mesa implementing the wayland-egl specification. This
> will not change. Northfield will always use the same driver stack as
> wayland. The difference is, that I now have the time to dedicate to
> being a (hopefully very) responsive maintainer.
> 

Then fork Weston and leave Wayland alone.

More and different and better compositors have always been expected. Forking
the wayland libs itself is just creating confusion and giving yourself the
opportunity to break the protocol (which is extensible by default, and Weston
already adds features to it).

This is just making a mess after Canonical has already confused things with
Mir. I'm already cringing at the thought of how Phoronix is going to cover this.

--CJD


pgpRbF6fvOr9s.pgp
Description: PGP signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston SDK

2013-02-14 Thread Casey Dahlin 
On Thu, Feb 14, 2013 at 11:27:22AM -0500, Kristian Høgsberg wrote:
> Hi,
> 
> I made a little experiment last night:
> 
>   http://cgit.freedesktop.org/~krh/overlay-plugin
> 
> It's an out-of-tree weston plugin.  It's just a silly little overlay
> that you can pop up with mod-space, but the interesting part here is
> that it's building outside weston [1].  Current, that works by copying
> the header files that defines the weston <-> plugins API, but I'd like
> to start thinking about how to formalize this process.  I don't think
> it should be a big problem, it more or less boils down to:
> 
>  - Interface version in headers and at runtime
> 
>  - Header files installed in /usr/include/weston
> 
>  - pkg-config file

This is all begging the question: what is the purpose of Weston. Graphics
developers I talk to who I don't see on this list still refer to it as an
"example compositor." They aren't awaiting a plugin API, they're awaiting a
toolkit library so they can write their own compositors.

Has this been miscommunicated? Because it increasingly seems like Weston is
being prepared for actual use.

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

Re: [PATCH wayland] protocol: Add wl_notification_daemon interface

2013-01-21 Thread Casey Dahlin 
On Sun, Jan 20, 2013 at 07:16:09PM +0100, Quentin Glidic wrote:
> This interface is designed to be binded only once by a notification
> daemon.
> 
> Notification surfaces are special surfaces that the user should
> always be able to see. The compositor is in charge of displaying
> them to be visible without disturbing the user workflow.

Is there a reason to do this in wayland protocol rather than the already
established freedesktop method over DBus?

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

Re: [systemd-devel] [RFC] VTs for multiple seats

2012-07-10 Thread Casey Dahlin 
On Tue, Jul 10, 2012 at 10:03:37PM +0200, David Herrmann wrote:
> On Tue, Jul 10, 2012 at 9:57 PM, Casey Dahlin  wrote:
> > On Tue, Jul 10, 2012 at 09:29:05PM +0200, David Herrmann wrote:
> >> I don't think this is currently possible with the weston codebase, as
> >> we require each compositor-backend to allow multiple surfaces.
> >
> > This part is all the conversation was about.
> 
> Sorry, I meant we require each backend to have multiple _active_
> surfaces. This is not needed by the system-compositor as we only need
> one active client. As I said all clients are fullscreen so we always
> show only a single surface. Or did I miss something?
> 

That's right. It also might sway the size argument back, as almost all of
weston's window management and a lot of its input code is no longer necessary.

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

Re: [systemd-devel] [RFC] VTs for multiple seats

2012-07-10 Thread Casey Dahlin 
On Tue, Jul 10, 2012 at 09:29:05PM +0200, David Herrmann wrote:
> I don't think this is currently possible with the weston codebase, as
> we require each compositor-backend to allow multiple surfaces.

This part is all the conversation was about.

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

Re: [systemd-devel] [RFC] VTs for multiple seats

2012-07-10 Thread Casey Dahlin 
On Tue, Jul 10, 2012 at 02:15:40PM -0400, Kristian Høgsberg wrote:
> On Tue, Jul 10, 2012 at 12:22:13PM -0400, Casey Dahlin wrote:
> > On Mon, Jul 09, 2012 at 06:17:13PM -0400, Kristian Høgsberg wrote:
> > > No, wayland is the protocol, weston is the compositor building
> > > toolkit.  If you want an EGL compositor on KMS with evdev input, you
> > 
> > But we don't want an EGL compositor. We want bare-bones KMS support.
> > 
> > One of the things he mentioned was replacing plymouth with the system
> > compositor. Do you really want to pack mesa into the initrd?
> > 
> > The system compositor needs to provide a lightweight SHM-only graphics
> > stack. It also needs to be able to provide the EGL stack /dynamically/
> > when the rest of userspace becomes available.
> 
> Yes, so what you want is an EGL/KMS/evdev compositor that can start
> out only using sw compositing.  How is that *smaller* than weston
> again?
> 

Good point, I suppose. If you count the module that eventually gets
plugged in to it, it would be a bit bigger.

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

Re: [systemd-devel] [RFC] VTs for multiple seats

2012-07-10 Thread Casey Dahlin 
On Mon, Jul 09, 2012 at 06:17:13PM -0400, Kristian Høgsberg wrote:
> No, wayland is the protocol, weston is the compositor building
> toolkit.  If you want an EGL compositor on KMS with evdev input, you

But we don't want an EGL compositor. We want bare-bones KMS support.

One of the things he mentioned was replacing plymouth with the system
compositor. Do you really want to pack mesa into the initrd?

The system compositor needs to provide a lightweight SHM-only graphics
stack. It also needs to be able to provide the EGL stack /dynamically/
when the rest of userspace becomes available.

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

Wayland-Cint repo needs a new home

2012-07-08 Thread Casey Dahlin 
Hey all,

So anyone that has been using it may have noticed that the Wayland Continuous
Integration Repo hasn't been updated in several weeks. While some of that is my
schedule tightening, the major blockage has been that I can't seem to push to
gitorious anymore.

I'm still not certain if this is a local issue with my copy of git or ssh or if
it's on their end, but bottom line is, I'd like somewhere else to push the
branch if possible. If anyone here uses it and knows of a place I could stash
it I'd be appreciative.

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

Re: OpenGL in USB Display Devices under wayland

2012-06-22 Thread Casey Dahlin 
On Fri, Jun 22, 2012 at 10:29:04PM +0300, Pekka Paalanen wrote:
> The trick is in the kernel DRM, which has to be able to deal with the
> buffer and actually push it to the USB device. This may require special
> allocation flags or somehow using the dmabuf infrastructure to allocate
> the buffer, where the composite is drawn.

Pretty sure it's possible right now to just copy the buffer out to normal
userspace memory and then in to another DRM buffer. Not the quickest
transition, but functional.

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

Re: OpenGL in USB Display Devices under wayland

2012-06-22 Thread Casey Dahlin 
On Fri, Jun 22, 2012 at 02:08:16PM -0400, rektide wrote:
> How about this question: might Weston be adaptable to serve this use case? 
> What would be the
> major changes to Weston to do this? What other subsystems would have to 
> change?
> 

Right now wayland doesn't have a protocol to export much notion of what 
associates a card and a
given output. Each DRM-capable device should expose a source of DRM buffers,
and whichever source you use determines which card does the work during
drawing. That's more or less in place in theory, though I don't think weston 
yet does
multiple devices.

When scanout happens, the client just says where they want their buffer mapped
in compositor coordinate space. What card ends up scanning it out depends on
what output is position to render that part of the coordinate space. You can
get access to those coordinates, and you can pick a particular output and
render fullscreen, but the assumption is kind of that any buffer could end up
on any card. DRM buffers are card specific, so a compositor would naturally
need to be prepared to shift all or part of a buffer to another card.

So the only mechanism that is missing afaik is a way for a compositor to
"recommend" a particular card for a particular output or for general use. That
might have to go into mesa (mesa carries a bit of wayland protocol code,
specifically the stuff around exposing buffer sources).

As for the implementation in weston itself, it's just some coordination of
buffer-to-buffer copying, and some intelligence about making card choices.

I guess a slightly interesting bit is if you want the composition itself to
happen on another card, which means the actual scanout buffer is allocated on
the "wrong" card and then copied once after the windows are blitted on.
Depending on how much shiny your window manager is performing that may or may
not be worth doing, but it isn't hard to imagine how.

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

Re: OpenGL in USB Display Devices under wayland

2012-06-22 Thread Casey Dahlin 
On Fri, Jun 22, 2012 at 09:40:43PM +0530, Sannu K wrote:
> After seeing the changes made in X server for offloading hardware
> acceleration for USB display devices (displaylink and others), I am curious
> to know about how Wayland takes care (if at all it does) of offloading
> hardware acceleration to primary GPU. X server uses primary GPU (intel or
> nvidia or ati) for 3D acceleration and just sends the scan out buffer to
> USB display device. As far as I went through the architecture of wayland I
> am not able to find where this fits in and how. Please provide some info on
> how this is (or will be) done.
> 

Wayland is just a protocol for exchanging buffers between apps and compositors.
It pushes concerns like this onto libraries.

Basically the client application just asks the compositor for a DRM buffer, and
the compositor turns around and asks mesa for it, then hands it back to the
application. Then the app uses mesa to draw on the DRM buffer without any
intervention from the compositor at all. When its done it signals the
compositor, which again uses mesa to render the buffer onto a master screen
surface, then hands it to libdrm for scanout.

The compositor itself isn't even part of wayland. Rather we expect each desktop
environment will implement their own (though the workflow for 3D should be the
same, and the weston example compositor demonstrates it if you need a working
example). Wayland is just a tiny protocol to coordinate the buffer exchanges
between the two apps. All of the graphics-related stuff is in mesa or libdrm.

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

Re: no package vpx found when building weston

2012-05-31 Thread Casey Dahlin 
On Thu, May 31, 2012 at 12:17:00PM -0400, dar...@chaosreigns.com wrote:
> On 05/31, Prigent, Christophe wrote:
> >I had an error when building Weston: "package requirements (cairo vpx)
> >were not met: no package vpx found".
> > 
> >The installation of libvpx0 and libvpx-dev from the synaptic package
> >manager didn’t fix the problem. I found that there is no .pc file related
> >to it inside /usr/share/pkgconfig.
> > 
> >I’m working on Ubuntu 10.04.
> 
>   libvpx
> 
>   webm video encoding library required for Weston video capture. Fedora
>   16 package works, Ubuntu Oneric package does not.
> ^^
> 
> $ git clone http://git.chromium.org/webm/libvpx.git
> 
> 
> - http://wayland.freedesktop.org/building.html as of three days ago.
> 

Debating whether to add this to the cint repo. Fedora's OS packages
already work, so I don't hit it. I'm guessing we don't integrate tightly
enough with it to bother. In a short time it will probably work for
everyone.

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

Re: [PATCH] window: use libXcursor for loading pointer images

2012-05-03 Thread Casey Dahlin 
On Thu, May 03, 2012 at 01:39:38PM -0400, Kristian Høgsberg wrote:
> etc.  Obviously we don't want a hard libX11 dependency in weston, but
> we could make a libwlcursor library that's just libXcursor with the
> Xrender part split out.
> 

I think if we're killing X dependencies, libwlkbmap would be the higher
priority, since it seems to call for libX11 as well, and X11 macros,
and xproto. Cairo and Mesa I believe also need them, but it might be
possible to buildflag that away.

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

Re: [PATCH 1/3] Change find_resource_for_surface to find_resource_for_client

2012-04-20 Thread Casey Dahlin 
On Fri, Apr 20, 2012 at 05:28:00PM +0300, Tiago Vignatti wrote:
> On 04/20/2012 04:36 PM, Kristian Høgsberg wrote:
> >No, it's an awkward five line helper function that I don't want to
> >make public API.
> 
> yes, I meant find_resource_for_client. Or is there some fancier way
> you're planning to look through a list of resources?
> 

It's an operation on a wl_list, with assumptions as to its properties. That's
not really great API design. Not to mention that, IIRC the wayland library
itself never exports any such list; they're all created within weston.

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

[PATCH] weston: update .gitignore files

2012-04-10 Thread Casey Dahlin 
Updates the .gitignore files for clients and tests to reflect a new test and a
couple of renamed applications.

Signed-off-by: Casey Dahlin 

---

diff --git a/clients/.gitignore b/clients/.gitignore
index 5954a54..81dab06 100644
--- a/clients/.gitignore
+++ b/clients/.gitignore
@@ -10,15 +10,15 @@ libtoytoolkit.a
 resizor
 screenshooter-client-protocol.h
 screenshooter-protocol.c
-screenshot
 simple-egl
 simple-shm
 simple-touch
 smoke
 tablet-shell-client-protocol.h
 tablet-shell-protocol.c
-terminal
 view
 weston-desktop-shell
 weston-tablet-shell
+weston-screenshooter
+weston-terminal
 wscreensaver
diff --git a/tests/.gitignore b/tests/.gitignore
index e8df81b..3c957f4 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -1,2 +1,3 @@
 matrix-test
+setbacklight
 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] Wayland continuous integration repository

2012-04-10 Thread Casey Dahlin 
I've been working for a bit on an easier way to build Wayland from source, and
more importantly, to get versions of all its dependencies that are known to
work together. This is what I came up with :)

I'm now offering for public consumption the Wayland continuous integration
repository. Git information here:

https://gitorious.org/wayland-cint/wayland-cint

Basically, the idea is that all the packages mentioned in Wayland's build
instructions[1] are checked out as submodules[2]. With a couple of commands all
the source is checked out, and the Makefile in the root of the repo can build
and clean them all together.

Right now it has latest masters for everything as of last night. I'd like to do
a 0.85 branch but we'd have to discuss policy on what dependencies get updated
to what bar.

I hope to add a script to the root of the repo soon with a few toys, but for
right now it's a simple and easy way to get and build Wayland.

Let me know what breaks!

--CJD

[1] http://wayland.freedesktop.org/building.html
[2] http://book.git-scm.com/5_submodules.html
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Why the GTK+ wayland backend can't be enabled in linux distros, at all

2012-03-27 Thread Casey Dahlin 
On Sun, Mar 18, 2012 at 05:07:11PM -0400, dar...@chaosreigns.com wrote:
> 
> I suppose E would be get Nouveau, the open source Nvidia driver, to work
> well enough that the proprietary driver is completely unnecessary.  That
> seems very challenging, with the complete lack of help from Nvidia.

In Fedora-land at least proprietary bits are officially not supported (it goes
beyond just not shipping them) so they just might go for F) Enable it and tell
proprietary software users where to stick it.

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

[PATCH 2/2] Move old functionality of wl_shell into desktop_shell

2011-10-25 Thread Casey Dahlin 
wl_shell is gone since many compositors didn't use it, so we need to have
desktop_shell pick up the slack.

Signed-off-by: Casey Dahlin 
---
 clients/Makefile.am|5 +-
 clients/simple-egl.c   |   10 ++--
 clients/simple-shm.c   |   10 ++--
 clients/terminal.c |6 +-
 clients/window.c   |   41 +--
 clients/window.h   |5 ++-
 compositor/shell.c |  122 ++--
 protocol/desktop-shell.xml |   59 +
 8 files changed, 166 insertions(+), 92 deletions(-)

diff --git a/clients/Makefile.am b/clients/Makefile.am
index 8c30882..4a9f108 100644
--- a/clients/Makefile.am
+++ b/clients/Makefile.am
@@ -4,10 +4,10 @@ noinst_PROGRAMS = $(clients_programs) \
 
 if BUILD_SIMPLE_CLIENTS
 simple_clients_programs = simple-egl simple-shm
-simple_egl_SOURCES = simple-egl.c
+simple_egl_SOURCES = simple-egl.c desktop-shell-protocol.c
 simple_egl_LDADD = $(SIMPLE_CLIENT_LIBS) -lm
 
-simple_shm_SOURCES = simple-shm.c
+simple_shm_SOURCES = simple-shm.c desktop-shell-protocol.c
 simple_shm_LDADD = $(SIMPLE_CLIENT_LIBS)
 endif
 
@@ -33,6 +33,7 @@ AM_CPPFLAGS = \
 
 libtoytoolkit_a_SOURCES =  \
window.c\
+   desktop-shell-protocol.c\
window.h\
cairo-util.c\
cairo-util.h
diff --git a/clients/simple-egl.c b/clients/simple-egl.c
index 95604de..06043bb 100644
--- a/clients/simple-egl.c
+++ b/clients/simple-egl.c
@@ -33,10 +33,12 @@
 #include 
 #include 
 
+#include "desktop-shell-client-protocol.h"
+
 struct display {
struct wl_display *display;
struct wl_compositor *compositor;
-   struct wl_shell *shell;
+   struct desktop_shell *shell;
struct {
EGLDisplay dpy;
EGLContext ctx;
@@ -208,7 +210,7 @@ create_surface(struct window *window)
   window->native,
   surface_attribs);
 
-   wl_shell_set_toplevel(display->shell, window->surface);
+   desktop_shell_set_toplevel(display->shell, window->surface);
 
ret = eglMakeCurrent(window->display->egl.dpy, window->egl_surface,
 window->egl_surface, window->display->egl.ctx);
@@ -289,8 +291,8 @@ display_handle_global(struct wl_display *display, uint32_t 
id,
if (strcmp(interface, "wl_compositor") == 0) {
d->compositor =
wl_display_bind(display, id, &wl_compositor_interface);
-   } else if (strcmp(interface, "wl_shell") == 0) {
-   d->shell = wl_display_bind(display, id, &wl_shell_interface);
+   } else if (strcmp(interface, "desktop_shell") == 0) {
+   d->shell = wl_display_bind(display, id, 
&desktop_shell_interface);
}
 }
 
diff --git a/clients/simple-shm.c b/clients/simple-shm.c
index a93c203..404839a 100644
--- a/clients/simple-shm.c
+++ b/clients/simple-shm.c
@@ -32,10 +32,12 @@
 #include 
 #include 
 
+#include "desktop-shell-client-protocol.h"
+
 struct display {
struct wl_display *display;
struct wl_compositor *compositor;
-   struct wl_shell *shell;
+   struct desktop_shell *shell;
struct wl_shm *shm;
uint32_t mask;
 };
@@ -104,7 +106,7 @@ create_window(struct display *display, int width, int 
height)
   WL_SHM_FORMAT_XRGB32,
   &window->data);
 
-   wl_shell_set_toplevel(display->shell, window->surface);
+   desktop_shell_set_toplevel(display->shell, window->surface);
 
return window;
 }
@@ -149,8 +151,8 @@ display_handle_global(struct wl_display *display, uint32_t 
id,
if (strcmp(interface, "wl_compositor") == 0) {
d->compositor =
wl_display_bind(display, id, &wl_compositor_interface);
-   } else if (strcmp(interface, "wl_shell") == 0) {
-   d->shell = wl_display_bind(display, id, &wl_shell_interface);
+   } else if (strcmp(interface, "desktop_shell") == 0) {
+   d->shell = wl_display_bind(display, id, 
&desktop_shell_interface);
} else if (strcmp(interface, "wl_shm") == 0) {
d->shm = wl_display_bind(display, id, &wl_shm_interface);
}
diff --git a/clients/terminal.c b/clients/terminal.c
index 092e069..d1fa87f 100644
--- a/clients/terminal.c
+++ b/clients/terminal.c
@@ -2053,12 +2053,12 @@ static int
 handle_bound_key(struct terminal *terminal,
 struct input *input, uint32_t sym, uint32_t time)
 {
-   struct wl_shell *shell;
+   struct w

[PATCH 1/2] Update .gitignores

2011-10-25 Thread Casey Dahlin 
---
 clients/.gitignore|4 
 compositor/.gitignore |2 ++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/clients/.gitignore b/clients/.gitignore
index 797e681..c369f6a 100644
--- a/clients/.gitignore
+++ b/clients/.gitignore
@@ -13,3 +13,7 @@ simple-shm
 smoke
 terminal
 view
+desktop-shell-client-protocol.h
+desktop-shell-protocol.c
+desktop-shell
+simple-client
diff --git a/compositor/.gitignore b/compositor/.gitignore
index 0231566..b63642f 100644
--- a/compositor/.gitignore
+++ b/compositor/.gitignore
@@ -5,3 +5,5 @@ meego-tablet-protocol.c
 meego-tablet-server-protocol.h
 xserver-protocol.c
 xserver-server-protocol.h
+desktop-shell-protocol.c
+desktop-shell-server-protocol.h
-- 
1.7.6

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

[PATCH] Gut wl_shell and rename to wl_transfer_src

2011-10-25 Thread Casey Dahlin 
wl_shell isn't needed anymore since most of the experimental compositors seem
to roll their own, often in support of different semantics. This rips
everything out of it except create_drag and create_selection. When those two
things get reworked we can kill this class entirely.

We rename to wl_transfer_src for clarity.

Signed-off-by: Casey Dahlin 
---
 protocol/wayland.xml |   75 +-
 1 files changed, 1 insertions(+), 74 deletions(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 48ba68a..88e4232 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -153,33 +153,7 @@
 
   
 
-  
-
-  
-  
-  
-
-
-
-  
-  
-  
-  
-  
-  
-  
-  
-  
-
-
-
-  
-  
-  
-  
-  
-
-
+  
 
   
 
@@ -187,53 +161,6 @@
 
   
 
-
-
-
-  
-
-
-
-
-  
-  
-  
-  
-  
-
-
-
-
-  
-
-
-
-
-  
-  
-  
-  
-  
-
   
 
   
-- 
1.7.6

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

Re: [PATCH] Update mesa build instructions

2011-07-18 Thread Casey Dahlin 
On Mon, Jul 18, 2011 at 01:59:41PM -0400, Kristian Høgsberg wrote:
> On Mon, Jul 18, 2011 at 2:02 AM, Casey Dahlin  wrote:
> > ---
> >  building.html |   20 +---
> >  1 files changed, 17 insertions(+), 3 deletions(-)
> 
> Thanks, applied.
> 

There's an error in it :( The second command in the 3 new prerequisite
builds should be cd macros, cd glproto, and cd dri2proto respectively.
Note they all say macros now.

--CJD

> > diff --git a/building.html b/building.html
> > index f52f80e..1cced7b 100644
> > --- a/building.html
> > +++ b/building.html
> > @@ -85,11 +85,25 @@ Other dependencies are development packages of xcb-dri2 
> > and xcb-xfixes.
> >     $ ./autogen.sh --prefix=$WLD --enable-nouveau-experimental-api
> >     $ make && make install
> >
> > +    $ git clone git://anongit.freedesktop.org/git/xorg/util/macros
> > +    $ cd macros
> > +    $ ./autogen.sh --prefix=$WLD
> > +    $ make && make install
> > +
> > +    $ git clone git://anongit.freedesktop.org/xorg/proto/glproto
> > +    $ cd macros
> > +    $ ./autogen.sh --prefix=$WLD
> > +    $ make && make install
> > +
> > +    $ git clone git://anongit.freedesktop.org/xorg/proto/dri2proto
> > +    $ cd macros
> > +    $ ./autogen.sh --prefix=$WLD
> > +    $ make && make install
> > +
> >     $ git clone git://anongit.freedesktop.org/mesa/mesa
> >     $ cd mesa
> > -    $ ./autogen.sh --prefix=$WLD --enable-gles2                   \
> > -      --disable-gallium-egl --enable-gallium-nouveau --enable-gallium-r600 
> > \
> > -      --with-egl-platforms=x11,wayland,drm
> > +    $ ./autogen.sh --prefix=$WLD --enable-gles2 --disable-gallium-egl \
> > +      --with-egl-platforms=x11,wayland,drm --enable-gbm 
> > --enable-shared-glapi
> >     $ make && make install
> >  
> >
> > --
> > 1.7.6
> >
> >
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] Update mesa build instructions

2011-07-17 Thread Casey Dahlin 
---
 building.html |   20 +---
 1 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/building.html b/building.html
index f52f80e..1cced7b 100644
--- a/building.html
+++ b/building.html
@@ -85,11 +85,25 @@ Other dependencies are development packages of xcb-dri2 and 
xcb-xfixes.
 $ ./autogen.sh --prefix=$WLD --enable-nouveau-experimental-api
 $ make && make install
 
+$ git clone git://anongit.freedesktop.org/git/xorg/util/macros
+$ cd macros
+$ ./autogen.sh --prefix=$WLD
+$ make && make install
+
+$ git clone git://anongit.freedesktop.org/xorg/proto/glproto
+$ cd macros
+$ ./autogen.sh --prefix=$WLD
+$ make && make install
+
+$ git clone git://anongit.freedesktop.org/xorg/proto/dri2proto
+$ cd macros
+$ ./autogen.sh --prefix=$WLD
+$ make && make install
+
 $ git clone git://anongit.freedesktop.org/mesa/mesa
 $ cd mesa
-$ ./autogen.sh --prefix=$WLD --enable-gles2   \
-  --disable-gallium-egl --enable-gallium-nouveau --enable-gallium-r600 \
-  --with-egl-platforms=x11,wayland,drm
+$ ./autogen.sh --prefix=$WLD --enable-gles2 --disable-gallium-egl \
+  --with-egl-platforms=x11,wayland,drm --enable-gbm --enable-shared-glapi
 $ make && make install
 
 
-- 
1.7.6

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

[PATCH 2/2] Pass object ID not pointer when sending a global announce event

2011-07-17 Thread Casey Dahlin 
When the type for the first argument of the global event changed from new_id to
uint, wl_connection_vmarshal started expecting an integer argument rather than
an object argument. As a result we were sending the client a chunk of pointer
rather than a useful global identifier.
---
 wayland/wayland-server.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/wayland/wayland-server.c b/wayland/wayland-server.c
index d4fdfc7..2019cb4 100644
--- a/wayland/wayland-server.c
+++ b/wayland/wayland-server.c
@@ -313,7 +313,7 @@ wl_client_post_global(struct wl_client *client, struct 
wl_object *object)
wl_client_post_event(client,
 &client->display->object,
 WL_DISPLAY_GLOBAL,
-object,
+object->id,
 object->interface->name,
 object->interface->version);
 }
-- 
1.7.6

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

[PATCH 1/2] Fix segfault in client when demarshalling fails

2011-07-17 Thread Casey Dahlin 
---
 wayland/wayland-client.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/wayland/wayland-client.c b/wayland/wayland-client.c
index ce27a90..d1ed25a 100644
--- a/wayland/wayland-client.c
+++ b/wayland/wayland-client.c
@@ -521,6 +521,11 @@ handle_event(struct wl_display *display,
closure = wl_connection_demarshal(display->connection,
  size, display->objects, message);
 
+   if (! closure) {
+   fprintf(stderr, "Error demarshalling closure: %m\n");
+   return;
+   }
+
if (wl_debug)
wl_closure_print(closure, &proxy->object, false);
 
-- 
1.7.6

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

[PATCH|demos] Support new mechanic for shell move and resize (cast to shell-surface)

2011-06-09 Thread Casey Dahlin 
---
 clients/window.c|   26 +++---
 compositor/compositor-wayland.c |   18 -
 compositor/compositor.h |1 +
 compositor/shell.c  |  156 ---
 4 files changed, 127 insertions(+), 74 deletions(-)

diff --git a/clients/window.c b/clients/window.c
index 758a536..f3c3da8 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -90,6 +90,7 @@ struct window {
struct display *display;
struct window *parent;
struct wl_surface *surface;
+   struct wl_shell_surface *shell_surface;
char *title;
struct rectangle allocation, saved_allocation, server_allocation;
int x, y;
@@ -1078,8 +1079,8 @@ window_handle_button(void *data,
if (button == BTN_LEFT && state == 1) {
switch (location) {
case WINDOW_TITLEBAR:
-   wl_shell_move(window->display->shell,
- window->surface, input_device, time);
+   wl_shell_surface_move(window->shell_surface,
+ input_device, time);
break;
case WINDOW_RESIZING_TOP:
case WINDOW_RESIZING_BOTTOM:
@@ -1089,9 +1090,8 @@ window_handle_button(void *data,
case WINDOW_RESIZING_TOP_RIGHT:
case WINDOW_RESIZING_BOTTOM_LEFT:
case WINDOW_RESIZING_BOTTOM_RIGHT:
-   wl_shell_resize(window->display->shell,
-   window->surface, input_device, time,
-   location);
+   wl_shell_surface_resize(window->shell_surface,
+   input_device, time, location);
break;
case WINDOW_CLIENT_AREA:
if (window->button_handler)
@@ -1251,8 +1251,8 @@ window_create_drag(struct window *window)
 void
 window_move(struct window *window, struct input *input, uint32_t time)
 {
-   wl_shell_move(window->display->shell,
- window->surface, input->input_device, time);
+   wl_shell_surface_move(window->shell_surface, input->input_device,
+ time);
 }
 
 void
@@ -1263,11 +1263,10 @@ window_activate_drag(struct wl_drag *drag, struct 
window *window,
 }
 
 static void
-handle_configure(void *data, struct wl_shell *shell,
-uint32_t time, uint32_t edges,
-struct wl_surface *surface, int32_t width, int32_t height)
+handle_configure(void *data, struct wl_shell_surface *shell_surface,
+uint32_t time, uint32_t edges, int32_t width, int32_t height)
 {
-   struct window *window = wl_surface_get_user_data(surface);
+   struct window *window = wl_shell_surface_get_user_data(shell_surface);
int32_t child_width, child_height;
 
/* FIXME: this is probably the wrong place to check for width
@@ -1294,7 +1293,7 @@ handle_configure(void *data, struct wl_shell *shell,
}
 }
 
-static const struct wl_shell_listener shell_listener = {
+static const struct wl_shell_surface_listener shell_surface_listener = {
handle_configure,
 };
 
@@ -1490,6 +1489,8 @@ window_create_internal(struct display *display, struct 
window *parent,
window->display = display;
window->parent = parent;
window->surface = wl_compositor_create_surface(display->compositor);
+   window->shell_surface =
+   wl_shell_create_shell_surface(display->shell, window->surface);
window->allocation.x = 0;
window->allocation.y = 0;
window->allocation.width = width;
@@ -1732,7 +1733,6 @@ display_handle_global(struct wl_display *display, 
uint32_t id,
display_add_input(d, id);
} else if (strcmp(interface, "wl_shell") == 0) {
d->shell = wl_shell_create(display, id, 1);
-   wl_shell_add_listener(d->shell, &shell_listener, d);
} else if (strcmp(interface, "wl_shm") == 0) {
d->shm = wl_shm_create(display, id, 1);
} else if (strcmp(interface, "wl_selection_offer") == 0) {
diff --git a/compositor/compositor-wayland.c b/compositor/compositor-wayland.c
index 6cd02ed..648f452 100644
--- a/compositor/compositor-wayland.c
+++ b/compositor/compositor-wayland.c
@@ -299,23 +299,6 @@ static const struct wl_output_listener output_listener = {
display_handle_geometry,
 };
 
-/* parent shell interface */
-static void
-handle_configure(void *data, struct wl_shell *shell,
-uint32_t time, uint32_t edges,
-struct wl_surface *surface, int32_t width, int32_t height)
-{
-#if 0
-   struct output *output = wl_surface_get_user_data(surface);
-
-   /* FIXME: add resize? */
-#endif
-}
-
-static const struct wl_shell_listener shell_listener = {
-   handle_configure,
-};
-
 /* parent input interface */
 static vo

[PATCH] Make shell movement actions methods on a shell surface

2011-06-09 Thread Casey Dahlin 
This patch makes move and resize methods on a surface rather than methods
stored in some "shell" global. However, to compartmentalize functionality, the
methods still appear in a different interface than wl_surface. The interface is
called wl_shell_surface. The client essentially "casts" a wl_surface to a
wl_shell_surface by constructing a new wl_shell_surface from a wl_surface. The
result is two object IDs with two interfaces, but representing the same
underlying conceptual object.
---
 protocol/wayland.xml |   26 +++---
 1 files changed, 15 insertions(+), 11 deletions(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 9d0a539..36a2d74 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -142,8 +142,22 @@
   
 
   
+
+  
+
+
+
+  
+
+
+
+  
+  
+
+  
+
+  
 
-  
   
   
 
@@ -161,21 +175,12 @@
 
 
 
-  
   
   
   
   
 
 
-
-  
-
-
-
-  
-
-

[PATCH] Update .gitignore

2011-05-18 Thread Casey Dahlin 
---
 compositor/.gitignore |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/compositor/.gitignore b/compositor/.gitignore
index 847efbd..6e8eb59 100644
--- a/compositor/.gitignore
+++ b/compositor/.gitignore
@@ -1,4 +1,4 @@
-compositor
+wayland-compositor
 screenshooter-protocol.c
 screenshooter-server-protocol.h
 meego-tablet-protocol.c
-- 
1.7.5.1

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

Re: Wayland Window Management Proposal

2011-05-13 Thread Casey Dahlin 
On Fri, May 13, 2011 at 03:13:01PM +0200, Michal Suchanek wrote:
> On 13 May 2011 11:26, Daniel Stone  wrote:
> > On Thu, May 12, 2011 at 06:22:01PM +0200, Michal Suchanek wrote:
> >> You can't expect that every single client is high-priority and lag-free.
> >
> > Run better clients, then? Or stop trying to micro-optimise for the case
> > of pressing the close button on an unresponsive client?
> >
> 
> This is not about pressing the close button. It need not have an
> immediate response and people can accept that, there are workarounds
> and you close windows only so often.
> 
> However, window resizes need to be responsive otherwise you introduce
> lag, possibly to the point that the person moving the mouse has no
> clue what is going on the moment a window resize is initiated.
> 

You can always use the "rubber band" style of resize, in which case the window
only needs to be told about the resize, and respond to it, when the user picks
a size and drops the corner.

In fact you can pretty easily do both, where the rubber band appears when the
window hasn't managed to keep up, so the user still has a visual cue to what
they are doing.

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

Re: Wayland Window Management Proposal

2011-05-13 Thread Casey Dahlin 
On Fri, May 13, 2011 at 08:44:23PM +0200, Michal Suchanek wrote:
> Again, do you really know only one transition between two frames - flashing?
> 
> With all the effects compositors are capable of today this is the only
> thing you can think of?
> 

Fade to corruption? That just means crap is onscreen for a longer amount of
time.

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

Re: [PATCH] compositor: Set EGL_PLATFORM env variable for each backend.

2011-05-10 Thread Casey Dahlin 
On Tue, May 10, 2011 at 04:42:56PM -0400, Kristian Høgsberg wrote:
> Indeed.  I'll commit this patch for now, since I've had enough of
> failing to set EGL_PLATFORM and then trying to figure out why it
> breaks.  The best solution I know of at this point is a "magic" way to
> look at the native display argument and detect what kind it is.  So
> for example, stat it to see if it's a char device, in which case we
> decide it's the drm platform.  If not, assume it's a pointer a struct
> and see if the first field looks like a valid pointer (not NULL and a
> multiple of 4), in which case we assume it's a X display pointer
> (Xlib.h, line 506).  For the wl_display struct we can make the first
> field a pointer to a wayland symbol which will let us distinguish it
> from an X display pointer.
> 

The way I thought to do it was to make eglDisplay take none of those as
arguments, but instead take a struct mesaEglDisplay * where said struct was
defined:

struct mesaEglDisplay {
/* uint64_t magic; */
char[8] platform;
void *display;
}

The reason it works is obvious, and its well within the egl spec. If you wanted
backward compatiblity, you could leave the magic uncommented and always fill
with 0xdeadbeefb4b3f00d, which would let you distinguish the new mechanism with
magic detection (though much more deterministic magic detection than what you
outlined) and otherwise just use the present system.

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

Re: [PATCH] compositor: Set EGL_PLATFORM env variable for each backend.

2011-05-10 Thread Casey Dahlin 
On Tue, May 10, 2011 at 08:00:19PM +, Egbert Eich wrote:
> I may have missed something, but - since the Wayland compositor 
> already picks a platform backend, opens a connection and initializes the
> backend specific display data structure it doesn't make sense
> to let egl pick a platform. If it picks a different one the 
> display specific data structure will most likely not match.
> Thus determine the platform in the Wayland rendering backend by setting
> the EGL_PLATFORM env variable.
> For the client any other platform than 'wayland' doesn't seem to make
> sense.
> I'm not sure if I've got the the platform ofr openfwd right.
> 
> Signed-off-by: Egbert Eich 

This is one of many ways to hack around the somewhat deficient platform
selection in EGL (which in turn is a product of attempting to implement
the spec as best as they can).

Some sort of architectural fix for mesa would probably be preferred, but
nobody has yet found one that people will agree on.

--CJD

> ---
>  clients/window.c|1 +
>  compositor/compositor-drm.c |1 +
>  compositor/compositor-openwfd.c |1 +
>  compositor/compositor-wayland.c |1 +
>  compositor/compositor-x11.c |1 +
>  5 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/clients/window.c b/clients/window.c
> index 9d0b753..8c3f8d2 100644
> --- a/clients/window.c
> +++ b/clients/window.c
> @@ -1757,6 +1757,7 @@ init_egl(struct display *d)
>   EGL_NONE
>   };
>  
> + setenv("EGL_PLATFORM", "wayland", 1);
>   d->dpy = eglGetDisplay(d->display);
>   if (!eglInitialize(d->dpy, &major, &minor)) {
>   fprintf(stderr, "failed to initialize display\n");
> diff --git a/compositor/compositor-drm.c b/compositor/compositor-drm.c
> index 4897b38..9fc5b49 100644
> --- a/compositor/compositor-drm.c
> +++ b/compositor/compositor-drm.c
> @@ -269,6 +269,7 @@ init_egl(struct drm_compositor *ec, struct udev_device 
> *device)
>   return -1;
>   }
>  
> + setenv("EGL_PLATFORM", "drm", 1);
>   ec->drm.fd = fd;
>   ec->base.display = eglGetDisplay(FD_TO_EGL_NATIVE_DPY(ec->drm.fd));
>   if (ec->base.display == NULL) {
> diff --git a/compositor/compositor-openwfd.c b/compositor/compositor-openwfd.c
> index 0ddde52..ccd3dce 100644
> --- a/compositor/compositor-openwfd.c
> +++ b/compositor/compositor-openwfd.c
> @@ -118,6 +118,7 @@ init_egl(struct wfd_compositor *ec)
>   return -1;
>  
>   ec->wfd_fd = fd;
> + setenv("EGL_PLATFORM", "drm", 1);
>   ec->base.display = eglGetDisplay(FD_TO_EGL_NATIVE_DPY(ec->wfd_fd));
>   if (ec->base.display == NULL) {
>   fprintf(stderr, "failed to create display\n");
> diff --git a/compositor/compositor-wayland.c b/compositor/compositor-wayland.c
> index 1a53e8d..6cd02ed 100644
> --- a/compositor/compositor-wayland.c
> +++ b/compositor/compositor-wayland.c
> @@ -111,6 +111,7 @@ wayland_compositor_init_egl(struct wayland_compositor *c)
>   EGL_NONE
>   };
>  
> + setenv("EGL_PLATFORM", "wayland", 1);
>   c->base.display = eglGetDisplay(c->parent.display);
>   if (c->base.display == NULL) {
>   fprintf(stderr, "failed to create display\n");
> diff --git a/compositor/compositor-x11.c b/compositor/compositor-x11.c
> index ac31881..3517fad 100644
> --- a/compositor/compositor-x11.c
> +++ b/compositor/compositor-x11.c
> @@ -113,6 +113,7 @@ x11_compositor_init_egl(struct x11_compositor *c)
>   EGL_NONE
>   };
>  
> + setenv("EGL_PLATFORM", "x11", 1);
>   c->base.display = eglGetDisplay(c->dpy);
>   if (c->base.display == NULL) {
>   fprintf(stderr, "failed to create display\n");
> -- 
> 1.7.3.4
> 
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Interface modules

2011-05-07 Thread Casey Dahlin 
Talking with krh on IRC, there's a few cases that have come up where a
compositor might want objects to have different methods available than usual.
Some examples include:

* System compositors, which might want map_fullscreen, but not the other map_*
functions.
* Network proxying compositors that might want the other map_* functions but
not map_fullscreen.
* A whole array of different potential additions and removals for wl_shell,
depending on the paradigm this compositor is using for window management.

There's a few ways that this can be handled:

We could have different interfaces when the set of functionality is different.
This is the approach that is being taken now. It keeps wayland simple and
somewhat extensible, but the disadvantage is that apps have to know which
version of the object to expect. If more than one version can provide for them
then they have to learn several ways to interact with different compositors.
The library could abstract around this a bit, but it would mean every version
of a given interface had to be known to the library, which makes it more
painful to, say, have new compositors implement their own shell interfaces
independently of wayland.

We could solve a good bit of this with a naming convention. For example, we
could say wl_shell.meego would contain all the methods in a basic wl_shell
plus whatever was added by meego. Apps that don't use the meego functionality
know that they can use the object like a regular wl_shell. This is nice in that
it is very easy to implement the way wayland is written now; the extended
interface just tacks its new methods onto the end of the implementation struct
in the object header. The disadvantage to this method is that its hard to layer
functionality. For example, if one extension might want to allow move but not
resize, and another wanted resize but not move, it isn't possible to specify
the base shell in such a way that either of those components could be dropped.
You could specify the base shell with move and resize as
wl_shell.with_move.with_resize, but since the names (and internal
interfaces)are strict subsets and supersets there's no way to drop with_move
and keep with_resize. There's also the danger of names becoming quite long,
especially if we want people to be able to snip out large chunks of
"basic" functionality from the interfaces.

A more flexible option is to implement modules for interfaces. From an OO
perspective these would behave semantically like modules in ruby, or like what
many other languages call mix-ins. An object may support one or more addon
modules to its interface, in any combination. Each addon module has its own
list of additional methods and events provided. The interface for this would
basically add one more uint32_t argument to wl_proxy_marshal, for module id,
and one more client call, wl_proxy_supports. When not using functionality added
by a module, the extra argument to wl_proxy_marshal is 0, and things continue
as normal.  When using functionality within a module, the client first calls
wl_proxy_supports, passing the proxy, a string name for the module, and a
desired version. If the function returns non-zero, then that value should be
used for the module id argument in wl_proxy_marshal when calling methods in
that module.

Thoughts?

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

Re: [PATCH 1/2] Add to output protocol to allow rotate/resize

2011-05-02 Thread Casey Dahlin 
On Fri, Apr 29, 2011 at 04:58:24PM -0400, Kristian Høgsberg wrote:
> Apps shouldn't generally change the *default* resolution.  Games and
> such may want to show their window at the native resolution and that's
> part of the fullscreen plan:
> 
>   
> http://lists.freedesktop.org/archives/wayland-devel/2010-November/000117.html
> 

Ah, that does make sense?

> Of course, the DE config tool will want to be able to change the
> default mode and placement of monitors.  In that case we're talking
> about a specific DE with it's own display configuration tool, and
> perhaps the tool can just update the underlying config (GConf or so)
> and the compositor picks up the change from there.  As a first step
> I'd rather just add the extra info to wl_output (list of available
> modes, refresh rates, sub pixel layout, connector name etc), and punt
> on how to change it for now.
> 

Would it make sense for the demo compositor to grow some sort of config
backend then? Obviously it wouldn't be directly useful to anyone else
but it would at least let us test the functionality that should be
exposed "elsewhere."

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

Re: [PATCH 1/2] Add to output protocol to allow rotate/resize

2011-04-29 Thread Casey Dahlin 
On Fri, Apr 29, 2011 at 09:43:53AM +0200, Benjamin Franzke wrote:
> 2011/4/29 Casey Dahlin :
> > Adds some parameters to the output geometry event. Also adds a move method 
> > to
> > change those parameters.
> > ---
> >  protocol/wayland.xml |   15 ---
> >  1 files changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> > index 11976fa..187e961 100644
> > --- a/protocol/wayland.xml
> > +++ b/protocol/wayland.xml
> > @@ -446,12 +446,21 @@
> >        published as global during start up, or when a screen is hot
> >        plugged.  -->
> >   
> > -    
> > +    
> > +    
> > +      
> > +      
> > +      
> > +    
> 
> I think we need a general debate first, about how to grant permission
> to only specific clients to change output configuration.
> Or even not making it part of the main protocol at all, just being an
> extension or so.
> We might not want every application to have control of these things.
> 

xrandr doesn't seem to have much more authentication than this. Its not much
more dangerous than changing the resolution, which many fairly pedestrian apps
expect to be able to do (i.e. games). Indeed its potentially a good deal less
dangerous than fullscreen mode (though that can be fixed with UI), far less
dangerous than screenshots from a security perspective (and we can't have
clients render certain effects if they can't get a copy of what's behind them
to distort), and even a good deal safer than input grabs.

> > +
> > +    
> >     
> >       
> >       
> > -      
> > -      
> > +      
> > +      
> > +      
> >     
> >   
> 
> Why changing the width and height datatype within this patch?
> That would be another patch. But Kristian denied that somewhen already.
> 

Oh yeah, I did do that didn't I? X( I'll kill it in the revision.

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

[PATCH 2/2] Add flip client

2011-04-29 Thread Casey Dahlin 
The flip client provides access to the move method of the output interface, and
lets you rotate, flip, and shift the screen view.
---
 clients/.gitignore  |1 +
 clients/Makefile.am |4 ++
 clients/flip.c  |  104 +++
 3 files changed, 109 insertions(+), 0 deletions(-)
 create mode 100644 clients/flip.c

diff --git a/clients/.gitignore b/clients/.gitignore
index fe7546d..419f05b 100644
--- a/clients/.gitignore
+++ b/clients/.gitignore
@@ -12,3 +12,4 @@ simple-client
 smoke
 terminal
 view
+flip
diff --git a/clients/Makefile.am b/clients/Makefile.am
index ca11be3..6dd5b5a 100644
--- a/clients/Makefile.am
+++ b/clients/Makefile.am
@@ -2,6 +2,7 @@ noinst_PROGRAMS =   \
gears   \
flower  \
screenshot  \
+   flip\
terminal\
image   \
$(poppler_programs) \
@@ -39,6 +40,9 @@ flower_LDADD = $(toolkit_libs)
 screenshot_SOURCES = screenshot.c screenshooter-protocol.c
 screenshot_LDADD = $(toolkit_libs)
 
+flip_SOURCES = flip.c
+flip_LDADD = $(CLIENT_LIBS) -lrt -lm
+
 terminal_SOURCES = terminal.c
 terminal_LDADD = $(toolkit_libs) -lutil
 
diff --git a/clients/flip.c b/clients/flip.c
new file mode 100644
index 000..5903a81
--- /dev/null
+++ b/clients/flip.c
@@ -0,0 +1,104 @@
+/*
+ * Copyright © 2011 Casey Dahlin
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no representations
+ * about the suitability of this software for any purpose.  It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "wayland-client.h"
+
+static void
+handle_global(struct wl_display *display, uint32_t id,
+ const char *interface, uint32_t version, void *data)
+{
+   struct wl_output **output = data;
+
+   if (strcmp(interface, "wl_output") == 0)
+   *output = wl_output_create(display, id, 1);
+}
+
+int main(int argc, char *argv[])
+{
+   struct wl_display *display;
+   struct wl_output *output;
+   int x = 0, y = 0, flags = 0, i;
+   int had_nums = 0;
+   char *end = "";
+
+   for (i = 1; i < argc; i++) {
+   if (! strcmp(argv[i], "--hflip")) {
+   flags |= WL_OUTPUT_HORIZFLIP;
+   } else if (! strcmp(argv[i], "--vflip")) {
+   flags |= WL_OUTPUT_VERTFLIP;
+   } else if (! strcmp(argv[i], "--rotatecw")) {
+   flags |= WL_OUTPUT_CWROTATE;
+   } else if (had_nums == 2) {
+   fprintf(stderr, "too many arguments\n");
+   goto usage;
+   } else if (had_nums++ == 1) {
+   y = strtoll(argv[i], &end, 0);
+   } else {
+   x = strtoll(argv[i], &end, 0);
+   }
+
+   if (*end) {
+   fprintf(stderr, "coordinates must be numeric\n");
+   goto usage;
+   }
+   }
+
+   if (had_nums == 1)
+   goto usage;
+
+   display = wl_display_connect(NULL);
+   if (display == NULL) {
+   fprintf(stderr, "failed to create display: %m\n");
+   return -1;
+   }
+
+   output = NULL;
+   wl_display_add_global_listener(display, handle_global, &output);
+   wl_display_iterate(display, WL_DISPLAY_READABLE);
+   if (output == NULL) {
+   fprintf(stderr, "output not found\n");
+   return -1;
+   }
+
+   wl_output_move(output, x, y, flags);
+   wl_display_iterate(display, WL_DISPLAY_WRITABLE);
+   wl_display_des

[PATCH 1/2] Add support for move method on outputs

2011-04-29 Thread Casey Dahlin 
Outputs can now be rotated, flipped, and shifted by using the new move method
of the output interface.
---
 clients/window.c|3 +-
 compositor/compositor-wayland.c |4 +-
 compositor/compositor.c |   97 --
 compositor/compositor.h |3 +-
 4 files changed, 77 insertions(+), 30 deletions(-)

diff --git a/clients/window.c b/clients/window.c
index 9d0b753..33dbc94 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -1523,7 +1523,8 @@ window_set_buffer_type(struct window *window, enum 
window_buffer_type type)
 static void
 display_handle_geometry(void *data,
struct wl_output *output,
-   int32_t x, int32_t y, int32_t width, int32_t height)
+   int32_t x, int32_t y, uint32_t tflags,
+   uint32_t width, uint32_t height)
 {
struct display *display = data;
 
diff --git a/compositor/compositor-wayland.c b/compositor/compositor-wayland.c
index 4093f2a..508ea88 100644
--- a/compositor/compositor-wayland.c
+++ b/compositor/compositor-wayland.c
@@ -283,8 +283,8 @@ cleanup_output:
 static void
 display_handle_geometry(void *data,
struct wl_output *output,
-   int32_t x, int32_t y,
-   int32_t width, int32_t height)
+   int32_t x, int32_t y, uint32_t tflags,
+   uint32_t width, uint32_t height)
 {
struct wayland_compositor *c = data;
 
diff --git a/compositor/compositor.c b/compositor/compositor.c
index df25407..4f0912f 100644
--- a/compositor/compositor.c
+++ b/compositor/compositor.c
@@ -113,6 +113,16 @@ wlsc_matrix_scale(struct wlsc_matrix *matrix, GLfloat x, 
GLfloat y, GLfloat z)
 }
 
 static void
+wlsc_matrix_rotate_90ccw(struct wlsc_matrix *matrix)
+{
+   struct wlsc_matrix rot = {
+   { 0, -1, 0, 0,  1, 0, 0, 0,  0, 0, 1, 0,  0, 0, 0, 1 }
+   };
+
+   wlsc_matrix_multiply(matrix, &rot);
+}
+
+static void
 wlsc_matrix_transform(struct wlsc_matrix *matrix, struct wlsc_vector *v)
 {
int i, j;
@@ -649,7 +659,7 @@ wlsc_output_damage(struct wlsc_output *output)
pixman_region32_union_rect(&compositor->damage_region,
   &compositor->damage_region,
   output->x, output->y,
-  output->width, output->height);
+  output->swidth, output->sheight);
wlsc_compositor_schedule_repaint(compositor);
 }
 
@@ -687,8 +697,8 @@ fade_output(struct wlsc_output *output,
surface.compositor = compositor;
surface.x = output->x;
surface.y = output->y;
-   surface.width = output->width;
-   surface.height = output->height;
+   surface.width = output->swidth;
+   surface.height = output->sheight;
surface.texture = GL_NONE;
 
if (tint <= 1.0)
@@ -727,7 +737,7 @@ wlsc_output_repaint(struct wlsc_output *output)
pixman_region32_intersect_rect(&new_damage,
   &ec->damage_region,
   output->x, output->y,
-  output->width, output->height);
+  output->swidth, output->sheight);
pixman_region32_subtract(&ec->damage_region,
 &ec->damage_region, &new_damage);
pixman_region32_union(&total_damage, &new_damage,
@@ -754,8 +764,8 @@ wlsc_output_repaint(struct wlsc_output *output)
}
}
 
-   if (es->width < output->width ||
-   es->height < output->height)
+   if (es->width < output->swidth ||
+   es->height < output->sheight)
glClear(GL_COLOR_BUFFER_BIT);
wlsc_surface_draw(es, output, &total_damage);
} else {
@@ -893,9 +903,10 @@ wlsc_surface_assign_output(struct wlsc_surface *es)
struct wlsc_output *tmp = es->output;
es->output = NULL;
 
+
wl_list_for_each(output, &ec->output_list, link) {
-   if (output->x < es->x && es->x < output->x + output->width &&
-   output->y < es->y && es->y < output->y + output->height) {
+   if (output->x < es->x && es->x < output->x + output->swidth &&
+   output->y < es->y && es->y < output->y + output->sheight) {
if (output != tmp)
printf("assiging surface %p to output %p\n",
   es, output);
@@ -928,8 +939,8 @@ surface_attach(struct wl_client *client,
es->buffer = buffer;
switch (es->map_type) {
case WLSC_SURFACE_MAP_FULLSCREEN:
-   es->x = (es->fullscreen_output->width - es->width) / 2;
-   es->y = (es->fullscreen_output->height - es->height) / 2;
+   es->x

[PATCH:demos 0/2] Update demos to support/show off output

2011-04-29 Thread Casey Dahlin 
See corresponding wayland patch series. This series updates the demo compositor
to correctly handle being flipped, rotated, and shifted. It also adds a small
client which does not draw anything or persist, but takes arguments to perform
any of the above actions.

Instructions for the client can be obtained by running it with --help

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

[PATCH] Add some new things to .gitignore

2011-04-28 Thread Casey Dahlin 
libtoytoolkit.a, and generated protocol headers for meego-tablet.
---
 clients/.gitignore|1 +
 compositor/.gitignore |2 ++
 2 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/clients/.gitignore b/clients/.gitignore
index 8b3c40c..fe7546d 100644
--- a/clients/.gitignore
+++ b/clients/.gitignore
@@ -1,3 +1,4 @@
+libtoytoolkit.a
 dnd
 eventdemo
 flower
diff --git a/compositor/.gitignore b/compositor/.gitignore
index dc926c1..847efbd 100644
--- a/compositor/.gitignore
+++ b/compositor/.gitignore
@@ -1,3 +1,5 @@
 compositor
 screenshooter-protocol.c
 screenshooter-server-protocol.h
+meego-tablet-protocol.c
+meego-tablet-server-protocol.h
-- 
1.7.5

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

[PATCH 1/2] Add to output protocol to allow rotate/resize

2011-04-28 Thread Casey Dahlin 
Adds some parameters to the output geometry event. Also adds a move method to
change those parameters.
---
 protocol/wayland.xml |   15 ---
 1 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 11976fa..187e961 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -446,12 +446,21 @@
published as global during start up, or when a screen is hot
plugged.  -->
   
-
+
+
+  
+  
+  
+
+
+
 
   
   
-  
-  
+  
+  
+  
 
   
 
-- 
1.7.5

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

[PATCH 2/2] Add wayland-protocol.h

2011-04-28 Thread Casey Dahlin 
This file can store flag values and such constants as are useful to have at
both ends of the protocol.
---
 wayland/Makefile.am|1 +
 wayland/wayland-client.h   |1 +
 wayland/wayland-protocol.h |   30 ++
 wayland/wayland-server.h   |1 +
 4 files changed, 33 insertions(+), 0 deletions(-)
 create mode 100644 wayland/wayland-protocol.h

diff --git a/wayland/Makefile.am b/wayland/Makefile.am
index ed31dfc..be6d6ab 100644
--- a/wayland/Makefile.am
+++ b/wayland/Makefile.am
@@ -7,6 +7,7 @@ include_HEADERS =   \
wayland-server.h\
wayland-client-protocol.h   \
wayland-client.h\
+   wayland-protocol.h  \
wayland-egl.h
 
 libwayland_util_la_SOURCES =   \
diff --git a/wayland/wayland-client.h b/wayland/wayland-client.h
index f1ac797..ae1e926 100644
--- a/wayland/wayland-client.h
+++ b/wayland/wayland-client.h
@@ -45,6 +45,7 @@ void wl_proxy_set_user_data(struct wl_proxy *proxy, void 
*user_data);
 void *wl_proxy_get_user_data(struct wl_proxy *proxy);
 
 #include "wayland-client-protocol.h"
+#include "wayland-protocol.h"
 
 #define WL_DISPLAY_READABLE 0x01
 #define WL_DISPLAY_WRITABLE 0x02
diff --git a/wayland/wayland-protocol.h b/wayland/wayland-protocol.h
new file mode 100644
index 000..7660779
--- /dev/null
+++ b/wayland/wayland-protocol.h
@@ -0,0 +1,30 @@
+/*
+ * Copyright © 2011 Casey Dahlin
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no representations
+ * about the suitability of this software for any purpose.  It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+
+#ifndef _WAYLAND_PROTOCOL_H
+#define _WAYLAND_PROTOCOL_H
+
+#define WL_OUTPUT_HORIZFLIP 0x01
+#define WL_OUTPUT_VERTFLIP  0x02
+#define WL_OUTPUT_CWROTATE  0x04
+
+#endif
diff --git a/wayland/wayland-server.h b/wayland/wayland-server.h
index 649bb6b..2026c6a 100644
--- a/wayland/wayland-server.h
+++ b/wayland/wayland-server.h
@@ -30,6 +30,7 @@ extern "C" {
 #include 
 #include "wayland-util.h"
 #include "wayland-server-protocol.h"
+#include "wayland-protocol.h"
 
 enum {
WL_EVENT_READABLE = 0x01,
-- 
1.7.5

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

[PATCH 0/2] RandR functionality for wayland protocol

2011-04-28 Thread Casey Dahlin 
The second R is a bit of a misnomer right now since there's not actually
modesetting, but this patch set extends the wayland protocol to allow rotating
and flipping outputs, and moving their position.

It adds a single method to the "output" interface to set x, y, and some flags
to perform transformation: one to flip horizontal, one to flip vertical, and
one to rotate 90 degrees clockwise (you'll note that setting both flips will
have the effect of a 180 degree rotation, and setting all 3 flags will rotate
270 degrees, so further transforms aren't necessary for the basic stuff).

The geometry event is ammended to report the transformation flags along with
the other info.

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

[PATCH] Add some things related to wayland-scanner to .gitignore

2011-04-28 Thread Casey Dahlin 
---
 .gitignore |1 +
 wayland/.gitignore |2 +-
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/.gitignore b/.gitignore
index 7c5bfe5..904eb50 100644
--- a/.gitignore
+++ b/.gitignore
@@ -9,6 +9,7 @@
 *~
 .libs
 /aclocal.m4
+/wayland-scanner.m4
 /autom4te.cache
 /config.guess
 /config.h
diff --git a/wayland/.gitignore b/wayland/.gitignore
index 0d28ba5..1813f89 100644
--- a/wayland/.gitignore
+++ b/wayland/.gitignore
@@ -1,4 +1,4 @@
-scanner
+wayland-scanner
 wayland-client-protocol.h
 wayland-protocol.c
 wayland-server-protocol.h
-- 
1.7.5

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

Must specify EGL_PLATFORM when running compositor?

2011-04-26 Thread Casey Dahlin 
I built Wayland for the first time since EGL grew specific support for it, and
I ran into a strange issue. I used the instructions at
http://wayland.freedesktop.org/building.html pretty much exactly, but when
running the compositor, I got a segmentation fault. The only way to avoid this
was to run the compositor with EGL_PLATFORM=x11 in the environment. Otherwise
EGL would attempt to load the wayland driver, and in the process attempt to use
the X11 "Display *" the compositor had allocated as a proxy "struct wl_display"

I don't see how this problem is supposed to be avoided looking at the EGL code,
and it seems rather silly that the EGL code would make such a mistake. Is it
supposed to be this way?

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

Re: Running on bare hardware

2011-02-21 Thread Casey Dahlin 
On Sun, Feb 20, 2011 at 10:23:18PM +0100, Enrico Weigelt wrote:
> * Dave Airlie  schrieb:
> 
> > The proper way is to design ioctls so compat layers aren't needed, to work
> > across all 32/64 combos, so that means using 64-bit aligned types as much
> > as possible, and padding to make sure 64-bit types don't end up unaligned.
> 
> Until, in several years, pointers get larger than 64bit ;-p

Most of us intend to be retired or dead by then.

> 
> Actually, I still didn't get the point why such simple things
> have to be ioctl()s (which are unportable and and local-only
> by design). Why not just using plain file operations ?
> 
> (eg. getting the version info could be as simple as someting like:
> `cat /dev/dri/version`)
> 

I doubt you'll get much weight behind it, but a small demonstrative
patch to linux-api would be the right way to start that conversation.

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

Re: What's wrong with wayland?

2011-02-21 Thread Casey Dahlin 
On Sun, Feb 20, 2011 at 10:12:42PM +0100, Enrico Weigelt wrote:
> That's the point that annoys me: I want the window manager to
> remain separate and exchangable at runtime.
> 

Then just use a proxy compositor over your wayland compositor.

Wayland doesn't, IMHO, replace X, so much as it replaces the window
manager. It manages to do this in a way that is clever, so much so that
it /obviates/ X. We don't replace X, we just get rid of it and let the
window manager do the scanout and clientside conversation by itself.

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

Re: Running on bare hardware

2011-02-06 Thread Casey Dahlin 
On Mon, Feb 07, 2011 at 07:28:35AM +1000, Dave Airlie wrote:
> 
> We then use libdrm in userspace to abstract away the internal details
> of the interface,
> you shouldn't ever be directly talking to drm ioctls.
> 

I'll take this moment to point out that, while its no excuse to go using them,
libdrm is actually documented worse than the ioctls (I found one LWN article
explaining how the ioctls work, I found absolutely nothing on the libdrm API,
and I've been fumbling through code examples trying to learn it myself). I'd be
happy to help fix this if I could get someone to sit down and lecture me on it.

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

Re: wayland implementation conformance

2011-01-27 Thread Casey Dahlin 
On Thu, Jan 27, 2011 at 11:35:17AM -0500, Jeremy Volkman wrote:
> Sure. xmllint, which comes with libxml2 (libxml2-utils in Ubuntu), supports
> RELAX NG these days.
> 
> scout:protocol jvolkman$ xmllint --noout --relaxng schema.xml wayland.xml
> wayland.xml validates
> 
> -Jeremy
> 

The only issue is there's no way to link a relaxng schema from the file,
so there's no sure path to find the documentation given the file itself.
I think a DTD in addition to the schema would solve that.

--CJD

> 2011/1/27 Kristian Høgsberg 
> 
> > On Wed, Jan 26, 2011 at 5:09 PM, Jeremy Volkman 
> > wrote:
> > > Here's my stab at a Wayland schema written in RELAX NG. It can be
> > converted
> > > to a W3C schema if preferred, but RELAX NG provides more functionality.
> > For
> > > example, the schema is able to require an "interface" attribute for an
> > > argument only if the argument type is "object" or "new_id".
> > > -Jeremy
> >
> > Is there a tool that can verify the protocol against the schema?
> >
> > Kristian
> >
> > > 2011/1/26 Kristian Høgsberg 
> > >>
> > >> 2011/1/26 Casey Dahlin :
> > >> > On Wed, Jan 26, 2011 at 01:40:25PM -0500, Kristian Høgsberg wrote:
> > >> >> 2011/1/26 Josh Leverette :
> > >> >> > I'm not certain, but I think there could eventually be enough
> > >> >> > variation for that to be needed. However, even if there isn't,
> > parsing an
> > >> >> > XML file might be a better long term solution that weakly linked
> > functions
> > >> >> > and things like that. Perhaps we could modify his idea about an XML
> > profile
> > >> >> > structure to allow you to delve into each supported profile and
> > find out
> > >> >> > more about what it supports without having to hard code acceptable
> > version
> > >> >> > numbers into a program. The only problem I foresee is how to modify
> > the XML
> > >> >> > file. It's not going to be the end user's job.. but if any program
> > could
> > >> >> > modify it there needs to be a fallback system to prevent a rogue
> > program
> > >> >> > from deleting other profile advertisements written in by the system
> > or other
> > >> >> > programs.
> > >> >>
> > >> >> The XML file isn't used at runtime.  It's just a convenient mechanism
> > >> >> to describe the interface.  The way it works is that a client
> > connects
> > >> >> to the server and the server will then advertise all the global
> > >> >> objects available by giving their object id, interface name and
> > >> >> version.  A client can then look through the list to see what's
> > >> >> available and adjust its behaviour accordingly.
> > >> >>
> > >> >> Kristian
> > >> >>
> > >> >
> > >> > Does the XML file have a particular schema?
> > >> >
> > >> > It might be useful to install it in /usr/share so it could be used by
> > >> > tools. I'm thinking mostly of a d-feet style introspection tool for
> > the
> > >> > Wayland protocol (we could even go as far as dynamically adaptable
> > >> > bindings for languages like Ruby or Python).
> > >>
> > >> I didn't actually write a schema for it, but if somebody with the
> > >> right XML-fu could do that that would be nice.  It's a good point that
> > >> dynamic languages probably just want to parse the XML directly and
> > >> generate the bindings on the fly and for that we would need to install
> > >> the XML.  As for introspection/logging/xscope, that's built into the
> > >> server side library: set WAYLAND_DEBUG=1 and watch the requests and
> > >> events fly by.
> > >>
> > >> Kristian
> > >> ___
> > >> wayland-devel mailing list
> > >> wayland-devel@lists.freedesktop.org
> > >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > >
> > >
> > > ___
> > > wayland-devel mailing list
> > > wayland-devel@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > >
> > >
> >

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

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

Re: wayland implementation conformance

2011-01-26 Thread Casey Dahlin 
On Wed, Jan 26, 2011 at 01:40:25PM -0500, Kristian Høgsberg wrote:
> 2011/1/26 Josh Leverette :
> > I'm not certain, but I think there could eventually be enough variation for 
> > that to be needed. However, even if there isn't, parsing an XML file might 
> > be a better long term solution that weakly linked functions and things like 
> > that. Perhaps we could modify his idea about an XML profile structure to 
> > allow you to delve into each supported profile and find out more about what 
> > it supports without having to hard code acceptable version numbers into a 
> > program. The only problem I foresee is how to modify the XML file. It's not 
> > going to be the end user's job.. but if any program could modify it there 
> > needs to be a fallback system to prevent a rogue program from deleting 
> > other profile advertisements written in by the system or other programs.
> 
> The XML file isn't used at runtime.  It's just a convenient mechanism
> to describe the interface.  The way it works is that a client connects
> to the server and the server will then advertise all the global
> objects available by giving their object id, interface name and
> version.  A client can then look through the list to see what's
> available and adjust its behaviour accordingly.
> 
> Kristian
> 

Does the XML file have a particular schema?

It might be useful to install it in /usr/share so it could be used by
tools. I'm thinking mostly of a d-feet style introspection tool for the
Wayland protocol (we could even go as far as dynamically adaptable
bindings for languages like Ruby or Python).

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