Rather than say schedule the coordinate change I think it would be
clearer to say something like this:
This changes the scheduled coordinates of the sub-surface.
The next wl_surface.commit on the parent surface will reset the
sub-surface's position to the scheduled coordinates.
The initial
If a feature remains in N minor versions the programmer would have to
put in N compatable-with macros to enable it. They would also have to
update the code every time a new minor version comes out (or just
predict a number of minor versions into the future and put in a bunch of
calls to this).
From the Kronos description:
interval is silently clamped to minimum and maximum implementation
dependent valuesbefore being stored; these values are defined by
EGLConfig attributes EGL_MIN_SWAP_INTERVAL and EGL_MAX_SWAP_INTERVAL
respectively.
I think wayland egl can just clamp to 0,1 (or
I believe what he is trying to achieve is this display of two desktops
on the same screen, such as for previewing desktop switching, or perhaps
for an intermediate state of a swipe from one desktop to another:
+--+ +---+
| +| | |
|
Ping Cheng wrote:
graphics tablets:
* extended axis event support
* tool change notification (could be just button events? not sure)
Will tool id, serial number, and tool type be supported here?
Shouldn't each tool be a different pointing device? It at least needs to
know which
There really should not be a fullscreen layer which is what is causing
this problem. layers are imho a mistake except for the desttop and the
mouse cursor.
What I think needs to happen:
Fullscreen, normal windows, and panels can be arranged in any stacking
order, except the compositor
Peter Hutterer wrote:
this has so many more cases where it won't work correctly from the user's
POV that it's likely easier to just have an easily accessible way of
switching between absolute and relative mode.
I really feel this automatic switch will work perfectly and would be a
huge
Jasper St. Pierre wrote:
Hiding windows should not have any influence over the client, as many
desktop environments, including Weston, want to show live previews for
minimized or hidden windows in alt-tab or Expose-alikes.
Also, it matches user expectations. If the user clicks minimize on a
Manuel Bachmann wrote:
Hi Bill, and thanks a lot for sharing your thoughts,
GTK+ seems to have an impl, so I will check what it does.
I think it may be trying to use X window groups which is an example of
an excessively complex api to try to solve this. It has not worked and
Gimp is now
Jasper St. Pierre wrote:
A simple problem is a floating window shared by two main windows.
Can you give a concrete example of such a case? Not because I'm assuming
none exist, but because I want a specific example to evaluate and think
about.
A toolbox over a painting program that has
Jasper St. Pierre wrote:
A toolbox over a painting program that has two documents open.
So, what is the expected behavior here exactly? There's a minimize
button on both of the content window's decorations, and clicking on one
should minimize all three windows?
Clicking minimize of
Emilio Pozuelo Monfort wrote:
Hi Bill,
On 30/01/14 23:33, Bill Spitzak wrote:
There really should not be a fullscreen layer which is what is causing this
problem. layers are imho a mistake except for the desttop and the mouse
cursor.
What I think needs to happen:
Fullscreen, normal
I was wondering if my problem is not something anybody else is seeing.
I have Wayland X11 compositor running. This is on an Nvidia card with
Nvidia drivers and therefore only SHM clients work. All other Wayland
apps either work correctly or they fail immediately because they require
EGL.
On 02/05/2014 09:21 AM, Jasper St. Pierre wrote:
What compositor are you using
The X11 compositor you get when you run wayland under X.
My X system is stock Ubuntu running Unity, though I suspect that has
little to do with it.
and how did you build Xwayland?
There is xwayland inside
-wayland
and have everything work.
On Wed, Feb 5, 2014 at 12:46 PM, Bill Spitzak spit...@gmail.com
mailto:spit...@gmail.com wrote:
On 02/05/2014 09:21 AM, Jasper St. Pierre wrote:
What compositor are you using
The X11 compositor you get when you run wayland under X.
My X
Got it a little further, but now wayland does not run at all.
I was able to compile mesa with the following (adding
--with-dri-drivers= --disable-dri3):
./autogen.sh --prefix=$WLD --enable-gles2 --disable-gallium-egl \
--with-egl-platforms=wayland,x11,drm --enable-gbm \
In order to try to compile the new xserver for wayland, I updated mesa
to the latest git version, and now wayland does not work at all!
Considering it has worked for a long time I would like to try to fix
this, it is really unfortunate.
It does appear the problem is in egl gallium and it's
Pekka Paalanen wrote:
This algorithm aims to start showing an update between t-T/2 and t+T/2,
which means that presentation may occur a little early or late, with
an average of zero. Another option would be to show the update between
t and t+T, which would mean that presentation would be always
I need to read the rest of the responses, but this does *not* sound like
what I think is necessary. There should not be any need for an event
saying you have been minimized as this should never happen without the
client first requesting it.
As I see it, if the compositor decides to minimize
Okay this sounds like it is going in exactly the wrong direction.
What I am trying to do is restore the ability to use overlapping windows
which was broken in approximatly 1990 when everybody started doing
click raises (when even then it was *trivial* for a client to raise
it's own windows),
I would think configure request is going to need to provide this
information. Otherwise the compositor cannot do tabbed or tiled layouts
were it wants a window to resize without the client requesting it.
Then again perhaps it is ok for compositor-initiated resizing to always
produce the same
sardemff7+wayl...@sardemff7.net wrote:
First, a compositor may have no mechanism of “minimization”, so it must
not be forced to obey such a request with no meaning for it.
I agree the compositor does not have to obey the minimize request. I
think I am not explaining things clearly: *BOTH*
sardemff7+wayl...@sardemff7.net wrote:
Not sure why you want to limit it like this. I certainly would like
the ability to minimized dialog windows.
If you want a dialog window to be minimized, then it makes even more
sense to allow minimizing multiple surfaces. The client could want to
sardemff7+wayl...@sardemff7.net wrote:
I was suggesting that one method of minimizing multiple surfaces
would be for the client to arrange them all as children of one of
them and then minimize the parent. The primary purpose is so the
compositor/taskbar knows all those windows are related, for
I would greatly prefer if the demo Wayland compositor did not enforce
active on top. This assumption is causing endless grief, it makes drag
drop impossible and overlapping windows useless.
A lower window that wants a popup or transient should end up with the
popup or transient above any
I think I was wrong to say the display time would always be = to the
time the client specifies. It would be rounded just like you are saying,
the nearest start time would be rounded to the nearest output frame
start time and thus could be earlier.
I tend to think of a frame as covering a
Mark Thomas wrote:
I've pushed some doc updates to the protocol.xml file my git repo. But
in terms of Jonas Ådahl's proposal, my protocol works the other way round:
A creates a main surface
A creates a hole on that surface and sets its position and size
A gets the uid (handle) from the
On 02/18/2014 11:09 AM, Mark Thomas wrote:
I think the above description can be greatly simplified by removing
the hole and plug objects and just using a subsurface:
A creates a main surface
A creates a subsurface for the hole
A gets the uid of the subsurface from the compositor
A passes
Mark Thomas wrote:
I suggest you read up on the subsurface protocol. A subsurface object
takes two surface arguments, one is the parent to attach to, and the
other is the child surface that becomes the subsurface.
You are right, the actual object I wanted to send from A to B is a
Okay, a bit more luck, in that I can compile weston.
I mostly discovered that there are parts of mesa you just cannot turn
off, no matter how much you are certain they are not used. Mesa
internally has calls into various functions in these modules from others
so they cannot be removed.
My
On 02/19/2014 02:42 AM, Pekka Paalanen wrote:
Besides, it's not that much code, really. clients/nested.c is 1140
lines, and that includes support for EGL-passthrough so that
nested-client.c can efficiently use GLES rendering.
Sample code like this does help a lot.
I would still be worried
This makes it impossible for a privileged client to distribute it's
privledges to more than one subprocess, or to both itself and a subprocess.
That is why I would prefer an id approach, which I still think would
be a good way for parent processes to send objects to children, even if
it is
Seema Singh wrote:
Focus window pid is used for below check:
1. If focus window APP is not a NFC APP then launch the NFC APP
2. If already launched but not in focus then bring it to foreground.
The NFC app should always launch, but then it should just check if it is
already running, and if
How about something like this, which is my understanding:
The frame callback is sent when it is known that the last commit will
be visible on the screen. If a second commit is sent before the frame
callback it is quite possible the first commit will never be seen, as
the new one will replace
Xiong Zhang wrote:
With the help of Ander, this is the new round clone mode patchset.
It seems like there is now two different methods of getting a surface to
be seen more than once: using this clone of an output, and the views
stuff for putting a surface on more than one output.
I think
Pekka Paalanen wrote:
+wl_list_for_each(seat, ec-seat_list, link) {
+if (seat) {
+shell-seat = seat;
'seat' cannot be NULL here. It seems you are assuming that there can be
only one seat? Why?
Ideally, I agree. However I am in automotive software, and I have habit
to
Isn't Wayland differentiating between the selection and the clipboard?
The selection is changed when the user selects an object. The clipboard
is changed only when the user does a cut or copy operation.
There is also drag drop. Though in most cases this can be the same as
the selection, I
John Kåre Alsaker wrote:
On Wed, Mar 12, 2014 at 7:32 PM, Bill Spitzak spit...@gmail.com wrote:
Isn't Wayland differentiating between the selection and the clipboard?
It is not doing that at the moment. Only explicit clipboard actions
are supposed to be used.
The selection is changed when
Pekka Paalanen wrote:
+request name=set_source since=2
+ description summary=set the source rectangle for cropping
+ Set the source rectangle of the associated wl_surface. See
+ wl_viewport for the description, and relation to the wl_buffer
+ size.
+
+ If width
Pekka Paalanen wrote:
A zero-area source can theoretically exist: you sample the color
exactly at src_x,src_y and use that single color for the whole
surface.
That's an interesting interpretation, but it implies that the filters
for sampling are allowed, and in fact expected, to sample
Pekka Paalanen wrote:
The sampling really goes into hair-splitting. It depends on how you
interpret a texel image; is each pixel a solid-colored tile, or does
the color vary smoothly from texel to the next. Then you have the
source rectangle, which is divided into dst_width x dst_height pixels
There certainly should be no need to worry about multiple threads from
the same client. I think you can work on the assumption that the
programmer who wrote the client is not insane! This is the way commit
for wl_surface works, right?
The per-client pending mode is probably cleanest, but I
Niels Ole Salscheider wrote:
The color correction protocol allows to attach an ICC profile to a
surface. It also tells the client about the blending color space and
the color spaces of all outputs.
As you pointed out, it does look like this has to be done by the
compositor, because a
I think this is a good argument for having source size of zero mean
unset, just like it does for the destination size. Then you don't have
to worry about this at all.
Pekka Paalanen wrote:
From: Pekka Paalanen pekka.paala...@collabora.co.uk
Ensure, that the resulting surface size is at least
Hardening wrote:
+ if (!settings-DesktopResize) {
+ /* peer does not support desktop resize */
+ weston_log(%s: client doesn't support resizing,
closing connection\n, __FUNCTION__);
+
It would be a lot simpler to only change the sighandler when you want it
to fail, and reverse the type of test to be a success test?
On 04/11/2014 02:48 AM, Marek Chalupa wrote:
bad-buffer-test is FAIL_TEST and every assert() (or even SIGSEGV signal)
make it pass. It shouldn't be so for
Rather than this ridiculousness, it would help a lot if there was a way
to send already-decoded keysyms to clients and the input method.
Keyboard mapping on remote X has always been a disaster because of this
strange requirement that you emulate a fake piece of hardware, and it
would be nice
On 04/11/2014 01:10 PM, Hardening wrote:
I have heard that in some cases windows layouts (which are also RDP
ones) don't match exact the XKB ones :(. So the surprises can come
when using mstsc against a linux host.
Regards.
I have had it fail between different versions of Linux with very
I think he is asking how to run Wayland so that it controls more than
one monitor. This has nothing to do with how windows act once Wayland is
running.
On 04/13/2014 11:34 PM, Jasper St. Pierre wrote:
I'd imagine this is something like _NET_WM_FULLSCREEN_MONITORS, which
allows an application
It looks like the xwayland branch of xserver has disappeared:
$ git pull
Your configuration specifies to merge with the ref 'xwayland'
from the remote, but no such ref was fetched.
I tried git pull origin master but it produced lots of conflicts, it
looks like there are many changes for
It looks like the text actually has the bytes Enter at the newlines,
rather than, say, a '\n'?
On 04/18/2014 03:52 AM, Manuel Bachmann wrote:
This fixes :
https://bugs.freedesktop.org/show_bug.cgi?id=77496
Regards,
Manuel
2014-04-18 12:50 GMT+02:00 Manuel Bachmann
just did:
$ git reset --hard origin/master
and then configured it with --enable-xwayland.
This way I made it run, I hope it'll help
Regards,
Marek
On 16 April 2014 06:45, Bill Spitzak spit...@gmail.com
mailto:spit...@gmail.com wrote:
It looks like the xwayland branch of xserver has
On 04/22/2014 05:34 PM, Peter Hutterer wrote:
Config with --enable-xwayland is not working however:
checking whether to build XWin DDX... no
checking dependency style of $(CC)... none
checking for DMXMODULES... no
checking whether to build Xdmx DDX... no
checking for XWAYLANDMODULES... no
On 04/22/2014 08:08 PM, Jasper St. Pierre wrote:
It looks OK, but the upstream is at https://github.com/anholt/libepoxy
Thanks, fixing that.
I had to add --disable-glx but I succeeded in getting xserver to compile.
Like before there are a lot of bugs with the window borders. It often is
On 04/29/2014 01:07 PM, Kristian Høgsberg wrote:
I'd like to drop cairo-egl, but not in a way that makes window.c shm
only. I'd like it to use GL by default and use cairo for rendering
assets, for example, render the frame in cairo, but use gl to stretch
and scale it and composite the title
Two comments on the proposal:
1. It would seem more useful for the desktop shell to send some info
about how the client was launched in environment variables. The client
may want to do other reactions besides just placing it's window, and
this will work for clients that do not want to use the
On 05/02/2014 03:49 PM, Neil Roberts wrote:
1. It would seem more useful for the desktop shell to send some info
about how the client was launched in environment variables.
Yes, maybe it would be cleaner to agree on some protocol for the parent
process to send the information directly to the
Okay, I am trying to build wayland again, from instructions, on a new
machine.
I am stuck trying to compile mesa:
./autogen.sh --prefix=$WLD --enable-gles2 --disable-gallium-egl
--with-egl-platforms=x11,wayland,drm --enable-gbm --enable-shared-glapi
On 05/07/2014 01:47 AM, Pekka Paalanen wrote:
It is for normal windows like registered with xdg_shell where
sub-surfaces are not suitable for tooltips. A sub-surface is a part of
the window, not another window. A tooltip is not expected to change the
window geometry, but a sub-surface does
On 05/07/2014 03:04 AM, Pekka Paalanen wrote:
Maybe you forgot to set some of the environment variables from here:
http://wayland.freedesktop.org/building.html
Don't play with the foofoo_CFLAGS and foofoo_LIBS variables, it is much
better to fix pkg-config to find the right .pc files.
Thank
Sorry, what I meant was the surface id and xy location in events.
If a subsurface belongs to a different client than the parent surface,
though, does this mean the child client will get events that have an xy
position relative to the parent surface?
On 05/07/2014 11:05 AM, Jasper St. Pierre
On 05/07/2014 10:54 PM, Pekka Paalanen wrote:
This is similar to session save/restore, lacking a better term for it.
We do not even pretend to support or enable this yet. It is just yet one
more feature that the shell protocol suite for desktop should cover,
but so far no-one has done any work
On 05/08/2014 11:31 AM, Jasper St. Pierre wrote:
I don't know how you can have been on the Wayland mailing list for this
long and not grasp core Wayland protocol concepts. Clients cannot get
global surface positions, and it's been that way since day 1 six years
ago.
Yes I know that. I said
Filter sampling outside the source image can leak black into the edges
of the
desktop image. This is most easily seen by scaling the default tiled image
with this weston.ini:
# no background-image and no background-color
background-type=scale-crop
---
clients/desktop-shell.c |
On 05/09/2014 12:34 AM, Pekka Paalanen wrote:
Possibly you are reading the words save/restore literally, in that you
are imagining some blob of data stored in the compositor that is
recognized to restore the layout. However this is NOT what is wanted.
Sure, that's the first thing comes to my
On 05/09/2014 02:11 AM, Pekka Paalanen wrote:
On Thu, 08 May 2014 20:00:35 -0700
Bill Spitzak spit...@gmail.com wrote:
Filter sampling outside the source image can leak black into the edges
of the
desktop image. This is most easily seen by scaling the default tiled image
with this weston.ini
Filter sampling outside the source image can leak black into the edges of the
desktop image. This is most easily seen by scaling the default tiled image
with this weston.ini:
# no background-image and no background-color
background-type=scale-crop
---
clients/desktop-shell.c |
Thanks, it looks like that setup worked, patch sent correctly now.
On 05/09/2014 11:52 AM, Jonas Ådahl wrote:
If you are using gmail, you can just use Googles SMTP server directly.
The example configuration in the manual [0] even is a @gmail.com
address setup.
Jonas
[0]
The reason functions should not validate pointers that are supposed to
be non-NULL is because it is misleading. An if (x)... in the code is a
very very strong indicator to a programmer that x can legitimately have
a NULL value. No amount of documentation is going to change that
programmer's
The weston.ini included in weston names a background image file that
does not exist on all machines, and produces a pretty ugly blue result.
I would recommend that all the background- lines be commented out so you
get the default tiled doily pattern on all systems.
The wayland build instructions also include the building of pixman and
cairo in order to enable the cairo gl backend.
However I get the impression that weston does not use this unless a
switch --with-cairo=gl is passed to configure. Only then does it produce
calls to attempt to make a context
On 05/14/2014 11:58 PM, Pekka Paalanen wrote:
On Wed, 14 May 2014 12:56:27 -0700
Bill Spitzak spit...@gmail.com wrote:
The wayland build instructions also include the building of pixman and
cairo in order to enable the cairo gl backend.
However I get the impression that weston does not use
On 05/14/2014 11:58 PM, Pekka Paalanen wrote:
I would be ok with just dropping the Cairo build instructions.
Personally I think cairo-gl/cairo-glesv2 are not useful for Weston
demos. You lose weston-gears and the screensaver, but I think those
should be ported away from cairo-gl anyway.
I
On 05/19/2014 12:43 AM, Pekka Paalanen wrote:
Oh, in fact there would be room for quite much of splitting here, like
the pre-boxing and adding $ to commands could be a separate patch,
and therefore much easier to get in while the rest may still be
discussed.
Changes are to be split into
On 05/19/2014 12:39 AM, Pekka Paalanen wrote:
On Fri, 16 May 2014 13:43:50 -0700
spit...@gmail.com wrote:
From: spitzak spit...@gmail.com
This is based on several experimental runs on two different
Ubuntu 12.04 machines. Latest version includes instructions for
a recent update of Mesa
On 05/19/2014 11:55 PM, Pekka Paalanen wrote:
What is the target audience of the build guide?
Somebody who wants to contribute to wayland.
I have been writing Linux software in C/C++ and OpenGL for about 20
years now, including making my own autoconf scripts. I have to tell you
that these
On 05/20/2014 01:12 PM, Kristian Høgsberg wrote:
• The weston input stack was split out as a new library, libinput.
Weston can be configured to link to libinput for input but defaults
to the built in input code for now. As the libinput API
stabilizes, we'll remove the in-weston
On 05/20/2014 11:23 PM, Peter Hutterer wrote:
pkg-config has an awful lot of bugs and gnu-isms, fixing them would help:
1. If I type pkg-config --verision foo I want the version of foo. Or an
error message. Don't print the pkg-config version. Holy crap.
2. Add an option to print where it found
On 05/21/2014 02:30 AM, Pekka Paalanen wrote:
But pkg-config is *the* standard way of finding build dependencies
during a build. How can you not know about it?
I never used it before and have not encountered it until I tried to
compile freedesktop.org stuff. Configure was done by testing
On 05/21/2014 02:16 PM, Thierry Reding wrote:
While I agree with the other points, I think it's perfectly consistent
for --version to output the version of pkg-config itself. There's
--modversion if you want to query the version of a given package.
It's fine that pkg-config --version prints
- One device has 2 strips, which report on ABS_RX/RY (radial??). Min/max
are 0..4096, but the reported values are 1,2,4,8,16... So effectively
a log2 scale, or more graphically a bit shifting over a bunch of 0s,
which is somewhat more resembling to the physical action on the
On 05/21/2014 03:24 PM, Peter Hutterer wrote:
On Tue, May 20, 2014 at 07:58:59AM -0400, Jasper St. Pierre wrote:
Fedora has this built-in:
# yum install 'pkgconfig(laalaa.pc)'
And that becomes a pretty generic guide on How
to build software, so if there is a site which already explains all
On 05/22/2014 12:01 AM, Pekka Paalanen wrote:
It looks about right to me. Mesa should stay, because quite probably
many distributions do not yet enable Wayland support in it, and we
might still get development there. Xserver needs to stay, because 1.16
has not been released yet, it receives
I started out using a script somebody wrote to build on Debian. But I
had to edit it considerably as dependencies changed and eventually I
reverted to pretty much cut paste of the configure lines. It also
installed about 100 packages, many of which were not needed (either
unused or because I
On 05/21/2014 03:09 PM, Thierry Reding wrote:
On Wed, May 21, 2014 at 02:54:36PM -0700, Bill Spitzak wrote:
On 05/21/2014 02:16 PM, Thierry Reding wrote:
While I agree with the other points, I think it's perfectly consistent
for --version to output the version of pkg-config itself. There's
On 05/22/2014 09:06 AM, Bill Spitzak wrote:
Cairo was included in the guide probably because distributions had
varying configurations wrt. enabling GL or GLESv2 support, and because
the GL/GLESv2 code was new and in development. If we drop the need for
cairo-gl/glesv2, we can drop Cairo
From: Bill Spitzak wspit...@oblong.com
- Removed xtrans as it is no different than other dependencies
- Added comment from commit message about new configure line
- Fix for bug in libepoxy configure
---
building.html |2 +-
xserver.html | 51
From: Bill Spitzak wspit...@oblong.com
---
building.html | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/building.html b/building.html
index 7f0c4b4..de721b5 100644
--- a/building.html
+++ b/building.html
@@ -26,7 +26,7 @@ fails with No package 'foo
From: Bill Spitzak wspit...@oblong.com
---
building.html| 18 +++-
ubuntu12.04.html | 280 ++
2 files changed, 294 insertions(+), 4 deletions(-)
create mode 100644 ubuntu12.04.html
diff --git a/building.html b/building.html
index
From: Bill Spitzak wspit...@oblong.com
---
building.html| 84 +++---
ubuntu12.04.html |2 +-
xserver.html | 13 +
3 files changed, 75 insertions(+), 24 deletions(-)
diff --git a/building.html b/building.html
index 1a054a0
From: Bill Spitzak wspit...@oblong.com
---
wayland.css |1 +
1 file changed, 1 insertion(+)
diff --git a/wayland.css b/wayland.css
index 7f058ba..003732d 100644
--- a/wayland.css
+++ b/wayland.css
@@ -8,3 +8,4 @@ a { color: #444; }
a:hover { color: #888; }
a:visited { color: #666; }
li
From: Bill Spitzak wspit...@oblong.com
- $WLD/bin must be on the path
- Put info about system-wide install in one place
- Removed drm, libxkbcommon, pixman, cairo as distributed versions
are usable nowadays.
- Added libinput
---
building.html | 162
From: Bill Spitzak wspit...@oblong.com
Moved $XDG_RUNTIME_DIR next to it.
---
building.html| 81 +++---
ubuntu12.04.html |9 ++
2 files changed, 50 insertions(+), 40 deletions(-)
diff --git a/building.html b/building.html
index
paragraphs, and the Ubuntu
specific instructions moved to their own document, and other
changes based on comments from previous version.
On 05/23/2014 06:54 PM, Bill Spitzak wrote:
From: Bill Spitzak wspit...@oblong.com
---
wayland.css |1 +
1 file changed, 1 insertion(+)
diff --git
On 05/24/2014 12:45 AM, Pekka Paalanen wrote:
On Fri, 23 May 2014 18:57:38 -0700
Bill Spitzak spit...@gmail.com wrote:
Not sure what happened here. I tested this and it came out with a
header email, with all the patches as replies to it. But when I
did it for real the header disappared. Header
On 05/26/2014 01:40 AM, Pekka Paalanen wrote:
I put what I did so far to:
http://cgit.collabora.com/git/user/pq/wayland-web.git/log/?h=for-bill
Could you take that branch and work it into a complete new series with
your other changes?
Thanks, I will base the next version on that. I think I
, 2014 at 2:46 PM, Bill Spitzak spit...@gmail.com
mailto:spit...@gmail.com wrote:
On 05/24/2014 12:45 AM, Pekka Paalanen wrote:
- No idea why you needed the CPPFLAGS for libepoxy, I certainly
didn't need it and it should not be needed. Not to mention that
variables
On 05/25/2014 11:22 PM, Pekka Paalanen wrote:
I suppose this refers to the DRI2 protocol for X11. I believe it is an
internal detail in getting Mesa EGL working properly under X11 for
Weston itself. This doesn't apply to totally different graphics stacks
like the Nvidia proprietary.
This has
This series is v4 of the patches. It includes changes suggested by Pekka
and many other fixes.
The final patch (adding help for dependencies) still needs work to add
links to the projects home pages, but I think the first 5 patches are ok.
Sorry for the email screwup. git send-email
Please ignore these 2, they were sent by accident. Git send-email
apparently ignored by --to switch?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
1 - 100 of 1326 matches
Mail list logo
