Skip to content

GitLab

Switch branch/tag
  1. 14 Jun, 2013 1 commit
  3. 07 Jun, 2013 1 commit
  5. 05 Jun, 2013 9 commits
  7. 28 May, 2013 2 commits
    • Alexander Larsson's avatar
      protocol: Modes are specified in HW pixels · b6930889
      Alexander Larsson authored 
      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).
      b6930889
    • Alexander Larsson's avatar
      protocol: Use signed int for scale values · e782dbec
      Alexander Larsson authored 
      We usually use signed ints for things like this, to avoid
issues C sign coersion.
      e782dbec
  9. 22 May, 2013 3 commits
    • Alexander Larsson's avatar
      protocol: Support scaled outputs and surfaces · d68c7d8a
      Alexander Larsson authored 
      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.
      d68c7d8a
    • Alexander Larsson's avatar
      protocol: Allow output changes to be treated atomically · 911c0684
      Alexander Larsson authored 
      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.
      911c0684
    • Peng Wu's avatar
      protocol: Fix documentation typo · 5144cf62
      Peng Wu authored
      5144cf62
  11. 08 May, 2013 1 commit
  13. 07 May, 2013 1 commit
    • Kristian Høgsberg's avatar
      Remove input structs · e920572e
      Kristian Høgsberg authored 
      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).
      e920572e
  15. 29 Apr, 2013 1 commit
  17. 18 Apr, 2013 2 commits
  19. 16 Apr, 2013 2 commits
  21. 04 Apr, 2013 7 commits
  23. 03 Apr, 2013 10 commits