Re: [PATCH weston 1/2] config-parser: add support for more color formats

[Bryce Harrington]

On Fri, Oct 21, 2016 at 04:02:15PM +0100, Eric Engestrom wrote:
> On Friday, 2016-10-21 12:30:07 +0200, Quentin Glidic wrote:
> > Hi,
> > 
> > On 20/10/2016 00:08, Eric Engestrom wrote:
> > > Valid colours start with an optional '0x' or '#', followed by:
> > > - AARRGGBB
> > > -   RRGGBB
> > > -  A R G B
> > > -R G B
> > > -   XYXYXY
> > > -   XX
> > 
> > I think this is way too much, even with minimal code effort.
> > 
> > The well-known CSS formats are #RRGGBB and #RGB, and the backward-compatible
> > extension are #RRGGBBAA and #RGBA.
> > The current 0xAARRGGBB are directly derived from the internal usage of a
> > colour as a number, because Weston devs are used to this. But *users* are
> > not, they are used to CSS notation.
> > 
> > IMO, 0x should be used as-is, with a little clamping, so the old way
> > continue to work. OTOH, the # notation should be fully compatible with CSS.
> > 
> > This code would lead to user-unexpected behaviour, and it’s easy to avoid
> > that.
> 
> You're right, I didn't really think this through :)
> I'll send a v2 with only commonly used formats/orders when
> I have some more time (probably sunday):
> 
> - (0x)(AA)RRGGBB (backward compatibility)
> - #RGB(A)
> - #RRGGBB(AA)
> 
> Bryce, I think you wanted a single repeating char format; do you also
> want the 2-char format?

I agree with Quentin that it's probably most important that color codes
are handled in consistent ways so that they don't encounter odd
unexpected behaviors.  In that light less maybe more as they say.

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

[PATCH v4] Add configuration option for no input device.

[Daniel Díaz]

As it has been discussed in the past [1], running Weston
without any input device at launch might be beneficial for
some use cases.

Certainly, it's best for the vast majority of users (and
the project) to require an input device to be present, as
to avoid frustration and hassle, but for those brave souls
that so prefer, this patch lets them run without any input
device at all.

This introduces a simple configuration in weston.ini:
  [core]
  require-input=true

True is the default, so no behavioral change is introduced.

[1] 
https://lists.freedesktop.org/archives/wayland-devel/2015-November/025193.html

Signed-off-by: Daniel Díaz 
Reviewed-by: Peter Hutterer 
---
v2: Try different approach
v3: Return 0 on successful init, not 1
v4: Remove a just-introduced warning (bool/int)

 compositor/main.c | 5 +
 libweston/compositor.h| 4 
 libweston/libinput-seat.c | 6 ++
 man/weston.ini.man| 5 +
 weston.ini.in | 1 +
 5 files changed, 21 insertions(+)

diff --git a/compositor/main.c b/compositor/main.c
index 8028ec3..080aa61 100644
--- a/compositor/main.c
+++ b/compositor/main.c
@@ -1738,6 +1738,7 @@ int main(int argc, char *argv[])
struct wl_listener primary_client_destroyed;
struct weston_seat *seat;
struct wet_compositor user_data;
+   int require_input;
 
const struct weston_option core_options[] = {
{ WESTON_OPTION_STRING, "backend", 'B',  },
@@ -1822,6 +1823,10 @@ int main(int argc, char *argv[])
if (weston_compositor_init_config(ec, config) < 0)
goto out;
 
+   weston_config_section_get_bool(section, "require-input",
+  _input, true);
+   ec->require_input = require_input;
+
if (load_backend(ec, backend, , argv, config) < 0) {
weston_log("fatal: failed to create compositor backend\n");
goto out;
diff --git a/libweston/compositor.h b/libweston/compositor.h
index 3e486d5..e00d285 100644
--- a/libweston/compositor.h
+++ b/libweston/compositor.h
@@ -830,6 +830,10 @@ struct weston_compositor {
 
void *user_data;
void (*exit)(struct weston_compositor *c);
+
+   /* Whether to let the compositor run without any input device. */
+   bool require_input;
+
 };
 
 struct weston_buffer {
diff --git a/libweston/libinput-seat.c b/libweston/libinput-seat.c
index 78a5fc4..8cf5666 100644
--- a/libweston/libinput-seat.c
+++ b/libweston/libinput-seat.c
@@ -259,6 +259,12 @@ udev_input_enable(struct udev_input *input)
devices_found = 1;
}
 
+   if (devices_found == 0 && !c->require_input) {
+   weston_log("warning: no input devices found, but none required "
+  "as per configuration.\n");
+   return 0;
+   }
+
if (devices_found == 0) {
weston_log(
"warning: no input devices on entering Weston. "
diff --git a/man/weston.ini.man b/man/weston.ini.man
index 7aa7810..2eac098 100644
--- a/man/weston.ini.man
+++ b/man/weston.ini.man
@@ -168,6 +168,11 @@ time, the one specified in the command-line will be used. 
On the other
 hand, if none of these sets the value, default idle timeout will be
 set to 300 seconds.
 .RS
+.PP
+.RE
+.TP 7
+.BI "require-input=" true
+require an input device for launch
 
 .SH "LIBINPUT SECTION"
 The
diff --git a/weston.ini.in b/weston.ini.in
index 14a4c0c..d837fb5 100644
--- a/weston.ini.in
+++ b/weston.ini.in
@@ -2,6 +2,7 @@
 #modules=xwayland.so,cms-colord.so
 #shell=desktop-shell.so
 #gbm-format=xrgb2101010
+#require-input=true
 
 [shell]
 background-image=/usr/share/backgrounds/gnome/Aqua.jpg
-- 
1.9.1

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

Re: [PATCH v3] Add configuration option for no input device.

[Daniel Stone]

Hi,

On 20 October 2016 at 23:12, Daniel Díaz  wrote:
> As it has been discussed in the past [1], running Weston
> without any input device at launch might be beneficial for
> some use cases.
>
> Certainly, it's best for the vast majority of users (and
> the project) to require an input device to be present, as
> to avoid frustration and hassle, but for those brave souls
> that so prefer, this patch lets them run without any input
> device at all.
>
> This introduces a simple configuration in weston.ini:
>   [core]
>   require-input=true
>
> True is the default, so no behavioral change is introduced.

../compositor/main.c: In function ‘main’:
../compositor/main.c:1827:12: warning: passing argument 3 of
‘weston_config_section_get_bool’ from incompatible pointer type
_input, true);
^
In file included from ../libweston/compositor.h:45:0,
 from ../compositor/weston.h:33,
 from ../compositor/main.c:51:
../shared/config-parser.h:103:1: note: expected ‘int *’ but argument
is of type ‘_Bool *’
 weston_config_section_get_bool(struct weston_config_section *section,
 ^

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

Re: [PATCH weston 1/2] config-parser: add support for more color formats

[Eric Engestrom]

On Friday, 2016-10-21 12:30:07 +0200, Quentin Glidic wrote:
> Hi,
> 
> On 20/10/2016 00:08, Eric Engestrom wrote:
> > Valid colours start with an optional '0x' or '#', followed by:
> > - AARRGGBB
> > -   RRGGBB
> > -  A R G B
> > -R G B
> > -   XYXYXY
> > -   XX
> 
> I think this is way too much, even with minimal code effort.
> 
> The well-known CSS formats are #RRGGBB and #RGB, and the backward-compatible
> extension are #RRGGBBAA and #RGBA.
> The current 0xAARRGGBB are directly derived from the internal usage of a
> colour as a number, because Weston devs are used to this. But *users* are
> not, they are used to CSS notation.
> 
> IMO, 0x should be used as-is, with a little clamping, so the old way
> continue to work. OTOH, the # notation should be fully compatible with CSS.
> 
> This code would lead to user-unexpected behaviour, and it’s easy to avoid
> that.

You're right, I didn't really think this through :)
I'll send a v2 with only commonly used formats/orders when
I have some more time (probably sunday):

- (0x)(AA)RRGGBB (backward compatibility)
- #RGB(A)
- #RRGGBB(AA)

Bryce, I think you wanted a single repeating char format; do you also
want the 2-char format?

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

Re: [PATCH weston 1/2] config-parser: add support for more color formats

[Quentin Glidic]

Hi,

On 20/10/2016 00:08, Eric Engestrom wrote:

Valid colours start with an optional '0x' or '#', followed by:
- AARRGGBB
-   RRGGBB
-  A R G B
-R G B
-   XYXYXY
-   XX


I think this is way too much, even with minimal code effort.

The well-known CSS formats are #RRGGBB and #RGB, and the 
backward-compatible extension are #RRGGBBAA and #RGBA.
The current 0xAARRGGBB are directly derived from the internal usage of a 
colour as a number, because Weston devs are used to this. But *users* 
are not, they are used to CSS notation.


IMO, 0x should be used as-is, with a little clamping, so the old way 
continue to work. OTOH, the # notation should be fully compatible with CSS.


This code would lead to user-unexpected behaviour, and it’s easy to 
avoid that.


Cheers,



Signed-off-by: Eric Engestrom 
---

I just stumbled back on this discussion from a few months ago, and
decided to give it a go.

Once again, I apologise for length of the lines in the switch, but
I believe they are much less readable when folded.

>

I feel like there should be a place where the supported colour formats$
are documented, but I couldn't find it?

---
 shared/config-parser.c | 39 +++
 1 file changed, 31 insertions(+), 8 deletions(-)

diff --git a/shared/config-parser.c b/shared/config-parser.c
index e2b5fa2..a00b2d6 100644
--- a/shared/config-parser.c
+++ b/shared/config-parser.c
@@ -224,6 +224,9 @@ weston_config_section_get_color(struct 
weston_config_section *section,
struct weston_config_entry *entry;
int len;
char *end;
+   const char alpha[] = "FF"; /* Default alpha when unspecified */
+   const char *val;
+   const char *color_string;

entry = config_section_get_entry(section, key);
if (entry == NULL) {
@@ -232,19 +235,39 @@ weston_config_section_get_color(struct 
weston_config_section *section,
return -1;
}

+   val = entry->value;
-   len = strlen(entry->value);
+   len = strlen(val);
+
-   if (len == 1 && entry->value[0] == '0') {
+   if (len == 1 && val[0] == '0') {
*color = 0;
return 0;
+   }
-   } else if (len != 8 && len != 10) {
-   *color = default_color;
-   errno = EINVAL;
-   return -1;
+
+   if (len > 2 && val[0] == '0' && val[1] == 'x')
+   {
+   val += 2;
+   len -= 2;
+   }
+   else if (len > 1 && val[0] == '#')
+   {
+   val += 1;
+   len -= 1;
+   }
+
+   switch (len) {
+   case 8: color_string = (char[]){   val[0],   val[1], val[2], val[3], 
val[4], val[5], val[6], val[7], '\0' }; break; /* AARRGGBB */
+   case 6: color_string = (char[]){ alpha[0], alpha[1], val[0], val[1], 
val[2], val[3], val[4], val[5], '\0' }; break; /*   RRGGBB */
+   case 4: color_string = (char[]){   val[0],   val[0], val[1], val[1], 
val[2], val[2], val[3], val[3], '\0' }; break; /*  A R G B */
+   case 3: color_string = (char[]){ alpha[0], alpha[1], val[0], val[0], 
val[1], val[1], val[2], val[2], '\0' }; break; /*R G B */
+   case 2: color_string = (char[]){ alpha[0], alpha[1], val[0], val[1], 
val[0], val[1], val[0], val[1], '\0' }; break; /*   XYXYXY */
+   case 1: color_string = (char[]){ alpha[0], alpha[1], val[0], val[0], 
val[0], val[0], val[0], val[0], '\0' }; break; /*   XX */
+   default: goto invalid;
}

errno = 0;
-   *color = strtoul(entry->value, , 16);
+   *color = strtoul(color_string, , 16);
-   if (errno != 0 || end == entry->value || *end != '\0') {
+   if (errno != 0 || end == color_string || *end != '\0') {
+invalid:
*color = default_color;
errno = EINVAL;
return -1;




--

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