Re:Re: Wayland application start failed
The error still existed. Is there any other way? At 2016-08-05 17:50:57, "madana gopal" wrote: >Hi, > >If you are running Qt app, QT_QPA_PLATFORM environment would have set >to wayland. So, it is throwing this error. You can try changing this >and see, whether the error is coming or not?. > >Thanks. > >Regards, >Madan > >On Fri, Aug 5, 2016 at 2:39 PM, Anthenony wrote: >> Hi, All: >> >> Error: >> " >> This application failed to start because it could not find or load >> the Qt platform plugin "wayland" in " ". >> Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, >> offscreen, wayland. >> Reinstalling the application may fix this problem." >> >> I can't find some solution about it on the website. >> I don't know why the wayland has been available, but it showed that >> wayland cannot be found or loaded. >> If anyone met the same problem as me when running the application, >> please share some solution to me. >> Thanks! >> >> Best regards, >> Anthenony >> >> >> >> >> >> >> >> >> ___ >> wayland-devel mailing list >> wayland-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/wayland-devel >> >___ >wayland-devel mailing list >wayland-devel@lists.freedesktop.org >https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v2] Introduce xdg-foreign protocol
On 05/08/16 10:52 AM, Jonas Ådahl wrote: > On Fri, Aug 05, 2016 at 07:45:50AM -0500, Derek Foreman wrote: >> On 27/07/16 02:54 AM, Jonas Ådahl wrote: >>> xdg-foreign is a protocol meant to enable setting up inter surface >>> relationships across clients. Potential use cases are out-of-process >>> dialogs, such as file dialogs, meant to be used by sandboxed processes >>> that may not have the access it needs to implement such dialogs. >>> >>> It works by enabling a client to export a surface, creating a handle >>> for the exported surface. The handle, in form of a unique string, may >>> be shared in some way with other clients (for example the provider of >>> the file dialog) which can then import the exported surface. >> >> Have you considered passing an fd (have the compositor create a pipe) >> instead of a string? >> >> Then the shared token is impossible to guess. > > As Carsten wrote in the other E-mail, a client can be lazy and generate > a bad string. The client also wouldn't be able to generate a globally > unique string, so to import a handle, the importing client would also > need to associate the string with some kind of client id. Why would clients be generating strings? I think maybe I was too terse, I've explained what I'd intended the fd to be used for in my other reply. I'm fine with the proposal as-is though, I just though perhaps a method in which nobody generated a string at all would be better. :) Thanks, Derek >> >> Even so, this looks workable and not too hard to implement. >> >> Reviewed-by: Derek Foreman > > Thanks! > > > Jonas > >> >> Thanks, >> Derek >>> Signed-off-by: Jonas Ådahl >>> --- >>> >>> Changes since v1: >>> >>> - Spelling and grammar fixes >>> - Wording changes (unexport -> revoke) >>> - Fixed the "Warning! .. unstable .." paragraph (was an old version) >>> - Added sandbox client -> unsandboxed file browser dialog example to >>> protocol >>>description >>> - Removed left-over note about restriction of importing a handle only >>> once. It >>>should be possible to import a handle multiple times, but the protocol >>> text >>>had only been updated in one of two places. >>> >>> >>> Jonas >>> >>> >>> >>> Makefile.am | 1 + >>> unstable/xdg-foreign/README | 4 + >>> unstable/xdg-foreign/xdg-foreign-unstable-v1.xml | 186 >>> +++ >>> 3 files changed, 191 insertions(+) >>> create mode 100644 unstable/xdg-foreign/README >>> create mode 100644 unstable/xdg-foreign/xdg-foreign-unstable-v1.xml >>> >>> diff --git a/Makefile.am b/Makefile.am >>> index 9e2a029..35df201 100644 >>> --- a/Makefile.am >>> +++ b/Makefile.am >>> @@ -9,6 +9,7 @@ unstable_protocols = >>> \ >>> unstable/pointer-constraints/pointer-constraints-unstable-v1.xml >>> \ >>> unstable/tablet/tablet-unstable-v1.xml >>> \ >>> unstable/tablet/tablet-unstable-v2.xml >>> \ >>> + unstable/xdg-foreign/xdg-foreign-unstable-v1.xml >>> \ >>> $(NULL) >>> >>> stable_protocols = >>> \ >>> diff --git a/unstable/xdg-foreign/README b/unstable/xdg-foreign/README >>> new file mode 100644 >>> index 000..f5bcb83 >>> --- /dev/null >>> +++ b/unstable/xdg-foreign/README >>> @@ -0,0 +1,4 @@ >>> +xdg foreign protocol >>> + >>> +Maintainers: >>> +Jonas Ådahl >>> diff --git a/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml >>> b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml >>> new file mode 100644 >>> index 000..c6f5775 >>> --- /dev/null >>> +++ b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml >>> @@ -0,0 +1,186 @@ >>> + >>> + >>> + >>> + >>> +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 CO
Re: [PATCH wayland-protocols v2] Introduce xdg-foreign protocol
On 05/08/16 09:18 AM, Carsten Haitzler (The Rasterman) wrote: > On Fri, 5 Aug 2016 07:45:50 -0500 Derek Foreman said: > >> On 27/07/16 02:54 AM, Jonas Ådahl wrote: >>> xdg-foreign is a protocol meant to enable setting up inter surface >>> relationships across clients. Potential use cases are out-of-process >>> dialogs, such as file dialogs, meant to be used by sandboxed processes >>> that may not have the access it needs to implement such dialogs. >>> >>> It works by enabling a client to export a surface, creating a handle >>> for the exported surface. The handle, in form of a unique string, may >>> be shared in some way with other clients (for example the provider of >>> the file dialog) which can then import the exported surface. >> >> Have you considered passing an fd (have the compositor create a pipe) >> instead of a string? >> >> Then the shared token is impossible to guess. >> >> Even so, this looks workable and not too hard to implement. > > are you sure this should just be some client chosen string. this sounds bad in > that it means if client choose bad strings they compromise their security. Hi, are you asking me this? I'm sure it shouldn't be. :) My suggestion was to have the compositor create a pipefd, hand the pipe to the exporter, then the exporter hands the pipe to the importer via some exogenous method (dbus, sendmsg, whatever), and then the compositor verifies that the fd is the other end of the pipe from the one it kept to itself. > https://git.enlightenment.org/core/efl.git/tree/src/lib/ecore_wayland/session-recovery.xml > > - the compositor will provide a uuid via an event. the idea is the compositor > picks some big long sha1 or whatever hash string. client supplies this if it > reconnects after compositor went away unexpectedly (crash/restart/upgrade). > > i think a similar system but uuid's for "naming a surface" would be good. then > client a can say "hey this dialog is for uuid xyz" as long as the client > owning > xyz can provide the uuid do this other one. > > the point of uuid's is so they CAN survive process restarts too, compositor > restarts etc. unlike fd's where the last process holding that fd dies you > lost the handle. (The rest of this is more about EFL's session recovery protocols than xdg-foreign...) Well, the client is going to have to recreate all of its surfaces on reconnect, and only the top level surfaces are positioned entirely by the compositor without app knowledge, so those are really the only ones that need UUIDs, so they can be accurately repositioned. I think it might be easier to have the clients re-negotiate the foreign stuff than to try to have compositor remember any of that over restart. This also avoids ever having to try to remember any kind of grab state over a compositor restart. This is, of course, assuming EFL apps ever need xdg-foreign or non-EFL apps that do ever speak our session recovery protocol. :) Thanks, Derek >> Reviewed-by: Derek Foreman >> >> Thanks, >> Derek >>> Signed-off-by: Jonas Ådahl >>> --- >>> >>> Changes since v1: >>> >>> - Spelling and grammar fixes >>> - Wording changes (unexport -> revoke) >>> - Fixed the "Warning! .. unstable .." paragraph (was an old version) >>> - Added sandbox client -> unsandboxed file browser dialog example to >>> protocol description >>> - Removed left-over note about restriction of importing a handle only >>> once. It should be possible to import a handle multiple times, but the >>> protocol text had only been updated in one of two places. >>> >>> >>> Jonas >>> >>> >>> >>> Makefile.am | 1 + >>> unstable/xdg-foreign/README | 4 + >>> unstable/xdg-foreign/xdg-foreign-unstable-v1.xml | 186 >>> +++ 3 files changed, 191 insertions(+) >>> create mode 100644 unstable/xdg-foreign/README >>> create mode 100644 unstable/xdg-foreign/xdg-foreign-unstable-v1.xml >>> >>> diff --git a/Makefile.am b/Makefile.am >>> index 9e2a029..35df201 100644 >>> --- a/Makefile.am >>> +++ b/Makefile.am >>> @@ -9,6 +9,7 @@ unstable_protocols >>> = \ >>> unstable/pointer-constraints/pointer-constraints-unstable-v1.xml\ >>> unstable/tablet/tablet-unstable-v1.xml >>> \ >>> unstable/tablet/tablet-unstable-v2.xml >>> \ >>> + >>> unstable/xdg-foreign/xdg-foreign-unstable-v1.xml\ >>> $(NULL) >>> stable_protocols >>> = \ diff >>> --git a/unstable/xdg-foreign/README b/unstable/xdg-foreign/README new file >>> mode 100644 index 000..f5bcb83 >>> --- /dev/null >>> +++ b/unstable/xdg-foreign/README >>> @@ -0,0 +1,4 @@ >>> +xdg foreign protocol >>> + >>> +Maintainers: >>> +Jonas Ådahl >>> diff --git a/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml >>> b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml new file mode 100644 >>> index 000..c6f5775 >>> --- /dev/null >>> +++ b/unstab
