[writing a compositor] Displaying something on the screen

2018-05-30 Thread adlo
I am attempting to write a simple test compositor using libweston.

Here is my code so far:

https://github.com/adlocode/test-libweston-desktop

What else do I need to do in order to get it to the point where something 
appears on the screen, such as a rectangle of solid colour?

Regards

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


Re: unique id for wayland objects

2018-05-30 Thread zou lan
Hi Michel & pekka

>>Yes, drm_handle_vblank must be called before drm_crtc_send_vblank_event,
>>otherwise it's not surprising that the timestamp in the event is wrong. :)
Yes. our code call drm_crtc_send_vblank event first. The orignal fps is 60,
but if I swap the order of drm_crtc_send_vblank_event and
drm_handle_vblank, the fps drop to 30fps.

@pekka
>>Weston schedules a repaint based on the pageflip timestamp. If the
>>timestamp is in the past by a whole refresh period, the computed new
>>deadline will be in the past as well, so Weston will attempt to repaint
>>as soon as possible.
I agree with this.

>>The intended behaviour is that Weston repaints at most once for each
>>display refresh cycle, the deadline being 7 ms (if using the default
>>value of repaint-window) before the next vblank. In other words, there
>>should be a significant delay (say, 50-90% of a refresh period) between
>>receiving the pageflip event and repaint.
I can't understand this. I use weston 1.9 now, the repaint_msc is 7ms.
our code always execute output_repaint_timer_handler() as soon as possible
because msec always lower than 1ms. Why there is delay?

Best Regards
Nancy

2018-05-31 0:12 GMT+08:00 Michel Dänzer :

> On 2018-05-30 02:48 PM, Pekka Paalanen wrote:
> > On Wed, 30 May 2018 18:33:40 +0800
> > zou lan  wrote:
> >
> >> Hi pekka
> >>
> >> I'm not familiar with kernel. I know part of drm driver is implement by
> >> ourself. I check the vblank callback function, it sends pageflip event
> >> first if there is a frame complete, update vblank timestamp later.
> >>
> >> I don't know why the owner write code like this. but if I swap the code
> >> order, the fps  decrease a lot.
> >
> > Hi Nancy,
> >
> > I do not know your hardware, so I cannot say why fps decreases, but the
> > order of sending event first and updating the timestamp later does
> > sound wrong to me.
>
> Yes, drm_handle_vblank must be called before drm_crtc_send_vblank_event,
> otherwise it's not surprising that the timestamp in the event is wrong. :)
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel


[PATCH libinput 1/2] udev: drop the custom firmware detection code in favor of a modalias

2018-05-30 Thread Peter Hutterer
This was overengineered. The separation between the model quirks file and the
udev hwdb matches allowed for more complex firmware detection. Except we never
used it anywhere but on ALPS and there we can, thankfully, just get it from
the version number in the input_id field exposed in the modalias.

So let's drop this and use that match instead. We just need an extra udev rule
to match on ID_INPUT_POINTINGSTICKs so we can differ between ALPS touchpads
and ALPS trackpoints.

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

Signed-off-by: Peter Hutterer 
---
 udev/90-libinput-model-quirks.hwdb | 17 +
 udev/90-libinput-model-quirks.rules.in | 21 
 udev/libinput-model-quirks.c   | 35 --
 3 files changed, 17 insertions(+), 56 deletions(-)

diff --git a/udev/90-libinput-model-quirks.hwdb 
b/udev/90-libinput-model-quirks.hwdb
index 6b3ca196..8135665e 100644
--- a/udev/90-libinput-model-quirks.hwdb
+++ b/udev/90-libinput-model-quirks.hwdb
@@ -13,7 +13,6 @@
 #  libinput:touchpad:
 #  libinput:name::dmi:
 #  libinput:name::dt:
-#  libinput:name::fwversion:
 #
 # Sort by brand, model
 
@@ -45,11 +44,21 @@ libinput:name:*AlpsPS/2 ALPS DualPoint TouchPad:dmi:*
 libinput:name:*AlpsPS/2 ALPS GlidePoint:dmi:*
  LIBINPUT_MODEL_ALPS_TOUCHPAD=1
 
-libinput:name:*AlpsPS/2 ALPS DualPoint TouchPad:fwversion:800
-libinput:name:*AlpsPS/2 ALPS GlidePoint:fwversion:800
+# ALPS firmware versions:
+# V1   = 0x100
+# V2   = 0x200
+# V3   = 0x300
+# V3_RUSHMORE  = 0x310
+# V4   = 0x400
+# V5   = 0x500
+# V6   = 0x600
+# V7   = 0x700 /* t3btl t4s */
+# V8   = 0x800 /* SS4btl SS4s */
+# V9   = 0x900 /* ss3btl */
+libinput:touchpad:input:b0011v0002p0008e0800*
  LIBINPUT_ATTR_SIZE_HINT=100x55
 
-libinput:name:*AlpsPS/2 ALPS DualPoint Stick:fwversion:800
+libinput:pointingstick:input:b0011v0002p0008e0800*
  LIBINPUT_ATTR_TRACKPOINT_RANGE=160
 
 ##
diff --git a/udev/90-libinput-model-quirks.rules.in 
b/udev/90-libinput-model-quirks.rules.in
index f29cb8a2..cab8dcda 100644
--- a/udev/90-libinput-model-quirks.rules.in
+++ b/udev/90-libinput-model-quirks.rules.in
@@ -11,23 +11,6 @@
 ACTION!="add|change", GOTO="libinput_model_quirks_end"
 KERNEL!="event*", GOTO="libinput_model_quirks_end"
 
-# Firmware detection, two-stage process.
-# First, run the program and import the LIBINPUT_MODEL_FIRMWARE_VERSION
-# environment (if any)
-KERNELS=="*input*", \
-  ENV{ID_INPUT_TOUCHPAD}=="1", \
-  ENV{.DETECT_FWVERSION}="1"
-KERNELS=="*input*", \
-  ENV{ID_INPUT_POINTINGSTICK}=="1", \
-  ENV{.DETECT_FWVERSION}="1"
-ENV{.DETECT_FWVERSION}!="1", GOTO="skip_fwversion"
-
-IMPORT{program}="@UDEV_TEST_PATH@libinput-model-quirks %S%p"
-ENV{LIBINPUT_MODEL_FIRMWARE_VERSION}!="", \
-  IMPORT{builtin}="hwdb 
'libinput:name:$attr{name}:fwversion:$env{LIBINPUT_MODEL_FIRMWARE_VERSION}'"
-# End of touchpad firmware detection
-LABEL="skip_fwversion"
-
 # libinput:touchpad:
 ENV{ID_INPUT_TOUCHPAD}=="1", \
   IMPORT{builtin}="hwdb --subsystem=input --lookup-prefix=libinput:touchpad:"
@@ -40,6 +23,10 @@ ENV{ID_INPUT_TABLET}=="1", \
 ENV{ID_INPUT_MOUSE}=="1", \
   IMPORT{builtin}="hwdb --subsystem=input --lookup-prefix=libinput:mouse:"
 
+# libinput:pointingstick:
+ENV{ID_INPUT_POINTINGSTICK}=="1", \
+  IMPORT{builtin}="hwdb --subsystem=input 
--lookup-prefix=libinput:pointingstick:"
+
 # libinput:touchpad:
 ENV{ID_INPUT_KEYBOARD}=="1", \
   IMPORT{builtin}="hwdb --subsystem=input --lookup-prefix=libinput:keyboard:"
diff --git a/udev/libinput-model-quirks.c b/udev/libinput-model-quirks.c
index 9eb15054..728f182f 100644
--- a/udev/libinput-model-quirks.c
+++ b/udev/libinput-model-quirks.c
@@ -51,24 +51,6 @@ prop_value(struct udev_device *device,
return prop_value;
 }
 
-static void
-handle_touchpad_alps(struct udev_device *device)
-{
-   const char *product;
-   int bus, vid, pid, version;
-
-   product = prop_value(device, "PRODUCT");
-   if (!product)
-   return;
-
-   if (sscanf(product, "%x/%x/%x/%x", , , , ) != 4)
-   return;
-
-   /* ALPS' firmware version is the version */
-   if (version)
-   printf("LIBINPUT_MODEL_FIRMWARE_VERSION=%x\n", version);
-}
-
 static void
 handle_touchpad_synaptics(struct udev_device *device)
 {
@@ -102,25 +84,10 @@ handle_touchpad(struct udev_device *device)
if (!name)
return;
 
-   if (strstr(name, "AlpsPS/2 ALPS") != NULL)
-   handle_touchpad_alps(device);
if (strstr(name, "Synaptics ") != NULL)
handle_touchpad_synaptics(device);
 }
 
-static void
-handle_pointingstick(struct udev_device *device)
-{
-   const char *name = NULL;
-
-   name = prop_value(device, "NAME");
-   if (!name)
-   return;
-
-   if (strstr(name, "AlpsPS/2 ALPS") != NULL)
-   

[PATCH libinput 2/2] udev: drop the JUMPING_SEMI_MT quirk, no-one uses it

2018-05-30 Thread Peter Hutterer
Obsolete since 342bc510164e89d7c9a742406fb98f9deabf5c8f when we disabled MT on
all semi-mt touchpads.

Signed-off-by: Peter Hutterer 
---
 src/evdev.c  |  1 -
 src/evdev.h  |  1 -
 test/litest-device-synaptics-hover.c | 10 -
 udev/libinput-model-quirks.c | 40 
 4 files changed, 52 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index 2a7743e4..625413c7 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1266,7 +1266,6 @@ evdev_read_model_flags(struct evdev_device *device)
MODEL(WACOM_TOUCHPAD),
MODEL(ALPS_TOUCHPAD),
MODEL(SYNAPTICS_SERIAL_TOUCHPAD),
-   MODEL(JUMPING_SEMI_MT),
MODEL(BOUNCING_KEYS),
MODEL(CYBORG_RAT),
MODEL(HP_STREAM11_TOUCHPAD),
diff --git a/src/evdev.h b/src/evdev.h
index 0d325fad..82094824 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -110,7 +110,6 @@ enum evdev_device_model {
EVDEV_MODEL_WACOM_TOUCHPAD = (1 << 7),
EVDEV_MODEL_ALPS_TOUCHPAD = (1 << 8),
EVDEV_MODEL_SYNAPTICS_SERIAL_TOUCHPAD = (1 << 9),
-   EVDEV_MODEL_JUMPING_SEMI_MT = (1 << 10),
EVDEV_MODEL_BOUNCING_KEYS = (1 << 11),
EVDEV_MODEL_LENOVO_X220_TOUCHPAD_FW81 = (1 << 12),
EVDEV_MODEL_LENOVO_CARBON_X1_6TH = (1 << 13),
diff --git a/test/litest-device-synaptics-hover.c 
b/test/litest-device-synaptics-hover.c
index 2cade172..17529015 100644
--- a/test/litest-device-synaptics-hover.c
+++ b/test/litest-device-synaptics-hover.c
@@ -102,15 +102,6 @@ static struct input_absinfo absinfo[] = {
{ .value = -1 }
 };
 
-static const char udev_rule[] =
-"ACTION==\"remove\", GOTO=\"synaptics_semi_mt_end\"\n"
-"KERNEL!=\"event*\", GOTO=\"synaptics_semi_mt_end\"\n"
-"\n"
-"ATTRS{name}==\"SynPS/2 Synaptics TouchPad\",\\\n"
-"ENV{LIBINPUT_MODEL_JUMPING_SEMI_MT}=\"1\"\n"
-"\n"
-"LABEL=\"synaptics_semi_mt_end\"";
-
 TEST_DEVICE("synaptics-hover",
.type = LITEST_SYNAPTICS_HOVER_SEMI_MT,
.features = LITEST_TOUCHPAD | LITEST_SEMI_MT | LITEST_BUTTON,
@@ -120,5 +111,4 @@ TEST_DEVICE("synaptics-hover",
.id = _id,
.events = events,
.absinfo = absinfo,
-   .udev_rule = udev_rule,
 )
diff --git a/udev/libinput-model-quirks.c b/udev/libinput-model-quirks.c
index 728f182f..020be6a2 100644
--- a/udev/libinput-model-quirks.c
+++ b/udev/libinput-model-quirks.c
@@ -51,43 +51,6 @@ prop_value(struct udev_device *device,
return prop_value;
 }
 
-static void
-handle_touchpad_synaptics(struct udev_device *device)
-{
-   const char *product, *props;
-   int bus, vid, pid, version;
-   int prop;
-
-   product = prop_value(device, "PRODUCT");
-   if (!product)
-   return;
-
-   if (sscanf(product, "%x/%x/%x/%x", , , , ) != 4)
-   return;
-
-   if (bus != BUS_I8042 || vid != 0x2 || pid != 0x7)
-   return;
-
-   props = prop_value(device, "PROP");
-   if (sscanf(props, "%x", ) != 1)
-   return;
-   if (prop & (1 << INPUT_PROP_SEMI_MT))
-   printf("LIBINPUT_MODEL_JUMPING_SEMI_MT=1\n");
-}
-
-static void
-handle_touchpad(struct udev_device *device)
-{
-   const char *name = NULL;
-
-   name = prop_value(device, "NAME");
-   if (!name)
-   return;
-
-   if (strstr(name, "Synaptics ") != NULL)
-   handle_touchpad_synaptics(device);
-}
-
 /**
  * For a non-zero fuzz on the x/y axes, print that fuzz as property and
  * reset the kernel's fuzz to 0.
@@ -165,9 +128,6 @@ int main(int argc, char **argv)
 
handle_absfuzz(device);
 
-   if (prop_value(device, "ID_INPUT_TOUCHPAD"))
-   handle_touchpad(device);
-
rc = 0;
 
 out:
-- 
2.14.3

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


Re: unique id for wayland objects

2018-05-30 Thread Michel Dänzer
On 2018-05-30 02:48 PM, Pekka Paalanen wrote:
> On Wed, 30 May 2018 18:33:40 +0800
> zou lan  wrote:
> 
>> Hi pekka
>>
>> I'm not familiar with kernel. I know part of drm driver is implement by
>> ourself. I check the vblank callback function, it sends pageflip event
>> first if there is a frame complete, update vblank timestamp later.
>>
>> I don't know why the owner write code like this. but if I swap the code
>> order, the fps  decrease a lot.
> 
> Hi Nancy,
> 
> I do not know your hardware, so I cannot say why fps decreases, but the
> order of sending event first and updating the timestamp later does
> sound wrong to me.

Yes, drm_handle_vblank must be called before drm_crtc_send_vblank_event,
otherwise it's not surprising that the timestamp in the event is wrong. :)


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer



signature.asc
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel


Re: [PATCH wayland-protocols v2] unstable/drm-lease: DRM lease protocol support

2018-05-30 Thread Marius-cristian Vlad
On Tue, 2018-05-29 at 17:10 +0300, Pekka Paalanen wrote:
> On Mon, 12 Feb 2018 16:51:51 +0200
> Marius Vlad  wrote:
> 
> > Simple protocol extension to manage DRM lease. Based on the work by
> > Keith
> > Packard in [1], respectively [2].
> > 
> > [1] https://cgit.freedesktop.org/mesa/drm/commit/?id=c4171535389d72
> > e9135c9615cecd07b346fd6d7e
> > [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.
> > git/commit/?h=v4.15-rc9=62884cd386b876638720ef88374b31a84ca7ee5f
> > 
> > Signed-off-by: Marius Vlad 
> > 
> > Changes since v1:
> > - added manager: advertise lease capability and manage the lease
> > (Daniel Stone)
> > - add request(s) for adding connector/crtc/plane to behave more
> > like dmabuf (Daniel Stone)
> > ---
> >  Makefile.am  |   1 +
> >  unstable/drm-lease/README|   4 +
> >  unstable/drm-lease/drm-lease-unstable-v1.xml | 150
> > +++
> >  3 files changed, 155 insertions(+)
> >  create mode 100644 unstable/drm-lease/README
> >  create mode 100644 unstable/drm-lease/drm-lease-unstable-v1.xml
> 
> Hi Marius,
> 
> it's great to have someone working on this!
> 
> I finally got a chance to look at it. Comments are inline as usual.
> Most
> of my questions call for an answer in the spec text.

Thanks for taking the time to go over this. I have some minor follow-up
questions bellow.

> 
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index 4b9a901..4f6a874 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -2,6 +2,7 @@ unstable_protocols =
> > \
> >     unstable/pointer-gestures/pointer-gestures-unstable-v1.xml
> > \
> >     unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
> > \
> >     unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
> > \
> > +   unstable/drm-lease/drm-lease-unstable-v1.xml
> > \
> >     unstable/text-input/text-input-unstable-v1.xml  
> > \
> >     unstable/input-method/input-method-unstable-v1.xml  
> > \
> >     unstable/xdg-shell/xdg-shell-unstable-v5.xml
> > \
> > diff --git a/unstable/drm-lease/README b/unstable/drm-lease/README
> > new file mode 100644
> > index 000..a25600c
> > --- /dev/null
> > +++ b/unstable/drm-lease/README
> > @@ -0,0 +1,4 @@
> > +Linux DRM lease
> > +
> > +Maintainers:
> > +Marius Vlad 
> > diff --git a/unstable/drm-lease/drm-lease-unstable-v1.xml
> > b/unstable/drm-lease/drm-lease-unstable-v1.xml
> > new file mode 100644
> > index 000..907efb0
> > --- /dev/null
> > +++ b/unstable/drm-lease/drm-lease-unstable-v1.xml
> > @@ -0,0 +1,150 @@
> > +
> > +
> > +
> > +  
> > +Copyright 2018 NXP
> > +
> > +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.
> > +  
> > +
> > +  
> > +
> > +  This interface makes use of DRM lease written by Keith
> > Packard.
> > +
> > +  A DRM master can create another DRM master and ``lease''
> > resources it has
> > +  control over to the new DRM master. Once leased, resources
> > can not be
> > +  controlled by the owner unless the owner cancels the lease,
> > or the new
> > +  DRM master is closed.
> > +
> > +  A lease is a contract between the Lessor (DRM master which
> > has leased out
> > +  resources to one or more other DRM masters) and a Lessee
> > +  (DRM master which controls resources leased from another DRM
> > master). This
> > +  contract specifies which resources may be controlled by the
> > Lessee.
> > +
> > +  The Lessee can issue modesetting/page-flipping atomic
> > operations etc.,
> > +  just like a Lesor using the leased file-descriptor passed by
> > the Lesor.
> 
> 

Re: unique id for wayland objects

2018-05-30 Thread zou lan
Hi pekka

I'm not familiar with kernel. I know part of drm driver is implement by
ourself. I check the vblank callback function, it sends pageflip event
first if there is a frame complete, update vblank timestamp later.

I don't know why the owner write code like this. but if I swap the code
order, the fps  decrease a lot.
I can sure this impact the weston's page flip timestamp. Does this have
some impacts to weston except timeline?

I study a little about timeline, I think the picture could still show the
c2p(interval between damage commit and hit screen). Is it right? Thank you.

Best Regards
Nancy

2018-05-24 15:42 GMT+08:00 Pekka Paalanen :

> On Thu, 24 May 2018 15:26:23 +0800
> zou lan  wrote:
>
> > Hi pekka
> >
> > >>are the c2p numbers from weston-presentation-shm demo?
> > yes. I use this demo. My clock is  CLOCK_MONOTONIC.
> >
> > I check the drm kernel code, I find each vblank event send the last
> > vblank's timestamp.
> >
> > system time sec  msec
> > [  263.000526] vblank_event  262  983
> > [  263.017236] vblank_event 2630
> > [  263.033864] vblank_event  263   17
> > [  263.050533] vblank_event  26333
> > [  263.067215] vblank_event  26350
> >
> > I think that's should be the main reason cause the c2p time weird. I
> don't
> > know why kernel return last frame's timestamp. I am still debuging it.
>
> Indeed, that does not sound right. Maybe contact the driver developers
> about this?
>
> Which kernel display driver are you using?
>
>
> Thanks,
> pq
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel


Re: [PATCH weston v9 8/9] weston: support clone mode on DRM-frontend

2018-05-30 Thread Marius-cristian Vlad
Hi, 

This no longer applies, due to man/weston-drm changes. 

Fixing that I get "atomic: get couldn't commit new state: Invalid
argument". Does that mean that HW doesn't support CRTC sharing you
mention in the description? Am I using it properly?

One more thing I found that using the following config:

[output]
name=HDMI-A-1
mode=current
same-as=HDMI-A-2

[output]
name=HDMI-A-2
mode=current

I get ``Output 'HDMI-A-2' enabled with head(s) HDMI-A-1, HDMI-A-2.''

I would've expected  to see ``Output 'HDMI-A-1' enabled with head(s)
HDMI-A-1, HDMI-A-2.'' I don't know of this matters or not... the other
way around is the same (using in HDMI-A-2 section same-as=HDMI-A-1). 



On Thu, 2018-04-19 at 15:09 +0300, Pekka Paalanen wrote:
> From: Pekka Paalanen 
> 
> Add a new output section key "same-as" for configuring clone mode. An
> output marked "same-as" another output will be configured identically
> to
> the other output.
> 
> The current implementation supports only CRTC sharing for clone mode.
> Independent CRTC clone mode cannot be supported until output layout
> logic is moved from libweston into the frontend and libweston's
> damage
> tracking issues stemming from overlapping outputs are solved.
> 
> Quite a lot of infrastructure is needed to properly configure clone
> mode. The implemented logic allows easy addition of independent CRTC
> clone mode once libweston supports it. The idea is that wet_layoutput
> is
> the item to be laid out and all weston_outputs a wet_layoutput
> contains show exactly the same area of the desktop.
> 
> The configuration logic attempts to automatically fall back to
> creating
> more weston_outputs when all heads do not work under the same
> weston_output. For now, the fallback path ends with an error message.
> 
> Enabling a weston_output is bit complicated, because one needs to
> first
> collect all relevant heads, try to attach them all to the
> weston_output,
> and then back up head by head until enabling the weston_output
> succeeds.
> A new weston_output is created for the left-over heads and the
> process
> is repeated.
> 
> CRTC-sharing clone mode is the most efficient clone mode, offering
> synchronized scanout timings, but it is not always supported by
> hardware.
> 
> v9:
> - replace weston_compositor_set_heads_changed_cb() with
>   weston_compositor_add_heads_changed_listener()
> - remove workaround in simple_head_enable()
> 
> v6:
> - Add man-page note about cms-colord.
> - Don't create an output just to turn it off.
> 
> Fixes: https://emea01.safelinks.protection.outlook.com/?url=https%3A%
> 2F%2Fphabricator.freedesktop.org%2FT7727=02%7C01%7Cmarius-
> cristian.vlad%40nxp.com%7C2382a4e34bb74b66b07c08d5a5ee862a%7C686ea1d3
> bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636597366236269669=xoi2xcBR3
> YD9gBAUidQ%2BmoO6oH0QhX3HIvGbGYqySU0%3D=0
> 
> Signed-off-by: Pekka Paalanen 
> Acked-by: Derek Foreman 
> ---
>  compositor/main.c  | 492
> ++---
>  man/weston-drm.man |  12 ++
>  2 files changed, 484 insertions(+), 20 deletions(-)
> 
> diff --git a/compositor/main.c b/compositor/main.c
> index 85c4d338..fe36e69d 100644
> --- a/compositor/main.c
> +++ b/compositor/main.c
> @@ -70,11 +70,41 @@ struct wet_output_config {
>  };
>  
>  struct wet_compositor;
> +struct wet_layoutput;
>  
>  struct wet_head_tracker {
>   struct wl_listener head_destroy_listener;
>  };
>  
> +/** User data for each weston_output */
> +struct wet_output {
> + struct weston_output *output;
> + struct wl_listener output_destroy_listener;
> + struct wet_layoutput *layoutput;
> + struct wl_list link;/**< in
> wet_layoutput::output_list */
> +};
> +
> +#define MAX_CLONE_HEADS 16
> +
> +struct wet_head_array {
> + struct weston_head *heads[MAX_CLONE_HEADS]; /**<
> heads to add */
> + unsigned n; /**< the number
> of heads */
> +};
> +
> +/** A layout output
> + *
> + * Contains wet_outputs that are all clones (independent CRTCs).
> + * Stores output layout information in the future.
> + */
> +struct wet_layoutput {
> + struct wet_compositor *compositor;
> + struct wl_list compositor_link; /**< in
> wet_compositor::layoutput_list */
> + struct wl_list output_list; /**< wet_output::link */
> + char *name;
> + struct weston_config_section *section;
> + struct wet_head_array add;  /**< tmp: heads to add as
> clones */
> +};
> +
>  struct wet_compositor {
>   struct weston_compositor *compositor;
>   struct weston_config *config;
> @@ -83,6 +113,7 @@ struct wet_compositor {
>   struct wl_listener heads_changed_listener;
>   int (*simple_output_configure)(struct weston_output
> *output);
>   bool init_failed;
> + struct wl_list layoutput_list;  /**<
> wet_layoutput::compositor_link */
>  };
>  
>  static FILE *weston_logfile = NULL;
> @@ -1094,12 +1125,6 @@ simple_head_enable(struct wet_compositor *wet,
> struct weston_head *head)
>   struct 

Re: [PATCH_v2] virtual-keyboard: Add new virtual keyboard protocol

2018-05-30 Thread Dorota Czaplejewicz
On Wed, 30 May 2018 14:28:12 +1000
Peter Hutterer  wrote:

> On Thu, May 24, 2018 at 08:27:29PM +0200, Dorota Czaplejewicz wrote:
> > Provides the ability to emulate keyboards by applications. Complementary to 
> > input-method protocol.
> > 
> > The interface is a mirror copy of wl_keyboard, with removed serials, and 
> > added seat binding.
> > ---
> > This is the slightly improved version of the virtual-keyboard-v1 protocol 
> > from Purism.
> > 
> > Changes done:
> > - fixed typos
> > - enum arguments don't have the "enum" key in them, in order not to trip up 
> > wayland-scanner
> > - added errors
> > 
> > The test client is at 
> > https://code.puri.sm/Librem5/weston/src/virtual_keyboard - please use the 
> > weston-keyboard program:
> > 
> > ./configure --enable-clients
> > ./weston-keyboard
> > 
> > A working wlroots implementation is available here:
> > 
> > https://github.com/swaywm/wlroots/pull/999
> > 
> > Thanks for feedback,
> > Dorota Czaplejewicz  
> 
> just one nitpick over Simon's comments, the copyright list starting at 2008
> seems excessive.
> 
> However, I wonder what you're really trying to achieve here. For virtual
> keyboards the mapping to a normal keyboard's physical buttons, then mapped
> to the glyph elsewhere seems strange and limiting. On a virtual keyboard,
> I'm not hitting KEY_A, I'm clicking on the button currently labelled with
> 'A'. There's a million things we could do to virtual keyboard that make the
> assumption of virtual keyboard == physical keyboards go boom quite quickly.
> e.g. on my phone once the emoticons are selected I don't get the normal
> qwerty layout anymore but just a row/column arrangement of smileys.
> 
> I read your v1 email about splitting input-method and virtual-keyboard but
> it's still not quite clear to me, sorry.
> 
> Cheers,
>Peter
> 

Hi Peter,

copyrights go back to 2008 because I used chunks of input-method and 
wayland.xml as the base.

This virtual keyboard protocol is just that - a way to provide an emulated 
input device. It's not expected to be a complete solution for what an actual 
on-screen keyboard is doing, but it's a necessary part. It allows for keyboard 
shortcuts to be used to interact with the compositor for example.

The second part of responsibilities of an on-screen keyboard is providing text 
composition capabilities, which covers the emojis you mentioned, but is also 
limited to text composition scenarios. As an example, it doesn't make sense to 
control the window manager by sending it text but they usually care about 
keyboard shortcuts.

These use cases both look like "a keyboard" as they were traditionally done 
with keyboards, but are really something completely different. To exaggerate 
the difference, the virtual-keyboard protocol is similar to using a game 
controller, and input-method is much closer to handwriting recognition than 
pressing buttons.

I hope that cleared it up a little. Either way, I will be submitting an 
input-method update soon to show the implementation.

Cheers,
Dorota
>  
> >  Makefile.am|   1 +
> >  unstable/virtual-keyboard/README   |   2 +
> >  .../virtual-keyboard-unstable-v1.xml   | 113 
> > +
> >  3 files changed, 116 insertions(+)
> >  create mode 100644 unstable/virtual-keyboard/README
> >  create mode 100644 
> > unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index 4b9a901..fcd4572 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -17,6 +17,7 @@ unstable_protocols =  
> > \
> > 
> > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
> >  \
> > unstable/xdg-output/xdg-output-unstable-v1.xml  
> > \
> > unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
> > +   unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml  \
> > $(NULL)
> >  
> >  stable_protocols = 
> > \
> > diff --git a/unstable/virtual-keyboard/README 
> > b/unstable/virtual-keyboard/README
> > new file mode 100644
> > index 000..a2c646d
> > --- /dev/null
> > +++ b/unstable/virtual-keyboard/README
> > @@ -0,0 +1,2 @@
> > +Virtual keyboard protocol
> > +
> > diff --git a/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml 
> > b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
> > new file mode 100644
> > index 000..df4d01c
> > --- /dev/null
> > +++ b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
> > @@ -0,0 +1,113 @@
> > +
> > +
> > +  
> > +Copyright © 2008-2011  Kristian Høgsberg
> > +Copyright © 2010-2013  Intel Corporation
> > +Copyright © 2012-2013  Collabora, Ltd.
> > +Copyright © 2018   Purism SPC
> > +
> > +Permission is hereby granted, free of charge, to any person obtaining a
> > +