Re: Wayland API to get the id of focus window [Seema Singh]

[Bill Spitzak]

Seema Singh wrote:


Focus window pid is used for below check:
1. If focus window APP is not a NFC APP then launch the NFC APP
2. If already launched but not in focus then bring it to foreground.


The NFC app should always launch, but then it should just check if it is 
already running, and if so tell the other one to raise and then exit.

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

Re: Wayland API to get the id of focus window [Seema Singh]

[The Rasterman]

On Fri, 21 Feb 2014 06:07:59 + (GMT) Seema Singh 
said:

> Hi Carsten,
> 
> Thank you for your response.
> 
> >first... by module... what does this code do? is it an enlightenment module?
> >or is it some external client process?
> 
> it's not an enlightenment module. It's an external client process.
> 
> 
> >so maybe you should first explain what you are doing, where and why, and
> >then... we can figure out what to do about it. :)
> 
> In our NFC module we are trying to do a NFC conditional APP launch.
> Whenever a tag detects, client processes the Tag NDEF data and launch the
> application if its not launched. 
> Focus window pid is used for below check:
> 1. If focus window APP is not a NFC APP then launch the NFC APP
> 2. If already launched but not in focus then bring it to foreground.

ok. then you're doing it wrong.

if you're planning on this for tizen 3 or have upgraded EFL, then you want to
look at gustavo's app server api. this is available in efl 1.8 and up:

http://git.enlightenment.org/apps/terminology.git/tree/src/bin/app_server.c
http://git.enlightenment.org/apps/terminology.git/tree/src/bin/app_server.h
http://git.enlightenment.org/apps/terminology.git/tree/src/bin/app_server_eet.c
http://git.enlightenment.org/apps/terminology.git/tree/src/bin/app_server_eet.h

(and look at the elm_app_server api too that it uses).

an alternative for earlier efl is just to ipc to yourself:

http://git.enlightenment.org/apps/terminology.git/tree/src/bin/ipc.c
http://git.enlightenment.org/apps/terminology.git/tree/src/bin/ipc.h

it's pretty simple. app creates a unix socket unique to itself and its
environment, and any new execution of the same binary/app tries to connect to
itself. this is the same case with both app_server and the ipc examples above.
they both work regardless of the display system you use. your app talks to
itself and passes any relevant arguments/info to the existing instance. the
existing instance can do whatever it likes. if you want a window to appear
and/or become focused (become active) use elm_win_activate() on the window.
this will request the wm to "make the window active/bring attention to it/focus
it etc."... slight catch - there is no core wayland protocol for this
currently. this SHOULD be covered in the xdg_shell protocol, but this is new
and i haven't looked at it yet. ecore_evas attracts these things for you and
currently there is no implementation for this because of xdg_shell being new
and shiny and we have not gotten to implementing it all yet, BUT... if you do
what i suggest above, you WILL have an app that is portable and that WILL work
just as soon as the efl bits get hooked together and that the compositor you
have supports the protocols necessary for this.

let me just take the time to advise you to  NOT drop down to layers like
ecore_x in efl *IF* you want to be portable. let the layers that deal with
portability deal with it. if they are currently not, then it's either simply a
missing implementation in efl or maybe entirely missing protocol in wayland
land and working around it in your app will simply waste your time now AND in
future in removing stuff. work with us to ensure you have what you need
implemented. :)


> Regards,
> Seema.
> 
> --- Original Message ---
> Sender : Carsten Haitzler 
> Date   : Feb 20, 2014 18:52 (GMT+09:00)
> Title  : Re: Wayland API to get the id of  focus window  [Seema Singh]
> 
> On Thu, 20 Feb 2014 09:12:50 + (GMT) Seema Singh 
> said:
> 
> > Hi All,
> > 
> > In our module we have used the below mentioned   ecore_x APIs.
> > 1.ecore_x_window_focus_get()
> > 2.ecore_x_netwm_pid_get()
> > 
> > We are planning to move to wayland platform. But  could not find the below
> > APIs in ecore_wayland.h file Please let me know if anyone has come across
> > the same issue.
> 
> first... by module... what does this code do? is it an enlightenment module?
> or is it some external client process?
> 
> if it's literally a module inside enlightenment... enlightenment knows the
> focus already - check other internal api's. you'll want to be looking at git
> master to track dev and features there as that is where the most complete
> wayland support is. as for pid - that would be something the compositor can
> get by interrogating the fd of the client socket connection.
> 
> if this is a 3rd party app/process, the answer is "the 3rd party process has
> no business knowing either of these bits of information for security reasons
> and simply cleanliness of design."
> 
> so maybe you should first explain what you are doing, where and why, and
> then... we can figure out what to do about it. :)
> 
> -- 
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>   
> ___

Re: Re: Wayland API to get the id of focus window [Seema Singh]

[Seema Singh]

Hi Carsten,

Thank you for your response.

>first... by module... what does this code do? is it an enlightenment module? or
>is it some external client process?

it's not an enlightenment module. It's an external client process.


>so maybe you should first explain what you are doing, where and why, and
>then... we can figure out what to do about it. :)

In our NFC module we are trying to do a NFC conditional APP launch.
Whenever a tag detects, client processes the Tag NDEF data and launch the 
application if its not launched.
  
Focus window pid is used for below check:
1. If focus window APP is not a NFC APP then launch the NFC APP
2. If already launched but not in focus then bring it to foreground.


Regards,
Seema.

--- Original Message ---
Sender : Carsten Haitzler 
Date   : Feb 20, 2014 18:52 (GMT+09:00)
Title  : Re: Wayland API to get the id of  focus window  [Seema Singh]

On Thu, 20 Feb 2014 09:12:50 + (GMT) Seema Singh 
said:

> Hi All,
> 
> In our module we have used the below mentioned   ecore_x APIs.
> 1.ecore_x_window_focus_get()
> 2.ecore_x_netwm_pid_get()
> 
> We are planning to move to wayland platform. But  could not find the below
> APIs in ecore_wayland.h file Please let me know if anyone has come across the
> same issue.

first... by module... what does this code do? is it an enlightenment module? or
is it some external client process?

if it's literally a module inside enlightenment... enlightenment knows the
focus already - check other internal api's. you'll want to be looking at git
master to track dev and features there as that is where the most complete
wayland support is. as for pid - that would be something the compositor can get
by interrogating the fd of the client socket connection.

if this is a 3rd party app/process, the answer is "the 3rd party process has no
business knowing either of these bits of information for security reasons and
simply cleanliness of design."

so maybe you should first explain what you are doing, where and why, and
then... we can figure out what to do about it. :)

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

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

Re: [RFC v2] Wayland presentation extension (video protocol)

[Mario Kleiner]

On 20/02/14 12:07, Pekka Paalanen wrote:

Hi Mario,



Ok, now i am magically subscribed. Thanks to the moderator!


I have replies to your comments below, but while reading what you said,
I started wondering whether Wayland would be good for you after all.

It seems that your timing sensitive experiment programs and you and
your developers use a great deal of effort into
- detecting the hardware and drivers,
- determining how the display server works, so that you can
- try to make it do exactly what you want, and
- detect if it still does not do exactly like you want it and bail,
   while also
- trying to make sure you get the right timing feedback from the kernel
   unmangled.



Yes. It's "trust buf verify". If i know that the api / protocol is well 
defined and suitable for my purpose and have verified that at least the 
reference compositor implements the protocol correctly then i can at 
least hope that all other compositors are also implemented correctly, so 
stuff should work as expected. And i can verify that at least some 
subset of compositors really works, and try to submit bug reports or 
patches if they don't.



Sounds like the display server is a huge source of problems to you, but
I am not quite sure how running on top a display server benefits you.
Your experiment programs want to be in precise control, get accurate
timings, and they are always fullscreen. Your users / test subjects
never switch away from the program while it's running, you don't need
windowing or multi-tasking, AFAIU, nor any of the application
interoperability features that are the primary features of a display
server.



They are fullscreen and timing sensitive in probably 95% of all typical 
application cases during actual "production use" while experiments are 
run. But some applications need the toolkit to present in regular 
windows and GUI thingys, a few even need compositing to combine my 
windows with windows of other apps. Some setups run multi-display, where 
some displays are used for fullscreen stimulus presentation to the 
tested person, but another display may be used for control/feedback or 
during debugging by the experimenter, in which case the regular desktop 
GUI and UI of the scripting environment is needed on that display. One 
popular case during debugging is having a half-transparent fullscreen 
window for stimulus presentation, but behind that window the whole 
regular GUI with the code editor and debugger in the background, so one 
can set breakpoints etc. - The window is made transparent for mouse and 
keyboard input, so users can interact with the editor.


So in most cases i need a display server running, because i sometimes 
need compositing and i often need a fully functional GUI during at the 
at least 50% of the work time where users are debugging and testing 
their code and also don't want to be separated from their e-mail clients 
and web browsers etc. during that time.



Why not take the display server completely out of the equation?

I understand that some years ago, it would probably not have been
feasible and X11 was the de facto interface to do any graphics.

However, it seems you are already married to DRM/KMS so that you get
accurate timing feedback, so why not port your experiment programs
(the framework) directly on top of DRM/KMS instead of Wayland?



Yes and no. DRM/KMS will be the most often used one and is the best bet 
if i need timing control and it's the one i'm most familiar with. I also 
want to keep the option of running on other backends if timing is not of 
much importance, or if it can be improved on them, should the need arise.



With Mesa EGL and GBM, you can still use hardware accelerated openGL if
you want to, but you will also be in explicit control of when you
push that rendered buffer into KMS for display. Software rendering by
direct pixel poking is also possible and at the end you just push that
buffer to KMS as usual too. You do not need any graphics card specific
code, it is all abstracted in the public APIs offered by Mesa and
libdrm, e.g. GBM. The new libinput should make hooking into input
devices much less painful, etc. All this thanks to Wayland, because on
Wayland, there is no single "the server" like the X.org X server is.
There will be lots of servers and each one needs the same
infrastructure you would need to run without a display server.

No display server obfuscating your view to the hardware, no
compositing manager fiddling with your presentation, and most likely no
random programs hogging the GPU at random times. Would the trade-off
not be worth it?



I thought about EGL/GBM etc. as a last resort for especially demanding 
cases, timing-wise. But given that the good old X-Server was good enough 
for almost everything so far, i'd expect Wayland to perform as good as 
or better timing-wise. If that turns out to be true, it would be good 
enough for hopefully almost all use cases, with all the benefits of 
compositing and GUI support when 

Re: [RFC] libinput configuration interface

[Peter Hutterer]

On Fri, Feb 21, 2014 at 01:29:05AM +0600, Alexander E. Patrakov wrote:
> 20.02.2014 12:21, I wrote:
> >20.02.2014 11:14, Peter Hutterer wrote:
> >>On Wed, Feb 19, 2014 at 11:55:28AM +0600, Alexander E. Patrakov wrote:
> >>> From my experience with the Sony touchpad (Vaio Z23A4R laptop), I'd
> >>>say that it doesn't solve the whole problem. Here is what goes wrong
> >>>with the old synaptics driver by default and can be worked around
> >>>with AreaBottomEdge.
> >>>
> >>> Option "SoftButtonAreas" "4360 0 4000 0 2880 4359 3500 0"
> >>> Option "AreaBottomEdge" "3500"
> >>>
> >>>1. I move the right-hand index finger on the touchpad, thus moving
> >>>the pointer to the place where I want to click.
> >>>
> >>>2. I place the left-hand index finger into the virtual-button area,
> >>>while still keeping the right finger on the touchpad. I cannot
> >>>remove the right-hand finger: if I do that, while the contact area
> >>>shrinks, its center also moves, and the driver picks that up.
> >>>
> >>>3. As I increase the pressure on the left-hand finger until the
> >>>touchpad clicks, the contact area increases. Unfortunately, its
> >>>center moves, too, and this can accumulate to ~2-3 pixels until it
> >>>clicks.
> >>>
> >>>The important point is that the bad thing happens before the
> >>>hardware button click, so the quoted solution totally misses the
> >>>point.
> >>>
> >>>So we need something, either a sledgehammer solution in the form of
> >>>ignoring all motion in the virtual button area (but that would break
> >>>Sony Vaio Duo 13 because the only usable height of the virtual
> >>>button area is 100% there), or some very good filter that pays
> 
> >>couple of comments here:
> >>2 is a synaptics bug that should really be fixed, the driver shouldn't be
> >>that sensible - in fact there's probably something that can be done about
> >>making the driver more sensible while the finger is moving and less
> >>sensible
> >>while the finger is still (just an idea, may not work for small
> >>movements). there is also the option of using pressure to counteract
> >>movements, i.e. a pressure change will increase the hysteresis to avoid
> >>erroneous movements. If you have that many issues with the Sony, I really
> >>recommend looking at the evdev-mt-touchpad patches I sent to this list,
> >>it'll allow for things like that relatively simple.
> >
> >OK, I will build this on my laptop from git later today.
> 
> Just did this, but have not looked at the code yet. Tested with
> xf86-input-libinput, thus had no chance to configure anything
> specific to libinput. If this has any chance of yielding different
> results, I will retest with Weston on Saturday.

libinput currently exposes no configuration interfaces, so the only
differences you may see is in pointer acceleration.

> Software versions:
> 
>  * mtdev 1.1.4 (Gentoo)
>  * xorg-server 1.15.0 (Gentoo)
>  * libevdev from git, cf70d0
>  * libinput from git, 128f98 + your 19 patches
>  * xf86-input-libinput from git, 761603
> 
> Hardware: Sony VAIO Z23A4R, the touchpad identifies itself as follows:
> 
> I: Bus=0011 Vendor=0002 Product=0007 Version=01b1
> N: Name="SynPS/2 Synaptics TouchPad"
> P: Phys=isa0060/serio1/input0
> S: Sysfs=/devices/platform/i8042/serio1/input/input4
> U: Uniq=
> H: Handlers=mouse0 event3
> B: PROP=5
> B: EV=b
> B: KEY=e520 1 0 0 0 0
> B: ABS=66080001103
> 
> Pointer movement works, but it is too slow by default on this
> laptop. That is, a VERY quick swipe (not expected during normal work
> and even during games) from left to right is just enough to move the
> pointer across the entire screen (1920x1080). Setting constant
> deceleration to 0.3 or 0.4 makes it more usable in terms of speed,
> but this might be my personal preference, and I am not sure if the
> constant deceleration is the correct knob here.

I have not yet looked into pointer-accel fine-tuning on the touchpad or in
xf86-input-libinput. What you're seeing is quite simliar to what I have here
- it's slow but not unusable. Sorry, just haven't focused on that yet by any
help would be appreciated.

I don't think deceleration is the right nob here, but I can't remember what
you need to tweak. Generally I try not to touch constant deceleration unless
the device is a high-resolution device that sends way too many events. If
you need to use a value 0..1 for CD then you're effectively using it to
speed things up, the term "deceleration" should hint that this may not work
perfectly :)

> With the default constant deceleration (1.0), pointer movement is
> very precise. It follows the finger equally well in all parts of the
> touchpad and in all directions, as expected. I get no misplaced
> clicks.
> 
> With constant deceleration 0.3, this is not true. It works better in
> the central part of the touchpad, but, when crossing the physical
> border between the area for pointer movement (which is rough) and
> the area for virtual buttons (which is smooth), it starts to behave
> like

Re: Summary of the security discussions around Wayland and privileged clients

[Thiago Macieira]

Em qui 20 fev 2014, às 14:34:39, Bill Spitzak escreveu:
> This makes it impossible for a privileged client to distribute it's
> privledges to more than one subprocess, or to both itself and a subprocess.

I think it's fine. That's hardly a common scenario.

To allow distribution of security settings, one could assign them per cgroup. 
The compositor simply needs to get the information from the caller of what 
cgroup it is in. Is that information available via SCM_CRED?

Alternatively, there could be a shared secret stored in a file for which the 
file descriptor can be passed. The Wayland compositor can modify the file 
frequently and request that the client prove its worthiness by reading from 
the file.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

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

Re: Summary of the security discussions around Wayland and privileged clients

[Bill Spitzak]

This makes it impossible for a privileged client to distribute it's 
privledges to more than one subprocess, or to both itself and a subprocess.


That is why I would prefer an "id" approach, which I still think would 
be a good way for parent processes to send objects to children, even if 
it is not used for privileges. If a process has an object it can ask the 
server for an "id". It can then use IPC (including environment variables 
or argv) and pass the id to any other process. That process can open the 
same server, send the id, and get the same object. The id is a random 
number generated by the server and it keeps a map of id->object (and 
probably throws them away after first use or a timeout).


The already-opened fd is still useful and the top-level privledged 
clients would still use this exactly as proposed. If a client tries to 
create a screenshooter object and it is not on the privledged socket 
then it fails. However any client if it can send the right id can get a 
second connection to the screen shooter object. But the only way to get 
that id is for a client that has the screen shooter object to ask for it.


The already-opened fd is also useful so all clients don't have to 
reproduce whatever rules there are for locating the server. A parent 
process using this can be pretty certain that it's child will use the 
correct wayland server.


Jason Ekstrand wrote:
On Thu, Feb 20, 2014 at 2:41 PM, Thiago Macieira > wrote:


Em qui 20 fev 2014, às 21:31:59, Martin Peres escreveu:
 > > Now, the privileged process wants to launch a sub-process. How
will the
 > > sub- process connect to the compositor? Remember:
WAYLAND_SOCKET contains
 > > a file descriptor number that isn't available to the child process.
 >
 > Ah, I see. You are suggesting un-setting WAYLAND_SOCKET and using
fcntl() to
 > set the socket's fd to CLOEXEC?

Setting the socket to O_CLOEXEC is mandatory after you start using
it. Two
processes cannot write to the same streaming socket file descriptor
at the same
time. You might be able to do this with a datagram socket, but
that's not the
case here.

 > It is true that multiple process could end up with the same
connection and
 > I didn't think about that. The problem is the same if an application
 > connects
 > to the compositor by itself and then forks. Not sure how the
compositor
 > could detect that :s

It can't. It will get very confused because two applications with
independent
states will start stepping on each other's toes. The best outcome of
this
would be if the compositor detected a problem early on and cut the
connection
to both.

The way I see it, wl_display_connect() must unset the WAYLAND_SOCKET
environment variable after getting the file descriptor number and it
must set
O_CLOEXEC. The socket is not available to child processes.


It already does both of these: 
http://cgit.freedesktop.org/wayland/wayland/tree/src/wayland-client.c#n763
 



But then the question returns: how do child processes connect to the
compositor, if the environment variable was cleared? How do they
find the
compositor?

Solutions:

1) the compositor MUST have a well-known socket name
  => not an option, since we want to have multiple concurrent
compositors

2) wl_display_connect() doesn't clear the environment, but resets it
to the
actual socket name. It needs to get the socket name from somewhere.
  => problem: if it's getting the name from the compositor, this may
take a
  few roundtrips and the process may have decided to start the child
process

3) use a different environment variable. One variable contains the
traditional
socket path and the other contains the file descriptor. The latter
overrides
the former.


This is what we are doing right now.  The WAYLAND_DISPLAY environment 
variable contains the name of a socket that can be found in 
XDG_RUNTIME_DIR.  The WAYLAND_SOCKET environment variable (if it exists) 
contains a file descriptor that a single client can use to connect to 
the compositor.  Inside wl_display_connect, we clear WAYLAND_SOCKET but 
not WAYLAND_DISPLAY.  If both are present, the client connects directly 
and is then free to spawn other clients which will connect via 
WAYLAND_DISPLAY.  However, those other clients will not have the same 
priviledged status because they didn't use the direct connection.  This 
is the way Weston's desktop-shell panel spawns things right now.
 


4) store both settings in WAYLAND_SOCKET. D-Bus does that:
DBUS_SESSION_BUS_ADDRESS can contain multiple addresses, to be
attempted in
order.


That's an interesting idea.  Not sure what benefit it would have for 
Wayland right now though.


Hope that helps,
--Jason Ekstrand


-

Re: Summary of the security discussions around Wayland and privileged clients

[Jason Ekstrand]

On Thu, Feb 20, 2014 at 2:41 PM, Thiago Macieira  wrote:

> Em qui 20 fev 2014, às 21:31:59, Martin Peres escreveu:
> > > Now, the privileged process wants to launch a sub-process. How will the
> > > sub- process connect to the compositor? Remember: WAYLAND_SOCKET
> contains
> > > a file descriptor number that isn't available to the child process.
> >
> > Ah, I see. You are suggesting un-setting WAYLAND_SOCKET and using
> fcntl() to
> > set the socket's fd to CLOEXEC?
>
> Setting the socket to O_CLOEXEC is mandatory after you start using it. Two
> processes cannot write to the same streaming socket file descriptor at the
> same
> time. You might be able to do this with a datagram socket, but that's not
> the
> case here.
>
> > It is true that multiple process could end up with the same connection
> and
> > I didn't think about that. The problem is the same if an application
> > connects
> > to the compositor by itself and then forks. Not sure how the compositor
> > could detect that :s
>
> It can't. It will get very confused because two applications with
> independent
> states will start stepping on each other's toes. The best outcome of this
> would be if the compositor detected a problem early on and cut the
> connection
> to both.
>
> The way I see it, wl_display_connect() must unset the WAYLAND_SOCKET
> environment variable after getting the file descriptor number and it must
> set
> O_CLOEXEC. The socket is not available to child processes.
>

It already does both of these:
http://cgit.freedesktop.org/wayland/wayland/tree/src/wayland-client.c#n763


>
> But then the question returns: how do child processes connect to the
> compositor, if the environment variable was cleared? How do they find the
> compositor?
>
> Solutions:
>
> 1) the compositor MUST have a well-known socket name
>   => not an option, since we want to have multiple concurrent compositors
>
> 2) wl_display_connect() doesn't clear the environment, but resets it to the
> actual socket name. It needs to get the socket name from somewhere.
>   => problem: if it's getting the name from the compositor, this may take a
>   few roundtrips and the process may have decided to start the child
> process
>
> 3) use a different environment variable. One variable contains the
> traditional
> socket path and the other contains the file descriptor. The latter
> overrides
> the former.
>

This is what we are doing right now.  The WAYLAND_DISPLAY environment
variable contains the name of a socket that can be found in
XDG_RUNTIME_DIR.  The WAYLAND_SOCKET environment variable (if it exists)
contains a file descriptor that a single client can use to connect to the
compositor.  Inside wl_display_connect, we clear WAYLAND_SOCKET but not
WAYLAND_DISPLAY.  If both are present, the client connects directly and is
then free to spawn other clients which will connect via WAYLAND_DISPLAY.
However, those other clients will not have the same priviledged status
because they didn't use the direct connection.  This is the way Weston's
desktop-shell panel spawns things right now.


> 4) store both settings in WAYLAND_SOCKET. D-Bus does that:
> DBUS_SESSION_BUS_ADDRESS can contain multiple addresses, to be attempted in
> order.
>

That's an interesting idea.  Not sure what benefit it would have for
Wayland right now though.

Hope that helps,
--Jason Ekstrand
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Summary of the security discussions around Wayland and privileged clients

[Thiago Macieira]

Em qui 20 fev 2014, às 21:31:59, Martin Peres escreveu:
> > Now, the privileged process wants to launch a sub-process. How will the
> > sub- process connect to the compositor? Remember: WAYLAND_SOCKET contains
> > a file descriptor number that isn't available to the child process.
> 
> Ah, I see. You are suggesting un-setting WAYLAND_SOCKET and using fcntl() to
> set the socket's fd to CLOEXEC?

Setting the socket to O_CLOEXEC is mandatory after you start using it. Two 
processes cannot write to the same streaming socket file descriptor at the same 
time. You might be able to do this with a datagram socket, but that's not the 
case here.

> It is true that multiple process could end up with the same connection and
> I didn't think about that. The problem is the same if an application
> connects
> to the compositor by itself and then forks. Not sure how the compositor
> could detect that :s

It can't. It will get very confused because two applications with independent 
states will start stepping on each other's toes. The best outcome of this 
would be if the compositor detected a problem early on and cut the connection 
to both.

The way I see it, wl_display_connect() must unset the WAYLAND_SOCKET 
environment variable after getting the file descriptor number and it must set 
O_CLOEXEC. The socket is not available to child processes.

But then the question returns: how do child processes connect to the 
compositor, if the environment variable was cleared? How do they find the 
compositor?

Solutions:

1) the compositor MUST have a well-known socket name
  => not an option, since we want to have multiple concurrent compositors

2) wl_display_connect() doesn't clear the environment, but resets it to the 
actual socket name. It needs to get the socket name from somewhere.
  => problem: if it's getting the name from the compositor, this may take a  
  few roundtrips and the process may have decided to start the child process

3) use a different environment variable. One variable contains the traditional 
socket path and the other contains the file descriptor. The latter overrides 
the former.

4) store both settings in WAYLAND_SOCKET. D-Bus does that: 
DBUS_SESSION_BUS_ADDRESS can contain multiple addresses, to be attempted in 
order.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

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

Re: Summary of the security discussions around Wayland and privileged clients

[Martin Peres]

Le 20/02/2014 21:26, Thiago Macieira a écrit :

Em qui 20 fev 2014, às 19:56:08, Martin Peres escreveu:

Le 20/02/2014 18:42, Thiago Macieira a écrit :

Unless you meant that the WAYLAND_SOCKET variable can contain a file
descriptor number. Is that the case? In that case, how should the
privileged process clear the environment to allow child processes to be
launched?

Yes, it takes an FD as a parameter
(http://code.metager.de/source/xref/freedesktop/wayland/wayland/doc/man/wl_d
isplay_connect.xml#63).

The environment must be cleared automatically by the kernel because
weston must be very careful about opening resources with O_CLOEXEC.

I don't think you've understood my question.

Suppose Weston is careful already. It creates the socket, ensures it's no
O_CLOEXEC, sets WAYLAND_SOCKET and launches the privileged process.

Now, the privileged process wants to launch a sub-process. How will the sub-
process connect to the compositor? Remember: WAYLAND_SOCKET contains a file
descriptor number that isn't available to the child process.

Ah, I see. You are suggesting un-setting WAYLAND_SOCKET and using fcntl() to
set the socket's fd to CLOEXEC?

It is true that multiple process could end up with the same connection and
I didn't think about that. The problem is the same if an application 
connects

to the compositor by itself and then forks. Not sure how the compositor
could detect that :s
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Summary of the security discussions around Wayland and privileged clients

[Thiago Macieira]

Em qui 20 fev 2014, às 19:56:08, Martin Peres escreveu:
> Le 20/02/2014 18:42, Thiago Macieira a écrit :
> > Unless you meant that the WAYLAND_SOCKET variable can contain a file
> > descriptor number. Is that the case? In that case, how should the
> > privileged process clear the environment to allow child processes to be
> > launched?
> 
> Yes, it takes an FD as a parameter
> (http://code.metager.de/source/xref/freedesktop/wayland/wayland/doc/man/wl_d
> isplay_connect.xml#63).
> 
> The environment must be cleared automatically by the kernel because
> weston must be very careful about opening resources with O_CLOEXEC.

I don't think you've understood my question.

Suppose Weston is careful already. It creates the socket, ensures it's no 
O_CLOEXEC, sets WAYLAND_SOCKET and launches the privileged process.

Now, the privileged process wants to launch a sub-process. How will the sub-
process connect to the compositor? Remember: WAYLAND_SOCKET contains a file 
descriptor number that isn't available to the child process.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

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

Re: Summary of the security discussions around Wayland and privileged clients

[Martin Peres]

Le 20/02/2014 20:43, Sebastian Wick a écrit :

Am 2014-02-20 20:02, schrieb Martin Peres:

Le 20/02/2014 13:04, Pekka Paalanen a écrit :

snip

It can be done, but with a little more effort than implied here.
Binding to an interace means wl_registry.bind request, and failing that
is always a fatal error, which terminates the client connection. All
errors in Wayland are fatal like that.

Instead, the interface should be always bindable, but include explicit
protocol to indicate failure in using its requests.


In this case, we can make something pretty simple, send a signal
to the application if rights to use this interface has been granted.

If the application tries to use the interface without having the rights
to do so, an EPERM signal can be sent (not to be confused with the
revokation signal that happens when  rights have been revoked).

What do you think?


I would like to have a request_permission and a revoke_permission 
method and respectively a permission_granted and a permission_revoked 
event. An application might not need to permission or only needs it 
for a small amount of time.


Yeah, seems good.


Slightly unrelated: We also need a way for a program to ask the 
compositor to start a client (and we have to ask ourselves how to 
handle arguments, environment variables etc.).


I was thinking about having a semantical approach to that. Something 
like "Open the preferred screenshot app" or "Open the preferred screen 
video capture app". The preferred apps would be configured by the user 
(with default settings from the DE) and could include parameters 
passing, but I'm not sure it will happen. Is that something that would 
satisfy you?


If you really want something generic, then isn't that something systemd 
could handle for us? I'm not really sure what you want to achieve here.



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

Re: Summary of the security discussions around Wayland and privileged clients

[Sebastian Wick]

Am 2014-02-20 20:02, schrieb Martin Peres:

Le 20/02/2014 13:04, Pekka Paalanen a écrit :

snip

It can be done, but with a little more effort than implied here.
Binding to an interace means wl_registry.bind request, and failing 
that

is always a fatal error, which terminates the client connection. All
errors in Wayland are fatal like that.

Instead, the interface should be always bindable, but include explicit
protocol to indicate failure in using its requests.


In this case, we can make something pretty simple, send a signal
to the application if rights to use this interface has been granted.

If the application tries to use the interface without having the rights
to do so, an EPERM signal can be sent (not to be confused with the
revokation signal that happens when  rights have been revoked).

What do you think?


I would like to have a request_permission and a revoke_permission method 
and respectively a permission_granted and a permission_revoked event. An 
application might not need to permission or only needs it for a small 
amount of time.


Slightly unrelated: We also need a way for a program to ask the 
compositor to start a client (and we have to ask ourselves how to handle 
arguments, environment variables etc.).

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

Re: [RFC] libinput configuration interface

[Alexander E. Patrakov]

20.02.2014 12:21, I wrote:

20.02.2014 11:14, Peter Hutterer wrote:

On Wed, Feb 19, 2014 at 11:55:28AM +0600, Alexander E. Patrakov wrote:

 From my experience with the Sony touchpad (Vaio Z23A4R laptop), I'd
say that it doesn't solve the whole problem. Here is what goes wrong
with the old synaptics driver by default and can be worked around
with AreaBottomEdge.

 Option "SoftButtonAreas" "4360 0 4000 0 2880 4359 3500 0"
 Option "AreaBottomEdge" "3500"

1. I move the right-hand index finger on the touchpad, thus moving
the pointer to the place where I want to click.

2. I place the left-hand index finger into the virtual-button area,
while still keeping the right finger on the touchpad. I cannot
remove the right-hand finger: if I do that, while the contact area
shrinks, its center also moves, and the driver picks that up.

3. As I increase the pressure on the left-hand finger until the
touchpad clicks, the contact area increases. Unfortunately, its
center moves, too, and this can accumulate to ~2-3 pixels until it
clicks.

The important point is that the bad thing happens before the
hardware button click, so the quoted solution totally misses the
point.

So we need something, either a sledgehammer solution in the form of
ignoring all motion in the virtual button area (but that would break
Sony Vaio Duo 13 because the only usable height of the virtual
button area is 100% there), or some very good filter that pays



couple of comments here:
2 is a synaptics bug that should really be fixed, the driver shouldn't be
that sensible - in fact there's probably something that can be done about
making the driver more sensible while the finger is moving and less
sensible
while the finger is still (just an idea, may not work for small
movements). there is also the option of using pressure to counteract
movements, i.e. a pressure change will increase the hysteresis to avoid
erroneous movements. If you have that many issues with the Sony, I really
recommend looking at the evdev-mt-touchpad patches I sent to this list,
it'll allow for things like that relatively simple.


OK, I will build this on my laptop from git later today.


Just did this, but have not looked at the code yet. Tested with 
xf86-input-libinput, thus had no chance to configure anything specific 
to libinput. If this has any chance of yielding different results, I 
will retest with Weston on Saturday.


Software versions:

 * mtdev 1.1.4 (Gentoo)
 * xorg-server 1.15.0 (Gentoo)
 * libevdev from git, cf70d0
 * libinput from git, 128f98 + your 19 patches
 * xf86-input-libinput from git, 761603

Hardware: Sony VAIO Z23A4R, the touchpad identifies itself as follows:

I: Bus=0011 Vendor=0002 Product=0007 Version=01b1
N: Name="SynPS/2 Synaptics TouchPad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input4
U: Uniq=
H: Handlers=mouse0 event3
B: PROP=5
B: EV=b
B: KEY=e520 1 0 0 0 0
B: ABS=66080001103

Pointer movement works, but it is too slow by default on this laptop. 
That is, a VERY quick swipe (not expected during normal work and even 
during games) from left to right is just enough to move the pointer 
across the entire screen (1920x1080). Setting constant deceleration to 
0.3 or 0.4 makes it more usable in terms of speed, but this might be my 
personal preference, and I am not sure if the constant deceleration is 
the correct knob here.


With the default constant deceleration (1.0), pointer movement is very 
precise. It follows the finger equally well in all parts of the touchpad 
and in all directions, as expected. I get no misplaced clicks.


With constant deceleration 0.3, this is not true. It works better in the 
central part of the touchpad, but, when crossing the physical border 
between the area for pointer movement (which is rough) and the area for 
virtual buttons (which is smooth), it starts to behave like a dirty 
mechanical mouse. Here is what I mean by that: hard to move the cursor 
diagonally (i.e. there is a strong preference towards horizontal or 
vertical movements), and the motion is uneven if I move the finger 
slowly. The same applies to the top part of the touchpad, although there 
is no sharp line where this appears.


In both cases, there is no spurious pointer movement when putting the 
finger on the touchpad or removing it. I.e., points 2 and 3 are somehow 
already dealt with.


Vertical two-finger scrolling works, but is way too sensitive both with 
constant deceleration 1.0 and with 0.3.


Clicking works. If there are two fingers on the touchpad at the time of 
clicking, it registers a right-click. As the touchpad cannot track more 
than two touches, three-finger gestures don't work. OTOH, I have read 
Documentation/input/multi-touch-protocol.txt: "Some devices identify 
and/or track more contacts than they can report to the driver." I have 
not yet tested whether this applies to my touchpad, and whether it uses 
BTN_TOOL_TRIPLETAP.


Tapping and tap-and-drag are not usabl

Re: Summary of the security discussions around Wayland and privileged clients

[Martin Peres]

Le 20/02/2014 13:04, Pekka Paalanen a écrit :

On Wed, 19 Feb 2014 17:11:03 +0100
Martin Peres  wrote:


Hi Guys,

Following to the giant and impossible to read "Authorized clients"
thread, I said I would take the time and write everything we talked
about down, for convenience and to check I took everyone's idea and
needs into account.

I published the whole article on my blog [1] but I also wanted to copy
the relevant information in this email, so as it could be easier for
people to comment inline (since I'm really interested in feedback here),
sorry for the markdown syntax but that's what I use for my website.

I added Martin Graesslin in CC because he has shown interest in this and
I'm sure his experience can benefit all of us.

Hope something close to this proposal will be satisfactory to everyone
and work can begin in this direction!

Cheers,
Martin Peres

[1]
http://mupuf.org/blog/2014/02/19/wayland-compositors-why-and-how-to-handle/


Nice work! :-)

Thanks, the write up did take some time. However, it's not technically my
work since at least 7 people have been discussing about this. I merely
compiled the ideas as best as I could.


 Recommendations to restricted Wayland interface designers

I have never designed an interface for Wayland and don't know what the
best practice is. However, I know that restricted interfaces should
never be considered as always usable.

The first important point is that before being able to use an interface,
a client should first bind to it. This binding process could either
succeed or fail, depending on the compositor's security policy. Clients
are mandated to test that binding worked well before using the
interface. In case it didn't, clients should fail gracefully and tell
the user what restricted interface couldn't be bound. Also, binding a
restricted interface could take some time and the application shouldn't
block on it.

It can be done, but with a little more effort than implied here.
Binding to an interace means wl_registry.bind request, and failing that
is always a fatal error, which terminates the client connection. All
errors in Wayland are fatal like that.

Instead, the interface should be always bindable, but include explicit
protocol to indicate failure in using its requests.


In this case, we can make something pretty simple, send a signal
to the application if rights to use this interface has been granted.

If the application tries to use the interface without having the rights
to do so, an EPERM signal can be sent (not to be confused with the
revokation signal that happens when  rights have been revoked).

What do you think?



To support privileges revocation, a revoke signal should be added to the
interface in order to inform clients their rights to access the
restricted interface have been revoked. Clients should fallback
gracefully and tell the user they received such a signal.

 Launching privileged Wayland clients from the compositor

The most-secure way of launching clients requiring restricted interfaces
is to let the compositor run them by itself. This way, it can control
the environment in which the process has been launched which lowers the
risks of environment attacks such as the ``LD_PRELOAD`` one exposed earlier.

Implementing such a system is difficult as the compositor needs to
remember that the PID of the client it launched should be granted the
privileges to access one or more restricted interfaces when this
(soon-to-become)client connects to the Wayland compositor. Not only does
it mean that the compositor needs to have a separate table of which PIDs
are supposed to get which privileges, it also means the compositor needs
to keep track of the death of the client's PID to avoid another process
from re-using the PID of this client and gaining access to privileged
interfaces it wasn't supposed to access.

FWIW, Weston already does track its children by pid also, so that it
can respawn them as needed if they e.g. crash.

Oh, ok. But not all Wayland compositors want to support that. They certainly
don't have to!

A simpler and more secure solution would be for the compositor to open a
UNIX socket to itself before exec'ing the client. Once opened, it should
be simpler for the compositor to set the client's capabilities to a flag
stored in the structure tracking the client and then execute the
client's binary. When running the exec() syscall, all the FDs that have
not been opened with the ``O_CLOEXEC``
[flag](http://linux.die.net/man/2/open) will be passed on to the new
process. A run-time parameter of the Wayland client could then be used
to tell which FD represents the unix socket to the Wayland compositor.
An example of such parameter could be ``--wayland-fd=xxx``. The
compositor should however be careful it doesn't leak any un-needed FD to
the new client.

Weston already implements this, and libwayland-client directly supports
this with the environment variable WAYLAND_SOCKET. This is documented
on wl_display_connect(). Th

Re: Summary of the security discussions around Wayland and privileged clients

[Martin Peres]

Le 20/02/2014 18:42, Thiago Macieira a écrit :

Unless you meant that the WAYLAND_SOCKET variable can contain a file descriptor
number. Is that the case? In that case, how should the privileged process
clear the environment to allow child processes to be launched?
Yes, it takes an FD as a parameter 
(http://code.metager.de/source/xref/freedesktop/wayland/wayland/doc/man/wl_display_connect.xml#63).


The environment must be cleared automatically by the kernel because 
weston must be very careful about opening resources with O_CLOEXEC.

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

Re: Summary of the security discussions around Wayland and privileged clients

[Thiago Macieira]

Em qui 20 fev 2014, às 14:04:42, Pekka Paalanen escreveu:
> FWIW, Weston already does track its children by pid also, so that it
> can respawn them as needed if they e.g. crash.

Some compositors may take advantage of an external process launcher & 
babysitter, like systemd --user.

> > A simpler and more secure solution would be for the compositor to open a 
> > UNIX socket to itself before exec'ing the client. Once opened, it should 
> > be simpler for the compositor to set the client's capabilities to a flag 
> > stored in the structure tracking the client and then execute the 
> > client's binary. When running the exec() syscall, all the FDs that have 
> > not been opened with the ``O_CLOEXEC`` 
> > [flag](http://linux.die.net/man/2/open) will be passed on to the new 
> > process. A run-time parameter of the Wayland client could then be used 
> > to tell which FD represents the unix socket to the Wayland compositor. 
> > An example of such parameter could be ``--wayland-fd=xxx``. The 
> > compositor should however be careful it doesn't leak any un-needed FD to 
> > the new client.
> 
> Weston already implements this, and libwayland-client directly supports
> this with the environment variable WAYLAND_SOCKET. This is documented
> on wl_display_connect(). That is, all Wayland clients automatically
> support this, AFAIK.

This can also be accomplished by having different mount namespaces, so the 
socket name is the same but it's not the same actual socket.

However, in both cases, this means child processes inherit access to the same 
privileged socket.

Unless you meant that the WAYLAND_SOCKET variable can contain a file descriptor 
number. Is that the case? In that case, how should the privileged process 
clear the environment to allow child processes to be launched?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

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

Re: [PATCH] xwayland: Destroy wl_buffers only after they are released

[Axel Davy]

Hi,

I've checked how it would behave when X closes properly,
and I think xwl_screen_close would need a new flush after the roundtrip:
. first flush: the server knows the wl_surface was destroyed
. dispatch: X gets the release
. missing flush: the server knows the wl_buffer has been destroyed.

Moreover I figured out that every windows and pixmaps should have been 
destroyed

before xwl_screen_close, making xwl_screen->window_list always empty,
so there is some useless code here.

I'm going to write a patch to do what you want on top of my tree with 
XWayland Present implementation, since

my XWayland Present patches are incompatible with yours.

Axel Davy

On 20/02/2014, Rui Matos wrote :

Destroying a wl_buffer that is still attached to a wl_surface is
undefined behavior according to the wayland protocol. We should delay
the destruction until we get the release event.

To achieve this we need to track ownership of wl_buffers, both our own
and the compositor's which occurs from either the first commit request
or the first commit request after a release event until the next
release event.
---

On 12 February 2014 08:54, Pekka Paalanen  wrote:

I assume the code never added a wl_buffer listener before, because if
it did, this patch would be a no-op. "wl_buffer_add_listener" is a
misnomer, there can only ever be one listener, and trying to "add"
another will not actually do anything.

Thanks for the headsup. But, indeed, there was nothing adding a
wl_buffer listener before.


Also, you rely on wl_buffer.release not having arrived before you add
the listener. With weston's gl-renderer, the release comes very soon
after each wl_surface.commit for wl_shm buffers. Maybe it works, maybe
it doesn't, but it seems very fragile. Did you check you don't leak
wl_buffers now?

Right, I was leaking in some cases. So, I came up with the solution
below which, if I'm reading the logs correctly, doesn't leak and works
correctly.

This solution abuses the user_data field to essentially keep two
toggle references, our own and the compositor's, and only destroys the
wl_buffer when both are dropped.

Thanks,
Rui

---
  hw/xfree86/xwayland/xwayland-cursor.c  |  4 ++-
  hw/xfree86/xwayland/xwayland-private.h |  4 +++
  hw/xfree86/xwayland/xwayland-window.c  |  8 +++---
  hw/xfree86/xwayland/xwayland.c | 50 ++
  4 files changed, 61 insertions(+), 5 deletions(-)

diff --git a/hw/xfree86/xwayland/xwayland-cursor.c 
b/hw/xfree86/xwayland/xwayland-cursor.c
index 2b3cb5e..232b038 100644
--- a/hw/xfree86/xwayland/xwayland-cursor.c
+++ b/hw/xfree86/xwayland/xwayland-cursor.c
@@ -125,6 +125,7 @@ xwl_realize_cursor(DeviceIntPtr device, ScreenPtr screen, 
CursorPtr cursor)
  cursor->bits->width, cursor->bits->height,
  cursor->bits->width * 4,
  WL_SHM_FORMAT_ARGB);
+_buffer_init(buffer);
  wl_shm_pool_destroy(pool);
  
  dixSetPrivate(&cursor->devPrivates,

@@ -143,7 +144,7 @@ xwl_unrealize_cursor(DeviceIntPtr device,
  xwl_screen = xwl_screen_get(screen);
  buffer = dixGetPrivate(&cursor->devPrivates,
 &xwl_screen->cursor_private_key);
-wl_buffer_destroy(buffer);
+_buffer_disown(buffer);
  
  return TRUE;

  }
@@ -176,6 +177,7 @@ xwl_seat_set_cursor(struct xwl_seat *xwl_seat)
  xwl_seat->x_cursor->bits->width,
  xwl_seat->x_cursor->bits->height);
  wl_surface_commit(xwl_seat->cursor);
+_buffer_commited(buffer);
  }
  
  static void

diff --git a/hw/xfree86/xwayland/xwayland-private.h 
b/hw/xfree86/xwayland/xwayland-private.h
index bdecf8a..41e7e13 100644
--- a/hw/xfree86/xwayland/xwayland-private.h
+++ b/hw/xfree86/xwayland/xwayland-private.h
@@ -137,4 +137,8 @@ void xwl_output_remove(struct xwl_output *output);
  
  extern const struct xserver_listener xwl_server_listener;
  
+void _buffer_commited(struct wl_buffer *buffer);

+void _buffer_disown(struct wl_buffer *buffer);
+void _buffer_init(struct wl_buffer *buffer);
+
  #endif /* _XWAYLAND_PRIVATE_H_ */
diff --git a/hw/xfree86/xwayland/xwayland-window.c 
b/hw/xfree86/xwayland/xwayland-window.c
index a2a8206..d18c7f6 100644
--- a/hw/xfree86/xwayland/xwayland-window.c
+++ b/hw/xfree86/xwayland/xwayland-window.c
@@ -62,10 +62,8 @@ xwl_window_attach(struct xwl_window *xwl_window, PixmapPtr 
pixmap)
  struct xwl_screen *xwl_screen = xwl_window->xwl_screen;
  struct wl_callback *callback;
  
-/* We can safely destroy the buffer because we only use one buffer

- * per surface in xwayland model */
  if (xwl_window->buffer)
-wl_buffer_destroy(xwl_window->buffer);
+_buffer_disown(xwl_window->buffer);
  
  xwl_screen->driver->create_window_buffer(xwl_window, pixmap);
  
@@ -74,6 +72,8 @@ xwl_window_attach(struct xwl_window *xwl_window, PixmapPtr pixmap)

return;
  }
  
+_buffer_init(xwl_window->buf

Re: Summary of the security discussions around Wayland and privileged clients

[Pekka Paalanen]

On Wed, 19 Feb 2014 17:11:03 +0100
Martin Peres  wrote:

> Hi Guys,
> 
> Following to the giant and impossible to read "Authorized clients" 
> thread, I said I would take the time and write everything we talked 
> about down, for convenience and to check I took everyone's idea and 
> needs into account.
> 
> I published the whole article on my blog [1] but I also wanted to copy 
> the relevant information in this email, so as it could be easier for 
> people to comment inline (since I'm really interested in feedback here), 
> sorry for the markdown syntax but that's what I use for my website.
> 
> I added Martin Graesslin in CC because he has shown interest in this and 
> I'm sure his experience can benefit all of us.
> 
> Hope something close to this proposal will be satisfactory to everyone 
> and work can begin in this direction!
> 
> Cheers,
> Martin Peres
> 
> [1] 
> http://mupuf.org/blog/2014/02/19/wayland-compositors-why-and-how-to-handle/
> 

Nice work! :-)

>  Recommendations to restricted Wayland interface designers
> 
> I have never designed an interface for Wayland and don't know what the 
> best practice is. However, I know that restricted interfaces should 
> never be considered as always usable.
> 
> The first important point is that before being able to use an interface, 
> a client should first bind to it. This binding process could either 
> succeed or fail, depending on the compositor's security policy. Clients 
> are mandated to test that binding worked well before using the 
> interface. In case it didn't, clients should fail gracefully and tell 
> the user what restricted interface couldn't be bound. Also, binding a 
> restricted interface could take some time and the application shouldn't 
> block on it.

It can be done, but with a little more effort than implied here.
Binding to an interace means wl_registry.bind request, and failing that
is always a fatal error, which terminates the client connection. All
errors in Wayland are fatal like that.

Instead, the interface should be always bindable, but include explicit
protocol to indicate failure in using its requests.

> To support privileges revocation, a revoke signal should be added to the 
> interface in order to inform clients their rights to access the 
> restricted interface have been revoked. Clients should fallback 
> gracefully and tell the user they received such a signal.
> 
>  Launching privileged Wayland clients from the compositor
> 
> The most-secure way of launching clients requiring restricted interfaces 
> is to let the compositor run them by itself. This way, it can control 
> the environment in which the process has been launched which lowers the 
> risks of environment attacks such as the ``LD_PRELOAD`` one exposed earlier.
> 
> Implementing such a system is difficult as the compositor needs to 
> remember that the PID of the client it launched should be granted the 
> privileges to access one or more restricted interfaces when this 
> (soon-to-become)client connects to the Wayland compositor. Not only does 
> it mean that the compositor needs to have a separate table of which PIDs 
> are supposed to get which privileges, it also means the compositor needs 
> to keep track of the death of the client's PID to avoid another process 
> from re-using the PID of this client and gaining access to privileged 
> interfaces it wasn't supposed to access.

FWIW, Weston already does track its children by pid also, so that it
can respawn them as needed if they e.g. crash.

> A simpler and more secure solution would be for the compositor to open a 
> UNIX socket to itself before exec'ing the client. Once opened, it should 
> be simpler for the compositor to set the client's capabilities to a flag 
> stored in the structure tracking the client and then execute the 
> client's binary. When running the exec() syscall, all the FDs that have 
> not been opened with the ``O_CLOEXEC`` 
> [flag](http://linux.die.net/man/2/open) will be passed on to the new 
> process. A run-time parameter of the Wayland client could then be used 
> to tell which FD represents the unix socket to the Wayland compositor. 
> An example of such parameter could be ``--wayland-fd=xxx``. The 
> compositor should however be careful it doesn't leak any un-needed FD to 
> the new client.

Weston already implements this, and libwayland-client directly supports
this with the environment variable WAYLAND_SOCKET. This is documented
on wl_display_connect(). That is, all Wayland clients automatically
support this, AFAIK.


Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] xwayland: Destroy wl_buffers only after they are released

[Pekka Paalanen]

On Thu, 20 Feb 2014 11:43:05 +0100
Rui Matos  wrote:

> Destroying a wl_buffer that is still attached to a wl_surface is
> undefined behavior according to the wayland protocol. We should delay
> the destruction until we get the release event.
> 
> To achieve this we need to track ownership of wl_buffers, both our own
> and the compositor's which occurs from either the first commit request
> or the first commit request after a release event until the next
> release event.
> ---
> 
> On 12 February 2014 08:54, Pekka Paalanen  wrote:
> > I assume the code never added a wl_buffer listener before, because if
> > it did, this patch would be a no-op. "wl_buffer_add_listener" is a
> > misnomer, there can only ever be one listener, and trying to "add"
> > another will not actually do anything.
> 
> Thanks for the headsup. But, indeed, there was nothing adding a
> wl_buffer listener before.
> 
> > Also, you rely on wl_buffer.release not having arrived before you add
> > the listener. With weston's gl-renderer, the release comes very soon
> > after each wl_surface.commit for wl_shm buffers. Maybe it works, maybe
> > it doesn't, but it seems very fragile. Did you check you don't leak
> > wl_buffers now?
> 
> Right, I was leaking in some cases. So, I came up with the solution
> below which, if I'm reading the logs correctly, doesn't leak and works
> correctly.
> 
> This solution abuses the user_data field to essentially keep two
> toggle references, our own and the compositor's, and only destroys the
> wl_buffer when both are dropped.
> 
> Thanks,
> Rui
> 
> ---
>  hw/xfree86/xwayland/xwayland-cursor.c  |  4 ++-
>  hw/xfree86/xwayland/xwayland-private.h |  4 +++
>  hw/xfree86/xwayland/xwayland-window.c  |  8 +++---
>  hw/xfree86/xwayland/xwayland.c | 50 
> ++
>  4 files changed, 61 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/xfree86/xwayland/xwayland-cursor.c 
> b/hw/xfree86/xwayland/xwayland-cursor.c
> index 2b3cb5e..232b038 100644
> --- a/hw/xfree86/xwayland/xwayland-cursor.c
> +++ b/hw/xfree86/xwayland/xwayland-cursor.c
> @@ -125,6 +125,7 @@ xwl_realize_cursor(DeviceIntPtr device, ScreenPtr screen, 
> CursorPtr cursor)
> cursor->bits->width, cursor->bits->height,
> cursor->bits->width * 4,
> WL_SHM_FORMAT_ARGB);
> +_buffer_init(buffer);
>  wl_shm_pool_destroy(pool);
>  
>  dixSetPrivate(&cursor->devPrivates,
> @@ -143,7 +144,7 @@ xwl_unrealize_cursor(DeviceIntPtr device,
>  xwl_screen = xwl_screen_get(screen);
>  buffer = dixGetPrivate(&cursor->devPrivates,
> &xwl_screen->cursor_private_key);
> -wl_buffer_destroy(buffer);
> +_buffer_disown(buffer);
>  
>  return TRUE;
>  }
> @@ -176,6 +177,7 @@ xwl_seat_set_cursor(struct xwl_seat *xwl_seat)
> xwl_seat->x_cursor->bits->width,
> xwl_seat->x_cursor->bits->height);
>  wl_surface_commit(xwl_seat->cursor);
> +_buffer_commited(buffer);
>  }
>  
>  static void
> diff --git a/hw/xfree86/xwayland/xwayland-private.h 
> b/hw/xfree86/xwayland/xwayland-private.h
> index bdecf8a..41e7e13 100644
> --- a/hw/xfree86/xwayland/xwayland-private.h
> +++ b/hw/xfree86/xwayland/xwayland-private.h
> @@ -137,4 +137,8 @@ void xwl_output_remove(struct xwl_output *output);
>  
>  extern const struct xserver_listener xwl_server_listener;
>  
> +void _buffer_commited(struct wl_buffer *buffer);
> +void _buffer_disown(struct wl_buffer *buffer);
> +void _buffer_init(struct wl_buffer *buffer);
> +
>  #endif /* _XWAYLAND_PRIVATE_H_ */
> diff --git a/hw/xfree86/xwayland/xwayland-window.c 
> b/hw/xfree86/xwayland/xwayland-window.c
> index a2a8206..d18c7f6 100644
> --- a/hw/xfree86/xwayland/xwayland-window.c
> +++ b/hw/xfree86/xwayland/xwayland-window.c
> @@ -62,10 +62,8 @@ xwl_window_attach(struct xwl_window *xwl_window, PixmapPtr 
> pixmap)
>  struct xwl_screen *xwl_screen = xwl_window->xwl_screen;
>  struct wl_callback *callback;
>  
> -/* We can safely destroy the buffer because we only use one buffer
> - * per surface in xwayland model */
>  if (xwl_window->buffer)
> -wl_buffer_destroy(xwl_window->buffer);
> +_buffer_disown(xwl_window->buffer);
>  
>  xwl_screen->driver->create_window_buffer(xwl_window, pixmap);
>  
> @@ -74,6 +72,8 @@ xwl_window_attach(struct xwl_window *xwl_window, PixmapPtr 
> pixmap)
>   return;
>  }
>  
> +_buffer_init(xwl_window->buffer);
> +
>  wl_surface_attach(xwl_window->surface, xwl_window->buffer, 0, 0);
>  wl_surface_damage(xwl_window->surface, 0, 0,
> pixmap->drawable.width,
> @@ -185,7 +185,7 @@ xwl_unrealize_window(WindowPtr window)
>   return ret;
>  
>  if (xwl_window->buffer)
> - wl_buffer_destroy(xwl_window->buffer);
> +_buffer_disown(xwl_window->buffer);
>  wl_surface_destroy(xwl_window->surface);
>  xorg_l

Re: [RFC v2] Wayland presentation extension (video protocol)

[Pekka Paalanen]

Hi Mario,

I have replies to your comments below, but while reading what you said,
I started wondering whether Wayland would be good for you after all.

It seems that your timing sensitive experiment programs and you and
your developers use a great deal of effort into
- detecting the hardware and drivers,
- determining how the display server works, so that you can
- try to make it do exactly what you want, and
- detect if it still does not do exactly like you want it and bail,
  while also
- trying to make sure you get the right timing feedback from the kernel
  unmangled.

Sounds like the display server is a huge source of problems to you, but
I am not quite sure how running on top a display server benefits you.
Your experiment programs want to be in precise control, get accurate
timings, and they are always fullscreen. Your users / test subjects
never switch away from the program while it's running, you don't need
windowing or multi-tasking, AFAIU, nor any of the application
interoperability features that are the primary features of a display
server.

Why not take the display server completely out of the equation?

I understand that some years ago, it would probably not have been
feasible and X11 was the de facto interface to do any graphics.

However, it seems you are already married to DRM/KMS so that you get
accurate timing feedback, so why not port your experiment programs
(the framework) directly on top of DRM/KMS instead of Wayland?

With Mesa EGL and GBM, you can still use hardware accelerated openGL if
you want to, but you will also be in explicit control of when you
push that rendered buffer into KMS for display. Software rendering by
direct pixel poking is also possible and at the end you just push that
buffer to KMS as usual too. You do not need any graphics card specific
code, it is all abstracted in the public APIs offered by Mesa and
libdrm, e.g. GBM. The new libinput should make hooking into input
devices much less painful, etc. All this thanks to Wayland, because on
Wayland, there is no single "the server" like the X.org X server is.
There will be lots of servers and each one needs the same
infrastructure you would need to run without a display server.

No display server obfuscating your view to the hardware, no
compositing manager fiddling with your presentation, and most likely no
random programs hogging the GPU at random times. Would the trade-off
not be worth it?

Of course your GUI tools and apps could continue using a display server
and would probably like to be ported to be Wayland compliant, I'm just
suggesting this for the sensitive experiment programs. Would this be
possible for your infrastructure?


On Thu, 20 Feb 2014 04:56:02 +0100
Mario Kleiner  wrote:

> On 17/02/14 14:12, Pekka Paalanen wrote:
> > On Mon, 17 Feb 2014 01:25:07 +0100
> > Mario Kleiner  wrote:
> >
> >> Hello Pekka,
> >>
> >> i'm not yet subscribed to wayland-devel, and a bit short on time atm.,
> >> so i'll take a shortcut via direct e-mail for some quick feedback for
> >> your Wayland presentation extension v2.
> >
> > Hi Mario,
> >
> > I'm very happy to hear from you! I have seen your work fly by on
> > dri-devel@ (IIRC) mailing list, and when I was writing the RFCv2 email,
> > I was thinking whether I should personally CC you. Sorry I didn't. I
> > will definitely include you on v3.
> >
> > I hope you don't mind me adding wayland-devel@ to CC, your feedback is
> > much appreciated and backs up my design nicely. ;-)
> >
> 
> Hi again,
> 
> still not subscribed, but maybe the server accepts the e-mail to 
> wayland-devel anyway as i'm subscribed to other xorg lists? I got an 
> "invalid captcha" error when trying to subscribe, despite no captcha was 
> ever presented to me? You may need to cc wayland-devel again for me.

I guess the web interface is still down. Emailing
wayland-devel-subscr...@lists.freedesktop.org should do, if I recall the
address correctly. And someone might process the moderation queue, too.

No worries anyway, I won't cut anything from you out, so it's all
copied below.

> >> 1. Wrt. an additional "preroll_feedback" request
> >> ,
> >> essentially the equivalent of glXGetSyncValuesOML(), that would be very
> >> valuable to us.
> >>
> ...
> >
> > Indeed, the "preroll_feedback" request was modeled to match
> > glXGetSyncValuesOML.
> >
> > Do you need to be able to call GetSyncValues at any time and have it
> > return ASAP? Do you call it continuously, and even between frames?
> >
> 
> Yes, at any time, even between frames, with a return asap. This is 
> driven by the specific needs of user code, e.g., to poll for a vblank, 
> or to establish a baseline of current (msc, ust) for timing stuff 
> relative. Psychtoolbox is an extension to a scripting language, so 
> usercode often decides how this is used.
> 
> Internally to the toolkit these calls are used on X11/GLX to translate 
> target timestamps into target v

xim-wayland

[Daiki Ueno]

Hi,

To add another use-case of wl_text_input protocol, I started a small
hack that enables XIM-based applications to use Wayland input methods:
https://github.com/ueno/xim-wayland

It runs as a standalone XIM server and translates between those
protocols.  A screenshot using weston-keyboard on xterm (on XWayland):
http://du-a.org/~ueno/junk/xim-wayland.webm

Unfortunately, it seems xterm does not support client-side preedit.
Here is another shot taken with gedit and GTK+ "xim" immodule:
http://du-a.org/~ueno/junk/xim-wayland-gedit-xim.webm

I'm wondering if it is possible to display preedit on a floating
wl_input_panel if an X client does not support preedit, though I have no
idea how to place it near the client window.

Regards,
--
Daiki Ueno

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

[PATCH] xwayland: Destroy wl_buffers only after they are released

[Rui Matos]

Destroying a wl_buffer that is still attached to a wl_surface is
undefined behavior according to the wayland protocol. We should delay
the destruction until we get the release event.

To achieve this we need to track ownership of wl_buffers, both our own
and the compositor's which occurs from either the first commit request
or the first commit request after a release event until the next
release event.
---

On 12 February 2014 08:54, Pekka Paalanen  wrote:
> I assume the code never added a wl_buffer listener before, because if
> it did, this patch would be a no-op. "wl_buffer_add_listener" is a
> misnomer, there can only ever be one listener, and trying to "add"
> another will not actually do anything.

Thanks for the headsup. But, indeed, there was nothing adding a
wl_buffer listener before.

> Also, you rely on wl_buffer.release not having arrived before you add
> the listener. With weston's gl-renderer, the release comes very soon
> after each wl_surface.commit for wl_shm buffers. Maybe it works, maybe
> it doesn't, but it seems very fragile. Did you check you don't leak
> wl_buffers now?

Right, I was leaking in some cases. So, I came up with the solution
below which, if I'm reading the logs correctly, doesn't leak and works
correctly.

This solution abuses the user_data field to essentially keep two
toggle references, our own and the compositor's, and only destroys the
wl_buffer when both are dropped.

Thanks,
Rui

---
 hw/xfree86/xwayland/xwayland-cursor.c  |  4 ++-
 hw/xfree86/xwayland/xwayland-private.h |  4 +++
 hw/xfree86/xwayland/xwayland-window.c  |  8 +++---
 hw/xfree86/xwayland/xwayland.c | 50 ++
 4 files changed, 61 insertions(+), 5 deletions(-)

diff --git a/hw/xfree86/xwayland/xwayland-cursor.c 
b/hw/xfree86/xwayland/xwayland-cursor.c
index 2b3cb5e..232b038 100644
--- a/hw/xfree86/xwayland/xwayland-cursor.c
+++ b/hw/xfree86/xwayland/xwayland-cursor.c
@@ -125,6 +125,7 @@ xwl_realize_cursor(DeviceIntPtr device, ScreenPtr screen, 
CursorPtr cursor)
  cursor->bits->width, cursor->bits->height,
  cursor->bits->width * 4,
  WL_SHM_FORMAT_ARGB);
+_buffer_init(buffer);
 wl_shm_pool_destroy(pool);
 
 dixSetPrivate(&cursor->devPrivates,
@@ -143,7 +144,7 @@ xwl_unrealize_cursor(DeviceIntPtr device,
 xwl_screen = xwl_screen_get(screen);
 buffer = dixGetPrivate(&cursor->devPrivates,
&xwl_screen->cursor_private_key);
-wl_buffer_destroy(buffer);
+_buffer_disown(buffer);
 
 return TRUE;
 }
@@ -176,6 +177,7 @@ xwl_seat_set_cursor(struct xwl_seat *xwl_seat)
  xwl_seat->x_cursor->bits->width,
  xwl_seat->x_cursor->bits->height);
 wl_surface_commit(xwl_seat->cursor);
+_buffer_commited(buffer);
 }
 
 static void
diff --git a/hw/xfree86/xwayland/xwayland-private.h 
b/hw/xfree86/xwayland/xwayland-private.h
index bdecf8a..41e7e13 100644
--- a/hw/xfree86/xwayland/xwayland-private.h
+++ b/hw/xfree86/xwayland/xwayland-private.h
@@ -137,4 +137,8 @@ void xwl_output_remove(struct xwl_output *output);
 
 extern const struct xserver_listener xwl_server_listener;
 
+void _buffer_commited(struct wl_buffer *buffer);
+void _buffer_disown(struct wl_buffer *buffer);
+void _buffer_init(struct wl_buffer *buffer);
+
 #endif /* _XWAYLAND_PRIVATE_H_ */
diff --git a/hw/xfree86/xwayland/xwayland-window.c 
b/hw/xfree86/xwayland/xwayland-window.c
index a2a8206..d18c7f6 100644
--- a/hw/xfree86/xwayland/xwayland-window.c
+++ b/hw/xfree86/xwayland/xwayland-window.c
@@ -62,10 +62,8 @@ xwl_window_attach(struct xwl_window *xwl_window, PixmapPtr 
pixmap)
 struct xwl_screen *xwl_screen = xwl_window->xwl_screen;
 struct wl_callback *callback;
 
-/* We can safely destroy the buffer because we only use one buffer
- * per surface in xwayland model */
 if (xwl_window->buffer)
-wl_buffer_destroy(xwl_window->buffer);
+_buffer_disown(xwl_window->buffer);
 
 xwl_screen->driver->create_window_buffer(xwl_window, pixmap);
 
@@ -74,6 +72,8 @@ xwl_window_attach(struct xwl_window *xwl_window, PixmapPtr 
pixmap)
return;
 }
 
+_buffer_init(xwl_window->buffer);
+
 wl_surface_attach(xwl_window->surface, xwl_window->buffer, 0, 0);
 wl_surface_damage(xwl_window->surface, 0, 0,
  pixmap->drawable.width,
@@ -185,7 +185,7 @@ xwl_unrealize_window(WindowPtr window)
return ret;
 
 if (xwl_window->buffer)
-   wl_buffer_destroy(xwl_window->buffer);
+_buffer_disown(xwl_window->buffer);
 wl_surface_destroy(xwl_window->surface);
 xorg_list_del(&xwl_window->link);
 if (RegionNotEmpty(DamageRegion(xwl_window->damage)))
diff --git a/hw/xfree86/xwayland/xwayland.c b/hw/xfree86/xwayland/xwayland.c
index c70a52d..c373fcc 100644
--- a/hw/xfree86/xwayland/xwayland.c
+++ b/hw/xfree86/xwayland/xwayland.c
@@ -72,6 +72,55 @@ 

Re: Wayland API to get the id of focus window [Seema Singh]

[The Rasterman]

On Thu, 20 Feb 2014 09:12:50 + (GMT) Seema Singh 
said:

> Hi All,
> 
> In our module we have used the below mentioned   ecore_x APIs.
> 1.ecore_x_window_focus_get()
> 2.ecore_x_netwm_pid_get()
> 
> We are planning to move to wayland platform. But  could not find the below
> APIs in ecore_wayland.h file Please let me know if anyone has come across the
> same issue.

first... by module... what does this code do? is it an enlightenment module? or
is it some external client process?

if it's literally a module inside enlightenment... enlightenment knows the
focus already - check other internal api's. you'll want to be looking at git
master to track dev and features there as that is where the most complete
wayland support is. as for pid - that would be something the compositor can get
by interrogating the fd of the client socket connection.

if this is a 3rd party app/process, the answer is "the 3rd party process has no
business knowing either of these bits of information for security reasons and
simply cleanliness of design."

so maybe you should first explain what you are doing, where and why, and
then... we can figure out what to do about it. :)

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

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

Re: Wayland API to get the id of focus window [Seema Singh]

[Christopher Michael]

Hi Semma,

Those APIs do not exist inside Ecore_Wayland yet. There is no concept of 
NetWM in wayland yet so that API was never added. Getting the current 
window which has focus would depend on the current shell. Due to not 
wanting Ecore_Wayland to be tied to any specific shell, that API was not 
added.


Which module are you trying to port ?

Kind Regards,
Chris Michael
SRUK

On 02/20/2014 09:12 AM, Seema Singh wrote:

Hi All,

In our module we have used the below mentioned   ecore_x APIs.
1.ecore_x_window_focus_get()
2.ecore_x_netwm_pid_get()

We are planning to move to wayland platform. But  could not find the below APIs 
in ecore_wayland.h file
Please let me know if anyone has come across the same issue.

Thanks & Regards,
Seema.

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



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

Wayland API to get the id of focus window [Seema Singh]

[Seema Singh]

Hi All,

In our module we have used the below mentioned   ecore_x APIs.
1.ecore_x_window_focus_get()
2.ecore_x_netwm_pid_get()

We are planning to move to wayland platform. But  could not find the below APIs 
in ecore_wayland.h file
Please let me know if anyone has come across the same issue.

Thanks & Regards,
Seema.

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

Re: Inter-client surface embedding

[Alex Elsayed]

Mark Thomas wrote:

> 
> As part of my current attempts to get MATE fully working on Wayland, I was
> planning to take a look at porting mate-panel this weekend.  However, I
> pretty quickly hit the first snag, which is that Gtk on Wayland doesn't
> support the GtkSocket/GtkPlug interface, which mate-panel relies heavily
> upon.



The question I find myself asking is "Do you really need a full-on surface 
to which you render arbitrarily?"

As I understand it, this is intended for the system-tray type use case, 
correct? Which generally has much simpler requirements in the common case, 
and the exceptional cases really do make more sense as shell plugins. Isn't 
that exactly what the proposed StatusNotifier[1] spec (which is used by KDE, 
I think Gnome as well, likely others) was intended to solve?

In particular, it was explicitly intended to get well clear of XEmbed 
precisely because of how horrid it was to deal with.

Because of the way it was designed, it should work with little-to-no 
modification, regardless of X11, Wayland, or anything else, so long as DBus 
is around.

[1] http://www.notmart.org/misc/statusnotifieritem/index.html

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