[RFC v3 wayland-protocols] inputfd - direct input access protocol

[Peter Hutterer]

For previous versions, see:
v1: https://lists.freedesktop.org/archives/wayland-devel/2017-March/033626.html
v2: https://lists.freedesktop.org/archives/wayland-devel/2017-April/033819.html

This update is closer to v1 again than v2. Biggest change is: instead of a
get_seat we have a get_seat_evdev request. Anything evdev is then hanging
off that seat, basically in how it was before. The hierarchy of objects is
thus something like this:

manager
  seat_evdev
 device_evdev
 device_evdev
 device_evdev

and in the future we could have other interfaces like this:

manager
  seat_evdev
 device_evdev
 device_evdev
 device_evdev
 device_evdev
  seat_hidraw
 device_hidraw
 device_hidraw
 device_hidraw
  seat_w3c
 device_w3c
 device_w3c

Having it split at the seat level means we don't have to pollute each
interface with the different needs of the other interfaces. evdev is the
easiest case, so that's done first. I dropped the extra properties, Bastien
and I discussed this at GUADEC and we agreed it's better to implement the
minimal version first and then see what we need before trying to come up
with a generic solution.

Cheers,
   Peter

diff --git a/Makefile.am b/Makefile.am
index 5b5ae96..7b0a3b0 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -4,6 +4,7 @@ unstable_protocols =
\
unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
\
unstable/text-input/text-input-unstable-v1.xml  
\
unstable/input-method/input-method-unstable-v1.xml  
\
+   unstable/inputfd/inputfd-unstable-v1.xml
\
unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
unstable/xdg-shell/xdg-shell-unstable-v6.xml
\
unstable/relative-pointer/relative-pointer-unstable-v1.xml  
\
diff --git a/unstable/inputfd/README b/unstable/inputfd/README
new file mode 100644
index 000..a24d858
--- /dev/null
+++ b/unstable/inputfd/README
@@ -0,0 +1,4 @@
+Input device fd passing protocol
+
+Maintainers:
+Peter Hutterer 
diff --git a/unstable/inputfd/inputfd-unstable-v1.xml 
b/unstable/inputfd/inputfd-unstable-v1.xml
new file mode 100644
index 000..c8a0380
--- /dev/null
+++ b/unstable/inputfd/inputfd-unstable-v1.xml
@@ -0,0 +1,268 @@
+
+
+  
+Copyright 2017 © Red Hat, Inc.
+
+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 description provides a high-level overview of the interfaces
+in this protocol. For details, see the protocol specification.
+
+Some input devices do not interact with the windowing system. Examples
+of such input devices are gaming controllers or 3D mice. In many cases,
+a client requires direct access to the device to access or interpret
+device-specific functionality.
+
+This interface provides client access to input devices via a file
+descriptor (fd). The compositor may restrict the type of device
+accessible and it may restrict specific events from being sent to the
+client (e.g.  by masking the Home button on a gamepad). Otherwise, a
+client should treat the device as if opened manually.
+
+Multiple input devices may exists and be assigned to different seats.
+The top-level object of this protocol is a wp_inputfd_manager. A client
+must request the desired interface for a given seat. This object then
+provides the list of devices for that category that match the fd type of
+that interface. At the moment, only the evdev fd type is supported but in
+the future, a device may be accessible via multiple fd interfaces.
+
+Once a compositor deems a device to be 

Re: [PATCH wayland-protocols v2] Introduce xdg-foreign protocol

[Marco Martin]

On Monday 21 August 2017 10:49:55 Jonas Ådahl wrote:
> On Thu, Aug 17, 2017 at 05:05:35PM +0200, Marco Martin wrote:
> > On Thu, Aug 10, 2017 at 3:47 AM, Jonas Ådahl  wrote:
> > > Anyhow, "export_surface" or maybe even "export_toplevel" (as that is the
> > > only thing we allow exporting anyway) seems fine to me. The "import"
> > > request should be renamed in a similar manner as well then.
> > 
> > here attached a patch to rename the calls to export_toplevel and
> > import_toplevel, is that ok?
> 
> You'll need to create an "unstable v2" version, as this is a
> non-backward compatible change. To do that, copy the XML file, changing

attached a patch that adds the new v2 file, comments adressed

-- 
Marco Martin>From 152b44e69c131d470c447f66aa9aadc819d5a1df Mon Sep 17 00:00:00 2001
From: Marco Martin 
Date: Tue, 22 Aug 2017 18:04:25 +0200
Subject: [PATCH] foreignv2: rename export and import calls

as export is a reserved keyword in C++, in order for the
output generated by wayland_scanner to compile correctly
rename export to export_toplevel and import to import_toplevel
this needs a new protocol version as is an incompatible change

Signed-off-by: Marco Martin 
---
 unstable/xdg-foreign/xdg-foreign-unstable-v2.xml | 182 +++
 1 file changed, 182 insertions(+)
 create mode 100644 unstable/xdg-foreign/xdg-foreign-unstable-v2.xml

diff --git a/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml b/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml
new file mode 100644
index 000..8e824c1
--- /dev/null
+++ b/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml
@@ -0,0 +1,182 @@
+
+
+
+  
+Copyright © 2015-2016 Red Hat Inc.
+
+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 protocol specifies a way for making it possible to reference a surface
+of a different client. With such a reference, a client can, by using the
+interfaces provided by this protocol, manipulate the relationship between
+its own surfaces and the surface of some other client. For example, stack
+some of its own surface above the other clients surface.
+
+In order for a client A to get a reference of a surface of client B, client
+B must first export its surface using xdg_exporter.export. Upon doing this,
+client B will receive a handle (a unique string) that it may share with
+client A in some way (for example D-Bus). After client A has received the
+handle from client B, it may use xdg_importer.import to create a reference
+to the surface client B just exported. See the corresponding requests for
+details.
+
+A possible use case for this is out-of-process dialogs. For example when a
+sandboxed client without file system access needs the user to select a file
+on the file system, given sandbox environment support, it can export its
+surface, passing the exported surface handle to an unsandboxed process that
+can show a file browser dialog and stack it above the sandboxed client's
+surface.
+
+Warning! The protocol described in this file is experimental and backward
+incompatible changes may be made. Backward compatible changes may be added
+together with the corresponding interface version bump. Backward
+incompatible changes are done by bumping the version number in the protocol
+and interface names and resetting the interface version. Once the protocol
+is to be declared stable, the 'z' prefix and the version number in the
+protocol and interface names are removed and the interface version number is
+reset.
+  
+
+  
+
+  A global interface used for exporting surfaces that can later be imported
+  using xdg_importer.
+
+
+
+  
+	Notify the compositor that the xdg_exporter object will no longer be
+	used.
+  
+
+
+
+  
+	The export_toplevel 

Re: [PATCH 4/5] build: set the scanner --object-type option

[Emil Velikov]

On 18 August 2017 at 13:14, Pekka Paalanen  wrote:
> On Fri, 28 Jul 2017 13:23:46 +0100
> Emil Velikov  wrote:
>
>> On 27 July 2017 at 14:36, Pekka Paalanen  wrote:
>> > On Wed, 26 Jul 2017 14:56:20 +0100
>> > Emil Velikov  wrote:
>> >
>> >> From: Emil Velikov 
>> >>
>> >> Unlike most other scanner users, the core wayland interfaces are
>> >> public ally available via the libwayland DSO.
>> >>
>> >> Signed-off-by: Emil Velikov 
>> >> ---
>> >>  Makefile.am | 2 +-
>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/Makefile.am b/Makefile.am
>> >> index d0c8bd3..4055d04 100644
>> >> --- a/Makefile.am
>> >> +++ b/Makefile.am
>> >> @@ -97,7 +97,7 @@ nodist_libwayland_client_la_SOURCES =   \
>> >>  pkgconfig_DATA += src/wayland-client.pc src/wayland-server.pc
>> >>
>> >>  protocol/%-protocol.c : $(top_srcdir)/protocol/%.xml
>> >> - $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) code < $< > $@
>> >> + $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) 
>> >> --object-type=shared code < $< > $@
>> >>
>> >>  protocol/%-server-protocol.h : $(top_srcdir)/protocol/%.xml
>> >>   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) server-header 
>> >> < $< > $@
>> >
>> > Hi,
>> >
>> > looks good, but I wonder if the header commands need the type set as
>> > well to avoid the warning.
>> >
>> My goal was to have the option only for "code", but it seems like the
>> scanner will throw a warning when client/server-header instances are
>> missing it.
>>
>> I could omit the warning or simply add have --object-type throughout
>> the Makefile, for consistence.
>
> Hi Emil,
>
> right. The only argument one way or another that I can think of for now
> is that it might be slightly more future-proof if all scanner
> invocations used the same set of options. That way if we need something
> in headers based on object-type, users would already be set. But I
> can't think of what it might be so it's a very weak argument.
>
Hey Pekka,

Fully agree: consistency and keeping it futureproof (future capable
really) sounds like a good idea.
I'll do so with v2 of the series.

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

Re: [PATCH 3/5] scanner: introduce --object-type option

[Emil Velikov]

On 18 August 2017 at 13:05, Pekka Paalanen  wrote:

>> >
>> > The exported configuration would then be:
>> > LOCAL_INTERFACE_DECL=extern
>> > EXTERN_INTERFACE_DECL=extern
>> > LOCAL_INTERFACE_DEF=WL_EXPORT
>> >
>> > That would be far too flexible and no-one would use it right, right?
>> >
>> I did not introduce separate tokens, since those are (and should be)
>> used _only_ in the .c file.
>> Personally then do not seem necessary, If you prefer we can add them though.
>
> Ah, no, that was just a wild idea of something completely different. I
> meant that the user project would be setting those macros before using
> scanner-generated files, and if unset, the scanner-emitted code would
> default to the legacy behaviour. That way there would be no visibility
> modes in scanner itself. If it's not obviously better, then nevermind.
> It certainly has a lot more room to go wrong than your proposal.
>
>
I see.

Personally I'd lean towards with my approach for now since it is
simpler, despite that it provides less flexibility.
As you pointed out the proposal is a bit more fragile, so might be
better to avoid until there's a real need for it.


> ...
>
>> > The patch looks pretty much correct to me, if we choose to go this way.
>> >
>> Glad to hear.
>>
>> I'll let me know once you guys are settled in on the approach, and
>> I'll respin the series with all the comments addressed.
>
> Cool, let's see if we can get the name conflict issue solved, and then
> I'll try to remember to ping you.
>
Ack, I'll keep an eye open, just in case.

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

Re: Remote Desktop with Wayland

[The Rasterman]

On Tue, 22 Aug 2017 11:00:19 +0300 Pekka Paalanen  said:

> On Fri, 18 Aug 2017 22:36:08 +0300
> Rostislav Krasny  wrote:
> 
> > Hi there,
> > 
> > I want to use Linux at work on my workstation PC but currently I
> > can't. The main reason is lack of useful Remote Desktop access to
> > Linux from outside. By useful Remote Desktop access I mean how it's
> > implemented in Windows. In Windows you can connect to a locally
> > started session and continue it remotely. When you do this the local
> > computer will be locked. You can go back to the local computer, unlock
> > it and take over the local session by entering your password. Also you
> > can connect to a Windows computer without any existing session and
> > this will start a new one remotely. After that you can go to that
> > computer, unlock it and continue that session locally. I need this
> > functionality to continue my work outside the office or from other
> > location in the office (a meeting room or a workplace of a colleague).
> 
> Hi,
> 
> that is a very nice description of a useful feature. I wonder if KDE,
> GNOME or Enlightenment would have something like that in their roadmap?

we currently have some bits and pieces, but not everything. eventually we do
want to offer remote access to an existing session (more likely via vnc
protocol or something more custom), but we're not there yet. still have other
things to do until we go there.

> > Today's Remote Desktop server solutions in Linux can't provide the
> > above functionality. I've tried xrdp, several implementations of VNC
> > and X2Go. None of them function as needed. They do one of the
> > following:
> > 
> > 1. Always start a new session
> > 2. Continue a locally started session in a sharing mode when the local
> > computer is not locked and anyone near it can see what I do and even
> > intervene to that session by local mouse and keyboard.
> > 
> > X2Go has even additional problem supporting different resolutions of
> > remote and local computers.
> > 
> > As far as I know you've also added the RDP support into the Weston
> > compositor. Do you support the Windows Remote Desktop functionality as
> > described above or this functionality should be implemented by a
> > higher layer that uses Weston? Or what other project (that uses
> > Wayland) should I ask about this?
> 
> I'm not too familiar with Weston's RDP-backend, but given it's a
> separate backend, I believe it cannot switch between local and remote
> modes, it will always be remote. There is also the screen-share plugin,
> but I doubt that's a solution here either, I would guess it is missing
> the local locking while in remote use.
> 
> I believe the functionality you describe must intimately integrate with
> the compositor and cannot be achieved by applications atop alone.
> 
> 
> Thanks,
> pq


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

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

Re: Remote Desktop with Wayland

[Pekka Paalanen]

On Fri, 18 Aug 2017 22:36:08 +0300
Rostislav Krasny  wrote:

> Hi there,
> 
> I want to use Linux at work on my workstation PC but currently I
> can't. The main reason is lack of useful Remote Desktop access to
> Linux from outside. By useful Remote Desktop access I mean how it's
> implemented in Windows. In Windows you can connect to a locally
> started session and continue it remotely. When you do this the local
> computer will be locked. You can go back to the local computer, unlock
> it and take over the local session by entering your password. Also you
> can connect to a Windows computer without any existing session and
> this will start a new one remotely. After that you can go to that
> computer, unlock it and continue that session locally. I need this
> functionality to continue my work outside the office or from other
> location in the office (a meeting room or a workplace of a colleague).

Hi,

that is a very nice description of a useful feature. I wonder if KDE,
GNOME or Enlightenment would have something like that in their roadmap?

> Today's Remote Desktop server solutions in Linux can't provide the
> above functionality. I've tried xrdp, several implementations of VNC
> and X2Go. None of them function as needed. They do one of the
> following:
> 
> 1. Always start a new session
> 2. Continue a locally started session in a sharing mode when the local
> computer is not locked and anyone near it can see what I do and even
> intervene to that session by local mouse and keyboard.
> 
> X2Go has even additional problem supporting different resolutions of
> remote and local computers.
> 
> As far as I know you've also added the RDP support into the Weston
> compositor. Do you support the Windows Remote Desktop functionality as
> described above or this functionality should be implemented by a
> higher layer that uses Weston? Or what other project (that uses
> Wayland) should I ask about this?

I'm not too familiar with Weston's RDP-backend, but given it's a
separate backend, I believe it cannot switch between local and remote
modes, it will always be remote. There is also the screen-share plugin,
but I doubt that's a solution here either, I would guess it is missing
the local locking while in remote use.

I believe the functionality you describe must intimately integrate with
the compositor and cannot be achieved by applications atop alone.


Thanks,
pq


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