I got a little over-eager with my sanity checks and didn't realize that the
client uses wl_map_insert_at to mark objects as zombies when they come from
the server-side.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
In order to use the second-lowest bit of each pointer in wl_map for the
WL_MAP_ENTRY_LEGACY flag, every pointer has to be a multiple of 4. This
was a good assumption, except with WL_ZOMBIE_OBJECT. This commit creates
an actual static variable to which WL_ZOMBIE_OBJECT now points. Since
things are only every compared to WL_ZOMBIE_OBJECT with "==" or "!=", the
only thing that matters is that it is unique.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
The implementation in this commit allows for one bit worth of flags. If
more flags are desired at a future date, then the wl_map implementation
will have to change but the wl_map API will not.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
The original wl_map implementation did no checking to ensures that ids fell
on the correct side of the WL_SERVER_ID_START line. This meant that a
client could send the server a server ID and it would happily try to use
it. Also, there was no distinction between server-side and client-side in
wl_map_remove. Because wl_map_remove added the entry to the free list
regardless of which side it came from, the following set of actions would
break the map:
1. Client creates a bunch of objects
2. Client deletes one or more of those objects
3. Client does something that causes the server to create an object
Because of the problem in wl_map_remove, the server would take an old
client-side id, apply the WL_SERVER_ID_START offset, and try to use it as a
server-side id regardless of whether or not it was valid.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Modes are mainly meant to be used in coordination with fullscreen in
DRIVER mode, by e.g. games. For such games what they generally want
is to match some hardware mode and resize their window for that. We
don't really need to complicate this with the scaling. So, we
keep the resolutions in HW pixels, and drop the SCALED flag (as it
is now useless).
This lets you just create e.g an 800x600 buffer of scale 1 and
fullscreen that, ignoring the output scaling factor (although you can
of course also respect it and create a 400x300 surface at scale 2).
Conceptually the mode change is treated like a scaling which overrides
the normal output scale.
The only complexity is the FILL mode where it can happen that the user
specifies a buffer of the same size as the screen, but the output has scale
2 and the buffer scale 1. Just scanning out this buffer will work, but
effectively this is a downscaling operation, as the "real" size of the surface
in pels is twice the size of the output. We solve this by allowing FILL to
downscale (but still not upscale).
This adds the wl_surface.set_buffer_scale request, and a wl_output.scale
event. These together lets us support automatic upscaling of "old"
clients on very high resolution monitors, while allowing "new" clients
to take advantage of this to render at the higher resolution when the
surface is displayed on the scaled output.
It is similar to set_buffer_transform in that the buffer is stored in
a transformed pixels (in this case scaled). This means that if an output
is scaled we can directly use the pre-scaled buffer with additional data,
rather than having to scale it.
Additionally this adds a "scaled" flag to the wl_output.mode flags
so that clients know which resolutions are native and which are scaled.
Also, in places where the documentation was previously not clear as to
what coordinate system was used this was fleshed out.
It also adds a scaling_factor event to wl_output that specifies the
scaling of an output.
This is meant to be used for outputs with a very high DPI to tell the
client that this particular output has subpixel precision. Coordinates
in other parts of the protocol, like input events, relative window
positioning and output positioning are still in the compositor space
rather than the scaled space. However, input has subpixel precision
so you can still get input at full resolution.
This setup means global properties like mouse acceleration/speed,
pointer size, monitor geometry, etc can be specified in a "mostly
similar" resolution even on a multimonitor setup where some monitors
are low dpi and some are e.g. retina-class outputs.
This add a wl_output.done event which is send after every group
of events caused by some property change. This allows clients to treat
changes touching multiple events in an atomic fashion.
Looking at the functionality in the server library, it's clear (in
hindsight) that there are two different "things" in there: 1) The IPC
API, that is, everything that concerns wl_display, wl_client,
wl_resource and 2) and half-hearted attempt at sharing input code and
focus logic that leaves a lot of problematic structs in the API
surface, only to share less than 1000 lines of code.
We can just move those input structs and helper functions into weston
and cut libwayland-server down to just the core server side IPC API.
In the short term, compositors can copy those structs and functions
into their source, but longer term, they're probably better off
reimplementing those objects and logic their native framework
(QObject, GObject etc).
This requires that doxygen is run before the man target so find can actually
find the man pages.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Originally written Tiago Vignatti <tiago.vignatti@intel.com>
Some modifications to adjust for previously merged conflicting patches and link
to the sections (instead of <emphasis>).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The only difference between the server and client xml files is the
directories and files being named *server* and *client*, respectively. Add a
new make target to get that process done to avoid duplication
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Same as WaylandClientAPI.xml we now also generate WaylandServerAPI.xml for
publication. Most of this hunk is just adding a client/ or server/ into the
xml path to keep the two separate.
The change in wayland.doxygen now causes a standard doxygen call to not
generate anything - what is generated is specified through the options
passed by make.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
[re-run of search/replace after rebasing]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Fix summary for wl_touch::motion, extend summary for wl_touch::down to match
up/motion a bit better.
Fix a typo in wl_touch, and claim that it's zero or more update events, not
one or more.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If an unknown id is deleted then the lookup in the map will return NULL and
so we should avoid dereferencing that.
As this is unexpected behaviour log a message about the problem too.
This sure is ugly - we feed output of publican -v into bc to compare
against minimum required version, 2.8. That's bad enough, but when
publican suddenly report 3.0.0, bc starts complaining...
Use sed to filter out 3.0 from the 'version=3.0.0' output from publican
instead. Seem a little more robust, but it's just a matter of time before
something else breaks this flaky setup.
Hey, publican, how about shipping .pc files?
This directory was called Wayland during my early tries with publican where
the source layout was different and it needed to be set to the same name as
the publican output directory. This reason doesn't exist anymore, so re-name
it to publican to make it more obvious what's hiding in here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Create client-side and server-side man pages from doxygen. The doxygen
config options are virtually the same as for the XML output, but we do pass
in the specific options via stdin.
WL_EXPORT is predefined to the empty string, it makes the man page look
confusing and provides no value here anyway. This applies for both xml and
man output.
JAVADOC_AUTOBRIEF is disabled for man pages, the formatting in the resulting
man page is IMO hard to read.
Most of the server man pages are virtually empty, there's just not enough
documentation in the source files.
Interesting issue: the usage of @code in the protocol to reference the
parameter breaks the expansion of WL_EXPORT, thus leaving us with WL_EXPORT
in all the man pages.
Presumably this is an issue with doxygen interpreting this as a @code
command, but I already wasted enough time narrowing this down.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Remove "mice, for example", it's described in the wl_pointer interface in
detail. And remove space before the full stop.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A bunch of changes to the xsl transformation stylesheet to make Chapter 4
(Client API) look nicer and more readable.
Main changes:
- function synopsis listed
- lists for parameters and return values
- long function descriptions
- misc other hooks for "see also", "note", etc
The long description is a sore point. doxygen xml output is difficult to
parse with the output being in the form of
<detailed description>
<para>
<parameterlist> .... </parameterlist>
<simplesect kind="return">... </simplesect>
First paragraph of long description
</para>
<para>
Second paragraph of long <sometag>description</sometag>
</para>
</detaileddescription>
So we need to ignore parameterlist and simplesect, but extract the text from
everything else. Any improvements on that welcome.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The reason this directory exists is because we need to copy it into
$builddir so we can combine it with generated sources (we can't pass
multiple source paths into publican).
So instead of having en_US, renamed to en-US stop the confusion and rename
the sources to "sources". That gets copied to en-US which will then contain
the actual output.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This makefile is a bit hard to read due to some publican requirements and
the need to generate some files through XSLT. Explain the lot, so that those
looking at this roughly know what will hit them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
I found the comment a bit confusing and it's quite hard to read. re-explain
with a simple step-by-step list
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Rename Overview.xml to Introduction.xml, reflecting the previous commit.
Organize also Wayland.xml order of the includes.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
