RE: Using EGL drivers in Weston without FBDev

2017-05-23 Thread Keskinarkaus, Teemu 
Hi,

I'm not sure if Yocto 2.3 has new enough version of Mesa and kernel for that. 
Seems that it defaults to Weston 1.11 so I'd assume no. Also I got impression 
that NXP versions of drivers support HW better (graphics work faster etc. 
maybe?). That I don't have my own experience so just relying what I've read.

But anyway thanks. Now I have something to go forward.

-Teemu Keskinarkaus

-Original Message-
From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On 
Behalf Of Daniel Stone
Sent: 23. toukokuuta 2017 10:04
To: Keskinarkaus, Teemu
Cc: wayland-devel@lists.freedesktop.org
Subject: Re: Using EGL drivers in Weston without FBDev

Hi Teemu,

On 23 May 2017 at 05:33, Keskinarkaus, Teemu 
 wrote:
> I just ran into this although support was dropped almost a year ago.
>
> Since FBDEV no longer has EGL ‘hackery’ support, what is then the ‘proper’
> way to use EGL drivers?  ie. What way they _should_ be used?
>
> I’m in no way expert in this whole Wayland/Weston/driver thing so
> that’s why I’m asking.
>
> We are currently using Weston in iMX6 based HW and NXP currently has
> only EGL/FBdev drivers available that’s why I ran to problems with
> Wayland/Weston when trying to upgrade to Weston 2.0.

The recommended way is to use EGL on top of KMS (kernel modesetting), the 
combination of which is called GBM. This is what's implemented by Mesa, and 
also several other drivers including ARM Mali.

The last time I saw NXP i.MX code for Weston, it was a fork of Weston using 
their own API for rendering and buffer management. I don't know if this ever 
got ported forward to newer versions, so you'd probably be needing to use their 
tree anyway. I know this isn't the advice you were hoping to get, but I would 
strongly recommend contacting NXP and asking them to support KMS and GBM like 
everyone else.

The good news is that the 'Etnaviv' and imx-drm drivers inside Mesa and the 
mainline Linux kernel work just fine, so if you use very new versions of Mesa 
and the kernel, there should be no need to run NXP's fork of Weston and their 
EGL drivers.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fwayland-devel&data=02%7C01%7Cteemu.keskinarkaus%40crosscontrol.com%7C2954ee0ac4564fe0ab6b08d4a1a9ee21%7C1602ae82026640d6910b11680fe0f6a5%7C0%7C0%7C636311198587709141&sdata=bwzA1B1u2Bk88SdS2AJJtcqYk05ChzyETPIwAHXarvo%3D&reserved=0



Actuant Corporation Email Notice

This message is intended only for the use of the Addressee and may contain 
information that is PRIVILEGED and/or CONFIDENTIAL.
This email is intended only for the personal and confidential use of the 
recipient(s) named above. If the reader of this email is not an intended 
recipient, you have received this email in error and any review, dissemination, 
distribution or copying is strictly prohibited.
If you have received this email in error, please notify the sender immediately 
by return mail and permanently delete the copy you received.

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

[PATCH libinput 2/5] evdev: read LIBINPUT_ATTR_KEYBOARD_INTEGRATION property

2017-05-23 Thread Peter Hutterer 
We have heuristics for detecting whether a keyboard is internal or external,
but in some cases (e.g. Surface 3) these heuristics fail. Add a udev property
that we can apply to these cases so we have something that's reliable.

This will likely eventually become ID_INPUT_KEYBOARD_INTEGRATION as shipped by
systemd, similar to the touchpad property.

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

Signed-off-by: Peter Hutterer 
---
 src/evdev-mt-touchpad.c|  3 +--
 src/evdev.c| 31 ++-
 src/evdev.h|  3 ++-
 udev/90-libinput-model-quirks.hwdb | 12 +++-
 udev/90-libinput-model-quirks.rules.in |  4 
 udev/parse_hwdb.py |  9 +++--
 6 files changed, 55 insertions(+), 7 deletions(-)

diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 17b14bc8..e5f2a5ce 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -1601,8 +1601,7 @@ tp_want_dwt(struct evdev_device *touchpad,
/* For Apple touchpads, always use its internal keyboard */
if (vendor_tp == VENDOR_ID_APPLE) {
return vendor_kbd == vendor_tp &&
-  keyboard->model_flags &
-   EVDEV_MODEL_APPLE_INTERNAL_KEYBOARD;
+  keyboard->tags & EVDEV_TAG_INTERNAL_KEYBOARD;
}
 
/* everything else we don't really know, so we have to assume
diff --git a/src/evdev.c b/src/evdev.c
index f7a019c6..02ed4f1a 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1089,10 +1089,25 @@ evdev_tag_trackpoint(struct evdev_device *device,
device->tags |= EVDEV_TAG_TRACKPOINT;
 }
 
+static inline void
+evdev_tag_keyboard_internal(struct evdev_device *device)
+{
+   device->tags |= EVDEV_TAG_INTERNAL_KEYBOARD;
+   device->tags &= ~EVDEV_TAG_EXTERNAL_KEYBOARD;
+}
+
+static inline void
+evdev_tag_keyboard_external(struct evdev_device *device)
+{
+   device->tags |= EVDEV_TAG_EXTERNAL_KEYBOARD;
+   device->tags &= ~EVDEV_TAG_INTERNAL_KEYBOARD;
+}
+
 static void
 evdev_tag_keyboard(struct evdev_device *device,
   struct udev_device *udev_device)
 {
+   const char *prop;
int code;
 
if (!libevdev_has_event_type(device->evdev, EV_KEY))
@@ -1105,6 +1120,21 @@ evdev_tag_keyboard(struct evdev_device *device,
return;
}
 
+   /* This should eventually become ID_INPUT_KEYBOARD_INTEGRATION */
+   prop = udev_device_get_property_value(udev_device,
+ 
"LIBINPUT_ATTR_KEYBOARD_INTEGRATION");
+   if (prop) {
+   if (streq(prop, "internal")) {
+   evdev_tag_keyboard_internal(device);
+   } else if (streq(prop, "external")) {
+   evdev_tag_keyboard_external(device);
+   } else {
+   evdev_log_info(device,
+  "tagged with unknown value %s\n",
+  prop);
+   }
+   }
+
device->tags |= EVDEV_TAG_KEYBOARD;
 }
 
@@ -2251,7 +2281,6 @@ evdev_read_model_flags(struct evdev_device *device)
MODEL(ALPS_TOUCHPAD),
MODEL(SYNAPTICS_SERIAL_TOUCHPAD),
MODEL(JUMPING_SEMI_MT),
-   MODEL(APPLE_INTERNAL_KEYBOARD),
MODEL(CYBORG_RAT),
MODEL(HP_STREAM11_TOUCHPAD),
MODEL(LENOVO_T450_TOUCHPAD),
diff --git a/src/evdev.h b/src/evdev.h
index a5c11fc3..b891f906 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -73,6 +73,8 @@ enum evdev_device_tags {
EVDEV_TAG_TRACKPOINT = (1 << 3),
EVDEV_TAG_KEYBOARD = (1 << 4),
EVDEV_TAG_LID_SWITCH = (1 << 5),
+   EVDEV_TAG_INTERNAL_KEYBOARD = (1 << 6),
+   EVDEV_TAG_EXTERNAL_KEYBOARD = (1 << 7),
 };
 
 enum evdev_middlebutton_state {
@@ -112,7 +114,6 @@ enum evdev_device_model {
EVDEV_MODEL_SYNAPTICS_SERIAL_TOUCHPAD = (1 << 9),
EVDEV_MODEL_JUMPING_SEMI_MT = (1 << 10),
EVDEV_MODEL_LENOVO_X220_TOUCHPAD_FW81 = (1 << 12),
-   EVDEV_MODEL_APPLE_INTERNAL_KEYBOARD = (1 << 13),
EVDEV_MODEL_CYBORG_RAT = (1 << 14),
EVDEV_MODEL_HP_STREAM11_TOUCHPAD = (1 << 16),
EVDEV_MODEL_LENOVO_T450_TOUCHPAD= (1 << 17),
diff --git a/udev/90-libinput-model-quirks.hwdb 
b/udev/90-libinput-model-quirks.hwdb
index 3f048092..229fb1de 100644
--- a/udev/90-libinput-model-quirks.hwdb
+++ b/udev/90-libinput-model-quirks.hwdb
@@ -26,6 +26,12 @@ libinput:name:*Lid Switch*:dmi:*:ct9:*
  LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=reliable
 
 ##
+# Serial keyboards are internal
+##
+libinput:keyboard:input:b0011v*
+ LIBINPUT_ATTR_KEYBOARD_INTEGRATION=internal
+
+##
 # ALPS
 ##
 libinput:name:*Al

[PATCH libinput 5/5] lid: setup the keyboard notifier when pairing it

2017-05-23 Thread Peter Hutterer 
From: Benjamin Tissoires 

On unreliable LID switches, we might have the LID declared as closed
while it is actually not. We can not wait for the first switch event to setup
the keyboard listener: it will never occur.

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

Signed-off-by: Benjamin Tissoires 
Signed-off-by: Peter Hutterer 
---
 src/evdev-lid.c |  7 +--
 test/test-lid.c | 51 +++
 2 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/src/evdev-lid.c b/src/evdev-lid.c
index 010cb42d..fe98e6e1 100644
--- a/src/evdev-lid.c
+++ b/src/evdev-lid.c
@@ -224,8 +224,11 @@ lid_switch_pair_keyboard(struct evdev_device *lid_switch,
lid_switch->devname,
keyboard->devname);
 
-   /* We don't init the event listener yet - we don't care
-* about keyboard events until the lid is closed */
+   /* We need to init the event listener now only if the reported 
state
+* is closed. */
+   if (dispatch->lid_is_closed)
+   lid_switch_toggle_keyboard_listener(dispatch,
+   dispatch->lid_is_closed);
}
 }
 
diff --git a/test/test-lid.c b/test/test-lid.c
index 1bd75cb6..4bf4c059 100644
--- a/test/test-lid.c
+++ b/test/test-lid.c
@@ -505,6 +505,56 @@ START_TEST(lid_update_hw_on_key)
 }
 END_TEST
 
+START_TEST(lid_update_hw_on_key_closed_on_init)
+{
+   struct litest_device *sw = litest_current_device();
+   struct libinput *li;
+   struct litest_device *keyboard;
+   struct libevdev *evdev = sw->evdev;
+   struct input_event ev;
+
+   litest_lid_action(sw, LIBINPUT_SWITCH_STATE_ON);
+
+   /* Make sure kernel state is right */
+   libevdev_next_event(evdev, LIBEVDEV_READ_FLAG_FORCE_SYNC, &ev);
+   while (libevdev_next_event(evdev, LIBEVDEV_READ_FLAG_SYNC, &ev) >= 0)
+   ;
+   ck_assert(libevdev_get_event_value(evdev, EV_SW, SW_LID));
+
+   keyboard = litest_add_device(sw->libinput, LITEST_KEYBOARD);
+
+   /* separate context for the right state on init */
+   li = litest_create_context();
+   libinput_path_add_device(li,
+libevdev_uinput_get_devnode(sw->uinput));
+   libinput_path_add_device(li,
+libevdev_uinput_get_devnode(keyboard->uinput));
+
+   /* don't expect a switch waiting for us */
+   while (libinput_next_event_type(li) != LIBINPUT_EVENT_NONE) {
+   ck_assert_int_ne(libinput_next_event_type(li),
+LIBINPUT_EVENT_SWITCH_TOGGLE);
+   libinput_event_destroy(libinput_get_event(li));
+   }
+
+   litest_event(keyboard, EV_KEY, KEY_A, 1);
+   litest_event(keyboard, EV_SYN, SYN_REPORT, 0);
+   litest_event(keyboard, EV_KEY, KEY_A, 0);
+   litest_event(keyboard, EV_SYN, SYN_REPORT, 0);
+   /* No switch event, we're still in vanilla (open) state */
+   litest_assert_only_typed_events(li, LIBINPUT_EVENT_KEYBOARD_KEY);
+
+   /* Make sure kernel state has updated */
+   libevdev_next_event(evdev, LIBEVDEV_READ_FLAG_FORCE_SYNC, &ev);
+   while (libevdev_next_event(evdev, LIBEVDEV_READ_FLAG_SYNC, &ev) >= 0)
+   ;
+   ck_assert(!libevdev_get_event_value(evdev, EV_SW, SW_LID));
+
+   libinput_unref(li);
+   litest_delete_device(keyboard);
+}
+END_TEST
+
 void
 litest_setup_tests_lid(void)
 {
@@ -525,4 +575,5 @@ litest_setup_tests_lid(void)
litest_add_no_device("lid:disable_touchpad", lid_suspend_with_touchpad);
 
litest_add_for_device("lid:buggy", lid_update_hw_on_key, 
LITEST_LID_SWITCH_SURFACE3);
+   litest_add_for_device("lid:buggy", lid_update_hw_on_key_closed_on_init, 
LITEST_LID_SWITCH_SURFACE3);
 }
-- 
2.13.0

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

[PATCH libinput 1/5] lid: add a comment for why we post the switch state there

2017-05-23 Thread Peter Hutterer 
Signed-off-by: Peter Hutterer 
---
 src/evdev-lid.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/evdev-lid.c b/src/evdev-lid.c
index 9e694ba1..9815b8fa 100644
--- a/src/evdev-lid.c
+++ b/src/evdev-lid.c
@@ -74,6 +74,10 @@ lid_switch_keyboard_event(uint64_t time,
 * regardless. */
}
 
+   /* Posting the event here means we preempt the keyboard events that
+* caused us to wake up, so the lid event is always passed on before
+* the key event.
+*/
dispatch->lid_is_closed = false;
switch_notify_toggle(&dispatch->device->base,
 time,
-- 
2.13.0

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

[PATCH libinput 3/5] lid: tighten the lid-keyboard pairing

2017-05-23 Thread Peter Hutterer 
Only pair if the keyboard is either tagged as internal device.

This has another (unlikely) behaviour change: previously we would override the
paired keyboards with ones that look more accurate (e.g. a usb keyboard paired
before a serial would be unpaired and the serial keyboard takes its place).
Now we assume there can only be one internal keyboard, once we have it we
ignore all others. This shouldn't matter in real life provided the tagging is
correct.

Signed-off-by: Peter Hutterer 
---
 src/evdev-lid.c | 28 +++-
 1 file changed, 11 insertions(+), 17 deletions(-)

diff --git a/src/evdev-lid.c b/src/evdev-lid.c
index 9815b8fa..80907801 100644
--- a/src/evdev-lid.c
+++ b/src/evdev-lid.c
@@ -202,29 +202,23 @@ lid_switch_pair_keyboard(struct evdev_device *lid_switch,
 {
struct lid_switch_dispatch *dispatch =
lid_dispatch(lid_switch->dispatch);
-   unsigned int bus_kbd = libevdev_get_id_bustype(keyboard->evdev);
 
if ((keyboard->tags & EVDEV_TAG_KEYBOARD) == 0)
return;
 
-   /* If we already have a keyboard paired, override it if the new one
-* is a serio device. Otherwise keep the current one */
-   if (dispatch->keyboard.keyboard) {
-   if (bus_kbd != BUS_I8042)
-   return;
+   if (dispatch->keyboard.keyboard)
+   return;
 
-   
libinput_device_remove_event_listener(&dispatch->keyboard.listener);
-   
libinput_device_init_event_listener(&dispatch->keyboard.listener);
+   if (keyboard->tags & EVDEV_TAG_INTERNAL_KEYBOARD) {
+   dispatch->keyboard.keyboard = keyboard;
+   evdev_log_debug(lid_switch,
+   "lid: keyboard paired with %s<->%s\n",
+   lid_switch->devname,
+   keyboard->devname);
+
+   /* We don't init the event listener yet - we don't care
+* about keyboard events until the lid is closed */
}
-
-   dispatch->keyboard.keyboard = keyboard;
-   evdev_log_debug(lid_switch,
-   "lid: keyboard paired with %s<->%s\n",
-   lid_switch->devname,
-   keyboard->devname);
-
-   /* We don't init the event listener yet - we don't care about
-* keyboard events until the lid is closed */
 }
 
 static void
-- 
2.13.0

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

[PATCH libinput 4/5] lid: track the notifier initial state internally, but not externally

2017-05-23 Thread Peter Hutterer 
From: Benjamin Tissoires 

What we do not want is libinput to believe the LID is closed while
it's not. But the internal notifier state need to be in sync with the evdev
node, or it's going to be a pain setting the keyboard listener.

But since we don't know if the state is reliable, we track the internal state
separately from the external state so that we can set up the keyboard listener
when the lid is closed, without having libinput actually send lid closed
events for unreliable devices.

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

Signed-off-by: Benjamin Tissoires 
Signed-off-by: Peter Hutterer 
---
 src/evdev-lid.c | 49 +++--
 1 file changed, 23 insertions(+), 26 deletions(-)

diff --git a/src/evdev-lid.c b/src/evdev-lid.c
index 80907801..010cb42d 100644
--- a/src/evdev-lid.c
+++ b/src/evdev-lid.c
@@ -34,6 +34,7 @@ struct lid_switch_dispatch {
enum switch_reliability reliability;
 
bool lid_is_closed;
+   bool lid_is_closed_client_state;
 
struct {
struct evdev_device *keyboard;
@@ -50,6 +51,20 @@ lid_dispatch(struct evdev_dispatch *dispatch)
 }
 
 static void
+lid_switch_notify_toggle(struct lid_switch_dispatch *dispatch,
+struct evdev_device *device,
+uint64_t time)
+{
+   if (dispatch->lid_is_closed ^ dispatch->lid_is_closed_client_state) {
+   switch_notify_toggle(&device->base,
+time,
+LIBINPUT_SWITCH_LID,
+dispatch->lid_is_closed);
+   dispatch->lid_is_closed_client_state = dispatch->lid_is_closed;
+   }
+}
+
+static void
 lid_switch_keyboard_event(uint64_t time,
  struct libinput_event *event,
  void *data)
@@ -79,10 +94,7 @@ lid_switch_keyboard_event(uint64_t time,
 * the key event.
 */
dispatch->lid_is_closed = false;
-   switch_notify_toggle(&dispatch->device->base,
-time,
-LIBINPUT_SWITCH_LID,
-dispatch->lid_is_closed);
+   lid_switch_notify_toggle(dispatch, dispatch->device, time);
 }
 
 static void
@@ -120,16 +132,12 @@ lid_switch_process_switch(struct lid_switch_dispatch 
*dispatch,
 
if (dispatch->lid_is_closed == is_closed)
return;
-
lid_switch_toggle_keyboard_listener(dispatch,
is_closed);
 
dispatch->lid_is_closed = is_closed;
 
-   switch_notify_toggle(&device->base,
-time,
-LIBINPUT_SWITCH_LID,
-dispatch->lid_is_closed);
+   lid_switch_notify_toggle(dispatch, device, time);
break;
}
 }
@@ -249,10 +257,12 @@ lid_switch_sync_initial_state(struct evdev_device *device,
 {
struct lid_switch_dispatch *dispatch = lid_dispatch(device->dispatch);
struct libevdev *evdev = device->evdev;
-   bool is_closed = false;
 
dispatch->reliability = evdev_read_switch_reliability_prop(device);
 
+   dispatch->lid_is_closed = libevdev_get_event_value(evdev, EV_SW, 
SW_LID);
+   dispatch->lid_is_closed_client_state = false;
+
/* For the initial state sync, we depend on whether the lid switch
 * is reliable. If we know it's reliable, we sync as expected.
 * If we're not sure, we ignore the initial state and only sync on
@@ -260,24 +270,11 @@ lid_switch_sync_initial_state(struct evdev_device *device,
 * that always have the switch in 'on' state thus don't mess up our
 * touchpad.
 */
-   switch(dispatch->reliability) {
-   case RELIABILITY_UNKNOWN:
-   case RELIABILITY_WRITE_OPEN:
-   is_closed = false;
-   break;
-   case RELIABILITY_RELIABLE:
-   is_closed = libevdev_get_event_value(evdev, EV_SW, SW_LID);
-   break;
-   }
-
-   dispatch->lid_is_closed = is_closed;
-   if (dispatch->lid_is_closed) {
+   if (dispatch->lid_is_closed &&
+   dispatch->reliability == RELIABILITY_RELIABLE) {
uint64_t time;
time = libinput_now(evdev_libinput_context(device));
-   switch_notify_toggle(&device->base,
-time,
-LIBINPUT_SWITCH_LID,
-LIBINPUT_SWITCH_STATE_ON);
+   lid_switch_notify_toggle(dispatch, device, time);
}
 }
 
-- 
2.13.0

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

[PATCH libinput 0/5] lid: Surface 3 lid handling fixes

2017-05-23 Thread Peter Hutterer 

Turns out the Surface3 lid switch handling didn't work as well as it should
(or at all?). The only patch that affects other devices now is 2/5, we tag
keyboards as internal/external which eventually will feed into the other
bits of libinput for DWT detection. That bit will come once this set is
merged.

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

Re: [PATCH][weston] configure.ac: Add --with-wayland-scanner-path

2017-05-23 Thread Quentin Glidic 

On 5/23/17 1:21 PM, Jussi Kukkonen wrote:

Thanks for feedback,

Anything I didn't comment on I think I agree with -- the 
wayland-scanner.m4 proposal I'll have to consider but I'd like to be 
_really_ sure of what most wayland-scanner users want before going that way.


If we cannot find a way that works for everyone, then we failed at 
defining what wayland-scanner is and how it should be used.



Jussi


On 23 May 2017 at 11:56, Quentin Glidic > wrote:

 >
 > On 5/23/17 10:05 AM, Jussi Kukkonen wrote:
 >>
 >> Modify wayland-scanner lookup: Use the path given by pkg-config
 >> but offer an option to override the path with
 >> "--with-wayland-scanner-path=PATH". The latter is useful for
 >> cross-compile situations.
 >
 >
 > I would rather use --with-wayland-scanner.

Name was chosen to match "--with-xserver-path" that already existed. 
"--with-wayland-scanner" works for me too.


Nevermind, let’s go with -path.



 >> AC_PATH_PROG is no longer used.
 >
 > I disagree with that, but you can at least make it work for 
cross-compiling (to an incompatible host) *without* the need to add 
--with-wayland-scanner-path in most cases.


If you take a look at the "Double-checking the correct way to find 
wayland-scanner" thread from last week (sorry, forgot to mention that in 
the patch), you'll see that my original proposal was based on 
AC_PATH_PROG. But pq had some comments:


| The obvious caveat of Weston style is that if you have wayland-scanner
| installed in your system, and you are building another version into a
| $prefix, you must set PATH to find things in $prefix or they will
| silently use the system version. This is problematic, because sometimes
| (rarely) the scanner changes and it is assumed that the scanner matches
| the libwayland you are building for. So, casual contributors can easily
| shoot their foot in Weston style, while in Mesa style they get the
| right one automatically - the one pkg-config is pointing to.

https://lists.freedesktop.org/archives/wayland-devel/2017-May/034136.html

So the idea was that looking in the path could accidentally lead one to 
find an installed wayland-scanner that does not match the libwayland 
we're trying to build against. So I tried to make the "casual case" 
always work safely even if it means the rest of us have to set a 
configure flag a little more often.


I read that, and I just disagree, no big deal. :-)
IMO, we must limit the extra flags to case that wouldn’t work otherwise. 
The simplest cross-compiling case (with correctly named tools and in 
system) must work without extra args.




 >> Also add a AC_SUBST-call (it seems previously the pkg-config value was
 >> never substituted into Makefiles).
 >
 > It was, AC_PATH_PROG() does call AC_SUBST().

Sure, AC_PATH_PROG() works. As I said, it's the value _from pkg-config_ 
(if wayland-scanner was not in path) that never makes it into Makefiles.


That’s not how m4 works.
AC_SUBST() is expanded at m4 time, so just having AC_PATH_PROG() will 
expand AC_SUBST() and thus, the pkg-config value *will* make it to 
Makefile just fine.




 >> My goal is to standardize wayland-scanner usage in a way that does
 >> not require patching when cross-compiling in Yocto. I'm sending a
 >> similar patch to mesa and will fix other projects if these two patches
 >> are well received.
 >>
 >> I did not check that wayland-scanner can actually run as pq suggested:
 >> I don't think that's typically a problem and the error on make should
 >> be fairly good in that case.
 >>
 >> Thanks,
 >>   Jussi
 >>
 >> configure.ac  | 19 ++-
 >>   1 file changed, 14 insertions(+), 5 deletions(-)
 >>
 >> diff --git a/configure.ac  b/configure.ac 


 >> index db757f20..e17135a9 100644
 >> --- a/configure.ac 
 >> +++ b/configure.ac 
 >> @@ -653,11 +653,20 @@ if test "x$enable_lcms" != "xno"; then
 >>   fi
 >>   AM_CONDITIONAL(HAVE_LCMS, [test "x$enable_lcms" = xyes])
 >>   -AC_PATH_PROG([wayland_scanner], [wayland-scanner])
 >> -if test x$wayland_scanner = x; then
 >> -   PKG_CHECK_MODULES(WAYLAND_SCANNER, [wayland-scanner])
 >> -   wayland_scanner=`$PKG_CONFIG --variable=wayland_scanner 
wayland-scanner`

 >> -fi
 >> +AC_ARG_WITH([wayland-scanner-path],
 >> +[AS_HELP_STRING([--with-wayland-scanner-path=PATH],
 >> +[Path to wayland-scanner (by default 
the path from
 >> + 'pkg-config --variable=wayland_scanner 
wayland-scanner'

 >> + is used)])],
 >> +[wayland_scanner="$withval"],
 >
 >
 > Drop that [].
 >
 >> +[wayland_scanner="auto"])
 >
 >
 > And use "with_wayland_scanner=yes" here. Then, (see post-fi comment)
 >
 >
 >> +if test x$wayland_scanner = xauto; then
 >> +PKG_CHECK_MODULES([WAYLAND_SCANNER],
 >> +  [wayland-s

Re: [PATCH][weston] configure.ac: Add --with-wayland-scanner-path

2017-05-23 Thread Jussi Kukkonen 
Thanks for feedback,

Anything I didn't comment on I think I agree with -- the wayland-scanner.m4
proposal I'll have to consider but I'd like to be _really_ sure of what
most wayland-scanner users want before going that way.

Jussi


On 23 May 2017 at 11:56, Quentin Glidic 
wrote:
>
> On 5/23/17 10:05 AM, Jussi Kukkonen wrote:
>>
>> Modify wayland-scanner lookup: Use the path given by pkg-config
>> but offer an option to override the path with
>> "--with-wayland-scanner-path=PATH". The latter is useful for
>> cross-compile situations.
>
>
> I would rather use --with-wayland-scanner.

Name was chosen to match "--with-xserver-path" that already existed.
"--with-wayland-scanner" works for me too.

>> AC_PATH_PROG is no longer used.
>
> I disagree with that, but you can at least make it work for
cross-compiling (to an incompatible host) *without* the need to add
--with-wayland-scanner-path in most cases.

If you take a look at the "Double-checking the correct way to find
wayland-scanner" thread from last week (sorry, forgot to mention that in
the patch), you'll see that my original proposal was based on AC_PATH_PROG.
But pq had some comments:

| The obvious caveat of Weston style is that if you have wayland-scanner
| installed in your system, and you are building another version into a
| $prefix, you must set PATH to find things in $prefix or they will
| silently use the system version. This is problematic, because sometimes
| (rarely) the scanner changes and it is assumed that the scanner matches
| the libwayland you are building for. So, casual contributors can easily
| shoot their foot in Weston style, while in Mesa style they get the
| right one automatically - the one pkg-config is pointing to.

https://lists.freedesktop.org/archives/wayland-devel/2017-May/034136.html

So the idea was that looking in the path could accidentally lead one to
find an installed wayland-scanner that does not match the libwayland we're
trying to build against. So I tried to make the "casual case" always work
safely even if it means the rest of us have to set a configure flag a
little more often.

>> Also add a AC_SUBST-call (it seems previously the pkg-config value was
>> never substituted into Makefiles).
>
> It was, AC_PATH_PROG() does call AC_SUBST().

Sure, AC_PATH_PROG() works. As I said, it's the value _from pkg-config_ (if
wayland-scanner was not in path) that never makes it into Makefiles.

>> My goal is to standardize wayland-scanner usage in a way that does
>> not require patching when cross-compiling in Yocto. I'm sending a
>> similar patch to mesa and will fix other projects if these two patches
>> are well received.
>>
>> I did not check that wayland-scanner can actually run as pq suggested:
>> I don't think that's typically a problem and the error on make should
>> be fairly good in that case.
>>
>> Thanks,
>>   Jussi
>>
>>   configure.ac | 19 ++-
>>   1 file changed, 14 insertions(+), 5 deletions(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index db757f20..e17135a9 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -653,11 +653,20 @@ if test "x$enable_lcms" != "xno"; then
>>   fi
>>   AM_CONDITIONAL(HAVE_LCMS, [test "x$enable_lcms" = xyes])
>>   -AC_PATH_PROG([wayland_scanner], [wayland-scanner])
>> -if test x$wayland_scanner = x; then
>> -   PKG_CHECK_MODULES(WAYLAND_SCANNER, [wayland-scanner])
>> -   wayland_scanner=`$PKG_CONFIG --variable=wayland_scanner
wayland-scanner`
>> -fi
>> +AC_ARG_WITH([wayland-scanner-path],
>> +[AS_HELP_STRING([--with-wayland-scanner-path=PATH],
>> +[Path to wayland-scanner (by default the
path from
>> + 'pkg-config --variable=wayland_scanner
wayland-scanner'
>> + is used)])],
>> +[wayland_scanner="$withval"],
>
>
> Drop that [].
>
>> +[wayland_scanner="auto"])
>
>
> And use "with_wayland_scanner=yes" here. Then, (see post-fi comment)
>
>
>> +if test x$wayland_scanner = xauto; then
>> +PKG_CHECK_MODULES([WAYLAND_SCANNER],
>> +  [wayland-scanner],
>> +  [wayland_scanner=`$PKG_CONFIG
--variable=wayland_scanner wayland-scanner`],
>
>
> Here, $PKG_CONFIG is wrong. Specifically in cross-compiling case, which
is what your patch is supposed to fix.

I believe this code is essentially the same as it used to be (with the
caveat that this code now runs if the option is not given, and it used to
run if AC_PATH_PROG failed). This code path cannot work when
cross-compiling but I would expect anyone cross-compiling to provide a
"--with-wayland-scanner-path=PATH".

I guess I could error out if $cross_compiling and
--with-wayland-scanner-path is not given? I can't think of a case where
that could work...

> Having a way to override the value is nice, but we already had.
> Running "./configure 
> ac_cv_path_wayland_scanner=/usr/yocto/bin/wayland-scanner"
should work. Doing nothing works in

Re: [PATCH weston v6 0/6] Implement screensaver/idle inhibition

2017-05-23 Thread Quentin Glidic 

On 9/9/16 4:31 AM, Bryce Harrington wrote:

Updated to include review feedback from Quentin on the v5.  That
involves refinements to the destructor behavior, reorganizing patches a
bit, and noting that if the idle manager is destroyed by the client, the
individual inhibitor objects remain active.  The libweston-desktop API
is renamed from surface_drop_idle_inhibitor to just drop_idle_inhibitor.


I’ve been trying to make up my mind of this series for quite some time 
now, and I’m sad that we hit v6 and still not have something usable.


Let’s start with global patches comments:

1. I merged it because it was nice and standalone, so we can stop 
worrying about it.

2.
3. This one seems odd to me. It patches stuff added in 2, that would be 
better squashed directly. And the protocol handling code looks too 
different from what it usually is (e.g. emitting the signal in the 
destroy request, not in the resource destroy handler).
4. As I said in v5, this patch is wrong. It will not work if you add an 
inhibitor to a popup, it will just crash (didn’t test that, but I’m 
pretty confident).

5. Mostly good, except for the libweston-desktop stuff.
6. It should allow to test for popup inhibition, and subsurface too.


To get the implementation right, we first need to define what it should do.

The first question is: when is an inhibitor “active”? The answer from 
the protocol file is:
“If the surface is destroyed, unmapped, becomes occluded, loses 
visibility, or otherwise becomes not visually relevant for the user, the 
idle inhibitor will not be honored by the compositor”
This means only visibility is taken into account. The shell has no 
checks to add to the inhibitor.


In libweston, this effectively means we can just check the 
weston_surface and ignore role-specific structures.

So all the *inhibitor* related code should be hidden in libweston.


Now, we want the compositor (the shell in weston’s case) to drive the 
fade in/out animation.


That means we need the shell to know when an *output* is being inhibited 
or not. Not individual surfaces.




I suggest a few things for the next round.
First, implement the client directly, this way we can merge it quickly 
to help other compositors to run tests. (And implement subsurface/popup 
testing.)


Then, reworking the output code to something like that (in pseudo-code):

output_set_on(output) {
  if output.compositor.inhibitor_handler != NULL
output.compositor.inhibitor_handler(output, ON)
  else
output.set_dpms(ON)
}

output_set_off(output) {
  if output.inhibited || output.compositor.idle
return

  if output.compositor.inhibitor_handler != NULL
output.compositor.inhibitor_handler(output, OFF)
  else
output.set_dpms(OFF)
}

idle_handler(compositor) {
  for output in compositor.outputs {
if compositor.idle
  output_set_off(output)
else
  output_set_on(output)
  }
}

output_check_inhibit(output) {
  was_inhibited = output.inhibited
  output.inhibited = false
  for v in output.views {
if v.surface.inhibit {
  output.inhibited = true
  break
}
  }
  if was_inhibited
output_set_off(output)
}

protocol_create_inhibitor(surface) {
  surface.inhibit = true
  for v in surface.views {
output_check_inhibit(v.output)
  }
}

protocol_destroy_inhibitor(surface) {
  surface.inhibit = false
  for v in surface.views {
output_check_inhibit(v.output)
  }
}

The shell/compositor would set the compositor.inhibitor_handler to drive 
fade in/out.

Does that seem sensible to you?

Cheers,

--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] configure.ac: use AC_HEADER_MAJOR to detect major()/minor()

2017-05-23 Thread Quentin Glidic 

On 3/13/17 11:40 AM, Sergei Trofimovich wrote:

Before the change build failed on Gentoo as:

   libweston/weston_launch-weston-launch.o: In function `handle_open':
   weston/libweston/weston-launch.c:363: undefined reference to `major'
   weston/libweston/weston-launch.c:365: undefined reference to `major'
   weston/libweston/weston-launch.c:325: undefined reference to `major'
   weston/libweston/weston-launch.c:326: undefined reference to `major'
   libweston/weston_launch-weston-launch.o: In function `setup_tty':
   weston/libweston/weston-launch.c:548: undefined reference to `major'
   weston/libweston/weston-launch.c:548: undefined reference to `minor'
   weston/libweston/weston-launch.c:555: undefined reference to `major'
   weston/libweston/weston-launch.c:558: undefined reference to `minor'
   libweston/weston_launch-weston-launch.o: In function `close_input_fds':
   weston/libweston/weston-launch.c:451: undefined reference to `major'

glibc plans to remove  from glibc's :
 https://sourceware.org/ml/libc-alpha/2015-11/msg00253.html

Gentoo already applied glibc patch to experimental glibc-2.24
to start preparingfor the change.

Autoconf has AC_HEADER_MAJOR to find out which header defines
reqiured macros:
 
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Particular-Headers.html

This change should also increase portability across other libcs.

Bug: https://bugs.gentoo.org/610652
Signed-off-by: Sergei Trofimovich 


We added sys/sysmacros.h includes in 
c4d7f66c12853b9575366dd9f4a7960ec5694934.

This patch is still relevant, but needs rebasing.

Also, please move the #ifdef and #include where we currently have the 
sysmacros.h #include. And no "#include" indentation.


Thanks,



---
  configure.ac   | 1 +
  libweston/launcher-direct.c| 8 
  libweston/launcher-logind.c| 8 
  libweston/launcher-weston-launch.c | 7 +++
  libweston/weston-launch.c  | 8 
  5 files changed, 32 insertions(+)

diff --git a/configure.ac b/configure.ac
index 9df85d20..b99e7fdd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -34,6 +34,7 @@ AC_CONFIG_MACRO_DIR([m4])
  
  AC_USE_SYSTEM_EXTENSIONS

  AC_SYS_LARGEFILE
+AC_HEADER_MAJOR
  
  AM_INIT_AUTOMAKE([1.11 parallel-tests foreign no-dist-gzip dist-xz color-tests subdir-objects])
  
diff --git a/libweston/launcher-direct.c b/libweston/launcher-direct.c

index 4195cf65..16bac5f4 100644
--- a/libweston/launcher-direct.c
+++ b/libweston/launcher-direct.c
@@ -46,6 +46,14 @@
  #define KDSKBMUTE 0x4B51
  #endif
  
+/* major()/minor() */

+#ifdef MAJOR_IN_MKDEV
+#include 
+#endif
+#ifdef MAJOR_IN_SYSMACROS
+#include 
+#endif
+
  #ifdef HAVE_LIBDRM
  
  #include 

diff --git a/libweston/launcher-logind.c b/libweston/launcher-logind.c
index 8de1ed11..663cff28 100644
--- a/libweston/launcher-logind.c
+++ b/libweston/launcher-logind.c
@@ -44,6 +44,14 @@
  
  #define DRM_MAJOR 226
  
+/* major()/minor() */

+#ifdef MAJOR_IN_MKDEV
+#include 
+#endif
+#ifdef MAJOR_IN_SYSMACROS
+#include 
+#endif
+
  struct launcher_logind {
struct weston_launcher base;
struct weston_compositor *compositor;
diff --git a/libweston/launcher-weston-launch.c 
b/libweston/launcher-weston-launch.c
index 930f4e0c..3f7dde50 100644
--- a/libweston/launcher-weston-launch.c
+++ b/libweston/launcher-weston-launch.c
@@ -74,6 +74,13 @@ drmSetMaster(int drm_fd)
  
  #endif
  
+/* major()/minor() */

+#ifdef MAJOR_IN_MKDEV
+#include 
+#endif
+#ifdef MAJOR_IN_SYSMACROS
+#include 
+#endif
  
  union cmsg_data { unsigned char b[4]; int fd; };
  
diff --git a/libweston/weston-launch.c b/libweston/weston-launch.c

index 140fde1d..5fe0c4a9 100644
--- a/libweston/weston-launch.c
+++ b/libweston/weston-launch.c
@@ -92,6 +92,14 @@ drmSetMaster(int drm_fd)
  
  #endif
  
+/* major()/minor() */

+#ifdef MAJOR_IN_MKDEV
+#include 
+#endif
+#ifdef MAJOR_IN_SYSMACROS
+#include 
+#endif
+
  struct weston_launch {
struct pam_conv pc;
pam_handle_t *ph;




--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston v3] xwm: Add icon support to the frame

2017-05-23 Thread Quentin Glidic 

On 4/4/17 4:34 PM, Emmanuel Gil Peyrot wrote:

From: Emmanuel Gil Peyrot 

This fetches the _NET_WM_ICON property of the X11 window, and use the
first image found as the frame icon.

This has been tested with various X11 programs, and improves usability
and user-friendliness a bit.

Changes since v1:
- Changed frame_button_create() to use
   frame_button_create_from_surface() internally.
- Removed a check that should never have been commited.

Changes since v2:
- Request UINT32_MAX items instead of 2048, to avoid cutting valid
   icons.
- Strengthen checks against malformed input.
- Handle XCB_PROPERTY_DELETE to remove the icon.
- Schedule a repaint if the icon changed.

Signed-off-by: Emmanuel Gil Peyrot 
Signed-off-by: Emmanuel Gil Peyrot 


We’re mostly good, still a few comments in the property handling.



---
  clients/window.c   |  4 +--
  libweston/compositor-wayland.c |  2 +-
  shared/cairo-util.h|  2 +-
  shared/frame.c | 54 +++--
  xwayland/window-manager.c  | 61 --
  5 files changed, 103 insertions(+), 20 deletions(-)

diff --git a/clients/window.c b/clients/window.c
index 95796d46..15a86e15 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -2546,7 +2546,7 @@ window_frame_create(struct window *window, void *data)
  
  	frame = xzalloc(sizeof *frame);

frame->frame = frame_create(window->display->theme, 0, 0,
-   buttons, window->title);
+   buttons, window->title, NULL);
  
  	frame->widget = window_add_widget(window, frame);

frame->child = widget_add_widget(frame->widget, data);
@@ -5449,7 +5449,7 @@ create_menu(struct display *display,
menu->user_data = user_data;
menu->widget = window_add_widget(menu->window, menu);
menu->frame = frame_create(window->display->theme, 0, 0,
-  FRAME_BUTTON_NONE, NULL);
+  FRAME_BUTTON_NONE, NULL, NULL);
fail_on_null(menu->frame, 0, __FILE__, __LINE__);
menu->entries = entries;
menu->count = count;
diff --git a/libweston/compositor-wayland.c b/libweston/compositor-wayland.c
index 14f2c8db..aa6e5043 100644
--- a/libweston/compositor-wayland.c
+++ b/libweston/compositor-wayland.c
@@ -862,7 +862,7 @@ wayland_output_set_windowed(struct wayland_output *output)
return -1;
}
output->frame = frame_create(b->theme, 100, 100,
-FRAME_BUTTON_CLOSE, output->title);
+FRAME_BUTTON_CLOSE, output->title, NULL);
if (!output->frame)
return -1;
  
diff --git a/shared/cairo-util.h b/shared/cairo-util.h

index 84cf005e..7893ca24 100644
--- a/shared/cairo-util.h
+++ b/shared/cairo-util.h
@@ -126,7 +126,7 @@ enum {
  
  struct frame *

  frame_create(struct theme *t, int32_t width, int32_t height, uint32_t buttons,
-const char *title);
+ const char *title, cairo_surface_t *icon);
  
  void

  frame_destroy(struct frame *frame);
diff --git a/shared/frame.c b/shared/frame.c
index eb0cd77a..32779856 100644
--- a/shared/frame.c
+++ b/shared/frame.c
@@ -106,9 +106,9 @@ struct frame {
  };
  
  static struct frame_button *

-frame_button_create(struct frame *frame, const char *icon,
-   enum frame_status status_effect,
-   enum frame_button_flags flags)
+frame_button_create_from_surface(struct frame *frame, cairo_surface_t *icon,
+ enum frame_status status_effect,
+ enum frame_button_flags flags)
  {
struct frame_button *button;
  
@@ -116,12 +116,7 @@ frame_button_create(struct frame *frame, const char *icon,

if (!button)
return NULL;
  
-	button->icon = cairo_image_surface_create_from_png(icon);

-   if (!button->icon) {
-   free(button);
-   return NULL;
-   }
-
+   button->icon = icon;
button->frame = frame;
button->flags = flags;
button->status_effect = status_effect;
@@ -131,6 +126,30 @@ frame_button_create(struct frame *frame, const char *icon,
return button;
  }
  
+static struct frame_button *

+frame_button_create(struct frame *frame, const char *icon_name,
+enum frame_status status_effect,
+enum frame_button_flags flags)
+{
+   struct frame_button *button;
+   cairo_surface_t *icon;
+
+   icon = cairo_image_surface_create_from_png(icon_name);
+   if (cairo_surface_status(icon) != CAIRO_STATUS_SUCCESS)
+   goto error;
+
+   button = frame_button_create_from_surface(frame, icon, status_effect,
+ flags);
+   if (!button)
+   goto error;
+
+   return button;
+
+error:
+   cairo_surf

Re: [PATCH] weston fbdev: Instead of less than 1 Hz use default refresh rate

2017-05-23 Thread Quentin Glidic 

On 4/17/17 1:11 PM, Oliver Smith wrote:

I ran Weston on a Nexus 4 mobile phone, with a native GNU/Linux userland,
and the latest Android kernel for that device from LineageOS [1].

calculate_refresh_rate() returned 1 (mHz), which gets rounded to 0 Hz later
and results in nothing being drawn to the screen.

This patch makes sure, that there is at least a refresh rate of 1 Hz, because
it returns the default refresh rate of 60 Hz otherwise.

[1]: https://github.com/LineageOS/lge-kernel-mako

Signed-off-by: Oliver Smith 


We’ll just pretend I know what I’m doing:
Reviewed-by: Quentin Glidic 

And pushed:
47bbdc72..a5066e00  master -> master

Thanks,



---
  libweston/compositor-fbdev.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libweston/compositor-fbdev.c b/libweston/compositor-fbdev.c
index 32d71e0..e80a504 100644
--- a/libweston/compositor-fbdev.c
+++ b/libweston/compositor-fbdev.c
@@ -253,7 +253,8 @@ calculate_refresh_rate(struct fb_var_screeninfo *vinfo)
if (refresh_rate > 20)
refresh_rate = 20; /* cap at 200 Hz */
  
-		return refresh_rate;

+   if (refresh_rate >= 1000) /* at least 1 Hz */
+   return refresh_rate;
}
  
  	return 60 * 1000; /* default to 60 Hz */





--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2] weston: Add support for "--foo bar" style options

2017-05-23 Thread Quentin Glidic 

On 5/8/17 6:47 PM, Lyude wrote:

A little earlier today I ended up spending a lot of time trying to
figure out why weston wasn't managing to launch over SSH and telling me
that I did not have a --tty option specified, despite me passing the
option strings ["--tty", "3"]. Turns out weston just doesn't support
that.

So, add support for this kind of format in addition to "--foo=bar" to
save others from making the same mistake I did.

Changes since v1:
  - Add comment about unreachable boolean check in long_option_with_arg()
  - Convert boolean check in long_option_with_arg() to assert

Signed-off-by: Lyude 
Reviewed-by: Eric Engestrom 


Nice one, I had one a lng time ago but never really rebased it:
Reviewed-by: Quentin Glidic 

Changed the style a tiny bit (line wrapping) and pushed:
dbfd248d..47bbdc72  master -> master

Thanks,



---
  shared/option-parser.c | 30 ++
  1 file changed, 30 insertions(+)

diff --git a/shared/option-parser.c b/shared/option-parser.c
index eee7546..831bd56 100644
--- a/shared/option-parser.c
+++ b/shared/option-parser.c
@@ -87,6 +87,30 @@ long_option(const struct weston_option *options, int count, 
char *arg)
  }
  
  static int

+long_option_with_arg(const struct weston_option *options, int count, char 
*arg, char *param)
+{
+   int k, len;
+
+   for (k = 0; k < count; k++) {
+   if (!options[k].name)
+   continue;
+
+   len = strlen(options[k].name);
+   if (strncmp(options[k].name, arg + 2, len) != 0)
+   continue;
+
+   /* Since long_option() should handle all booleans, we should
+* never reach this
+*/
+   assert(options[k].type != WESTON_OPTION_BOOLEAN);
+
+   return handle_option(options + k, param);
+   }
+
+   return 0;
+}
+
+static int
  short_option(const struct weston_option *options, int count, char *arg)
  {
int k;
@@ -148,6 +172,12 @@ parse_options(const struct weston_option *options,
if (long_option(options, count, argv[i]))
continue;
  
+/* ...also handle --foo bar */

+   if (i + 1 < *argc &&
+   long_option_with_arg(options, count, 
argv[i], argv[i+1])) {
+   i++;
+   continue;
+   }
} else {
/* Short option, e.g -f or -f42 */
if (short_option(options, count, argv[i]))




--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH][weston] configure.ac: Add --with-wayland-scanner-path

2017-05-23 Thread Quentin Glidic 

On 5/23/17 10:05 AM, Jussi Kukkonen wrote:

Modify wayland-scanner lookup: Use the path given by pkg-config
but offer an option to override the path with
"--with-wayland-scanner-path=PATH". The latter is useful for
cross-compile situations.


I would rather use --with-wayland-scanner.



AC_PATH_PROG is no longer used.


I disagree with that, but you can at least make it work for 
cross-compiling (to an incompatible host) *without* the need to add 
--with-wayland-scanner-path in most cases.




Also add a AC_SUBST-call (it seems previously the pkg-config value was
never substituted into Makefiles).


It was, AC_PATH_PROG() does call AC_SUBST().


---

My goal is to standardize wayland-scanner usage in a way that does
not require patching when cross-compiling in Yocto. I'm sending a
similar patch to mesa and will fix other projects if these two patches
are well received.

I did not check that wayland-scanner can actually run as pq suggested:
I don't think that's typically a problem and the error on make should
be fairly good in that case.

Thanks,
  Jussi

  configure.ac | 19 ++-
  1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index db757f20..e17135a9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -653,11 +653,20 @@ if test "x$enable_lcms" != "xno"; then
  fi
  AM_CONDITIONAL(HAVE_LCMS, [test "x$enable_lcms" = xyes])
  
-AC_PATH_PROG([wayland_scanner], [wayland-scanner])

-if test x$wayland_scanner = x; then
-   PKG_CHECK_MODULES(WAYLAND_SCANNER, [wayland-scanner])
-   wayland_scanner=`$PKG_CONFIG --variable=wayland_scanner wayland-scanner`
-fi
+AC_ARG_WITH([wayland-scanner-path],
+[AS_HELP_STRING([--with-wayland-scanner-path=PATH],
+[Path to wayland-scanner (by default the path from
+ 'pkg-config --variable=wayland_scanner 
wayland-scanner'
+ is used)])],
+[wayland_scanner="$withval"],


Drop that [].


+[wayland_scanner="auto"])


And use "with_wayland_scanner=yes" here. Then, (see post-fi comment)



+if test x$wayland_scanner = xauto; then
+PKG_CHECK_MODULES([WAYLAND_SCANNER],
+  [wayland-scanner],
+  [wayland_scanner=`$PKG_CONFIG 
--variable=wayland_scanner wayland-scanner`],


Here, $PKG_CONFIG is wrong. Specifically in cross-compiling case, which 
is what your patch is supposed to fix.

Having a way to override the value is nice, but we already had.
Running "./configure 
ac_cv_path_wayland_scanner=/usr/yocto/bin/wayland-scanner" should work. 
Doing nothing works in most cases.


With this patch, you’re breaking cross-compilation to incompatible host 
in the default case, to add something you can already do.


At the very least, you should be using the *build* pkg-config, with 
something like that:

AC_CANONICAL_BUILD
AC_ARG_VAR([BUILD_PKG_CONFIG])
AC_PATH_PROGS([BUILD_PKG_CONFIG],
[${build}-pkg-config pkg-config], [${PKG_CONFIG}])
# We’re safe, ${PKG_CONFIG} is used elsewhere so it’s a good fallback
wayland_scanner=`${BUILD_PKG_CONFIG} --variable=wayland_scanner 
wayland-scanner`
# But using ${PKG_CONFIG} can lead to unusable executable here, we 
*must* check it works

wl_scanner_version=`${wayland_scanner} --version 2>/dev/null`
AS_IF([test "x$?" != "x0"], [AC_MSG_ERROR([${wayland_scanner} is not 
usable])])




+  [AC_MSG_ERROR([wayland-scanner was not found and 
--with-wayland-scanner-path was not used])])
+fi


Use AS_CASE, for "yes" (= "auto"), "no" (= error, to make 
--without-wayland-scanner fails) and "*" (= do nothing, consider the 
path is ok).




+AC_SUBST(wayland_scanner)


Adding a run test would be nice, indeed, but we should have a working value.


  AC_ARG_ENABLE(systemd_notify,
AS_HELP_STRING([--enable-systemd-notify],



I think this patch should be in Wayland, to wayland-scanner.m4 for other 
projects to use (they would depend on a recent Wayland for "make dist" 
and Git builds only, so the “extra dep” should be fine, one can always 
backport the .m4 to their tree if needed).

The proper macro name is WAYLAND_PROG_WAYLAND_SCANNER (or WL_PROG…).

A nice thing would be to check the version too.

Once we’ve figured out the proper algorithm to use, I’ll make a match to 
create a wayland module in Meson to do the same thing.


--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH][weston] configure.ac: Add --with-wayland-scanner-path

2017-05-23 Thread Jussi Kukkonen 
Modify wayland-scanner lookup: Use the path given by pkg-config
but offer an option to override the path with
"--with-wayland-scanner-path=PATH". The latter is useful for
cross-compile situations.

AC_PATH_PROG is no longer used.

Also add a AC_SUBST-call (it seems previously the pkg-config value was
never substituted into Makefiles).
---

My goal is to standardize wayland-scanner usage in a way that does
not require patching when cross-compiling in Yocto. I'm sending a
similar patch to mesa and will fix other projects if these two patches
are well received.

I did not check that wayland-scanner can actually run as pq suggested:
I don't think that's typically a problem and the error on make should
be fairly good in that case.

Thanks,
 Jussi

 configure.ac | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index db757f20..e17135a9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -653,11 +653,20 @@ if test "x$enable_lcms" != "xno"; then
 fi
 AM_CONDITIONAL(HAVE_LCMS, [test "x$enable_lcms" = xyes])
 
-AC_PATH_PROG([wayland_scanner], [wayland-scanner])
-if test x$wayland_scanner = x; then
-   PKG_CHECK_MODULES(WAYLAND_SCANNER, [wayland-scanner])
-   wayland_scanner=`$PKG_CONFIG --variable=wayland_scanner wayland-scanner`
-fi
+AC_ARG_WITH([wayland-scanner-path],
+[AS_HELP_STRING([--with-wayland-scanner-path=PATH],
+[Path to wayland-scanner (by default the path from
+ 'pkg-config --variable=wayland_scanner 
wayland-scanner'
+ is used)])],
+[wayland_scanner="$withval"],
+[wayland_scanner="auto"])
+if test x$wayland_scanner = xauto; then
+PKG_CHECK_MODULES([WAYLAND_SCANNER],
+  [wayland-scanner],
+  [wayland_scanner=`$PKG_CONFIG 
--variable=wayland_scanner wayland-scanner`],
+  [AC_MSG_ERROR([wayland-scanner was not found and 
--with-wayland-scanner-path was not used])])
+fi
+AC_SUBST(wayland_scanner)
 
 AC_ARG_ENABLE(systemd_notify,
   AS_HELP_STRING([--enable-systemd-notify],
-- 
2.11.0

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

Re: Using EGL drivers in Weston without FBDev

2017-05-23 Thread Daniel Stone 
Hi Teemu,

On 23 May 2017 at 05:33, Keskinarkaus, Teemu
 wrote:
> I just ran into this although support was dropped almost a year ago.
>
> Since FBDEV no longer has EGL ‘hackery’ support, what is then the ‘proper’
> way to use EGL drivers?  ie. What way they _should_ be used?
>
> I’m in no way expert in this whole Wayland/Weston/driver thing so that’s why
> I’m asking.
>
> We are currently using Weston in iMX6 based HW and NXP currently has only
> EGL/FBdev drivers available that’s why I ran to problems with Wayland/Weston
> when trying to upgrade to Weston 2.0.

The recommended way is to use EGL on top of KMS (kernel modesetting),
the combination of which is called GBM. This is what's implemented by
Mesa, and also several other drivers including ARM Mali.

The last time I saw NXP i.MX code for Weston, it was a fork of Weston
using their own API for rendering and buffer management. I don't know
if this ever got ported forward to newer versions, so you'd probably
be needing to use their tree anyway. I know this isn't the advice you
were hoping to get, but I would strongly recommend contacting NXP and
asking them to support KMS and GBM like everyone else.

The good news is that the 'Etnaviv' and imx-drm drivers inside Mesa
and the mainline Linux kernel work just fine, so if you use very new
versions of Mesa and the kernel, there should be no need to run NXP's
fork of Weston and their EGL drivers.

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