[PATCH wayland-protocols v3] text-input: Add v3 of the text-input protocol

This new protocol description is a simplification over v2. - All pre-edit text styling is gone. - Pre-edit cursor can span characters. - No events regarding input panel (OSK) state nor covered rectangle. Compositors are still free to handle situations where the keyboard focus rectangle is

Re: [PATCH wayland-protocols v4] unstable: add xdg-toplevel-decoration protocol

On 2018-04-13 4:59 PM, Jonas Ådahl wrote: > Neither these need the "set_mode" or "preferred_mode" stuff. I don't think I'm following. I wonder if you have time to write up a proposed revision to the patch? > > Clients have an arbitrary surface in which they can render whatever they > > want,

Re: [PATCH wayland-protocols v4] unstable: add xdg-toplevel-decoration protocol

On Fri, Apr 13, 2018 at 10:48:56AM -0400, Drew DeVault wrote: > On 2018-04-13 4:35 PM, Jonas Ådahl wrote: > > Is this the consensus as well? Because if it should be possible, there > > are those things I mentioned to consider regarding capabilities. A > > potential mode could for example be to

Re: [PATCH wayland-protocols v4] unstable: add xdg-toplevel-decoration protocol

On 2018-04-13 4:35 PM, Jonas Ådahl wrote: > Is this the consensus as well? Because if it should be possible, there > are those things I mentioned to consider regarding capabilities. A > potential mode could for example be to outsource drawing shadow or > something. This use-case is valid, but

Re: [PATCHv3] Add name event to xdg-output

On 2018-04-13 4:16 PM, Jonas Ådahl wrote: > If that is the case, I'd rather we introduced data that has actual > meaning, like something similar to "connector" (even though connector is > the wrong thing here since an "xdg_output" might not have one, maybe, > something that doesn't identify the

Re: [PATCH wayland-protocols v4] unstable: add xdg-toplevel-decoration protocol

On Fri, Apr 13, 2018 at 10:03:11AM -0400, Drew DeVault wrote: > On 2018-04-13 3:56 PM, Jonas Ådahl wrote: > > What is the purpose of making the compositor changing the "preferred" > > mode? If we would make the assumption that a compositor stays the same > > during the whole session as in it'll

[PATCH] xdg-shell: add enums for tiled window state to toplevel configure

this adds implementation from a related discussion long ago in which it was decided that it would be useful for clients to know if/where their windows were tiled so that various behaviors and visuals could be modified to improve UX a window which is e.g., tiled on the right side of the screen

Re: [PATCHv3] Add name event to xdg-output

On Fri, Apr 13, 2018 at 10:05:39AM -0400, Drew DeVault wrote: > On 2018-04-13 4:02 PM, Jonas Ådahl wrote: > > > - A client using fullscreen-shell could offer the user a list of outputs > > > by name to fullscreen on > > > > I think this would need something different, an actual "human

Re: [PATCH weston v6 00/73] Head-based output configuration API a.k.a clone mode infrastructure

On Thu, 12 Apr 2018 12:09:26 +0200 Daniel Stone wrote: > Hi Pekka, > > On 16 February 2018 at 15:56, Pekka Paalanen wrote: > > here is the v6 of the shared-CRTC clone mode series. Since v5, quite > > many patches have been extracted from this series,

Re: [PATCHv3] Add name event to xdg-output

On 2018-04-13 4:02 PM, Jonas Ådahl wrote: > > - A client using fullscreen-shell could offer the user a list of outputs > > by name to fullscreen on > > I think this would need something different, an actual "human friendly" > name, like 'Dell 24"' or 'Builtin monitor'. If you'd have strings

Re: [PATCH wayland-protocols v4] unstable: add xdg-toplevel-decoration protocol

On 2018-04-13 3:56 PM, Jonas Ådahl wrote: > What is the purpose of making the compositor changing the "preferred" > mode? If we would make the assumption that a compositor stays the same > during the whole session as in it'll either always prefer or not prefer > dealing with decorations, and we

Re: [PATCHv3] Add name event to xdg-output

On Wed, Apr 11, 2018 at 08:35:34AM -0400, Drew DeVault wrote: > On 2018-04-11 9:17 AM, Philipp Kerling wrote: > > maybe I missed it at some point in the discussion (sorry if that is the > > case), but what is your use case for the "name?" What are clients > > expected to use it for? > > This is

Re: [PATCH wayland-protocols v4] unstable: add xdg-toplevel-decoration protocol

On Sat, Mar 24, 2018 at 07:08:15AM -0400, Simon Ser wrote: > This adds a new protocol to negotiate server-side rendering of window > decorations for xdg-toplevels. This allows compositors that want to draw > decorations themselves to send their preference to clients, and clients that > prefer

Re: [PATCH] xdg-shell: add enums for tiled window state to toplevel configure

On Tue, Apr 10, 2018 at 09:05:28AM -0400, Mike Blumenkrantz wrote: > this adds implementation from a related discussion long ago in which > it was decided that it would be useful for clients to know if/where their > windows were tiled so that various behaviors and visuals could be modified > to

Re: [PATCHv3] Add name event to xdg-output

On Tue, 10 Apr 2018 20:27:55 -0400 Drew DeVault wrote: > Signed-off-by: Drew DeVault > Reviewed-by: Simon Ser > --- > This version clarifies the uniqueness constraint, mapping of names to > wl_outputs, and persistence between sessions. > >

Re: Wayland presentation extension (video protocol) WIP after RFCv2

Hi, On 13 April 2018 at 12:29, Michel Dänzer wrote: > On 2018-04-13 11:43 AM, Daniel Stone wrote: >> On 13 April 2018 at 10:17, Michel Dänzer wrote: >>> Also, both higher-level APIs I know of which allow the application to >>> specify a target timestamp

Re: Wayland presentation extension (video protocol) WIP after RFCv2

On 2018-04-13 11:43 AM, Daniel Stone wrote: > On 13 April 2018 at 10:17, Michel Dänzer wrote: > >> Also, both higher-level APIs I know of which allow the application to >> specify a target timestamp for presentation (VDPAU and >> VK_GOOGLE_display_timing) use "not before"

Re: Wayland presentation extension (video protocol) WIP after RFCv2

Hi Michel, On 13 April 2018 at 10:17, Michel Dänzer wrote: > reviving an old topic... Inspired by the thread "RFC for a render API to > support adaptive sync and VRR" currently happening on the dri-devel list. I've been following that thread pretty keenly. > On 2014-02-26

Re: Wayland presentation extension (video protocol) WIP after RFCv2

Hi Pekka, reviving an old topic... Inspired by the thread "RFC for a render API to support adaptive sync and VRR" currently happening on the dri-devel list. On 2014-02-26 10:30 AM, Pekka Paalanen wrote: > Hi all, > > I just wanted to mention where I am with this at the moment, as it > seems

Re: [PATCH weston 21/25] protocol: add weston_touch_calibration

On Fri, 13 Apr 2018 14:31:39 +1000 Peter Hutterer wrote: > On Wed, Apr 11, 2018 at 02:00:49PM +0300, Pekka Paalanen wrote: > > On Wed, 11 Apr 2018 10:16:46 +1000 > > Peter Hutterer wrote: > > > > > > + > > > > > > + > > > > > > +

Re: [PATCHv2] text-input: Add v3 of the text-input protocol

On Thu, Apr 12, 2018 at 9:53 PM, Dorota Czaplejewicz wrote: > On Thu, 12 Apr 2018 21:26:08 +0200 > Silvan Jegen wrote: > >> Hi Dorota >> >> On Wed, Apr 11, 2018 at 03:03:58PM +0200, Dorota Czaplejewicz wrote: >> > This new protocol description is a

[PATCH] compositor-headless: Report a more realistic physical size

Some clients rely on the physical size to determine the physical DPI. With the previous implementation, we would report 1px==1mm, which is a DPI of 25.4, which is incredibly low. The problem is solved by setting a physical size so the DPI is close to 72 instead. If the output is scaled, the DPI