Re: EXT: Re: [PATCH weston 0/4] Optimize pixman renderer

[Ray, Ian (GE Healthcare)]

> On 21 May 2018, at 16.29, Pekka Paalanen  wrote:
> 
> Hi,
> 
> this series was originally written by me as you can see, and Fabien
> lifted the patches, reviewed, tested and submitted them. If no-one
> objects, I would like to land these on Thursday.

Reviewed-by: Ian Ray 

(Nit: patch 3, typo “shadoe”.)


> 
> 
> Thanks,
> pq
> 
> 
> On Mon, 23 Apr 2018 11:44:55 +0200
> Fabien Lahoudere  wrote:
> 
>> Optimizes pixman renderer by:
>> - optimizing compositing damage in DRM/pixman
>> 
>>  Reduce Weston's CPU usage by avoiding unnecessary compositing when updating 
>>  the shadow buffer in pixman-renderer, under the DRM backend. The test was a 
>>  proprietary graphical X11 application in demo mode. The effect is a drop of
>>  total system CPU usage from 0.41 to 0.33.
>> 
>> - optimizing shadow buffer usage
>> 
>>  The shadow framebuffer is an intermediate buffer where the scene is 
>> composited
>>  and then copied from the shadow to the actual hardware buffer. This extra 
>> step
>>  costs memory bandwidth compared to compositing directly into a hardware 
>> buffer.
>> 
>>  Weston's DRM-backend with the Pixman-renderer uses a shadow framebuffer by
>>  default. Especially on systems with dedicated VRAM, read-modify-write cycles
>>  (a.k.a blending) into the scanout-capable buffer can be very slow. Also the
>>  scanout pixel format may not be optimal for compositing. Therefore Weston 
>> takes
>>  the safe default to always use a shadow framebuffer.
>> 
>>  However, in our use case, the hardware does not have dedicated VRAM behind a
>>  relatively slow bus, and the graphical load has practically no blending. We 
>>  can reduce Weston's CPU usage quite a lot by not using the shadow 
>> frambuffer.
>> 
>>  We test on proprietary graphical X11 application in demo mode. Using perf we
>>  measure that this change improve weston CPU usage by 13% with dual display 
>> and
>>  11% with clone mode.
>> 
>> Pekka Paalanen (4):
>>  pixman,drm: do not composite previous damage
>>  pixman: make shadow buffer optional
>>  compositor-drm: expose global shadow flag for pixman
>>  main: add setting for DRM/pixman shadow framebuffer
>> 
>> compositor/main.c   |  3 ++
>> libweston/compositor-drm.c  | 30 +++--
>> libweston/compositor-drm.h  |  3 ++
>> libweston/compositor-fbdev.c|  3 +-
>> libweston/compositor-headless.c |  3 +-
>> libweston/compositor-rdp.c  |  5 ++-
>> libweston/compositor-wayland.c  |  3 +-
>> libweston/compositor-x11.c  |  6 ++-
>> libweston/pixman-renderer.c | 99 
>> -
>> libweston/pixman-renderer.h | 13 +-
>> man/weston-drm.man  |  4 ++
>> 11 files changed, 118 insertions(+), 54 deletions(-)
>> 
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

Re: EXT: Re: [PATCH weston 0/4] Handle several NULL output pointer

[Ray, Ian (GE Healthcare)]

> On 21 May 2018, at 16.37, Pekka Paalanen  wrote:
> 
> Hi,
> 
> this series was originally written by me as you can see, and Fabien
> lifted the patches, reviewed, tested and submitted them. If no-one
> objects, I would like to land these on Thursday.
> 

Reviewed-by: Ian Ray 


(Nit: patch 4 has a typo “somwhere”.)


> 
> Thanks,
> pq
> 
> 
> On Wed,  2 May 2018 10:21:54 +0200
> Fabien Lahoudere  wrote:
> 
>> This is a series of fixes, for the case when Weston is running without any
>> connected outputs (weston_outputs).
>> 
>> Pekka Paalanen (4):
>>  desktop-shell: handle NULL output in get_output_work_area()
>>  desktop-shell: handle NULL output in center_on_output()
>>  desktop-shell: do not lower_fullscreen_layer(s, NULL)
>>  desktop-shell: survive NULL output in shell_configure_fullscreen()
>> 
>> desktop-shell/shell.c | 24 +++-
>> 1 file changed, 23 insertions(+), 1 deletion(-)
>> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[ANNOUNCE] libinput 1.10.901

[Peter Hutterer]

The first RC for libinput 1.11 is now available.

Quite a long development cycle this time and a bunch of things have changed,
some of which have already found their way onto the 1.10.x branch. Here's
and abbreviated list of changes since the 1.10.0 release:

A new tool pair is available now: libinput record and libinput replay.
These tools supersede the evemu-record/evemu-play tools currently used to
debug events. Usage is basically the same for users, simply run
sudo libinput record
and select your device. The biggest advantages are that we can now
record and replay multiple devices at once and interleave the output from
evdev with the one from libinput. This should make debugging a lot easier.
For more info, see 
https://wayland.freedesktop.org/libinput/doc/latest/tools.html#libinput-record

The touchpad jitter detection code has been improved to reduce the
number of false positives. Some touchpads require the kernel fuzz setting to
be set to avoid pointer jitter though, please see this page for details:
https://wayland.freedesktop.org/libinput/doc/latest/touchpad_jitter.html

A new touchpad acceleration code has been merged, the behavior now resembles
the pointer acceleration of macos. You will notice that your touchpad is
slower at slow speeds and accelerates sooner. At the same time, the speed
range available has been greatly extended, so the slowest speed and highest
speed are quite significantly apart now. This should, hopefully, allow all
users to select a speed to match their preferences.

The maximum delta for trackpoints has been increased, reducing the amount of
pressure required to move the pointer around the screen. We also merged a
bunch of trackpoint range hwdb entries to set the expected range for some
common devices. The POINTINGSTICK_SENSITIVITY udev property is now ignored,
instead we just read that value directly from sysfs.

A new API call is now available to fetch the number of supported touches
from a device with the LIBINPUT_DEVICE_CAP_TOUCH capability:
   libinput_device_touch_get_touch_count()
You can use this call to determine if the touch device is single- or
multi-touch capable.

Note to packagers: the libinput-list-devices and libinput-debug-events
compat scripts have been dropped, see commit 8a223e739b0a35e28. Revert that
one if you need to keep shipping those.

In addition to the above, we have various fixes across the board including
palm detection and thumb detection improvements, better handling of Aiptek,
HUION, etc. graphics tablets and better handling of the stylus -> touch
transition on graphics tablets.

As usual, the git shortlog is below.

Chow Loong Jin (1):
  Bump TRACKPOINT_DEFAULT_MAX_DELTA to 120

Daniel van Vugt (2):
  Introduce omnidirectional (elliptical) hysteresis
  Improve responsiveness for Apple Magic Trackpad

Davide Depau (1):
  evdev: don't suspend keyboard on ThinkPad X1 Yoga 1st in tablet mode

Deepa Dinamani (1):
  Update struct input_event

Friedrich Schöller (1):
  touchpad: fix tapping that happens after a moving thumb

Konstantin Kharlamov (3):
  indentation: add .dir-locals.el for emacs
  touchpad: remove the code for disabling hysteresis
  touchpad: add wobbling detection

Mario Di Raimondo (1):
  Fix Apple Magic Trackpad sensitivity

Maxin B. John (1):
  libinput-measure-touchpad-tap: use /usr/bin/env to invoke python3

Mike Hogye (1):
  Fix spurious palm detections for Logitech Wireless Touchpad

Nandor Han (1):
  udev: validate input devices during cold-plug

Paul Kocialkowski (1):
  udev: Fix Chromebook R13 CB5-312T hwdb name

Peter Ganzhorn (1):
  fallback: Add IBM/Lenovo Scrollpoint mice quirk to enable smooth 
scrolling.

Peter Hutterer (198):
  evdev: fail before open_restricted if the devnode doesn't exist
  evdev: add a quirk to disable debouncing on the MS Nano Transcievers
  test: make the mouse tool a litest feature bit
  tablet: move the quirk disabling up within tablet_init
  tablet: release the tablet state on device delete
  tablet: skip tablet_flush() if our current tool type is none
  tablet: disable BTN_TOOL_MOUSE/LENS for non-Wacom tablets
  tablet: fake a BTN_TOOL_PEN on the first event if needed
  Add a test device for aiptek tablets
  Silence coverity warning about uninitialized entry
  Don't leak when realloc fails
  udev: fix segfault when resuming before assigning a seat
  touchpad: compress a statement
  touchpad: add a touch index for debugging
  test: send major/minor for the wacom intous 5 finger device
  touchpad: only begin fake touches when we have at least one finger down
  meson: add the 221 version to the libsystemd dependency
  touchpad: reset the palm state to NONE on a new touch
  touchpad: change the stylus palm arbitration to process touches
  evdev: pass the time down to toggle_touch
  touchpad: delay arbitration by 90ms after touch toggle
  

Re: [PATCH] xwm: Handle changing override redirect flag

[Scott Moreau]

Hi,

I think un-reparenting would involve reparenting to the whatever the parent
was before reparenting in the first place. I haven't given this too much
thought and I don't know if this case ever happens in practice but figured
I'd comment about it since Pekka mentioned possibly reviewing it soon.

Thanks,
Scott

On Thu, Mar 29, 2018 at 5:17 AM, Pekka Paalanen  wrote:

> On Sun, 18 Mar 2018 12:22:15 -0600
> Scott Moreau  wrote:
>
> > Xwayland windows might be created with a different override redirect
> > flag than is given on map or configure notify. This causes confusion
> > about whether a window should be treated as override redirect or not.
> > Here we handle the changing override redirect flag in relevant notify
> > handlers so windows are treated appropriately. In particular, this
> > fixes positioning menus in clients like VLC, though it is not a
> > complete fix. If the window is moved, the menus are still positioned
> > as if the window wasn't moved.
> > ---
> >  xwayland/window-manager.c | 43 ++
> +
> >  1 file changed, 35 insertions(+), 8 deletions(-)
>
> Hi,
>
> this patch looks big enough that I'd consider it more a new feature
> than just a bug fix, so I'd like to postpone this after the 4.0.0
> release.
>
> I've marked this as deferred in Patchwork.
>
>
> Thanks,
> pq
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: unique id for wayland objects

[zou lan]

Hi pekka

I debug the presentation time recently. I have checked each user call
drmAtomicCommit get the corresponding pageflip event.
But some presentation results (c2p) are a little weird. They are 1~5ms or
-1 ~ -5 ms. some results are normal(8 ~ 20 ms).
I used to explain the weird result is because  pageflip return last frame's
timestamp, but I can't explain the normal results.

I suspect whether the kernel and user have the same time start point. It's
just a guess, I have no evidence.

Do you have some tips about the c2p results? Thank you.

Best Regards
Nancy


2018-05-12 23:17 GMT+08:00 Pekka Paalanen :

> On Thu, 10 May 2018 12:53:49 +0800
> zou lan  wrote:
>
> > Hi pekka
> >
> > I test presentation on my side. The presentation results is not accurate
> > because our pageflip event send last frame's timestamp every time. So
> > weston_output_finish_frame send last frame's present tine
> > to current frame's feedback. For this situation, I just delay one frame
> to
> > send present event. Does this get the right c2p time? Thank you.
>
> Hi Nancy,
>
> I think your driver needs to get fixed, so that it provides the
> correct timestamp instead of an outdated one. If this is a kernel
> DRM driver, then the behaviour you describe is clearly a bug. The
> timestamp of the pageflip event signifies the time the new frame
> starts transmitting out of the connector. I believe there should be
> DRM driver API documentation stating that.
>
> This is also what weston_output_finish_frame() expects. Anything
> else will cause the frame scheduling to misbehave.
>
> It may be possible to work around the bug as you suggest, but that
> will make the compositor incorrect on any other driver, and it may
> cause other subtle breakage (the timestamp may be correct, but the
> time the event gets sent is now wrong and might even be delayed
> indefinitely if nothing causes a repaint).
>
>
> Thanks,
> pq
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 1/1] desktop-shell: detect stale shell surface outputs

[Pekka Paalanen]

On Wed,  2 May 2018 11:10:32 +0200
Fabien Lahoudere  wrote:

> From: Semi Malinen 
> 
> When displays are hot (un)plugged, it may happen that
> a shell surface is left with a stale pointer to an output
> that has already been freed. Add an output destroy listener
> to catch such situations and set the output pointer to NULL.
> 
> Signed-off-by: Semi Malinen 
> Signed-off-by: Fabien Lahoudere 
> ---
>  desktop-shell/shell.c | 29 +++--
>  1 file changed, 27 insertions(+), 2 deletions(-)

Pushed with my R-b:
   e7a52fbb..99f8c085  master -> master


Thanks,
pq


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

Re: [PATCH weston 0/2] xwm: Dump properties.

[Pekka Paalanen]

Hi,

I'd like to push these two patches as well on Thursday if no-one objects.

I'll hold off with the O-R state debugging patch until I get a chance
to look at Scott's implementation for O-R changes. I think Scott's
patch should make the debugging patch unnecessary.


Thanks,
pq

On Fri,  4 May 2018 12:53:53 +0200
Fabien Lahoudere  wrote:

> This series adds code to help debug by dumping properties of type CARDINAL and
> WINDOW.
> 
> Pekka Paalanen (2):
>   xwm: dump properties of type CARDINAL
>   xwm: dump properties of type WINDOW
> 
>  xwayland/window-manager.c | 70 
> ++-
>  1 file changed, 69 insertions(+), 1 deletion(-)
> 


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

Re: [PATCH weston 0/4] Handle several NULL output pointer

[Pekka Paalanen]

Hi,

this series was originally written by me as you can see, and Fabien
lifted the patches, reviewed, tested and submitted them. If no-one
objects, I would like to land these on Thursday.


Thanks,
pq


On Wed,  2 May 2018 10:21:54 +0200
Fabien Lahoudere  wrote:

> This is a series of fixes, for the case when Weston is running without any
> connected outputs (weston_outputs).
> 
> Pekka Paalanen (4):
>   desktop-shell: handle NULL output in get_output_work_area()
>   desktop-shell: handle NULL output in center_on_output()
>   desktop-shell: do not lower_fullscreen_layer(s, NULL)
>   desktop-shell: survive NULL output in shell_configure_fullscreen()
> 
>  desktop-shell/shell.c | 24 +++-
>  1 file changed, 23 insertions(+), 1 deletion(-)
> 


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

Re: [PATCH weston 0/4] Optimize pixman renderer

[Pekka Paalanen]

Hi,

this series was originally written by me as you can see, and Fabien
lifted the patches, reviewed, tested and submitted them. If no-one
objects, I would like to land these on Thursday.


Thanks,
pq


On Mon, 23 Apr 2018 11:44:55 +0200
Fabien Lahoudere  wrote:

> Optimizes pixman renderer by:
> - optimizing compositing damage in DRM/pixman
> 
>   Reduce Weston's CPU usage by avoiding unnecessary compositing when updating 
>   the shadow buffer in pixman-renderer, under the DRM backend. The test was a 
>   proprietary graphical X11 application in demo mode. The effect is a drop of
>   total system CPU usage from 0.41 to 0.33.
> 
> - optimizing shadow buffer usage
> 
>   The shadow framebuffer is an intermediate buffer where the scene is 
> composited
>   and then copied from the shadow to the actual hardware buffer. This extra 
> step
>   costs memory bandwidth compared to compositing directly into a hardware 
> buffer.
> 
>   Weston's DRM-backend with the Pixman-renderer uses a shadow framebuffer by
>   default. Especially on systems with dedicated VRAM, read-modify-write cycles
>   (a.k.a blending) into the scanout-capable buffer can be very slow. Also the
>   scanout pixel format may not be optimal for compositing. Therefore Weston 
> takes
>   the safe default to always use a shadow framebuffer.
> 
>   However, in our use case, the hardware does not have dedicated VRAM behind a
>   relatively slow bus, and the graphical load has practically no blending. We 
>   can reduce Weston's CPU usage quite a lot by not using the shadow 
> frambuffer.
>   
>   We test on proprietary graphical X11 application in demo mode. Using perf we
>   measure that this change improve weston CPU usage by 13% with dual display 
> and
>   11% with clone mode.
> 
> Pekka Paalanen (4):
>   pixman,drm: do not composite previous damage
>   pixman: make shadow buffer optional
>   compositor-drm: expose global shadow flag for pixman
>   main: add setting for DRM/pixman shadow framebuffer
> 
>  compositor/main.c   |  3 ++
>  libweston/compositor-drm.c  | 30 +++--
>  libweston/compositor-drm.h  |  3 ++
>  libweston/compositor-fbdev.c|  3 +-
>  libweston/compositor-headless.c |  3 +-
>  libweston/compositor-rdp.c  |  5 ++-
>  libweston/compositor-wayland.c  |  3 +-
>  libweston/compositor-x11.c  |  6 ++-
>  libweston/pixman-renderer.c | 99 
> -
>  libweston/pixman-renderer.h | 13 +-
>  man/weston-drm.man  |  4 ++
>  11 files changed, 118 insertions(+), 54 deletions(-)
> 



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

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

[Markus Ongyerth]

On 2018/5月/18 07:23, roderick.colenbran...@sony.com wrote:
> Hi Dorota,
> 
> Thanks for sharing your proposal. Ourselves we have interest in this 
> kind of capability as well. Looking at our own use cases, I wonder if 
> this proposal goes far enough.
> 
> We are basically interested in the ability to inject keyboard, mouse, 
> touch (and gamepad). On regular X some of that worked through XTest 
> protocol. From my perspective any virtual keyboard proposal, would make 
> sense to be flexible enough to handle other input devices as well.
All of these devices are different enough, that they need a dedicated API in 
some way (keys/analog axis/relative movements). This could be implemented as 
different interfaces in the same protocol, or separate protocols.
IMO splitting it up will be nicer, so compositors and clients can update the 
versions they support indipendently, and we aren't forced to bump a version on 
virtual keyboards to add to virtual gamepads.

> 
> On the other hand some may bring up, why virtual device support should 
> be in Wayland as input devices can also be spoofed through uinput.
Doing this as a wayland protocol has the (IMO huge) advantage that it doesn't 
require root permissions, and can be well confined.
Adding an input device into a test session with uinput sounds like a hassle as 
well, since the user session will pick it up as well by default. As wayland 
protocol it can just be spawned into the correct session.

Cheers,
ongy
> 
> Thanks,
> 
> Roderick Colenbrander
> Sr Manager Hardware & Systems Engineering
> Sony Interactive Entertainment
> 
> On 05/17/2018 09:55 AM, 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 proposal is another one needed by Purism to support on screen 
> > keyboards on a phone screen.
> > 
> > Virtual-keyboard is a protocol to let applications send arbitrary keyboard 
> > events. The need for this protocol comes from the fact that the 
> > input-method protocol combines two separate input responsibilities. It 
> > currently deals both with text input and raw keyboard events. I hope to 
> > split input-method along this line into virtual-keyboard and the rest of 
> > input-method. I'm going to submit the updated input-method for review soon.
> > 
> > Applications should be able to control both interfaces at the same time. A 
> > screen keyboard supporting autocorrect (input-method) still wants to send 
> > arrow keys (vityual-keyboard) correctly. Because of this, both kinds of 
> > events at minimum must be sent to the same seat. I made the seat binding 
> > explicitly done by the application, taking inspiration from text-input 
> > protocol, which assumes per-seat binding as well.
> > 
> > Input welcome.
> > 
> > Cheers,
> > Dorota
> > 
> >   Makefile.am|  1 +
> >   .../virtual-keyboard-unstable-v1.xml   | 97 
> > ++
> >   2 files changed, 98 insertions(+)
> >   create mode 100644 
> > unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index 4b9a901..51a47a2 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  \
> > +   nstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml   \
> > $(NULL)
> >   
> >   stable_protocols =
> > \
> > 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..18130e2
> > --- /dev/null
> > +++ b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
> > @@ -0,0 +1,97 @@
> > +
> > +
> > +  
> > +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
> > +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 

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

[Dorota Czaplejewicz]

Hello Roderick,

On Fri, 18 May 2018 19:23:15 +
 wrote:

> Hi Dorota,
> 
> Thanks for sharing your proposal. Ourselves we have interest in this 
> kind of capability as well. Looking at our own use cases, I wonder if 
> this proposal goes far enough.
> 
> We are basically interested in the ability to inject keyboard, mouse, 
> touch (and gamepad). On regular X some of that worked through XTest 
> protocol. From my perspective any virtual keyboard proposal, would make 
> sense to be flexible enough to handle other input devices as well.

I thought about adding mouse or game controller support in the same protocol, 
but I came to the conclusion that they would be better off as dedicated 
protocols. We already have an input method protocol, which can be considered an 
input device, then the separate keyboard protocol already, and using a 
dedicated one for any other type of device would follow this trend.

The main reason to keep separate, however, is to keep it simple to develop. 
Personally, I don't have much of an idea about approaching a mouse or gamepad 
protocol, because they are not in the scope of what I'm doing. That puts a 
damper on my efforts regarding virtual keyboard. In the same way, I expect 
protocol designers of the future to only have experience in a subset of 
devices, and they will probably want to avoid worrying about possible changes 
to other devices when they update what they care about.
> 
> On the other hand some may bring up, why virtual device support should 
> be in Wayland as input devices can also be spoofed through uinput.
> 
Wayland can still be a good place for these kinds of protocols, due to how it 
handles seat assignment. I would not be able to ensure that an input method and 
a virtual keyboard is assigned the same seat if I tried to emulate the keyboard 
in a lower layer. I suspect that this is not the only possible issue in this 
area. The effect of a single standard interface is also important – 
applications don't have to rely on system-specific libraries any more, and make 
things like nested sessions much more palatable.

> Thanks,
> 
> Roderick Colenbrander
> Sr Manager Hardware & Systems Engineering
> Sony Interactive Entertainment
> 

Have a nice day,
Dorota Czaplejewicz

> On 05/17/2018 09:55 AM, 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 proposal is another one needed by Purism to support on screen 
> > keyboards on a phone screen.
> > 
> > Virtual-keyboard is a protocol to let applications send arbitrary keyboard 
> > events. The need for this protocol comes from the fact that the 
> > input-method protocol combines two separate input responsibilities. It 
> > currently deals both with text input and raw keyboard events. I hope to 
> > split input-method along this line into virtual-keyboard and the rest of 
> > input-method. I'm going to submit the updated input-method for review soon.
> > 
> > Applications should be able to control both interfaces at the same time. A 
> > screen keyboard supporting autocorrect (input-method) still wants to send 
> > arrow keys (vityual-keyboard) correctly. Because of this, both kinds of 
> > events at minimum must be sent to the same seat. I made the seat binding 
> > explicitly done by the application, taking inspiration from text-input 
> > protocol, which assumes per-seat binding as well.
> > 
> > Input welcome.
> > 
> > Cheers,
> > Dorota
> > 
> >   Makefile.am|  1 +
> >   .../virtual-keyboard-unstable-v1.xml   | 97 
> > ++
> >   2 files changed, 98 insertions(+)
> >   create mode 100644 
> > unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index 4b9a901..51a47a2 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  \
> > +   nstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml   \
> > $(NULL)
> >   
> >   stable_protocols =
> > \
> > 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..18130e2
> > --- /dev/null
> > +++ b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
> > @@ -0,0 +1,97 @@
> > +
> > +
> > +  
> > +Copyright © 2008-2011  Kristian Høgsberg
> > 

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

[Roderick.Colenbrander]

Hi Dorota,

Thanks for sharing your proposal. Ourselves we have interest in this 
kind of capability as well. Looking at our own use cases, I wonder if 
this proposal goes far enough.

We are basically interested in the ability to inject keyboard, mouse, 
touch (and gamepad). On regular X some of that worked through XTest 
protocol. From my perspective any virtual keyboard proposal, would make 
sense to be flexible enough to handle other input devices as well.

On the other hand some may bring up, why virtual device support should 
be in Wayland as input devices can also be spoofed through uinput.

Thanks,

Roderick Colenbrander
Sr Manager Hardware & Systems Engineering
Sony Interactive Entertainment

On 05/17/2018 09:55 AM, 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 proposal is another one needed by Purism to support on screen keyboards 
> on a phone screen.
> 
> Virtual-keyboard is a protocol to let applications send arbitrary keyboard 
> events. The need for this protocol comes from the fact that the input-method 
> protocol combines two separate input responsibilities. It currently deals 
> both with text input and raw keyboard events. I hope to split input-method 
> along this line into virtual-keyboard and the rest of input-method. I'm going 
> to submit the updated input-method for review soon.
> 
> Applications should be able to control both interfaces at the same time. A 
> screen keyboard supporting autocorrect (input-method) still wants to send 
> arrow keys (vityual-keyboard) correctly. Because of this, both kinds of 
> events at minimum must be sent to the same seat. I made the seat binding 
> explicitly done by the application, taking inspiration from text-input 
> protocol, which assumes per-seat binding as well.
> 
> Input welcome.
> 
> Cheers,
> Dorota
> 
>   Makefile.am|  1 +
>   .../virtual-keyboard-unstable-v1.xml   | 97 
> ++
>   2 files changed, 98 insertions(+)
>   create mode 100644 
> unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
> 
> diff --git a/Makefile.am b/Makefile.am
> index 4b9a901..51a47a2 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  \
> + nstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml   \
>   $(NULL)
>   
>   stable_protocols =  
> \
> 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..18130e2
> --- /dev/null
> +++ b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
> @@ -0,0 +1,97 @@
> +
> +
> +  
> +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
> +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.
> +  
> +
> +  
> +
> +  The virtual keyboard provides an application with requests which 
> emulate
> +  the behaviour of a physical keyboard.
> +
> +  This interface can be used by clients on its own to provide raw input
> +  events, or it can accompany the input method protocol.
> +
> +
> +
> +  
> +Provide a file descriptor to the compositor 

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

[Simon Ser]

On May 21, 2018 12:12 AM, Dorota Czaplejewicz  
wrote:
> Apart from the typo that Silvan spotted, I have also encountered the issue 
> where
> the .c/.h generator complained about undefined key_state and keymap_format 
> enums
> which are defined in wayland.xml. I'm not sure what the correct way to solve
> this - should they be copied into this protocol?

This is a bug in wayland-scanner, see [1]. Fixing wayland-scanner has been on my
TODO-list for a while, but if you want to do it, go ahead. A (less than ideal)
workaround is to remove the "enum" attribute from the  for now.

[1]: https://lists.freedesktop.org/archives/wayland-devel/2018-April/037960.html

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