[RFC v2 wayland-protocols] tablet: define our own enum for tablet tool buttons

[Peter Hutterer]

Rather than relying on input-event-codes, define our own enum that is tailored
towards the tablet interface.

Signed-off-by: Peter Hutterer 
---
Because it's usually easier to pick holes into a patch proposal than come up
with ideas elsewhere, here's a quick-and-dirty patch.

Advantage: we control the button names/numbers and clients don't have to
know about cases where linux/input.h isn't enough.
Obvious drawback: adding new buttons requires a new protocol. Given this
hardware hasn't really changed much in quite a while, this may not be much
of an issue.

 unstable/tablet/tablet-unstable-v2.xml | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/unstable/tablet/tablet-unstable-v2.xml 
b/unstable/tablet/tablet-unstable-v2.xml
index 728a3df..88aed83 100644
--- a/unstable/tablet/tablet-unstable-v2.xml
+++ b/unstable/tablet/tablet-unstable-v2.xml
@@ -539,6 +539,26 @@
   
 
 
+
+  
+   Describes the physical button that produced the button event.
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+
+
 
   
Describes the physical state of a button that produced the button event.
@@ -558,7 +578,7 @@
   
 
   
-  
+  
   
 
 
-- 
2.9.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] protocol: spell out that we're using linux/input-event-codes.h key codes

[Peter Hutterer]

On Fri, Nov 18, 2016 at 11:29:53AM +0800, Jonas Ådahl wrote:
> On Fri, Nov 18, 2016 at 12:25:21PM +1000, Peter Hutterer wrote:
> > On Thu, Nov 17, 2016 at 10:42:41AM +0800, Jonas Ådahl wrote:
> > > On Wed, Nov 16, 2016 at 04:00:23PM +, Daniel Stone wrote:
> > > > Hi,
> > > > 
> > > > On 15 November 2016 at 09:42, Jonas Ådahl  wrote:
> > > > > On Thu, Nov 10, 2016 at 10:22:41AM +, Daniel Stone wrote:
> > > > >> But this I'd prefer to drop. We need to describe the button codes, 
> > > > >> but
> > > > >> the key codes are _already_ perfectly described in the keymap. 
> > > > >> Leaving
> > > > >> this undefined opens the door to making life much easier for, e.g.,
> > > > >> RDP-based compositors.
> > > > >
> > > > > Maybe it'd make it easier for RDP based compositors, but it'd make it
> > > > > harder for clients who don't care about keymaps and just wants 
> > > > > keycodes
> > > > > (think WASD using games). Such clients doesn't care if it's actually
> > > > >  > > > > would
> > > > > make such clients rely on undefined behaviour.
> > > > 
> > > > Those clients can trivially introspect the keymap, then ... ?
> > > 
> > > Instrospect how? I don't see how I can get anything resembling a
> > > physical position on a keyboard from a xkb_keycode_t and a struct
> > > xkb_keymap.
> > 
> > coincidentally, that actually outlines the problem Daniel was talking about.
> > The physical position of KEY_W is not guaranteed. It could be in a different
> > postcode and no-one would notice as long as it sends the same key code.
> > So by relying on KEY_W to be where you think it is, you're contributing to
> > exactly that problem we had switching to evdev.
> > 
> > The only thing that could've provided actual physical positioning for the
> > key was the geometry stuff but that was discarded in libxkbcommon, for
> > a number of good reasons.
> 
> So lets assume we define wl_keyboard.key to be useless by itself, and
> that its meaning only depends on the keymap_format enum value.
> 
> If the keymap_format is 'xkb_v1', the keycode can only be offset by 8
> then passed to a libxkbcommon state set up with the keymap passed via
> wl_keyboard.keymap. The client will AFAICS have no information about the
> keymap; it'll just feed it key-up/down events. Would it be possible to
> add API to libxkbcommon to provide enough information about the passed
> keyboard layout so the client can create its own variant (such as
> xkb_rule_names::model,rules, so that the client can create its own
> layout but with the known layout). That would at least give something
> resembling a key position.

the xkb key names are that. e.g. 

struct xkb_context  *ctx = xkb_context_new(0);
struct xkb_rule_names names = { "evdev", "pc104", "us", "", "" };
struct xkb_keymap *keymap = xkb_keymap_new_from_names(ctx, , 0);
xkb_keycode_t min = xkb_keymap_min_keycode(keymap),
  max = xkb_keymap_max_keycode(keymap);
for (int i = min; i < max; i++)
printf("key name for %d: %s\n", i, xkb_keymap_key_get_name(keymap, i));
xkb_context_unref(ctx);

this prints out e.g. "AE01" which is "row E, key 01" and refers to F1, A is
AC01, etc.  These names are semi-standard in that xkb has been using them
for decades but they're technically freeform (e.g. LALT or I147 and new
xkb models may define anything)

xkb also gives you the syms for each key code per level, so you should be
able to reconstruct everything you need this way. One problem is that XKB
is largely uni-directional, i.e. keycode->keysym is defined but
keysym->keycode is not always unique. but afaict the tools are already there
to re-build the layout on the client side, albeit without exact position
information.

> If 'no_keymap' is the enum value used, which says the keycode should be
> interpreted directly, how could that be possible if it's undefined?
> Should we then instead define it to only be valid in a tightly
> integrated system (where a certain software only ever runs on a specific
> hardware/software setup)? This is awkward by itself btw, the server
> seems to be required to send a useless fd just to have something to
> pass. I guess that can be avoided by having 'no_keymap' as default,
> assuming one never goes xkb_v1 -> no_keymap.

isn't no_keymap the default anyway, merely by the wl_keyboardf.keymap being
an event that may or may not be sent? It's not spelled out explicitly but
that's how we've been treating other interfaces. Technically, no_keymap
isn't even necessary if the event is skipped altogether.

As for "how could that be possible if it's undefined", I guess there's a
slight difference between the technical term "undefined" and the more blurry
term "not defined". Having no keymap means the latter and as the doc says
"client must understand how to interpret the raw keycode".

Cheers,
   Peter

> 
> 
> Jonas
> 
> > 
> > Cheers,
> >Peter
> > 
> > > > We 

Re: [wayland-protocols v2] linux-dmabuf: advertise format modifiers with modifier event

[Yong Bakos]

Hi Varad,

> On Nov 17, 2016, at 11:28 PM, Varad Gautam  wrote:
> 
> From: Varad Gautam 
> 
> advertise the supported fourcc format modifiers along with supported
> formats to the client.
> 
> bump zwp_linux_dmabuf_v1, zwp_linux_buffer_params_v1 interface
> versions to 3.
> 
> v2: specify request name in event description for clarity (Yong Bakos)
> 
> Signed-off-by: Varad Gautam 

One minor nit below but this is:

Reviewed-by: Yong Bakos 


> ---
> unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml | 25 +++---
> 1 file changed, 22 insertions(+), 3 deletions(-)
> 
> diff --git a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml 
> b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
> index a0aa42e..3b008ee 100644
> --- a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
> +++ b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
> @@ -26,7 +26,7 @@
> THIS SOFTWARE.
>   
> 
> -  
> +  
> 
>   Following the interfaces from:
>   
> https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
> @@ -34,7 +34,8 @@
> 
>   This interface offers ways to create generic dmabuf-based
>   wl_buffers. Immediately after a client binds to this interface,
> -  the set of supported formats is sent with 'format' events.
> +  the set of supported formats and format modifiers is sent with
> +  'format' and 'modifier' events.
> 
>   The following are required from clients:
> 
> @@ -110,9 +111,27 @@
>   
>   
> 
> +
> +
> +  
> +This event advertises the formats that the server supports, along 
> with
> +the modifiers supported for each format. All the supported modifiers 
> for
> +all the supported formats are advertised once when the client binds 
> to
> +this interface. A roundtrip after binding guarantees that the client
> +has received all supported format-modifier pairs.
> +
> +For the definition of the format and modifier codes, see
> +zwp_linux_buffer_params_v1::create request.

For the definition of the format and modifier codes, see the 
zwp_linux_buffer_params_v1::create request.

(note the 'the').

yong



> +  
> +  
> +   +   summary="high 32 bits of layout modifier"/>
> +   +   summary="low 32 bits of layout modifier"/>
> +
>   
> 
> -  
> +  
> 
>   This temporary object is a collection of dmabufs and other
>   parameters that together form a single logical buffer. The temporary
> -- 
> 2.6.2
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [wayland-protocols] linux-dmabuf: clarify format event description

[Yong Bakos]

Hi Varad,

> On Nov 17, 2016, at 11:32 PM, Varad Gautam  wrote:
> 
> From: Varad Gautam 
> 
> clearly state the request name in format event to avoid abmiguous
> interpretation between 'zwp_linux_buffer_params_v1::create' and
> 'zwp_linux_dmabuf_v1::create_params' requests.
> 
> Suggested-by: Yong Bakos 
> Signed-off-by: Varad Gautam 

One minor nit below but this is:

Reviewed-by: Yong Bakos 


> ---
> unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml 
> b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
> index 3b008ee..c6aa2cd 100644
> --- a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
> +++ b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
> @@ -105,7 +105,8 @@
> binds to this interface. A roundtrip after binding guarantees
> that the client has received all supported formats.
> 
> -For the definition of the format codes, see create request.
> +For the definition of the format codes, see
> +zwp_linux_buffer_params_v1::create request.


For the definition of the format codes, see the
zwp_linux_buffer_params_v1::create request.

(Note the 'the'.)

yong



> 
> XXX: Can a compositor ever enumerate them?
>   
> -- 
> 2.6.2
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH libinput] evdev: add a quirk for the HP Zbook Studio G3

[Peter Hutterer]

Announces 4 slots but only sends data for the first two. This causes libinput
to miss three-finger actions (we don't look at BTN_TOOL_TRIPLETAP if we have
3 or more slots).

https://bugs.freedesktop.org/show_bug.cgi?id=98100

Signed-off-by: Peter Hutterer 
---
 src/evdev.c| 6 ++
 src/evdev.h| 1 +
 udev/90-libinput-model-quirks.hwdb | 4 
 3 files changed, 11 insertions(+)

diff --git a/src/evdev.c b/src/evdev.c
index fac8fcb..6a34e37 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -2179,6 +2179,7 @@ evdev_read_model_flags(struct evdev_device *device)
MODEL(APPLE_MAGICMOUSE),
MODEL(HP8510_TOUCHPAD),
MODEL(HP6910_TOUCHPAD),
+   MODEL(HP_ZBOOK_STUDIO_G3),
 #undef MODEL
{ "ID_INPUT_TRACKBALL", EVDEV_MODEL_TRACKBALL },
{ NULL, EVDEV_MODEL_DEFAULT },
@@ -2762,6 +2763,11 @@ evdev_pre_configure_model_quirks(struct evdev_device 
*device)
if (device->model_flags & EVDEV_MODEL_HP_STREAM11_TOUCHPAD)
libevdev_enable_property(device->evdev,
 INPUT_PROP_BUTTONPAD);
+
+   /* Touchpad claims to have 4 slots but only ever sends 2
+* https://bugs.freedesktop.org/show_bug.cgi?id=98100 */
+   if (device->model_flags & EVDEV_MODEL_HP_ZBOOK_STUDIO_G3)
+   libevdev_set_abs_maximum(device->evdev, ABS_MT_SLOT, 1);
 }
 
 struct evdev_device *
diff --git a/src/evdev.h b/src/evdev.h
index b811f51..888cc28 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -121,6 +121,7 @@ enum evdev_device_model {
EVDEV_MODEL_APPLE_MAGICMOUSE = (1 << 20),
EVDEV_MODEL_HP8510_TOUCHPAD = (1 << 21),
EVDEV_MODEL_HP6910_TOUCHPAD = (1 << 22),
+   EVDEV_MODEL_HP_ZBOOK_STUDIO_G3 = (1 << 23),
 };
 
 struct mt_slot {
diff --git a/udev/90-libinput-model-quirks.hwdb 
b/udev/90-libinput-model-quirks.hwdb
index 4bfc0f9..347a229 100644
--- a/udev/90-libinput-model-quirks.hwdb
+++ b/udev/90-libinput-model-quirks.hwdb
@@ -103,6 +103,10 @@ libinput:name:SynPS/2 Synaptics 
TouchPad:dmi:*svnHewlett-Packard:*pnHPCompaq8510
 libinput:name:SYN1EDE:00 
06CB:7442:dmi:*svnHewlett-Packard:pnHPStreamNotebookPC11*
  LIBINPUT_MODEL_HP_STREAM11_TOUCHPAD=1
 
+# HP Zbook Studio G3
+libinput:name:AlpsPS/2 ALPS GlidePoint:dmi:*svnHP:pnHPZBookStudioG3:*
+ LIBINPUT_MODEL_HP_ZBOOK_STUDIO_G3=1
+
 ##
 # LENOVO
 ##
-- 
2.9.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[RFC wayland-protocols] Add the color-management protocol

[Niels Ole Salscheider]

Signed-off-by: Niels Ole Salscheider 
---
 Makefile.am|   1 +
 unstable/color-management/README   |   4 +
 .../color-management-unstable-v1.xml   | 136 +
 3 files changed, 141 insertions(+)
 create mode 100644 unstable/color-management/README
 create mode 100644 unstable/color-management/color-management-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index e693afa..ff435d5 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -12,6 +12,7 @@ unstable_protocols =  
\
unstable/tablet/tablet-unstable-v2.xml  
\
unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
\
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml  
\
+   unstable/color-management/color-management-unstable-v1.xml  
\
$(NULL)
 
 stable_protocols = 
\
diff --git a/unstable/color-management/README b/unstable/color-management/README
new file mode 100644
index 000..3bd3e6c
--- /dev/null
+++ b/unstable/color-management/README
@@ -0,0 +1,4 @@
+Color management protocol
+
+Maintainers:
+Niels Ole Salscheider 
diff --git a/unstable/color-management/color-management-unstable-v1.xml 
b/unstable/color-management/color-management-unstable-v1.xml
new file mode 100644
index 000..f2bb3f6
--- /dev/null
+++ b/unstable/color-management/color-management-unstable-v1.xml
@@ -0,0 +1,136 @@
+
+
+
+  
+Copyright © 2014-2016 Niels Ole Salscheider
+
+Permission to use, copy, modify, distribute, and sell this
+software and its documentation for any purpose is hereby granted
+without fee, provided that the above copyright notice appear in
+all copies and that both that copyright notice and this permission
+notice appear in supporting documentation, and that the name of
+the copyright holders not be used in advertising or publicity
+pertaining to distribution of the software without specific,
+written prior permission.  The copyright holders make no
+representations about the suitability of this software for any
+purpose.  It is provided "as is" without express or implied
+warranty.
+
+THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
+ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
+THIS SOFTWARE.
+  
+
+  
+
+  This interface allows attaching a color space to a wl_surface. The
+  compositor uses this information to display the colors correctly.
+  For this, the compositor converts any attached surfaces to the blending
+  color space before performing the blending operations. After blending,
+  the output surface is converted to the color space of the output device.
+  This interface also provides requests for the sRGB and the blending color
+  space. It further allows creation of a color space from an ICC profile.
+  The client is informed by an event if the color space of one of the
+  outputs changes.
+
+
+
+  
+With this request, the color space of a wl_surface can be set.
+The sRGB colorspace is attached to a surface before set_colorspace is
+called for the first time.
+  
+  
+  
+
+
+
+  
+This request allows to create a zwp_colorspace_v1 object from an ICC
+profile. The fd argument is the file descriptor to the ICC profile (ICC
+V2 or V4).
+  
+  
+  
+
+
+
+  
+This request returns a zwp_colorspace_v1 object for the requested
+output. A client can use this when it does not want its surfaces to be
+color-corrected. In this case it can attach the color space of its main
+output to its surfaces.
+  
+  
+  
+
+
+
+  
+This request returns a zwp_colorspace_1 object for the sRGB color
+space. The sRGB color space is initially attached to all surfaces.
+  
+  
+
+
+
+  
+This request returns a zwp_colorspace_v1 object for the blending color
+space of the compositor. All surfaces are converted by the compositor
+to the blending color space before the blending operations. Once the
+blending is performed, a further color conversion to the output color
+spaces is carried out by the compositor.
+A client should render in the blending color space returned by this
+

[RFC wayland-protocols] Color management protocol

[Niels Ole Salscheider]

Hello,

it has been some time since I proposed the first two RFCs for a color
management protocol in weston. You can find the old discussions here:

https://lists.freedesktop.org/archives/wayland-devel/2014-March/013951.html
https://lists.freedesktop.org/archives/wayland-devel/2014-October/017759.html

During the discussion of the second RFC it became clear that color correction
was out of scope for weston at that time.
In the meantime wayland-protocols was split from weston and libweston was
created. Several wayland compositors start to see everyday usage and wide-gamut
screens became more common so that color management becomes more important.

Therefore I think that the situation has changed and I'd like to propose this
protocol for inclusion in wayland-protocols again.
What do you think?

Ole

Niels Ole Salscheider (1):
  Add the color-management protocol

 Makefile.am|   1 +
 unstable/color-management/README   |   4 +
 .../color-management-unstable-v1.xml   | 136 +
 3 files changed, 141 insertions(+)
 create mode 100644 unstable/color-management/README
 create mode 100644 unstable/color-management/color-management-unstable-v1.xml

-- 
2.10.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel