Re:Re: Hide or show the surface

[Anthenony]

Hi，Jonas：
 
I try to set invisible on current surface with “attach(0, 0, 0)”, but as said 
in website, attach NULL buffer will cause freeze issue, so I want to use 
another way to make invisible effort.
I find this function “set_buffer_scale”, but how to use it?
I have done experiment to use  wl_surface::set_buffer_scale(0), the surface can 
be invisible, but how recover it to visible? I tried 
wl_surface::set_buffer_scale(1), but nothing happens, the surface is still 
invisible.
wl_surface::set_buffer_scale - sets the buffer scaling factor

scale

int - positive scale for interpreting buffer contents

This request sets an optional scaling factor on how the compositor interprets 
the contents of the buffer attached to the window.

Buffer scale is double-buffered state, see wl_surface.commit.

A newly created surface has its buffer scale set to 1.

wl_surface.set_buffer_scale changes the pending buffer scale. wl_surface.commit 
copies the pending buffer scale to the current one. Otherwise, the pending and 
current values are never changed.

The purpose of this request is to allow clients to supply higher resolution 
buffer data for use on high resolution outputs. It is intended that you pick 
the same buffer scale as the scale of the output that the surface is displayed 
on. This means the compositor can avoid scaling when rendering the surface on 
that output.

Note that if the scale is larger than 1, then you have to attach a buffer that 
is larger (by a factor of scale in each dimension) than the desired surface 
size.

If scale is not positive the invalid_scale protocol error is raised. 




At 2016-12-23 11:25:05, "Jonas Ådahl"  wrote:
>On Fri, Dec 23, 2016 at 09:52:45AM +0800, Anthenony wrote:
>> Hi, All:
>> 
>> 
>> As far as I know there is no interface to hide or show the client. I 
>> want to make sure whether other method is feasible.
>> For example, I move the client out of the screen.
>> 
>> Hide:
>> attach(m_wl_sufface, 1000, 1000);
>> commit();
>>  
>> Show:
>> attach(m_wl_sufface, 0, 0);
>> commit();
>> 
>> 
>> Anyway, is there any other methods?
>
>Attaching with an offset should not be used to hide a surface. It's a
>total abuse of those parameters and will definitely not work reliably. I
>wouldn't be surprised if compositors will blatantly terminate clients
>abusing it in such ways, since it would make no sense from the point of
>view of the way those parameters were intended to be used.
>
>The proper way depends on the role the surface has. For example if it's
>a pointer cursor surface, and you want to hide the cursor, you set the
>pointer cursor to a NULL surface. If it's a shell surface (xdg_toplevel
>or a toplevel wl_shell_surface) you unmap it; how unmapping is done
>depends on the protocol defining the role. For example if it's a
>xdg_toplevel, to unmap the surface you destroy the xdg_toplevel and
>xdg_surface objects. For wl_shell_surface clients, it's similar; destroy
>the wl_shell_surface object to unmap the surface.
>
>For other roles, it's up to the role to define how to hide/unmap the
>corresponding surface view.
>
>
>Jonas
>
>> 
>> 
>> 
>> 
>> Best regards,
>> Anthenony
>

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

[PATCH libinput 2/5] test: simplify some checks in the path test

[Peter Hutterer]

The first event is always a device added event, skip the loops that would
paper over this. If we ever change this, the tests *should* fail.

Signed-off-by: Peter Hutterer 
---
 test/path.c | 150 ++--
 1 file changed, 64 insertions(+), 86 deletions(-)

diff --git a/test/path.c b/test/path.c
index 0890d3e..93c78dc 100644
--- a/test/path.c
+++ b/test/path.c
@@ -310,24 +310,16 @@ START_TEST(path_added_device)
struct libinput *li = dev->libinput;
struct libinput_event *event;
struct libinput_device *device;
+   enum libinput_event_type type;
 
libinput_dispatch(li);
 
-   while ((event = libinput_get_event(li))) {
-   enum libinput_event_type type;
-   type = libinput_event_get_type(event);
-
-   if (type == LIBINPUT_EVENT_DEVICE_ADDED) {
-   break;
-   }
-
-   libinput_event_destroy(event);
-   }
-
-   ck_assert(event != NULL);
-
+   event = libinput_get_event(li);
+   ck_assert_notnull(event);
+   type = libinput_event_get_type(event);
+   ck_assert_int_eq(type, LIBINPUT_EVENT_DEVICE_ADDED);
device = libinput_event_get_device(event);
-   ck_assert(device != NULL);
+   ck_assert_notnull(device);
 
libinput_event_destroy(event);
 }
@@ -339,23 +331,21 @@ START_TEST(path_add_device)
struct libinput *li = dev->libinput;
struct libinput_event *event;
struct libinput_device *device;
-   const char *sysname1 = NULL, *sysname2 = NULL;
+   char *sysname1 = NULL, *sysname2 = NULL;
+   enum libinput_event_type type;
 
libinput_dispatch(li);
 
-   while ((event = libinput_get_event(li))) {
-   enum libinput_event_type type;
-   type = libinput_event_get_type(event);
+   event = libinput_get_event(li);
+   ck_assert_notnull(event);
+   type = libinput_event_get_type(event);
+   ck_assert_int_eq(type, LIBINPUT_EVENT_DEVICE_ADDED);
+   device = libinput_event_get_device(event);
+   ck_assert_notnull(device);
+   sysname1 = strdup(libinput_device_get_sysname(device));
+   libinput_event_destroy(event);
 
-   if (type == LIBINPUT_EVENT_DEVICE_ADDED) {
-   ck_assert(sysname1 == NULL);
-   device = libinput_event_get_device(event);
-   ck_assert(device != NULL);
-   sysname1 = libinput_device_get_sysname(device);
-   }
-
-   libinput_event_destroy(event);
-   }
+   litest_assert_empty_queue(li);
 
device = libinput_path_add_device(li,
  
libevdev_uinput_get_devnode(dev->uinput));
@@ -363,23 +353,19 @@ START_TEST(path_add_device)
 
libinput_dispatch(li);
 
-   while ((event = libinput_get_event(li))) {
-   enum libinput_event_type type;
-   type = libinput_event_get_type(event);
-
-   if (type == LIBINPUT_EVENT_DEVICE_ADDED) {
-   ck_assert(sysname2 == NULL);
-   device = libinput_event_get_device(event);
-   ck_assert(device != NULL);
-   sysname2 = libinput_device_get_sysname(device);
-   }
-
-   libinput_event_destroy(event);
-   }
+   event = libinput_get_event(li);
+   ck_assert_notnull(event);
+   type = libinput_event_get_type(event);
+   ck_assert_int_eq(type, LIBINPUT_EVENT_DEVICE_ADDED);
+   device = libinput_event_get_device(event);
+   ck_assert_notnull(device);
+   sysname2 = strdup(libinput_device_get_sysname(device));
+   libinput_event_destroy(event);
 
ck_assert_str_eq(sysname1, sysname2);
 
-   libinput_event_destroy(event);
+   free(sysname1);
+   free(sysname2);
 }
 END_TEST
 
@@ -411,21 +397,23 @@ START_TEST(path_device_sysname)
struct libinput_event *ev;
struct libinput_device *device;
const char *sysname;
+   enum libinput_event_type type;
 
libinput_dispatch(dev->libinput);
 
-   while ((ev = libinput_get_event(dev->libinput))) {
-   if (libinput_event_get_type(ev) != LIBINPUT_EVENT_DEVICE_ADDED)
-   continue;
+   ev = libinput_get_event(dev->libinput);
+   ck_assert_notnull(ev);
+   type = libinput_event_get_type(ev);
+   ck_assert_int_eq(type, LIBINPUT_EVENT_DEVICE_ADDED);
+   device = libinput_event_get_device(ev);
+   ck_assert_notnull(device);
+   sysname = libinput_device_get_sysname(device);
 
-   device = libinput_event_get_device(ev);
-   sysname = libinput_device_get_sysname(device);
-   ck_assert(sysname != NULL && strlen(sysname) > 1);
-   ck_assert(strchr(sysname, '/') == NULL);
-   ck_assert_int_eq(strncmp(sysname, "event", 5), 0);
+   c

[PATCH libinput 3/5] test: fix pointer accel defaults test

[Peter Hutterer]

Loop immediately exited, this code was never triggered.

Signed-off-by: Peter Hutterer 
---
 test/pointer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/test/pointer.c b/test/pointer.c
index e0cd064..f4663db 100644
--- a/test/pointer.c
+++ b/test/pointer.c
@@ -1062,7 +1062,7 @@ START_TEST(pointer_accel_defaults)
speed);
}
 
-   for (speed = 1.2; speed <= -2.0; speed += 0.2) {
+   for (speed = 1.2; speed <= 2.0; speed += 0.2) {
status = libinput_device_config_accel_set_speed(device,
speed);
ck_assert_int_eq(status,
-- 
2.9.3

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

[PATCH libinput 4/5] test: fix some tablet tests' unreached code

[Peter Hutterer]

These conditions were never triggered by our test suite, so let's tighten up
the tests to match what we expect.

Signed-off-by: Peter Hutterer 
---
 test/tablet.c | 42 +++---
 1 file changed, 7 insertions(+), 35 deletions(-)

diff --git a/test/tablet.c b/test/tablet.c
index 212ef0c..149b058 100644
--- a/test/tablet.c
+++ b/test/tablet.c
@@ -700,16 +700,7 @@ START_TEST(proximity_in_out)
ck_assert(have_proximity_out);
 
/* Proximity out must not emit axis events */
-   litest_tablet_proximity_out(dev);
-   libinput_dispatch(li);
-
-   while ((event = libinput_get_event(li))) {
-   enum libinput_event_type type = libinput_event_get_type(event);
-
-   ck_assert(type != LIBINPUT_EVENT_TABLET_TOOL_AXIS);
-
-   libinput_event_destroy(event);
-   }
+   litest_assert_empty_queue(li);
 }
 END_TEST
 
@@ -1601,16 +1592,8 @@ START_TEST(motion_event_state)
 
libinput_dispatch(li);
 
-   while ((event = libinput_get_event(li))) {
-   if (libinput_event_get_type(event) == 
LIBINPUT_EVENT_TABLET_TOOL_AXIS)
-   break;
-   libinput_event_destroy(event);
-   }
-
-   /* pop the first event off */
-   ck_assert_notnull(event);
-   tablet_event = libinput_event_get_tablet_tool_event(event);
-   ck_assert_notnull(tablet_event);
+   event = libinput_get_event(li);
+   tablet_event = litest_is_tablet_event(event, 
LIBINPUT_EVENT_TABLET_TOOL_AXIS);
 
last_x = libinput_event_tablet_tool_get_x(tablet_event);
last_y = libinput_event_tablet_tool_get_y(tablet_event);
@@ -2022,7 +2005,6 @@ START_TEST(pad_buttons_ignored)
 {
struct litest_device *dev = litest_current_device();
struct libinput *li = dev->libinput;
-   struct libinput_event *event;
struct axis_replacement axes[] = {
{ ABS_DISTANCE, 10 },
{ ABS_PRESSURE, 0 },
@@ -2040,15 +2022,12 @@ START_TEST(pad_buttons_ignored)
libinput_dispatch(li);
}
 
-   while ((event = libinput_get_event(li))) {
-   ck_assert_int_ne(libinput_event_get_type(event),
-LIBINPUT_EVENT_TABLET_TOOL_BUTTON);
-   libinput_event_destroy(event);
-   libinput_dispatch(li);
-   }
+   litest_assert_empty_queue(li);
 
/* same thing while in prox */
litest_tablet_proximity_in(dev, 10, 10, axes);
+   litest_drain_events(li);
+
for (button = BTN_0; button < BTN_MOUSE; button++) {
litest_event(dev, EV_KEY, button, 1);
litest_event(dev, EV_SYN, SYN_REPORT, 0);
@@ -2056,15 +2035,8 @@ START_TEST(pad_buttons_ignored)
litest_event(dev, EV_SYN, SYN_REPORT, 0);
libinput_dispatch(li);
}
-   litest_tablet_proximity_out(dev);
 
-   libinput_dispatch(li);
-   while ((event = libinput_get_event(li))) {
-   ck_assert_int_ne(libinput_event_get_type(event),
-LIBINPUT_EVENT_TABLET_TOOL_BUTTON);
-   libinput_event_destroy(event);
-   libinput_dispatch(li);
-   }
+   litest_assert_empty_queue(li);
 }
 END_TEST
 
-- 
2.9.3

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

[PATCH libinput 5/5] test: remove tablet axis normalization test

[Peter Hutterer]

gcov analysis showed that none of the actual testing conditions were hit, so
the test succeeded despite not actually testing anything. Which is good,
because testing for tilt normalization isn't correct anyway, tilt is in
physical degrees,

Drop the test and replace it with a test for pressure normalization instead.
We already have a similar one to check for [0, 1] range, this new one
explicitly tests for the extents.

Signed-off-by: Peter Hutterer 
---
 test/tablet.c | 180 ++
 1 file changed, 43 insertions(+), 137 deletions(-)

diff --git a/test/tablet.c b/test/tablet.c
index 149b058..b4e9944 100644
--- a/test/tablet.c
+++ b/test/tablet.c
@@ -1720,142 +1720,6 @@ START_TEST(bad_distance_events)
 }
 END_TEST
 
-START_TEST(normalization)
-{
-   struct litest_device *dev = litest_current_device();
-   struct libinput *li = dev->libinput;
-   struct libinput_event_tablet_tool *tablet_event;
-   struct libinput_event *event;
-   double pressure,
-  tilt_vertical,
-  tilt_horizontal;
-   const struct input_absinfo *pressure_absinfo,
-   *tilt_vertical_absinfo,
-   *tilt_horizontal_absinfo;
-
-   litest_drain_events(li);
-
-   pressure_absinfo = libevdev_get_abs_info(dev->evdev, ABS_PRESSURE);
-   tilt_vertical_absinfo = libevdev_get_abs_info(dev->evdev, ABS_TILT_X);
-   tilt_horizontal_absinfo = libevdev_get_abs_info(dev->evdev, ABS_TILT_Y);
-
-   /* Test minimum */
-   if (pressure_absinfo != NULL)
-   litest_event(dev,
-EV_ABS,
-ABS_PRESSURE,
-pressure_absinfo->minimum);
-
-   if (tilt_vertical_absinfo != NULL)
-   litest_event(dev,
-EV_ABS,
-ABS_TILT_X,
-tilt_vertical_absinfo->minimum);
-
-   if (tilt_horizontal_absinfo != NULL)
-   litest_event(dev,
-EV_ABS,
-ABS_TILT_Y,
-tilt_horizontal_absinfo->minimum);
-
-   litest_event(dev, EV_SYN, SYN_REPORT, 0);
-
-   libinput_dispatch(li);
-
-   while ((event = libinput_get_event(li))) {
-   if (libinput_event_get_type(event) == 
LIBINPUT_EVENT_TABLET_TOOL_AXIS) {
-   tablet_event = 
libinput_event_get_tablet_tool_event(event);
-
-   if (libinput_event_tablet_tool_pressure_has_changed(
-   tablet_event)) {
-   pressure = 
libinput_event_tablet_tool_get_pressure(
-   tablet_event);
-
-   litest_assert_double_eq(pressure, 0);
-   }
-
-   if (libinput_event_tablet_tool_tilt_x_has_changed(
-   tablet_event)) {
-   tilt_vertical =
-   libinput_event_tablet_tool_get_tilt_x(
-   tablet_event);
-
-   litest_assert_double_eq(tilt_vertical, -1);
-   }
-
-   if (libinput_event_tablet_tool_tilt_y_has_changed(
-   tablet_event)) {
-   tilt_horizontal =
-   libinput_event_tablet_tool_get_tilt_y(
-   tablet_event);
-
-   litest_assert_double_eq(tilt_horizontal, -1);
-   }
-   }
-
-   libinput_event_destroy(event);
-   }
-
-   /* Test maximum */
-   if (pressure_absinfo != NULL)
-   litest_event(dev,
-EV_ABS,
-ABS_PRESSURE,
-pressure_absinfo->maximum);
-
-   if (tilt_vertical_absinfo != NULL)
-   litest_event(dev,
-EV_ABS,
-ABS_TILT_X,
-tilt_vertical_absinfo->maximum);
-
-   if (tilt_horizontal_absinfo != NULL)
-   litest_event(dev,
-EV_ABS,
-ABS_TILT_Y,
-tilt_horizontal_absinfo->maximum);
-
-   litest_event(dev, EV_SYN, SYN_REPORT, 0);
-
-   libinput_dispatch(li);
-
-   while ((event = libinput_get_event(li))) {
-   if (libinput_event_get_type(event) == 
LIBINPUT_EVENT_TABLET_TOOL_AXIS) {
-   tablet_event = 
libinput_event_get_tablet_tool_event(event);
-
-   if (libinput_event_tablet_tool_pressure_has_changed(
-

[PATCH libinput 1/5] test: remove some untriggered code from the keyboard tests

[Peter Hutterer]

The second condition was never triggered because we shouldn't get anything but
keyboard events here. Drain the initial event burst and remove the two
skipping conditions that won't happen anyway.

Signed-off-by: Peter Hutterer 
---
 test/keyboard.c | 16 ++--
 1 file changed, 2 insertions(+), 14 deletions(-)

diff --git a/test/keyboard.c b/test/keyboard.c
index 780506a..4f52c85 100644
--- a/test/keyboard.c
+++ b/test/keyboard.c
@@ -50,18 +50,13 @@ START_TEST(keyboard_seat_key_count)
  NULL, NULL, NULL);
}
 
+   litest_drain_events(libinput);
+
for (i = 0; i < num_devices; ++i)
litest_keyboard_key(devices[i], KEY_A, true);
 
libinput_dispatch(libinput);
while ((ev = libinput_get_event(libinput))) {
-   if (libinput_event_get_type(ev) !=
-   LIBINPUT_EVENT_KEYBOARD_KEY) {
-   libinput_event_destroy(ev);
-   libinput_dispatch(libinput);
-   continue;
-   }
-
kev = litest_is_keyboard_event(ev,
   KEY_A,
   LIBINPUT_KEY_STATE_PRESSED);
@@ -82,13 +77,6 @@ START_TEST(keyboard_seat_key_count)
 
libinput_dispatch(libinput);
while ((ev = libinput_get_event(libinput))) {
-   if (libinput_event_get_type(ev) !=
-   LIBINPUT_EVENT_KEYBOARD_KEY) {
-   libinput_event_destroy(ev);
-   libinput_dispatch(libinput);
-   continue;
-   }
-
kev = libinput_event_get_keyboard_event(ev);
ck_assert_notnull(kev);
ck_assert_int_eq(libinput_event_keyboard_get_key(kev), KEY_A);
-- 
2.9.3

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

Re: [PATCH libinput 0/5] Disable laptop touchpad on lid close

[Peter Hutterer]

On Thu, Jan 05, 2017 at 06:00:05PM +0100, Carlos Garnacho wrote:
> Hey,
> 
> Thanks James for these patches!
> 
> On Thu, Jan 5, 2017 at 11:02 AM, Peter Hutterer
>  wrote:
> > On Thu, Jan 05, 2017 at 05:11:24PM +1100, James Ye wrote:
> >> Although a laptop touchpad is usually not accessible when the lid is 
> >> closed,
> >> some laptop models suffer from a hardware bug where the touchpad can be
> >> activated even if the lid is closed.  This bug can be worked around by 
> >> disabling
> >> the touchpad when the lid is closed.
> >>
> >> This patch set adds:
> >> 1: hwdb patch to mark switches as input devices (needs to go to systemd)
> >> 2: switch interface[1]
> >> 3: evdev dispatch interface for laptop lid switches
> >> 4: mechanism for pairing touchpad with lid, and disabling the touchpad
> >> 5: test cases
> >>
> >> Best regards,
> >> James Ye
> >
> > thanks for picking this up, much appreciated. The patches look good bar a
> > few minor nitpicks and a few test cases we should add. But the series even
> > *has* test cases, so there's really very little I can complain about :)
> >
> > One thing I found missing when I reviewed the tests: we don't sync the
> > status of the switch on startup. There are two options here (either can be a
> > follow-up patch):
> > * send a switch toggle event immediately after DEVICE_ADDED on startup.
> >   That's in-line with the other events and iirc also what we do for
> >   proximity if a tablet tool is already in proximity on device added.
> > * add a libinput_device_switch_get_state() function for callers to query the
> >   state if they need it and only send the actual changes after we have a
> >   context initialised. That has a small potential for race conditions, so
> >   I'm tending to the first option
> >
> > Carlos, Jonas, Hans, any opinions?
> 
> I tend to favor the first option as well, at least seems more
> consistent. Another thing I'd maybe miss is separating toggle on/off
> events, so it could be documented that you're always guaranteed to
> receive the other event next without fiddling on the event contents
> themselves (although you still need to lookup lid/tablet-mode...).

We don't do this for other events except touch/gesture events. I'd like to
keep this consistent with the key and button events which are closer to
switch events. And as you said, since you still need to check which switch
it is, you don't get around looking at the event itself anyway.

Agree with the documentation though, James, please add a paragraph that
libinput guarantees that the event sequence is always correct (i.e. that it
will never send two switch on or two switch off in a row for the same
switch).

Cheers,
   Peter

> 
> Other than that, the patches look correct to me.
> 
> Cheers,
>   Carlos
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput 0/5] Disable laptop touchpad on lid close

[Carlos Garnacho]

Hey,

Thanks James for these patches!

On Thu, Jan 5, 2017 at 11:02 AM, Peter Hutterer
 wrote:
> On Thu, Jan 05, 2017 at 05:11:24PM +1100, James Ye wrote:
>> Although a laptop touchpad is usually not accessible when the lid is closed,
>> some laptop models suffer from a hardware bug where the touchpad can be
>> activated even if the lid is closed.  This bug can be worked around by 
>> disabling
>> the touchpad when the lid is closed.
>>
>> This patch set adds:
>> 1: hwdb patch to mark switches as input devices (needs to go to systemd)
>> 2: switch interface[1]
>> 3: evdev dispatch interface for laptop lid switches
>> 4: mechanism for pairing touchpad with lid, and disabling the touchpad
>> 5: test cases
>>
>> Best regards,
>> James Ye
>
> thanks for picking this up, much appreciated. The patches look good bar a
> few minor nitpicks and a few test cases we should add. But the series even
> *has* test cases, so there's really very little I can complain about :)
>
> One thing I found missing when I reviewed the tests: we don't sync the
> status of the switch on startup. There are two options here (either can be a
> follow-up patch):
> * send a switch toggle event immediately after DEVICE_ADDED on startup.
>   That's in-line with the other events and iirc also what we do for
>   proximity if a tablet tool is already in proximity on device added.
> * add a libinput_device_switch_get_state() function for callers to query the
>   state if they need it and only send the actual changes after we have a
>   context initialised. That has a small potential for race conditions, so
>   I'm tending to the first option
>
> Carlos, Jonas, Hans, any opinions?

I tend to favor the first option as well, at least seems more
consistent. Another thing I'd maybe miss is separating toggle on/off
events, so it could be documented that you're always guaranteed to
receive the other event next without fiddling on the event contents
themselves (although you still need to lookup lid/tablet-mode...).

Other than that, the patches look correct to me.

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

Re: A solution for gamma-adjustment support in Wayland

[Graeme Gill]

Chris Murphy wrote:

> On Mon, Dec 26, 2016 at 10:25 PM, Graeme Gill  I'm not sure what you are thinking of here - the existing per channel
> VideoLUT API's are universally simple, and the only temptation in
> making changes to this might be in the direction of better coordinating
> competing use of this shared resource.
>
> I don't see why Wayland or the compositor or display server would need to be 
> aware of it.
> It should be independent of X vs Wayland vs Mir - even if eventually X and 
> Mir are going
> away.

Hi Chris,

The reason is standardization (i.e. reliability of a resource that an 
application
writer can program to), and coordination of HW identification.

If it relies on some other API that is unconnected with Wayland, then
one cannot confidently write a "Wayland" application that performs these 
operations.
For instance, say that Wayland becomes the display server of choice on
Linux and BSD, but on Linux one has to use DRM/KMS to access the VideoLUT,
but on BSD this isn't available, and (say) some ioctl to some /dev/crtcXX is 
needed, etc.
i.e. this is a platform fragmentation nightmare. Contrast this with it being 
part
of an optional Wayland protocol - the Linux based compositors would provide the
Wayland API via DRM/KMS, while the BSD based compositor would provide the 
Wayland
via its ioctl. The application writer has one cross platform target - Wayland.

The second reason is HW identification. Different interfaces may well
identify the same element by different identifiers or in different
orders. If so, how does one know which corresponds with which ?
(i.e. which VideoLUT corresponds with which Output and/or CRTC, etc.)

> A possible advantage of leveraging more sophisticated capability than just a 
> LUT defined
> TRC in the video card, is the ability to do what high end displays are doing 
> now, where
> they expect (in fact insist) on linear video card LUT, and do their own 3D 
> LUT transform
> in the display itself. I don't know if this hardware is using an ASIC, but I 
> can give its
> user space software a CMYK ICC profile, and the software then creates a kind 
> of devicelink
> from CMYK to display RGB and pushes that 3D LUT to the display. I can play 
> movies and
> video in any program, and they are all subject to this lookup at playback 
> speed. The more
> common usage though is to make a wide gamut display have a smaller gamut, 
> e.g. Rec 709/sRGB.

Hmm. I have my doubts that any of the current or near future graphic cards offer
3D LUTs in hardware (although very doable using the GPU of course).

But the same logical problems with it being at all useful for display
from a general purpose computer platform remain as for a matrix
being available. I can imagine it being great for having the display
emulate a different colorspace in hardware, but a color managed
desktop doesn't want that - it wants to make the full display
capability available to every application, and each application
can then decide what colorspace it needs to emulate for its
particular inputs.

I can imagine using a hardware 3D LUT for some sort of super
advanced display calibration, where it is used to linearize
internally (although even this may be limited, since it
can't change the values at the gamut surface if it is
not to diminish the gamut or introduce "flat spots"), but
I'm not sure if the effort to exploit this capability would
be worthwhile, even if it became a widely available standard.

As for software to create some sort of virtual device link -
yes I've been thinking through some of those sorts of
scenarios in connection to the idea that a Wayland
color management extension support ICC device links, but there
is a drawback to splitting the overall conversion into
two cLUT lookups, and that is conversion quality. It's
noticeably higher quality to do a single lookup from
source to native display gamut. So the best usage of such
hardware is likely to be using the 1D LUTs to linearise,
and set matrix's and 3DLUTs to do nothing.

> The conventional wisdom using video LUTs for calibration came about with 
> CRTs. Pretty much
> all of that has to be thrown out with LCD's - they have a natural TRC that's 
> nothing like
> a CRT, what the manufacturers have done is glue in hard wired transform to 
> make them
> behave as if they have a native sRGB like TRC. Trying to unwind that with an 
> 8 bit (and in
> rare cases 10 bits today) to make them better behaved is pretty questionable, 
> and a huge
> assumption that we're in fact improving the display performance by 
> "calibrating" them by
> depending on video card LUTs in the first place. That is exactly why the high 
> end display
> don't use it at all. And for laptop displays my experience overwhelmingly has 
> been that
> changing the videocard LUT produces worse results than not calibrating it, 
> and just making
> an ICC profile and letting high precision display compensation sort it all 
> out.

OK - I'll take that on board sinc

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Daniel Stone wrote:

> (By way of example, Mesa does not usefully expose 10bpc formats for
> non-Intel drivers right now; the hardware and underlying drivers do;
> it's just a small bit of missing glue code. On the other hand, there
> is no silent jump between precision; it just wouldn't work.)

Right, so that's all (near) future stuff, whereas 10 bpc
VideoLUT output precision is rather old and currently
supported, even on ancient HW like my GeForce 8600 and
its predecessor. (So old in fact, that the D/A and VGA output
conveys that 10 bit to the display).

I'd also rather hope (but haven't had any confirmation)
that HW that permits 10 bpc frame buffers has 12 bit
VideoLUT precision

Graeme Gill.

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

Re: A solution for gamma-adjustment support in Wayland

[Graeme Gill]

Chris Murphy wrote:

Hi Chris,

> As for CIEXYZ, to literally convert pixels into this space, or even as an 
> exchange space,
> it will require minimum 16 bits per channel or there will be noticeable 
> quantization. It's
> a huge color space. You could maybe get away with 8 bit per channel CIE 
> L*a*b* but even
> that's questionable these days. I'm pretty sure there is an agreed upon 8 bit 
> encoding for
> Lab, but no agreed upon 8 bit encoding for XYZ.

Even ICC style 8 bit L*a*b* has a gamut that doesn't encompass
some real world display primaries. I'm making the assumption that
any very wide gamut space would be encoded to sufficient bit
resolution to be useful.

Cheers,

Graeme.

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

Re: A solution for gamma-adjustment support in Wayland

[Graeme Gill]

Mattias Andrée wrote:

Hi,

> Ideally I think the display server should support sRGB,
> CIE XYZ, and the monitors' native RGB for input. sRGB is
> useful for programs such as image viewers and video players.

Hmm. It's not a typical approach for a color managed workflow
to have hard wired colorspaces, but instead to allow them
to be configured, typically by using an ICC profile
to specify them.

> Native RGB is useful for utilising the full gamut,

Right, but the reaction so far is that Wayland can't/won't
allow this in any useful way, because the client isn't
allowed to know which output a native pixel will end up
on.

> and
> CIE XYZ is useful because almost all colour models can be
> converted to CIE XYZ in one step, it is device independent
> and can represent any visible colour.

Right, and using very wide gamut spaces like XYZ can also have
drawbacks, namely introducing more processing steps that reduce
fidelity (i.e. add inaccuracy and banding), as well
as potentially loosing control over gamut mapping
and clipping. i.e. they have their place, but they are not
a panacea.

> But of only supporting
> one colour space I think the monitors' native RGB should be
> used and that it is up to the application to find out one
> which monitor each part of the application's windows are
> visible and which colour space each monitor uses.

That's certainly the traditional way of doing it,
but some of the features of Wayland evidently make
such an approach less desirable.

> But supporting matrices is useful for filters such as
> simulating defective colour vision and changing colours
> to make it easier for people with defective colour vision
> to distinguish them.

Sure, and I'm reasonably certain that there are other
mechanisms available too, if a color managed workflow was
available, by suitable construction of input and/or
output device profiles. (This is an area that I'm
currently doing a little research into.)

Cheers,

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

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Daniel Stone wrote:

> (By way of example, Mesa does not usefully expose 10bpc formats for
> non-Intel drivers right now; the hardware and underlying drivers do;
> it's just a small bit of missing glue code. On the other hand, there
> is no silent jump between precision; it just wouldn't work.)

Right, so that's all (near) future stuff, whereas 10 bpc
VideoLUT output precision is rather old and currently
supported, even on ancient HW like my GeForce 8600 and
its predecessor. (So old in fact, that the D/A and VGA output
conveys that 10 bit to the display).

I'd also rather hope (but haven't had any confirmation)
that HW that permits 10 bpc frame buffers has 12 bit
VideoLUT precision, particularly with HDR now being a thing.

Graeme Gill.

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

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Daniel Stone wrote:

Hi Daniel,

> I would definitely benefit from seeing an expansion of some of the
> terminology that is thrown around which can be subtly misleading. But
> yes, as said, I've got some Christmas reading to do.

If anybody would like some concise explanations for color management
terms and concepts, I'm willing to so explain, as well as
provide references for more expansion or detail.
Being lucid enough to succeed in conveying comprehension
is another thing of course.

> Per my reply to Chris, some of those gaps can be filled in ways which
> are not obvious when coming from other environments. Trying to solve
> them in the exact same way would be bashing a square peg into a round
> hole, so it can be useful to step back and have a think about
> first-order requirements, rather than just jumping directly to deeply
> specific solutions.

Agreed - and this is something I'm trying to do as well, to outline
the big picture as the background that leads to specific suggestions.

>> I'm not sure what you mean by a "known-bad compositors",
>> nor do I really understand how this paints a false dichotomy.
> 
> By 'known-bad compositor', I speak of a compositor which, when
> processing information from clients, does so destructively. Such that
> the final output from the compositor (to any connected display, or
> screenshot/screencast, be it via means of direct scanout from a plane,
> or intermediate GPU rendering, or an intermediate hardware composition
> through a dedicated block, or software composition, or, or), produces
> incorrect results.

Incorrect in the sense of spatial rendering, or color values/fidelity or both ?

> A lot of the discussion on this thread seems aimed at ensuring
> compositors are not involved in colour management and colour-critical
> applications are forced to use external systems to route around them
> in order to achieve the desired colour result. This is a
> self-fulfilling prophecy.

That's not what I'm suggesting. Compositors have a vital
role in allowing different applications to share a desktop,
as well as help applications and toolkits compose and
operate a GUI. But that is all about buffer management,
spatial rendering and coordination of updates. Transparency
and color encoding formats starts to dip into some color
related aspects, but only in a simple way that isn't related
to the colorimetry. A color managed workflow is about how
color is best preserved between different device dependent
color spaces, and in the context of a display system driven
by applications, this is primarily about the color spaces the
application takes in, or defines its own colors in, and the
display colorspace. (And lets be clear, when I say "colorspace"
here I'm speaking of the colorimetry, tonal response and color
mixing characteristics represented by the (often) RGB values,
although applications in general will deal with many other
types of input colorspaces such as CMYK, device independent
colorspaces, multi-channel spaces, etc. etc.)

> Yes, but it's also how you work with people. Security had the same
> issue for the longest time, where there were application/system
> people, and then there were security people, and the only time they
> met was to tell each other that they didn't live in the real world. I
> desperately want to avoid colour management remaining a ghetto where
> the only way to get correct results is via complex external systems
> which attempt to route around the underlying display pipeline. I want
> it to be a first-class part of our system. But this thread is not a
> good start.

Agreed it's not a good start, and I guess the gulf in
understanding is far wider than I have imagined from my
normal technical interactions with people.

> Simply providing video LUT data and nothing else is not a complete
> solution, because it means GPU-based composition pipelines (they do
> exist for non-alpha-blended cases too) are unaware of colourspace, and
> are thus liable to be destructive to the end result, especially if
> they attempt to do things such as taking clients with no explicit
> source information to be in sRGB colourspace.

I'm not sure what you are alluding to. A compositor pipeline
that alters color values in arbitrary ways will of course
make a color managed workflow difficult to impossible,
but what sort of compositor processing do you anticipate will
do this kind of thing ?

> That you keep saying 'program the video LUT' makes me think you
> perhaps do not realise the full complexity of colour management in
> modern display hardware (again, see other thread). This includes that
> LUTs can sometimes be applied on a per-plane basis as well as
> per-output.

Right - so this is perhaps something that might be made more
flexible. Currently it's kind of random whether things like video
overlay planes get VideoLUT curves applied to them or not, depending
on the hardware capability and/or diligence or understanding of the
driver writers.

> The last part is important,

Re: [PATCH libinput 0/5] Disable laptop touchpad on lid close

[Peter Hutterer]

On Thu, Jan 05, 2017 at 05:11:24PM +1100, James Ye wrote:
> Although a laptop touchpad is usually not accessible when the lid is closed,
> some laptop models suffer from a hardware bug where the touchpad can be
> activated even if the lid is closed.  This bug can be worked around by 
> disabling
> the touchpad when the lid is closed.
> 
> This patch set adds:
> 1: hwdb patch to mark switches as input devices (needs to go to systemd)
> 2: switch interface[1]
> 3: evdev dispatch interface for laptop lid switches
> 4: mechanism for pairing touchpad with lid, and disabling the touchpad
> 5: test cases
> 
> Best regards,
> James Ye

thanks for picking this up, much appreciated. The patches look good bar a
few minor nitpicks and a few test cases we should add. But the series even
*has* test cases, so there's really very little I can complain about :)

One thing I found missing when I reviewed the tests: we don't sync the
status of the switch on startup. There are two options here (either can be a
follow-up patch):
* send a switch toggle event immediately after DEVICE_ADDED on startup.
  That's in-line with the other events and iirc also what we do for
  proximity if a tablet tool is already in proximity on device added.
* add a libinput_device_switch_get_state() function for callers to query the
  state if they need it and only send the actual changes after we have a
  context initialised. That has a small potential for race conditions, so
  I'm tending to the first option

Carlos, Jonas, Hans, any opinions?

Cheers,
   Peter

> 
> [1]: 
> https://lists.freedesktop.org/archives/wayland-devel/2016-January/026349.html
> 
> James Ye (5):
>   udev: mark switches as input devices
>   Add a "switch" interface for parts of the SW_* range
>   Add evdev_dispatch interface for lid switch
>   Pair touchpad and lid_switch for disable
>   test: add tests for lid switch
> 
>  doc/Makefile.am|   1 +
>  doc/switches.dox   |  13 +++
>  src/evdev-mt-touchpad.c|  47 
>  src/evdev-mt-touchpad.h|   5 +
>  src/evdev.c|  92 ++-
>  src/evdev.h|   8 ++
>  src/libinput-private.h |   5 +
>  src/libinput.c | 103 +
>  src/libinput.h | 107 +
>  src/libinput.sym   |   9 ++
>  test/Makefile.am   |   4 +-
>  test/lid.c | 228 
> +
>  test/litest-device-lid-switch.c|  58 ++
>  test/litest.c  |  31 +
>  test/litest.h  |  10 ++
>  tools/event-debug.c|  34 ++
>  udev/90-libinput-model-quirks.hwdb |   6 +
>  17 files changed, 758 insertions(+), 3 deletions(-)
>  create mode 100644 doc/switches.dox
>  create mode 100644 test/lid.c
>  create mode 100644 test/litest-device-lid-switch.c
> 
> -- 
> 2.9.3
> 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput 2/5] Add a "switch" interface for parts of the SW_* range

[Peter Hutterer]

On Thu, Jan 05, 2017 at 05:11:26PM +1100, James Ye wrote:
> Adapted from:
> https://lists.freedesktop.org/archives/wayland-devel/2016-January/026349.html

Note: libinput requires patches to be signed-off please, thanks.

Only two doxygen nitpicks here, but given the diffstat to the patch you
linked to I'd like at least a Co-authored-by: for me ;)

and please also link to the bug report and expand the commit message to
contain enough information of what's planned. Most of that is available from
the patch above.

[...]

>  /**
> + * @ingroup device
> + *
> + * The state of a switch.
> + */
> +enum libinput_switch_state {
> + LIBINPUT_SWITCH_STATE_OFF = 0,
> + LIBINPUT_SWITCH_STATE_ON = 1,
> +};
> +
> +/**
> + * @ingroup device
> + *
> + * The type of a switch.
> + */
> +enum libinput_switch {
> + /**
> +  * The laptop lid was closed (LIBINPUT_SWITCH_STATE_ON) or opened
> +  * (LIBINPUT_SWITCH_STATE_OFF).

Add @ref before the enum values so doxygen can pick them up

> +  */
> + LIBINPUT_SWITCH_LID = 1,
> + /**
> +  * The device was switched to or from tablet mode, usually by
> +  * rotating the screen and fixating it in place over the keyboard so
> +  * that the device now looks like a tablet.
> +  */
> + LIBINPUT_SWITCH_TABLET_MODE = 2,

Please add which mode corresponds to the switch state.

> +};
> +
> +/**
> + * @ingroup event_switch
> + * @struct libinput_event_switch
> + *
> + * A switch event representing a changed state in a switch.
> + */
> +struct libinput_event_switch;
> +
> +/**
>   * @ingroup base
>   *
>   * Event type for events returned by libinput_get_event().
> @@ -746,6 +784,8 @@ enum libinput_event_type {
>   LIBINPUT_EVENT_GESTURE_PINCH_BEGIN,
>   LIBINPUT_EVENT_GESTURE_PINCH_UPDATE,
>   LIBINPUT_EVENT_GESTURE_PINCH_END,
> +
> + LIBINPUT_EVENT_SWITCH_TOGGLE = 900,
>  };
>  
>  /**
> @@ -883,6 +923,17 @@ struct libinput_event_tablet_pad *
>  libinput_event_get_tablet_pad_event(struct libinput_event *event);
>  
>  /**
> + * Return the switch event that is this input event. If the event type does
> + * not match the switch event types, this function returns NULL.
> + *
> + * The inverse of this function is libinput_event_switch_get_base_event().
> + *
> + * @return A switch event, or NULL for other events
> + */
> +struct libinput_event_switch *
> +libinput_event_get_switch_event(struct libinput_event *event);
> +
> +/**
>   * @ingroup event
>   *
>   * Return the device event that is this input event. If the event type does
> @@ -2684,6 +2735,62 @@ uint64_t
>  libinput_event_tablet_pad_get_time_usec(struct libinput_event_tablet_pad 
> *event);
>  
>  /**
> + * @ingroup event_switch
> + *
> + * Return the switch that triggered this event.
> + * For pointer events that are not of type @ref
> + * LIBINPUT_EVENT_SWITCH_TOGGLE, this function returns 0.
> + *
> + * @note It is an application bug to call this function for events other than
> + * @ref LIBINPUT_EVENT_SWITCH_TOGGLE.
> + *
> + * @return The switch triggering this event
> + */
> +enum libinput_switch
> +libinput_event_switch_get_switch(struct libinput_event_switch *event);

double-check with the other event functions to see if we usually document
@param for them. I think we do, let's keep it consistent.

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

Re: [PATCH libinput 5/5] test: add tests for lid switch

[Peter Hutterer]

On Thu, Jan 05, 2017 at 05:11:29PM +1100, James Ye wrote:
> ---
>  test/Makefile.am|   4 +-
>  test/lid.c  | 228 
> 
>  test/litest-device-lid-switch.c |  58 ++
>  test/litest.c   |  28 +
>  test/litest.h   |  10 ++
>  5 files changed, 327 insertions(+), 1 deletion(-)
>  create mode 100644 test/lid.c
>  create mode 100644 test/litest-device-lid-switch.c
> 
> diff --git a/test/Makefile.am b/test/Makefile.am
> index 983264c..94978b9 100644
> --- a/test/Makefile.am
> +++ b/test/Makefile.am
> @@ -32,6 +32,7 @@ liblitest_la_SOURCES = \
>   litest-device-keyboard.c \
>   litest-device-keyboard-all-codes.c \
>   litest-device-keyboard-razer-blackwidow.c \
> + litest-device-lid-switch.c \
>   litest-device-logitech-trackball.c \
>   litest-device-nexus4-touch-screen.c \
>   litest-device-magic-trackpad.c \
> @@ -114,7 +115,8 @@ libinput_test_suite_runner_SOURCES = udev.c \
>misc.c \
>keyboard.c \
>device.c \
> -  gestures.c
> +  gestures.c \
> +  lid.c
>  
>  libinput_test_suite_runner_CFLAGS = $(AM_CFLAGS) 
> -DLIBINPUT_LT_VERSION="\"$(LIBINPUT_LT_VERSION)\""
>  libinput_test_suite_runner_LDADD = $(TEST_LIBS)
> diff --git a/test/lid.c b/test/lid.c
> new file mode 100644
> index 000..459c7d7
> --- /dev/null
> +++ b/test/lid.c
> @@ -0,0 +1,228 @@
> +/*
> + * Copyright © 2017 James Ye 
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include 
> +
> +#include 
> +#include 
> +
> +#include "libinput-util.h"
> +#include "litest.h"
> +
> +START_TEST(lid_switch)
> +{
> + struct litest_device *sw = litest_current_device();
> + struct libinput *li = sw->libinput;
> + struct libinput_event *event;
> +
> + litest_drain_events(li);
> +
> + /* lid closed */
> + litest_lid_action(sw, LIBINPUT_SWITCH_STATE_ON);
> + libinput_dispatch(li);
> +
> + event = libinput_get_event(li);
> + litest_is_switch_event(event, LIBINPUT_SWITCH_STATE_ON);

pls check that the switch is correctly set to the LIBINPUT_SWITCH_LID

> + libinput_event_destroy(event);
> +
> + /* lid opened */
> + litest_lid_action(sw, LIBINPUT_SWITCH_STATE_OFF);
> + libinput_dispatch(li);
> +
> + event = libinput_get_event(li);
> + litest_is_switch_event(event, LIBINPUT_SWITCH_STATE_OFF);
> + libinput_event_destroy(event);

same here.

and add a trailing litest_assert_empty_queue() so we check for accidental
other events.

> +}
> +END_TEST
> +
> +static inline struct litest_device *
> +lid_init_paired_touchpad(struct libinput *li)
> +{
> + enum litest_device_type which = LITEST_SYNAPTICS_I2C;
> +
> + return litest_add_device(li, which);
> +}
> +
> +START_TEST(lid_disable_touchpad)
> +{
> + struct litest_device *sw = litest_current_device();
> + struct litest_device *touchpad;
> + struct libinput *li = sw->libinput;
> +
> + touchpad = lid_init_paired_touchpad(li);
> + litest_disable_tap(touchpad->libinput_device);
> + litest_drain_events(li);
> +
> + /* lid is down - no events */
> + litest_lid_action(sw, LIBINPUT_SWITCH_STATE_ON);
> + litest_assert_only_typed_events(li, LIBINPUT_EVENT_SWITCH_TOGGLE);
> +
> + litest_touch_down(touchpad, 0, 50, 50);
> + litest_touch_move_to(touchpad, 0, 50, 50, 70, 50, 10, 1);
> + litest_touch_up(touchpad, 0);
> + litest_assert_empty_queue(li);
> +
> + /* lid is up - motion events */
> + litest_lid_action(sw, LIBINPUT_SWITCH_STATE_OFF);
> + litest_assert_only_typed_events(li, LIBINPUT_EVENT_SWITCH_TOGGLE);
> +
> + litest_touch_down(touchpad, 0

Re: [PATCH libinput 3/5] Add evdev_dispatch interface for lid switch

[Peter Hutterer]

On Thu, Jan 05, 2017 at 05:11:27PM +1100, James Ye wrote:
> Create a lid_switch_interface to handle lid switch events, so touchpad

typo: so *the* touchpad ...

> can be disabled when lid is closed.
> ---
>  src/evdev.c | 92 
> +++--
>  src/evdev.h |  8 ++
>  2 files changed, 98 insertions(+), 2 deletions(-)
> 
> diff --git a/src/evdev.c b/src/evdev.c
> index c06daa6..94b1a2e 100644
> --- a/src/evdev.c
> +++ b/src/evdev.c
> @@ -68,6 +68,7 @@ enum evdev_device_udev_tags {
>  EVDEV_UDEV_TAG_TABLET_PAD = (1 << 8),
>  EVDEV_UDEV_TAG_POINTINGSTICK = (1 << 9),
>  EVDEV_UDEV_TAG_TRACKBALL = (1 << 10),
> +EVDEV_UDEV_TAG_SWITCH = (1 << 11),
>  };
>  
>  struct evdev_udev_tag_match {
> @@ -88,6 +89,7 @@ static const struct evdev_udev_tag_match 
> evdev_udev_tag_matches[] = {
>   {"ID_INPUT_ACCELEROMETER",  EVDEV_UDEV_TAG_ACCELEROMETER},
>   {"ID_INPUT_POINTINGSTICK",  EVDEV_UDEV_TAG_POINTINGSTICK},
>   {"ID_INPUT_TRACKBALL",  EVDEV_UDEV_TAG_TRACKBALL},
> + {"ID_INPUT_SWITCH", EVDEV_UDEV_TAG_SWITCH},
>  
>   /* sentinel value */
>   { 0 },
> @@ -1072,6 +1074,13 @@ evdev_tag_keyboard(struct evdev_device *device,
>  }
>  
>  static void
> +evdev_tag_lid_switch(struct evdev_device *device,
> +  struct udev_device *udev_device)
> +{
> + device->tags |= EVDEV_TAG_LID_SWITCH;
> +}
> +
> +static void
>  fallback_process(struct evdev_dispatch *evdev_dispatch,
>struct evdev_device *device,
>struct input_event *event,
> @@ -1113,6 +1122,31 @@ fallback_process(struct evdev_dispatch *evdev_dispatch,
>  }
>  
>  static void
> +lid_switch_process(struct evdev_dispatch *evdev_dispatch,
> +struct evdev_device *device,
> +struct input_event *event,
> +uint64_t time)
> +{
> + struct lid_switch_dispatch *dispatch = (struct 
> lid_switch_dispatch*)evdev_dispatch;

all these need to be split over two lines to fit within the limits

> +
> + switch (event->type) {
> + case EV_SW:
> + dispatch->lid_is_closed = event->value;

use !!event->value here to make sure/obvious it's a boolean.

> +
> + switch_notify_toggle(&device->base,
> +  time,
> +  LIBINPUT_SWITCH_LID,
> +  dispatch->lid_is_closed);
> + break;
> + case EV_SYN:
> + break;
> + default:
> + assert(0 && "Unknown event type");
> + break;
> + }
> +}
> +
> +static void
>  release_touches(struct fallback_dispatch *dispatch,
>   struct evdev_device *device,
>   uint64_t time)
> @@ -1237,6 +1271,14 @@ fallback_destroy(struct evdev_dispatch *evdev_dispatch)
>   free(dispatch);
>  }
>  
> +static void
> +lid_switch_destroy(struct evdev_dispatch *evdev_dispatch)
> +{
> + struct lid_switch_dispatch *dispatch = (struct 
> lid_switch_dispatch*)evdev_dispatch;
> +
> + free(dispatch);
> +}
> +
>  static int
>  evdev_calibration_has_matrix(struct libinput_device *libinput_device)
>  {
> @@ -1291,6 +1333,19 @@ struct evdev_dispatch_interface fallback_interface = {
>   fallback_toggle_touch, /* toggle_touch */
>  };
>  
> +struct evdev_dispatch_interface lid_switch_interface = {
> + lid_switch_process,
> + NULL, /* suspend */
> + NULL, /* remove */
> + lid_switch_destroy,
> + NULL, /* device_added */
> + NULL, /* device_removed */
> + NULL, /* device_suspended */
> + NULL, /* device_resumed */
> + NULL, /* post_added */
> + NULL, /* toggle_touch */
> +};
> +
>  static uint32_t
>  evdev_sendevents_get_modes(struct libinput_device *device)
>  {
> @@ -1800,6 +1855,25 @@ fallback_dispatch_create(struct libinput_device 
> *device)
>   return &dispatch->base;
>  }
>  
> +static struct evdev_dispatch *
> +lid_switch_dispatch_create(struct libinput_device *device)
> +{
> + struct lid_switch_dispatch *dispatch = zalloc(sizeof *dispatch);
> + struct evdev_device *lid_device = (struct evdev_device *)device;
> +
> + if (dispatch == NULL)
> + return NULL;
> +
> + dispatch->base.interface = &lid_switch_interface;
> +
> + evdev_init_sendevents(lid_device, &dispatch->base);
> +
> + dispatch->lid_is_closed = 0;

'false' instead of 0 for booleans

> +
> + return &dispatch->base;
> +}
> +
> +
>  static inline void
>  evdev_process_event(struct evdev_device *device, struct input_event *e)
>  {
> @@ -2508,7 +2582,7 @@ evdev_configure_device(struct evdev_device *device)
>   }
>  
>   log_info(libinput,
> -  "input device '%s', %s is tagged by udev 
> as:%s%s%s%s%s%s%s%s%s%s\n",
> +  "input device '%s', %s is tagged by udev 
> as:%s%s%s%s%s%s%s%s%s%s%s\n",
>device->devname, devnode,
>udev_tags & EVDEV_UDEV_TA

Re: [PATCH libinput 1/5] udev: mark switches as input devices

[Peter Hutterer]

On Thu, Jan 05, 2017 at 05:11:25PM +1100, James Ye wrote:
> ---

fwiw, I have the required bits here
https://github.com/whot/systemd/tree/wip/ID_INPUT_SWITCH

I'll get the upstream as soon as we're happy with this set

Cheers,
   Peter

>  udev/90-libinput-model-quirks.hwdb | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/udev/90-libinput-model-quirks.hwdb 
> b/udev/90-libinput-model-quirks.hwdb
> index eb74f61..f038144 100644
> --- a/udev/90-libinput-model-quirks.hwdb
> +++ b/udev/90-libinput-model-quirks.hwdb
> @@ -15,6 +15,12 @@
>  #libinput:name::fwversion:
>  #
>  # Sort by brand, model
> +#
> +
> +
> +# TEMPORARY UNTIL SYSTEMD HAS THIS PATCH
> +libinput:name:*Switch*
> + ID_INPUT_SWITCH=1
>  
>  ##
>  # ALPS
> -- 
> 2.9.3
> 
> ___
> 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