Re: More problems building xserver
If you have the binary packages, this is obviously quicker, but I found that the easiest thing to do is to google the name plus "source code" and I usually found the source. I stuff all the deps into /opt/wayland which wound up (for most packages) to be quicker than tracking down the right vers of pre-build binaries. Fred On Sun, Mar 3, 2013 at 10:08 PM, Bill Spitzak wrote: > With the newest version I am able to get wayland and weston to compile to > working forms, but attempting to compile xserver fails. > > I am using a slightly modified version of this to compile: > http://www.chaosreigns.com/wayland/buildscript/ > > The script is attempting to build the xwayland-1.12 branch of > git://anongit.freedesktop.org/xorg/xserver. > > xserver configure fails with this error: > > Requested 'xtrans >= 1.2.7' but version of XTrans is 1.2.6 > No package 'xineramaproto' found > > I'm guessing that these two packages also need to be compiled, but have not > had any luck in guessing the git repository names. It is also possible the > wrong xserver branch is being used? > > This is not a huge deal but I did get the x server to work once, and it > would be nice to test it against any window management experiements. > ___ > 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: Weston SDK
Why not have an external api which does not change? Surely there is functionality that plugin authors will want which will not change? I know that one objection is that there's the question of who is going to maintain the glue b/w the external and internal. Perhaps we can leave that to the plugin authors... Sincrerely, Fred >> Now, I don't want this to slow down what we can do with weston >> internals, so this won't be stable API across major releases for the >> forseeable future. But for a stable branch we should be able to avoid >> breaking the plugin API. For 1.0 for example, we haven't changed the >> API or ABI at all. >> >> Another caveat is that this doesn't imply that the exported API is >> particular useful or coherent. I think what we have is fairly decent >> though, it's just that we never developed it with an eye to be an >> external, self-contained API. So we may be exposing too little or too >> much or there may be broken or inconsitent stuff in there. But I >> think the first step towards working this out is to try to expose the >> API and just be careful about not promising too much in >> terms of usefulness or stability initially. > > > Thanks, > pq > ___ > 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
qt5 waylnd support
I have compiled wayland from git as well as qt5 under LFS 7.2 using the instructions from LFS to get the dependencies installed (into /opt/wayland) as well as the wayland and qt5 from git instructions respectively. I have a working weston system and I can run the demos for qt5, but the menus do not work. The cursor (pointer) never changes from a stop watch. The applications are a mix of usable and not. Here's some debug spew: Qml debugging is enabled. Only use this in a safe environment! Using Wayland-EGL This plugin does not support propagateSizeHints() This plugin does not support raise() This plugin does not support raise() This plugin does not support grabbing the keyboard This plugin does not support raise() Any ideas on how to get the last mile done, the menus working and so on. Any info you need to help with this? I'm willing to make changes on my system for better testing. Sincerely, Fred Ollinger ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
