RE: Re: Summary of the security discussions around Wayland and privileged clients
> Hi Steve, thanks for the thoughtful response. > > PAM's technical implementation allows a number of modules to be tried in > order for authentication. Your API, as a PAM authentication module, is > limited to four operations: ask the user a non-secret question (with a > textual response), ask the user a secret question (with a textual > response), tell the user a piece of information (with no guarantee how this > will be displayed, or if it will be erased upon the next request), or tell > the user about an error (again, with no guarantee). > > This directly limits the types of authentication you can do: you can't > easily do out-of-bound authentication UI like facial detection unless the > thing using PAM knows enough about the stack to put up a webcam display. > > In addition, PAM only supports one module at a time, meaning it's > impossible to run multiple at the same time (enter your PIN, swipe your > fingerprint, or wave a smartcard to unlock); the user first has to fail > three times on the PIN before moving to the next module in the stack. On one hand that is a problem, but on the other hand if a module were run in parallel with another one, a policy would be required to decide what to do when one returns "Yes" and the other returns "No". Typically face detection or fingerprint detection is not so hard to spoof, and an attacker would always go for the easy way in if users were to choose which PAM module to use to authenticate. I'm getting offtopic though! > This flexibility on the part of the system builder means it's hard for us > to build an API. Additionally, it's hard to do things like automatically > log the user in unless we make the assumption that pam_unix is the first > entry in the stack, and simply replay the user's password to the first > secret question request we get. (This might sound silly, but this is a > problem we had with our Initial Setup tool, which already takes the user's > password as part of the setup process). > > Obviously, there's nothing fundamentally wrong with the security model of > PAM, it's all just in the implementation details. But I'm afraid we're > going to run into the same trap here: you're going to write a specification > and code for a WSM framework, in which we might pass it not enough data, > and the module won't have enough data to determine whether to allow or deny > such an application. I would state that the issue here is that you are allowed to provide modules that make a local security decision (on an auth factor) but that cannot also decide on the global policy. If that's a correct translation of your concern, then I believe I understand what you're worried about. I'll explain my personal view on what a WSM should provide below. > Has this same application spammed the screenshot app more than 10 times in > the last minute? How much disk space is it using right now? Has the user > tried to kill this application before for misbehaving? Do we have any data > on record about this app? Are there updates to this application available? I would rather say then that you want to make decisions on applications at a higher level than just the compositor, possibly using compositor information in the process. That's fine, see below! [snip] > > > > Here you're not speaking about infrastructure but policy. Who decides who's > > allowed to use the gnome photo service? Who enforces that? > > > In the app sandboxing mechanism we've discussed before, an application can > only use the capabilities it's requested. If it requests the "Chat" > capability, then I'd assume we'd allow it to use the wl_notification_shell > interface along with org.freedesktop.Telepathy, and access "~/Personal > Data/Chat Logs". > > It was just a simple example, and the details need fleshing out, but I feel > it's a powerful metaphor for the user: instead of asking about the > low-level details, it works out a relatively sane high-level definition of > what a role would have, and what low-level operations it might encompass. I have rather strong opinions on how and what to sandbox but they would be very offtopic, I'd love to chat about this with you though if you're interested in the topic. Shortly it seems to me you'd be interested in FBAC (http://schreuders.org/FBAC-LSM/). I personally dislike the idea of per-app sandboxing and feel uneasy with having to label apps with any kind of information on what they can be used for, though that's already quite flexible and easy to setup. I just don't trust packagers to make security/usability decisions for me. > > This policy certainly could be governed by a WSM, but I feel that > implementing a "Wayland Security Module", a "DBus Security Module", and a > "Local Filesystem Access Security Module" would be missing the point: these > are all system APIs, and should be governed together instead of separately. > Allowing me to patch in a WSM that always allows, but keeping the DBusSM > the same isn't much help. > > For a screenshot app, it m
Re: Summary of the security discussions around Wayland and privileged clients
On 27/02/2014 18:01, Jasper St. Pierre wrote: On Wed, Feb 26, 2014 at 10:02 PM, Sebastian Wick mailto:sebast...@sebastianwick.net>> wrote: Hey Jasper, maybe I didn't understand what you're saying but why can't you use the application authorization mechanism you're talking about in a "WSM"? Wouldn't it make sense to make it independent of the compositor? Of course. That's why I'd love to have not just a "WSM" but a full application authorization system that can be used not only for Wayland requests but correspond to full capability management. DBus is a perfect example. We should allow an app to only see the DBus peers that it needs to see. So, org.gnome.Photos should never be able to see or call APIs on org.kde.Konqueror or vice versa. But an app might want a capability to interface with org.freedesktop.Telepathy. And the same app might want access to a privileged wl_notification_shell API so it can display a chat window in a special corner of the screen when you get a message. And they'd probably want read/write access to "~/Personal Data/Chat Logs/" or wherever the user configured their chat logs folder to be, without access to "~/Porn/". We need to think about the full surface of how applications will interact with the system, without thinking about it in terms of Wayland-only or DBus-only specifics. That's why I'm opposed to the idea of "WSMs", and instead say we should start thinking about a full application sandboxing and capability mechanism. For a system like GNOME, for which our compositor, mutter, is used, I'd never allow a different WSM to be configured, because then it won't integrate with the rest of the system. A dialog pops up to ask the user to allow wl_notification_shell, but they still can't use org.freedesktop.Telepathy. I think the policy should be compositor-agnostic, especially since some may run multiple compositors at the same time. We thus need to abstract the different compositors and I think that's the role of libwsm. Just like LSM (Linux Security Module), libwsm is just a collection of hooks that get called with a well-defined semantic, most-likely mostly based on the Wayland protocol rather than the internal implementation of the compositor. Libwsm would indeed ship with a default policy that doesn't depend on anything else than POSIX but it could be replaced very easily to use any security decision engine, may it be SELinux or whatever new and shiny decision engine appears in the future. The way I intend to do that is by having libwsm forward the hooks to the right security backend. A security backend would be a dynamically loaded .so by libwsm. libwsm will know which .so should be loaded by reading its configuration file. I already implemented such a system in PPassKeeper[1]. Just to make it clear, if no such abstraction is made, then all compositors will require changes when a new decision engine becomes available. But the worst problem is that each compositor will have different hook points with different semantics and this will require to write a different policy for each and every compositor. If I may say, I think it sucks hard ;) Your pluggable WSM just made the user unhappy. You're killing the messenger, not the problem ;). In this case, the problem would be the policy. WSM isn't PAM, I think having WSM only load ONE security backend is just easier and simpler. Cheers, Martin [1] http://www.mupuf.org/project/ppasskeeper.html ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Re: Summary of the security discussions around Wayland and privileged clients
Hi Steve, thanks for the thoughtful response. On Thu, Feb 27, 2014 at 3:27 PM, Dodier-Lazaro, Steve < s.dodier-lazaro...@ucl.ac.uk> wrote: > Hello Jasper, > > A quick reply on some of your emails (grouped to avoid spamming the ML). > > > My experience with PAM and similar "pluggable security modules" is that > > they provide a subpar user experience, are hard to integrate properly > into > > the system, and have large pain points that stem from having such > > flexibility. > > I'm really unsure what you mean by subpar UX here. Subpar involves a > comparison > with another approach, but then it'd be easier for us to discuss what you > think > is wrong in PAM if you told us what you think would work better and why. > Otherwise it's hard for us to see the parallel you're making with WSMs and > understand what it is you're concerned about and what we should do about > those > concerns. > PAM's technical implementation allows a number of modules to be tried in order for authentication. Your API, as a PAM authentication module, is limited to four operations: ask the user a non-secret question (with a textual response), ask the user a secret question (with a textual response), tell the user a piece of information (with no guarantee how this will be displayed, or if it will be erased upon the next request), or tell the user about an error (again, with no guarantee). This directly limits the types of authentication you can do: you can't easily do out-of-bound authentication UI like facial detection unless the thing using PAM knows enough about the stack to put up a webcam display. In addition, PAM only supports one module at a time, meaning it's impossible to run multiple at the same time (enter your PIN, swipe your fingerprint, or wave a smartcard to unlock); the user first has to fail three times on the PIN before moving to the next module in the stack. This flexibility on the part of the system builder means it's hard for us to build an API. Additionally, it's hard to do things like automatically log the user in unless we make the assumption that pam_unix is the first entry in the stack, and simply replay the user's password to the first secret question request we get. (This might sound silly, but this is a problem we had with our Initial Setup tool, which already takes the user's password as part of the setup process). Obviously, there's nothing fundamentally wrong with the security model of PAM, it's all just in the implementation details. But I'm afraid we're going to run into the same trap here: you're going to write a specification and code for a WSM framework, in which we might pass it not enough data, and the module won't have enough data to determine whether to allow or deny such an application. Has this same application spammed the screenshot app more than 10 times in the last minute? How much disk space is it using right now? Has the user tried to kill this application before for misbehaving? Do we have any data on record about this app? Are there updates to this application available? > > My compositor, mutter, will probably never call out to your "WSM", and > > we'll probably defer to another application authorization mechanism, > > probably the same one that provides application sandboxing, and other > such > > capabilities. I'd also recommend that you go ahead and talk to the > people, > > and perhaps even help build that mechanism, which isn't specific to > > Wayland, but will also cover DBus requests, system calls, and more. > > The idea of security modules is not that you decide which modules to speak > to or > what modules do, but rather that a number of operations in your compositor > can > cause security issues, and that these operations can be monitored and a > policy > enforced over them. What Martin speaks about in his blog post is mostly the > infrastructure allowing this, in short he's thinking about how to implement > complete mediation of the interactions between apps that occur in the > graphic > stack. WSMs are then pieces of code that can use these hooks to decide what > policy to implement. To a certain extent we also discuss what we believe > would > be a sensible (wrt. the current reasonable requirements of apps found on > Linux > systems, usability requirements and security requirements) default policy > for a > default WSM to enforce. > > It's not really relevant to you what the WSM does or why. A default policy > would > make sure that an app cannot spy on another at the graphic stack level > (and this > has direct consequences for e.g. when you're typing a password in a dialog > - it > may just stay in the corresponding process's memory and never be dumped to > disk, > hence a security benefit already). Of course a WSM will never mediate file > system accesses, but that is not the point of it. What matters is that > Wayland > and compositors are the only place where you can put infrastructure for > graphic > stack security. I'm currently working on implement a sy
RE: Re: Summary of the security discussions around Wayland and privileged clients
Hello Jasper, A quick reply on some of your emails (grouped to avoid spamming the ML). > My experience with PAM and similar "pluggable security modules" is that > they provide a subpar user experience, are hard to integrate properly into > the system, and have large pain points that stem from having such > flexibility. I'm really unsure what you mean by subpar UX here. Subpar involves a comparison with another approach, but then it'd be easier for us to discuss what you think is wrong in PAM if you told us what you think would work better and why. Otherwise it's hard for us to see the parallel you're making with WSMs and understand what it is you're concerned about and what we should do about those concerns. > My compositor, mutter, will probably never call out to your "WSM", and > we'll probably defer to another application authorization mechanism, > probably the same one that provides application sandboxing, and other such > capabilities. I'd also recommend that you go ahead and talk to the people, > and perhaps even help build that mechanism, which isn't specific to > Wayland, but will also cover DBus requests, system calls, and more. The idea of security modules is not that you decide which modules to speak to or what modules do, but rather that a number of operations in your compositor can cause security issues, and that these operations can be monitored and a policy enforced over them. What Martin speaks about in his blog post is mostly the infrastructure allowing this, in short he's thinking about how to implement complete mediation of the interactions between apps that occur in the graphic stack. WSMs are then pieces of code that can use these hooks to decide what policy to implement. To a certain extent we also discuss what we believe would be a sensible (wrt. the current reasonable requirements of apps found on Linux systems, usability requirements and security requirements) default policy for a default WSM to enforce. It's not really relevant to you what the WSM does or why. A default policy would make sure that an app cannot spy on another at the graphic stack level (and this has direct consequences for e.g. when you're typing a password in a dialog - it may just stay in the corresponding process's memory and never be dumped to disk, hence a security benefit already). Of course a WSM will never mediate file system accesses, but that is not the point of it. What matters is that Wayland and compositors are the only place where you can put infrastructure for graphic stack security. I'm currently working on implement a system with app sandboxing, and I have my own subjective and debatable idea of what the policy should be and I would expect others to disagree with me on this. Yet, what matters to me is that there is a mediation infrastructure that is flexible and complete enough for me to enforce the policy I want. It's the case in certain aspects of the system with SELinux, it's not the case at all in many many areas of userland (not relevant to this email to discuss that) including the graphic stack (even XACE does not allow me to implement a simple/easy clipboard access policy). It's not really ok to state that since other threats exist on a system then it's not worth finding responses to threats in one's own code base (saying that it's not necessary to isolate windows in Wayland because they can steal one another's file is a bit like saying that session passwords are useless because one might as well steal a computer's HDD and read the data from there. Turns out this becomes false on the day people fix the HDD-related threat with full-disk encryption). The whole goal of discussing WSMs and discussing what a policy could look like is making sure that we (well, you Wayland developers, actually) don't forget to mediate some operations that may be exploited to harm users' assets later on -- irrespective of whether other threats in other subsystems of an OS exist. > Of course. That's why I'd love to have not just a "WSM" but a full > application authorization system that can be used not only for Wayland > requests but correspond to full capability management. Nothing prevents a WSM from collaborating with a LSM and some other types of SMs! However without infrastructure for WSMs in the first place, then people like me would have to dump X11/Wayland/whatever's out there and rewrite a whole graphic stack. Ouch! We do need to bring security to userland incrementally because there is so much to fix, but yes the default policy will have to encompass more aspects than just who shares what GPU buffers. > DBus is a perfect example. We should allow an app to only see the DBus > peers that it needs to see. So, org.gnome.Photos should never be able to > see or call APIs on org.kde.Konqueror or vice versa. But an app might want > a capability to interface with org.freedesktop.Telepathy. And the same app > might want access to a privileged wl_notification_shell API so it can > display
Re: Summary of the security discussions around Wayland and privileged clients
On Wed, Feb 26, 2014 at 10:02 PM, Sebastian Wick < sebast...@sebastianwick.net> wrote: > Hey Jasper, > > maybe I didn't understand what you're saying but why can't you use the > application authorization mechanism you're talking about in a "WSM"? > Wouldn't it make sense to make it independent of the compositor? > Of course. That's why I'd love to have not just a "WSM" but a full application authorization system that can be used not only for Wayland requests but correspond to full capability management. DBus is a perfect example. We should allow an app to only see the DBus peers that it needs to see. So, org.gnome.Photos should never be able to see or call APIs on org.kde.Konqueror or vice versa. But an app might want a capability to interface with org.freedesktop.Telepathy. And the same app might want access to a privileged wl_notification_shell API so it can display a chat window in a special corner of the screen when you get a message. And they'd probably want read/write access to "~/Personal Data/Chat Logs/" or wherever the user configured their chat logs folder to be, without access to "~/Porn/". We need to think about the full surface of how applications will interact with the system, without thinking about it in terms of Wayland-only or DBus-only specifics. That's why I'm opposed to the idea of "WSMs", and instead say we should start thinking about a full application sandboxing and capability mechanism. For a system like GNOME, for which our compositor, mutter, is used, I'd never allow a different WSM to be configured, because then it won't integrate with the rest of the system. A dialog pops up to ask the user to allow wl_notification_shell, but they still can't use org.freedesktop.Telepathy. Your pluggable WSM just made the user unhappy. Am 2014-02-26 23:05, schrieb Jasper St. Pierre: > >> Hi Martin, >> >> My experience with PAM and similar "pluggable security modules" is >> that they provide a subpar user experience, are hard to integrate >> properly into the system, and have large pain points that stem from >> having such flexibility. >> >> My compositor, mutter, will probably never call out to your "WSM", and >> we'll probably defer to another application authorization mechanism, >> probably the same one that provides application sandboxing, and other >> such capabilities. I'd also recommend that you go ahead and talk to >> the people, and perhaps even help build that mechanism, which isn't >> specific to Wayland, but will also cover DBus requests, system calls, >> and more. >> >> On Wed, Feb 26, 2014 at 4:40 PM, Martin Peres >> wrote: >> >> Le 19/02/2014 17:11, Martin Peres a écrit : >>> >>> Wayland Security Modules As seen earlier, granting access to a restricted interface or not depends on the context of the client (how it was launched, previous actions). The expected behaviour should be defined by a security policy. As no consensus on the policy [can apparently be >>> reached](https://www.mail-archive.com/Wayland-devel@ >> lists.freedesktop.org/msg12261.html >> >>> [1]) (as usual in security), we have all agreed that we needed to separate the policy from the code. This is very much alike [Linux Security Modules >>> (LSM)](http://www.nsa.gov/research/_files/selinux/ >> papers/module/x45.shtml >> >>> [2]) or [X Access Control Extension >>> (XACE)](http://www.x.org/releases/X11R7.5/doc/security/XACE-Spec.html >> >>> [3]). From a software engineering point of view, we would work on a security library called Wayland Security Modules (name subject to changes) that Wayland compositors would call when a security decision would need to be made. The library would then load the wanted security policy, defined by a shared-object that I will refer to as the security backend. In the case of allowing a client to bind a restricted interface or not, the corresponding WSM hook should return ``ACCEPT``, ``PROMPT`` or ``DENY``, prompt meaning the compositor would have to ask the user if he wants to accept the risk or not. Let me stress out that prompting should be a last-resort measure as numerous studies have been made proving that unless asked very rarely, users will always allow the operation. Some additional hooks would also be needed in order to track the state of Wayland clients (open, close, etc...) but nothing too major should be needed. The compositors would just have to store this context in a ``void *security;`` attribute in the Wayland client structure. Finally, WSM could be extended to control the access to the clipboard and maybe other interfaces I haven't thought about yet. The design of this library has not started yet. If you are interested in helping out, I would love to have some feedback on what are your use cases for WSM. >>> >>> Hey Guys, >>> >>> I think
Re: [PATCH 0/6] Add weston randr protocol
For comparison, here is the dbus API that gnome-shell is exposing for display configuration under both X and wayland: https://wiki.gnome.org/Initiatives/Wayland/Gaps/DisplayConfig ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [PATCH 0/6] Add weston randr protocol
-Original Message- From: wayland-devel-boun...@lists.freedesktop.org [mailto:wayland-devel-boun...@lists.freedesktop.org] On Behalf Of Hardening Sent: Thursday, February 27, 2014 5:15 PM To: wayland-devel@lists.freedesktop.org Subject: Re: [PATCH 0/6] Add weston randr protocol Le 27/02/2014 04:27, Quanxian Wang a écrit : > These patches will provide weston randr protocol, its implementation > and randr application. > > The idea is from xrandr provided by xserver. *Dynamic* mode setting is > the main objective of this protocol. Remember, it is one shot > operation. For example, if setting the mode, just call one request > wl_randr_set_mode without any other operation. > > With this protocol, weston-wrandr application is developped to help > user implement randr protocol in command line just like xrandr command > in xserver. > Hi Quanxian, I have submitted such functionality one year ago: http://lists.freedesktop.org/archives/wayland-devel/2013-March/007872.html. The scope was smaller (targeting essentially mode resolution) but it was working. At the time there were no real enthusiasm, some people were even against. Perhaps some have changed their mind since. [Wang, Quanxian] Got it, Thanks. Ahaha. Seems we really need the access control mechanism to make it happen. After all, it should be a good tool from my viewpoint. Regards. -- David FORT website: http://www.hardening-consulting.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: [PATCH 1/6] Add weston randr protocol
-Original Message- From: Pekka Paalanen [mailto:ppaala...@gmail.com] Sent: Thursday, February 27, 2014 5:45 PM To: Wang, Quanxian Cc: wayland-devel@lists.freedesktop.org; Zhang, Xiong Y Subject: Re: [PATCH 1/6] Add weston randr protocol On Thu, 27 Feb 2014 09:15:55 + "Wang, Quanxian" wrote: > > > -Original Message- > From: Pekka Paalanen [mailto:ppaala...@gmail.com] > Sent: Thursday, February 27, 2014 4:36 PM > To: Wang, Quanxian > Cc: wayland-devel@lists.freedesktop.org; Zhang, Xiong Y > Subject: Re: [PATCH 1/6] Add weston randr protocol > > On Thu, 27 Feb 2014 08:06:23 + > "Wang, Quanxian" wrote: > > > > > > > -Original Message- > > From: Pekka Paalanen [mailto:ppaala...@gmail.com] > > Sent: Thursday, February 27, 2014 3:28 PM > > To: Wang, Quanxian > > Cc: wayland-devel@lists.freedesktop.org; Zhang, Xiong Y > > Subject: Re: [PATCH 1/6] Add weston randr protocol > > > > On Thu, 27 Feb 2014 11:28:00 +0800 > > Quanxian Wang wrote: > > > > > Weston protocol wrandr will provide interface to > > > 1) set output mode > > > 2) set output transform > > > 3) move output to relative position > > > 4) provide disconnected display port information > > > > > > *Dynamic* mode setting is the main objective of this protocol. > > > Remember, it is one shot operation. For example, if setting the > > > mode, just call one request wl_randr_set_mode without any other > > > operation. > > > > Hi, > > > > like I said in my other reply, this is a configuration interface, > > not something for all applications to use. Protocol comments below > > assuming, that this will be a configuration interface and that the > > generic idea is acceptable. ... > > If I change the mode on two different outputs, how do I know which > > action_done corresponds to which request? [Wang, Quanxian] right, > > add wl_output parameter. > > No. If I do two mode set operations on the same wl_output, then again > I would not know which answer was for which. [Wang, Quanxian] I know > you mean. Yes, if the same client has more threads which send mode > change at the same time, we have to use unique number to stand for > every operation. That unique number could be a serial, but here more appropriate is a unique number for each request. You can let Wayland do all the unique number management for you by using the feedback object design I referred to below. After all, a Wayland protocol object is essentially just a unique number. They are very cheap. That is why you almost never need to manually fiddle with "unique numbers" in the protocol. > Instead, a generic pattern for this kind of "return data" is to let > the original request also create a feedback protocol object. This > object is unique to the request that was sent, and can deliver any > return data without any ambiguity. An example of a feedback object is > wl_callback, except it can only deliver "done", not "yes"/"no"; not > delivering anything will cause problems. [Wang, Quanxian] Good, > thanks. > > > > > What if move succeeds but mode change fails? Wouldn't that leave the > > output in an unwanted state which is neither the original nor the > > wanted setting? [Wang, Quanxian] one by one. Not support complex. If > > you have such case, have to turn back. Call another move back. But > > firstly make sure the previous is successful. > > That will require a lot of roundtrips, and it essentially forces the > compositor to show all the intermediate steps on the monitors. IOW, > that is designed to be both slow and glitchy. That's not how you > should do dynamic mode setting. I think you are going to need atomic > group operations. [Wang, Quanxian] Yes, we could provide a request > with more parameters setting(group operations). Just like many > parameters in weston_output_switch_mode. Except you would need to let it cover an arbitrary number of outputs in one go. That means that you will need something like what wl_surface.commit does. Having a request with a huge number of arguments is not only ugly but inflexible, and cannot be extended in the future. [Wang, Quanxian] Agree, I have found that when using this. Basically I want to add transform parameter, at last I give up. because it is complex, also ugly, and not readable. :) > > The solution to this would tie in with the solution to take changes > > atomic. For instance, to prepare for a configuration change, one > > might create a change object in the protocol, store all changes in > > that object, and then commit that set of changes atomically. Then > > have one return value: the whole set either succeeds or fails. > > > > I guess you could look for inspiration in the DRM atomic mode > > setting API. I don't know how the RandR X11 protocol works, if that > > would be a good example also. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman
Re: [PATCH 1/6] Add weston randr protocol
On Thu, 27 Feb 2014 09:15:55 + "Wang, Quanxian" wrote: > > > -Original Message- > From: Pekka Paalanen [mailto:ppaala...@gmail.com] > Sent: Thursday, February 27, 2014 4:36 PM > To: Wang, Quanxian > Cc: wayland-devel@lists.freedesktop.org; Zhang, Xiong Y > Subject: Re: [PATCH 1/6] Add weston randr protocol > > On Thu, 27 Feb 2014 08:06:23 + > "Wang, Quanxian" wrote: > > > > > > > -Original Message- > > From: Pekka Paalanen [mailto:ppaala...@gmail.com] > > Sent: Thursday, February 27, 2014 3:28 PM > > To: Wang, Quanxian > > Cc: wayland-devel@lists.freedesktop.org; Zhang, Xiong Y > > Subject: Re: [PATCH 1/6] Add weston randr protocol > > > > On Thu, 27 Feb 2014 11:28:00 +0800 > > Quanxian Wang wrote: > > > > > Weston protocol wrandr will provide interface to > > > 1) set output mode > > > 2) set output transform > > > 3) move output to relative position > > > 4) provide disconnected display port information > > > > > > *Dynamic* mode setting is the main objective of this protocol. > > > Remember, it is one shot operation. For example, if setting the > > > mode, just call one request wl_randr_set_mode without any other > > > operation. > > > > Hi, > > > > like I said in my other reply, this is a configuration interface, > > not something for all applications to use. Protocol comments below > > assuming, that this will be a configuration interface and that the > > generic idea is acceptable. ... > > If I change the mode on two different outputs, how do I know which > > action_done corresponds to which request? [Wang, Quanxian] right, > > add wl_output parameter. > > No. If I do two mode set operations on the same wl_output, then again > I would not know which answer was for which. [Wang, Quanxian] I know > you mean. Yes, if the same client has more threads which send mode > change at the same time, we have to use unique number to stand for > every operation. That unique number could be a serial, but here more appropriate is a unique number for each request. You can let Wayland do all the unique number management for you by using the feedback object design I referred to below. After all, a Wayland protocol object is essentially just a unique number. They are very cheap. That is why you almost never need to manually fiddle with "unique numbers" in the protocol. > Instead, a generic pattern for this kind of "return data" is to let > the original request also create a feedback protocol object. This > object is unique to the request that was sent, and can deliver any > return data without any ambiguity. An example of a feedback object is > wl_callback, except it can only deliver "done", not "yes"/"no"; not > delivering anything will cause problems. [Wang, Quanxian] Good, > thanks. > > > > > What if move succeeds but mode change fails? Wouldn't that leave > > the output in an unwanted state which is neither the original nor > > the wanted setting? [Wang, Quanxian] one by one. Not support > > complex. If you have such case, have to turn back. Call another > > move back. But firstly make sure the previous is successful. > > That will require a lot of roundtrips, and it essentially forces the > compositor to show all the intermediate steps on the monitors. IOW, > that is designed to be both slow and glitchy. That's not how you > should do dynamic mode setting. I think you are going to need atomic > group operations. [Wang, Quanxian] Yes, we could provide a request > with more parameters setting(group operations). Just like many > parameters in weston_output_switch_mode. Except you would need to let it cover an arbitrary number of outputs in one go. That means that you will need something like what wl_surface.commit does. Having a request with a huge number of arguments is not only ugly but inflexible, and cannot be extended in the future. > > The solution to this would tie in with the solution to take changes > > atomic. For instance, to prepare for a configuration change, one > > might create a change object in the protocol, store all changes in > > that object, and then commit that set of changes atomically. Then > > have one return value: the whole set either succeeds or fails. > > > > I guess you could look for inspiration in the DRM atomic mode > > setting API. I don't know how the RandR X11 protocol works, if that > > would be a good example also. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] FreeRds backend, simplifications and improvements take 2
Le 26/02/2014 19:14, Mariusz Ceier a écrit : Hi, I did some basic testing of this version, and it seems to be as stable as x11-backend :) Issues that still aren't resolved: - when trying to enter polish letter they send either ^C or characters from different keymap(?), depending on client used. But this may not be issue in freerds backend of weston, but in FreeRDS or FreeRDP. - focus never changes (at least it's not indicated visually which window has focus), to reproduce: run 2 instances of weston-terminal and see that cursor block isn't filled in, and title bar doesn't change, when switching between windows. Other than that, it works great :) Hi Mariusz, for a fair comparison with the x11-backend, you have to run it with the pixman mode. We have discussed that on IRC: the pixman renderer is missing the opacity management so you're loosing some nice effects. Exposé effect is really ugly, and at connection you don't have the nice fade-in. For keyboards this needs inquiry, I know that it works perfectly fine at least with French and German keyboards. Regards. -- David FORT website: http://www.hardening-consulting.com/ ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 0/6] Add weston randr protocol
Le 27/02/2014 04:27, Quanxian Wang a écrit : These patches will provide weston randr protocol, its implementation and randr application. The idea is from xrandr provided by xserver. *Dynamic* mode setting is the main objective of this protocol. Remember, it is one shot operation. For example, if setting the mode, just call one request wl_randr_set_mode without any other operation. With this protocol, weston-wrandr application is developped to help user implement randr protocol in command line just like xrandr command in xserver. Hi Quanxian, I have submitted such functionality one year ago: http://lists.freedesktop.org/archives/wayland-devel/2013-March/007872.html. The scope was smaller (targeting essentially mode resolution) but it was working. At the time there were no real enthusiasm, some people were even against. Perhaps some have changed their mind since. Regards. -- David FORT website: http://www.hardening-consulting.com/ ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [PATCH 1/6] Add weston randr protocol
-Original Message- From: Pekka Paalanen [mailto:ppaala...@gmail.com] Sent: Thursday, February 27, 2014 4:36 PM To: Wang, Quanxian Cc: wayland-devel@lists.freedesktop.org; Zhang, Xiong Y Subject: Re: [PATCH 1/6] Add weston randr protocol On Thu, 27 Feb 2014 08:06:23 + "Wang, Quanxian" wrote: > > > -Original Message- > From: Pekka Paalanen [mailto:ppaala...@gmail.com] > Sent: Thursday, February 27, 2014 3:28 PM > To: Wang, Quanxian > Cc: wayland-devel@lists.freedesktop.org; Zhang, Xiong Y > Subject: Re: [PATCH 1/6] Add weston randr protocol > > On Thu, 27 Feb 2014 11:28:00 +0800 > Quanxian Wang wrote: > > > Weston protocol wrandr will provide interface to > > 1) set output mode > > 2) set output transform > > 3) move output to relative position > > 4) provide disconnected display port information > > > > *Dynamic* mode setting is the main objective of this protocol. > > Remember, it is one shot operation. For example, if setting the > > mode, just call one request wl_randr_set_mode without any other > > operation. > > Hi, > > like I said in my other reply, this is a configuration interface, not > something for all applications to use. Protocol comments below > assuming, that this will be a configuration interface and that the > generic idea is acceptable. > > > Signed-off-by: Quanxian Wang > > Reviewed-by: Zhang, Xiong Y > > --- > > protocol/Makefile.am | 1 + > > protocol/randr.xml | 151 > > +++ 2 files > > changed, 152 insertions(+) create mode 100644 protocol/randr.xml > > > > diff --git a/protocol/Makefile.am b/protocol/Makefile.am index > > 5e331a7..df2e070 100644 > > --- a/protocol/Makefile.am > > +++ b/protocol/Makefile.am > > @@ -5,6 +5,7 @@ protocol_sources = \ > > text.xml\ > > input-method.xml\ > > workspaces.xml \ > > + randr.xml \ > > text-cursor-position.xml\ > > wayland-test.xml\ > > xdg-shell.xml \ > > diff --git a/protocol/randr.xml b/protocol/randr.xml new file mode > > 100644 index 000..f15e87a > > --- /dev/null > > +++ b/protocol/randr.xml > > @@ -0,0 +1,151 @@ > > + > > + > > + > > +Copyright (c) 2012-2013 Collabora, Ltd. > > Fix this. > > > + > > +Permission to use, copy, modify, distribute, and sell this > > +software and its documentation for any purpose is hereby > > granted > > +without fee, provided that the above copyright notice appear in > > +all copies and that both that copyright notice and this > > permission > > +notice appear in supporting documentation, and that the name of > > +the copyright holders not be used in advertising or publicity > > +pertaining to distribution of the software without specific, > > +written prior permission. The copyright holders make no > > +representations about the suitability of this software for any > > +purpose. It is provided "as is" without express or implied > > +warranty. > > + > > +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO > > THIS > > +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY > > AND > > +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR > > ANY > > +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > > +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, > > WHETHER IN > > +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, > > +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF > > +THIS SOFTWARE. > > + > > + > > + > > + > > + The global interface exposing randr capabilities. > > + As a wl_randr, that provides the interfaces for apps to more > > operations > > + on output. > > + > > + The aim of wl_randr is to get modes list, choose preferred > > mode, > > + layout the output including position, rotate, and en/disable. > > + The idea is from xrandr protocoal of xserver. It is very > > convenient for > > + weston/wayland user to operates on mode setting of output. > > + > > + > > + > > + > + summary="the to-be wl_randr is invalid"/> > > + > > + > > + > > + > > + Informs the server that the client will not be using this > > + protocol object anymore. This does not affect any other > > + objects, wl_randr objects included. > > + > > + > > + > > + > > + > > + set the mode of output > > + > > + > + summary="the output object"/> > > + > > + > > + > > + > > Since you require a wl_output, there does not seem to be a way to > force a disconnected output on? Should there be? Why else would you > need a way to list disconnected outputs? [Wang, Quanxian] list > disconnected outputs, just let user
Re: [PATCH 1/6] Add weston randr protocol
On Thu, 27 Feb 2014 08:06:23 + "Wang, Quanxian" wrote: > > > -Original Message- > From: Pekka Paalanen [mailto:ppaala...@gmail.com] > Sent: Thursday, February 27, 2014 3:28 PM > To: Wang, Quanxian > Cc: wayland-devel@lists.freedesktop.org; Zhang, Xiong Y > Subject: Re: [PATCH 1/6] Add weston randr protocol > > On Thu, 27 Feb 2014 11:28:00 +0800 > Quanxian Wang wrote: > > > Weston protocol wrandr will provide interface to > > 1) set output mode > > 2) set output transform > > 3) move output to relative position > > 4) provide disconnected display port information > > > > *Dynamic* mode setting is the main objective of this protocol. > > Remember, it is one shot operation. For example, if setting the > > mode, just call one request wl_randr_set_mode without any other > > operation. > > Hi, > > like I said in my other reply, this is a configuration interface, not > something for all applications to use. Protocol comments below > assuming, that this will be a configuration interface and that the > generic idea is acceptable. > > > Signed-off-by: Quanxian Wang > > Reviewed-by: Zhang, Xiong Y > > --- > > protocol/Makefile.am | 1 + > > protocol/randr.xml | 151 > > +++ 2 files > > changed, 152 insertions(+) create mode 100644 protocol/randr.xml > > > > diff --git a/protocol/Makefile.am b/protocol/Makefile.am index > > 5e331a7..df2e070 100644 > > --- a/protocol/Makefile.am > > +++ b/protocol/Makefile.am > > @@ -5,6 +5,7 @@ protocol_sources = \ > > text.xml\ > > input-method.xml\ > > workspaces.xml \ > > + randr.xml \ > > text-cursor-position.xml\ > > wayland-test.xml\ > > xdg-shell.xml \ > > diff --git a/protocol/randr.xml b/protocol/randr.xml new file mode > > 100644 index 000..f15e87a > > --- /dev/null > > +++ b/protocol/randr.xml > > @@ -0,0 +1,151 @@ > > + > > + > > + > > +Copyright (c) 2012-2013 Collabora, Ltd. > > Fix this. > > > + > > +Permission to use, copy, modify, distribute, and sell this > > +software and its documentation for any purpose is hereby > > granted > > +without fee, provided that the above copyright notice appear in > > +all copies and that both that copyright notice and this > > permission > > +notice appear in supporting documentation, and that the name of > > +the copyright holders not be used in advertising or publicity > > +pertaining to distribution of the software without specific, > > +written prior permission. The copyright holders make no > > +representations about the suitability of this software for any > > +purpose. It is provided "as is" without express or implied > > +warranty. > > + > > +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO > > THIS > > +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY > > AND > > +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR > > ANY > > +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > > +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, > > WHETHER IN > > +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, > > +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF > > +THIS SOFTWARE. > > + > > + > > + > > + > > + The global interface exposing randr capabilities. > > + As a wl_randr, that provides the interfaces for apps to more > > operations > > + on output. > > + > > + The aim of wl_randr is to get modes list, choose preferred > > mode, > > + layout the output including position, rotate, and en/disable. > > + The idea is from xrandr protocoal of xserver. It is very > > convenient for > > + weston/wayland user to operates on mode setting of output. > > + > > + > > + > > + > + summary="the to-be wl_randr is invalid"/> > > + > > + > > + > > + > > + Informs the server that the client will not be using this > > + protocol object anymore. This does not affect any other > > + objects, wl_randr objects included. > > + > > + > > + > > + > > + > > + set the mode of output > > + > > + > + summary="the output object"/> > > + > > + > > + > > + > > Since you require a wl_output, there does not seem to be a way to > force a disconnected output on? Should there be? Why else would you > need a way to list disconnected outputs? [Wang, Quanxian] list > disconnected outputs, just let user get to know the status of display > port in this current machine. Who are connected, who are not > connected. > > Should there be a way to force a connected output off? > > What about detailed mode timings? Should the client be allowed to use > e.g. CV
RE: [PATCH 1/6] Add weston randr protocol
-Original Message- From: Pekka Paalanen [mailto:ppaala...@gmail.com] Sent: Thursday, February 27, 2014 3:28 PM To: Wang, Quanxian Cc: wayland-devel@lists.freedesktop.org; Zhang, Xiong Y Subject: Re: [PATCH 1/6] Add weston randr protocol On Thu, 27 Feb 2014 11:28:00 +0800 Quanxian Wang wrote: > Weston protocol wrandr will provide interface to > 1) set output mode > 2) set output transform > 3) move output to relative position > 4) provide disconnected display port information > > *Dynamic* mode setting is the main objective of this protocol. > Remember, it is one shot operation. For example, if setting the mode, > just call one request wl_randr_set_mode without any other operation. Hi, like I said in my other reply, this is a configuration interface, not something for all applications to use. Protocol comments below assuming, that this will be a configuration interface and that the generic idea is acceptable. > Signed-off-by: Quanxian Wang > Reviewed-by: Zhang, Xiong Y > --- > protocol/Makefile.am | 1 + > protocol/randr.xml | 151 > +++ > 2 files changed, 152 insertions(+) > create mode 100644 protocol/randr.xml > > diff --git a/protocol/Makefile.am b/protocol/Makefile.am index > 5e331a7..df2e070 100644 > --- a/protocol/Makefile.am > +++ b/protocol/Makefile.am > @@ -5,6 +5,7 @@ protocol_sources =\ > text.xml\ > input-method.xml\ > workspaces.xml \ > + randr.xml \ > text-cursor-position.xml\ > wayland-test.xml\ > xdg-shell.xml \ > diff --git a/protocol/randr.xml b/protocol/randr.xml new file mode > 100644 index 000..f15e87a > --- /dev/null > +++ b/protocol/randr.xml > @@ -0,0 +1,151 @@ > + > + > + > +Copyright (c) 2012-2013 Collabora, Ltd. Fix this. > + > +Permission to use, copy, modify, distribute, and sell this > +software and its documentation for any purpose is hereby granted > +without fee, provided that the above copyright notice appear in > +all copies and that both that copyright notice and this permission > +notice appear in supporting documentation, and that the name of > +the copyright holders not be used in advertising or publicity > +pertaining to distribution of the software without specific, > +written prior permission. The copyright holders make no > +representations about the suitability of this software for any > +purpose. It is provided "as is" without express or implied > +warranty. > + > +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS > +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND > +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY > +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN > +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, > +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF > +THIS SOFTWARE. > + > + > + > + > + The global interface exposing randr capabilities. > + As a wl_randr, that provides the interfaces for apps to more operations > + on output. > + > + The aim of wl_randr is to get modes list, choose preferred mode, > + layout the output including position, rotate, and en/disable. > + The idea is from xrandr protocoal of xserver. It is very convenient for > + weston/wayland user to operates on mode setting of output. > + > + > + > + + summary="the to-be wl_randr is invalid"/> > + > + > + > + > + Informs the server that the client will not be using this > + protocol object anymore. This does not affect any other > + objects, wl_randr objects included. > + > + > + > + > + > + set the mode of output > + > + + summary="the output object"/> > + > + > + > + Since you require a wl_output, there does not seem to be a way to force a disconnected output on? Should there be? Why else would you need a way to list disconnected outputs? [Wang, Quanxian] list disconnected outputs, just let user get to know the status of display port in this current machine. Who are connected, who are not connected. Should there be a way to force a connected output off? What about detailed mode timings? Should the client be allowed to use e.g. CVT or GTF formulae to invent completely new modes that the hardware might support? [Wang, Quanxian] wl_out or mode will be firstly be available in compositor. Otherwise, this interface will not allow that. We will check the parameter to make sure if user sets it rightly or under the control. > + > + > + > + s
