Re: What's wrong with wayland?
On Mon, Feb 21, 2011 at 3:35 AM, Enrico Weigelt wrote: > * Marty Jack schrieb: > >> If remote clients is your thing, instead of forecasting doom >> because the old way may not work any more, first off, nothing >> stops someone from writing a thing that listens on port 6000 >> and acts just like a remote X server only it is a Wayland >> client, and second off, > > At this point, I fail to see the real benefit of Wayland, at > least from user or infrastructure view. (yes, having the hw > and composition part of the fat Xserver IMHO is a good thing > from sw-architectural view). > > One thing that annoys me is that the current design papers > explicitly take remoting out of the picture (almost declares > that obsolete or tells people to use insufficient workarounds > like VNC) and delegates a lot of things to individual clients > (so in the end introducing massive code and data duplications). It really isn't that complicated. Just make a "Netland" server which manages your application's buffer and transmits it across the network to the other Netland server which then fills the buffer on the client machine. The whole reason remoting was taken out at the server level is because these days it accounts for a lot of the overhead you'll get with rendering, since the majority of clients will do all the surface painting Client-side (cairo, Qt) or direct to the hardware (OpenGL). For the case where the server and client are running on the same hardware, this is advantageous since you can actually have smooth rendering without round-tripping to the server all the time (which can only do things such as lines, fills, arcs and bitmap fills, the latter of which is used the most today). There isn't any way to describe something like a "Gaussian blur" to the server, and trying to add such things would only lead to an infinite expansion of the core protocol to try and describe every new drawing operation that someone comes up with. The other reason why remoting at a server level has become more useless is because people *are* choosing to use client-side rendering libraries like cairo and Qt and just sending the bitmaps to the X Server. In a network situation this drastically increases bandwidth usage, rather than the relatively small bandwidth operations such as lines, arcs and fills. So what we have now for networking is this sub-optimal mix of both round-tripping a lot when we don't need to (latency) /and/ high-bandwidth usage. > >> nothing stops someone from redesigning and rethinking what >> the proper remote protocol is, > > I'd start with an proper model before starting to think about > an specific protocol: why should a client still be responsible > for drawing, instead of just describing what it wants to have > displays (eg. an scene graph or something more hi-level) ? > > Typical GUI applications have concepts of windows (and windows > within windows), widgets, etc. Those are all objects that can > be described formally and rendered in a hi-level display server. > This also would allow large savings of now heavily duplicated > code and data in the individual clients. > > 8 1/2 could be a interesting conceptional starting point. This is indeed the kind of remoting that could be achieved at a toolkit level. > >> using modern encryption and compression techniques and whatever >> else is needed to get a VNC like solution that performs well >> and is secure. > > VNC can not be done right that way, as it's conceptionally > meant for a whole different purpose: it operates on screen level. > It has no idea windows, server-side resource objects, etc. > Simply lacks this information. Indeed, VNC is a bandwidth hog and not really useful for different media types. A good talk to watch on all of this remoting stuff is the talk that Adam Jackson gave at LCA a few weeks ago [1], he's working on SPICE and describes quite well all the different problems and solutions to doing display remoting. Regards, Sam [1] http://linuxconfau.blip.tv/file/4693225/ > > > cu > -- > -- > Enrico Weigelt, metux IT service -- http://www.metux.de/ > > phone: +49 36207 519931 email: weig...@metux.de > mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 > -- > Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme > -- > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Sam Spilsbury ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Type safety of protocol calls
* Chris Morgan schrieb: > Maybe we could compile the c code as c++? Wouldn't require using > classes etc but would provide better type conversion checking. Actually, I'm currently in process of building several packages with an C++ (instead of C) compiler for analysis and cleanup purposes (eg. it enforced you to write parameter types before the parameter names, and other things I'd consider much cleaner). This approach might turn out as a fine QM tool ... cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: What's wrong with wayland?
On Sun, Feb 20, 2011 at 2:35 PM, Enrico Weigelt wrote: > * Marty Jack schrieb: > >> If remote clients is your thing, instead of forecasting doom >> because the old way may not work any more, first off, nothing >> stops someone from writing a thing that listens on port 6000 >> and acts just like a remote X server only it is a Wayland >> client, and second off, > > At this point, I fail to see the real benefit of Wayland, at > least from user or infrastructure view. (yes, having the hw > and composition part of the fat Xserver IMHO is a good thing > from sw-architectural view). > > One thing that annoys me is that the current design papers > explicitly take remoting out of the picture (almost declares > that obsolete or tells people to use insufficient workarounds > like VNC) and delegates a lot of things to individual clients > (so in the end introducing massive code and data duplications). There is an excellent emerging protocol for app remoting called HTML5. Code your app as an HTML5 app and problem solved. Nothing stops you from running both the client and server parts on a single machine. Gee - we just did that with the Xserver. If you do this your app is cross platform and also able to be immediately used in a cloud environment. HTML5 graphics can do everything desktop graphics do so there is no real loss in changing your coding model. Coding for the existing desktop model is backwards looking. HTML5 is building for the future. Look at ChromeOS. HTML5 based apps are the only kind of app that you can run. If you need extreme graphics speed check out Google's NaCl project. > >> nothing stops someone from redesigning and rethinking what >> the proper remote protocol is, > > I'd start with an proper model before starting to think about > an specific protocol: why should a client still be responsible > for drawing, instead of just describing what it wants to have > displays (eg. an scene graph or something more hi-level) ? > > Typical GUI applications have concepts of windows (and windows > within windows), widgets, etc. Those are all objects that can > be described formally and rendered in a hi-level display server. > This also would allow large savings of now heavily duplicated > code and data in the individual clients. > > 8 1/2 could be a interesting conceptional starting point. > >> using modern encryption and compression techniques and whatever >> else is needed to get a VNC like solution that performs well >> and is secure. > > VNC can not be done right that way, as it's conceptionally > meant for a whole different purpose: it operates on screen level. > It has no idea windows, server-side resource objects, etc. > Simply lacks this information. > > > cu > -- > -- > Enrico Weigelt, metux IT service -- http://www.metux.de/ > > phone: +49 36207 519931 email: weig...@metux.de > mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 > -- > Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme > -- > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Jon Smirl jonsm...@gmail.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Some of my thoughts on input for wayland
* Bill Spitzak schrieb: > I'm wary of a "config" file the window manager reads. What users want to do > is go into the application and run some control panel that says "now the > shortcut X+Y+Z does this" and it starts happening, and they can then change > their mind and it goes back to the way it was before. Having to write a > file to do this and signal the compositor that it changed does not sound > like a very nice design. What if we're writing to a file *in* the compositor ? (IOW: making it a fileserver). cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Running on bare hardware
* 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 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`) cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: What's wrong with wayland?
* Sam Spilsbury schrieb: > But the core part of X11 is that it only managed windows and > pixmaps which were owned by clients running in different processes > over a network protocol. The window manager and compositors are > implemented externally, using that information from the server to > blit the graphics on to the screen and actually change the size > and position of the windows. ACK. And that is a very strong concept. It allows one to eg. choose window manager on the fly and even run it on a different host. Very handy for distributed environments. I, personally, definitively don't want to loose that, similarily as I also never want to loose the ability to run individual clients on separate hosts easily. > The key difference with wayland is two-fold. First of all, it > recognizes that server-side rendering is a bit useless and Why exactly is that useless ? Do you want all remote clients to transfer huge bitmaps for every little change on screen ? Or do you want no remote clients at all ? > Second of all, it integrates the windowmanager, compositing manager > and window server into one process(through libwayland-compositor). That's the point that annoys me: I want the window manager to remain separate and exchangable at runtime. > Wayland requires that you render to a graphics buffer on the hardware > (eg direct to memory that is accessible to the video card). So, no chance for distribution between several hosts, virtualization, etc. At this point, I'm really curious about what makes it so different from or better than Fusion ? > It is also likely that any other drawing frameworks are going to be > implemented on top of OpenGL ES since that is the most portable way > of implementing a draw-to-buffer method. What about graphics devices that don't support it ? Software rendering ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: What's wrong with wayland?
* Marty Jack schrieb: > If remote clients is your thing, instead of forecasting doom > because the old way may not work any more, first off, nothing > stops someone from writing a thing that listens on port 6000 > and acts just like a remote X server only it is a Wayland > client, and second off, At this point, I fail to see the real benefit of Wayland, at least from user or infrastructure view. (yes, having the hw and composition part of the fat Xserver IMHO is a good thing from sw-architectural view). One thing that annoys me is that the current design papers explicitly take remoting out of the picture (almost declares that obsolete or tells people to use insufficient workarounds like VNC) and delegates a lot of things to individual clients (so in the end introducing massive code and data duplications). > nothing stops someone from redesigning and rethinking what > the proper remote protocol is, I'd start with an proper model before starting to think about an specific protocol: why should a client still be responsible for drawing, instead of just describing what it wants to have displays (eg. an scene graph or something more hi-level) ? Typical GUI applications have concepts of windows (and windows within windows), widgets, etc. Those are all objects that can be described formally and rendered in a hi-level display server. This also would allow large savings of now heavily duplicated code and data in the individual clients. 8 1/2 could be a interesting conceptional starting point. > using modern encryption and compression techniques and whatever > else is needed to get a VNC like solution that performs well > and is secure. VNC can not be done right that way, as it's conceptionally meant for a whole different purpose: it operates on screen level. It has no idea windows, server-side resource objects, etc. Simply lacks this information. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Mesa-dev] [PATCH] Adding -enable-egl-dri2 option. Happy Chinese Spring Festival!
2011/2/6 Arthur Zhu :
> From 7f26f3b6692a8a8061c0d817388505d4190e88a0 Mon Sep 17 00:00:00 2001
> From: Arthur Zhu
> Date: Mon, 7 Feb 2011 13:50:55 +0800
> Subject: [PATCH] Adding --enable-egl-dri2-x11&drm option.
>
> ---
> configure.ac | 34 +-
> 1 files changed, 21 insertions(+), 13 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 46938f4..18c2731 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1091,6 +1091,20 @@ if test "x$enable_egl" = xno; then
> AC_MSG_ERROR([cannot enable OpenVG without EGL])
> fi
> fi
> +
> +AC_ARG_ENABLE([egl-dri2-x11],
> + [AS_HELP_STRING([--enable-egl-dri2-x11],
> + [enable EGL egl-dri2-x11 driver,
> + Just omits libudev package checking. @<:@default=disabled@:>@])],
> + [enable_egl_dri2_x11="$enableval"],
> + [enable_egl_dri2_x11=no])
> +
> +AC_ARG_ENABLE([egl-dri2-drm],
> + [AS_HELP_STRING([--enable-egl-dri2-drm],
> + [enable EGL egl-dri2-drm driver. @<:@default=disabled@:>@])],
> + [enable_egl_dri2_drm="$enableval"],
> + [enable_egl_dri2_drm=no])
> +
$enable_egl_dri2_{x11,drm} should be "auto" by default, followed by
if test "x$mesa_driver" = "xdri"; then
if test "x$enable_egl_dri2_x11" = "xauto"; then
enable_egl_dri2_x11=yes
fi
if test "x$enable_egl_dri2_drm" = "xauto"; then
enable_egl_dri2_drm=yes
fi
fi
The check for $mesa_driver can be omitted below.
> if test "x$enable_egl" = xyes; then
> SRC_DIRS="$SRC_DIRS egl"
> EGL_LIB_DEPS="$DLOPEN_LIBS -lpthread"
> @@ -1100,20 +1114,14 @@ if test "x$enable_egl" = xyes; then
> if test "$mesa_driver" = xlib -o "$mesa_driver" = dri; then
> EGL_DRIVERS_DIRS="glx"
> fi
> -
> - if test "$mesa_driver" = dri; then
> + if test "x$enable_egl_dri2_x11" = xyes -o "x$enable_egl_dri2_drm" =
> xyes -a "$mesa_driver" = dri; then
> # build egl_dri2 when xcb-dri2 is available
> - PKG_CHECK_MODULES([XCB_DRI2], [x11-xcb xcb-dri2 xcb-xfixes],
> - [have_xcb_dri2=yes],[have_xcb_dri2=no])
> - PKG_CHECK_MODULES([LIBUDEV], [libudev > 150],
> - [have_libudev=yes],[have_libudev=no])
> -
> - if test "$have_xcb_dri2" = yes; then
> - EGL_DRIVER_DRI2=dri2
> - DEFINES="$DEFINES -DHAVE_XCB_DRI2"
> - if test "$have_libudev" = yes; then
> - DEFINES="$DEFINES -DHAVE_LIBUDEV"
> - fi
> + PKG_CHECK_MODULES([XCB_DRI2], [x11-xcb xcb-dri2 xcb-xfixes])
> + EGL_DRIVER_DRI2=dri2
> + DEFINES="$DEFINES -DHAVE_XCB_DRI2"
> + if test "x$enable_egl_dri2_drm" = xyes; then
> + PKG_CHECK_MODULES([LIBUDEV], [libudev > 150])
> + DEFINES="$DEFINES -DHAVE_LIBUDEV"
> fi
> fi
>
> --
> 1.7.0.4
>
>
> Arthur
>
>
> 2011/2/3 Kristian Høgsberg
>>
>> On Thu, Feb 3, 2011 at 9:15 AM, Dan Nicholson wrote:
>> > On Thu, Feb 3, 2011 at 5:26 AM, Arthur Zhu
>> > wrote:
>> >>
>> >> Thanks your good suggestions.
>> >>
>> >> Arthur
>> >>
>> >>
>> >> From 7034307045f1d334e25adf7f739c5144a9afcb46 Mon Sep 17 00:00:00 2001
>> >> From: Arthur Zhu
>> >> Date: Thu, 3 Feb 2011 21:12:04 +0800
>> >> Subject: [PATCH] Adding -enable-egl-dri2 option.
>> >>
>> >> ---
>> >> configure.ac | 26 --
>> >> 1 files changed, 12 insertions(+), 14 deletions(-)
>> >>
>> >> diff --git a/configure.ac b/configure.ac
>> >> index 46938f4..bd50767 100644
>> >> --- a/configure.ac
>> >> +++ b/configure.ac
>> >> @@ -1091,6 +1091,12 @@ if test "x$enable_egl" = xno; then
>> >> AC_MSG_ERROR([cannot enable OpenVG without EGL])
>> >> fi
>> >> fi
>> >> +
>> >> +AC_ARG_ENABLE([egl-dri2],
>> >> + [AS_HELP_STRING([--enable-egl-dri2],
>> >> + [enable EGL egl-dri2 driver @<:@default=disabled@:>@])],
>> >> + [enable_egl_dri2="$enableval"],
>> >> + [enable_egl_dri2=no])
>> >> if test "x$enable_egl" = xyes; then
>> >> SRC_DIRS="$SRC_DIRS egl"
>> >> EGL_LIB_DEPS="$DLOPEN_LIBS -lpthread"
>> >> @@ -1100,21 +1106,13 @@ if test "x$enable_egl" = xyes; then
>> >> if test "$mesa_driver" = xlib -o "$mesa_driver" = dri; then
>> >> EGL_DRIVERS_DIRS="glx"
>> >> fi
>> >> -
>> >> - if test "$mesa_driver" = dri; then
>> >> + if test "x$enable_egl_dri2" = xyes -a "$mesa_driver" = dri;
>> >> then
>> >> # build egl_dri2 when xcb-dri2 is available
>> >> - PKG_CHECK_MODULES([XCB_DRI2], [x11-xcb xcb-dri2
>> >> xcb-xfixes],
>> >> - [have_xcb_dri2=yes],[have_xcb_dri2=no])
>> >> - PKG_CHECK_MODULES([LIBUDEV], [libudev > 150],
>> >> - [have_libudev=yes],[have_libudev=no])
>> >> -
>> >> - if test "$have_xcb_dri2" = yes; then
>> >> - EGL_DRIVER_DRI2=dri2
>> >> - DEFINES="$DEFINES -DHAVE_XCB_DRI2"
>>
