Re: Comment on global shortcuts security
On 09/30/2012 01:35 AM, Pekka Paalanen wrote: On Wed, 26 Sep 2012 08:21:44 +0200 Daniel wrote: El dt 25 de 09 de 2012 a les 11:15 -0400, en/na Kristian Høgsberg va escriure: On Mon, Sep 24, 2012 at 04:53:20PM -0700, Bill Spitzak wrote: Keystrokes should be sent to the application first. Only if the application refuses them should they be considered global shortcuts. No. Could you elaborate a little bit the logic leading to this decission, please? It is a roundtrip, which is already bad in itself. All the normal keystorkes that a client handles are a roundtrip, so I really can't see this being a problem. I certainly agree with Wayland's design that once a client decides to change it's display, that it be able to do that with no further roundtrips. But that is different than event handling. Furthermore, it allows clients override global shortcuts of the compositor, which means that it would be impossible to have secure shortcuts, e.g. "kill this client" or "switch sessions". There certainly would still be "secure shortcuts" like you describe. These are identifiable to the user as "you hold down lots of strange shift keys". For instance ctrl+alt+del. The reason "lots of strange shift keys" are needed is to avoid breaking applications by blocking a keystroke the application designer thought was available. My main concern is that we don't have to make *ALL* shortcuts "lots of strange shift keys". The type of shortcuts I think me and Daniel are worrying about is the volume buttons. I would like hitting the volume button to change the volume in the current app that has focus, and only change the global volume if that app does not have a local control. Third, if the client hangs, it would mean global shortcuts would stop working, and you could not e.g. alt-tab away from a frozen window, which might be even fullscreen. There would be a timeout, same as being suggested for the window drag controls, after which the shell acts as though the client ignored the keystroke. It would also mean, that every application would need additional code to cooperate with the compositor. Missing that code would by default stop all global shortcuts from working. Programmers would have to spend effort to not break the *whole* desktop, instead of just having their app working right with the desktop by no effort. This just requires toolkits to require a "I used the key" return value from keystroke handlers. The amount of work for a programmer to support that is trivial (they are likely calling several functions that already return this information), and failure of the programmer to do this will result in obvious bad behavior of the application (such as breaking Tab navigation) even if there are no global shortcuts. You might invent elaborate schemes to overcome the latter cons, but even the roundtrip argument alone is a serious one, and there would have to be a serious benefit in doing so. This would just bring a lot more problems than it would solve. I'm worried that a "shortcut registry" will add enormous complexity and bugs and make it difficult for programmers to get the behavior they want. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Gamma correct rendering with Wayland and Weston
On 09/29/2012 01:28 AM, John Kåre Alsaker wrote: Wayland also does scaling and rotations but the difference between linear and srgb is much smaller for these. I think the real solution for this is to allow clients to know the actual transform of their surfaces to the screen and be allowed to draw the transformed image, since this will avoid resampling and filtering, as well as letting the clients choose the color space. Part of the point of Wayland is that clients shouldn't know about how they are placed or transformed, even if they did, the compositor would still have to compose them and know about the gamma encoding they use. Clients certainly should not *have* to know about the transformation, and the shell will transform for them. However, even thought there is a deliberate attempt to make clients not know it in current Wayland, I think client awareness of the transform is going to be needed eventually. Lots of clients could draw their transformed windows enormously faster and higher quality than then if they drew the non-transformed one and the shell then transformed the image. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Gamma correct rendering with Wayland and Weston
On 09/29/2012 01:28 AM, John Kåre Alsaker wrote: You seemed to have gotten the impression that I suggested we blend each surface in either sRGB or linear depending on it's encoding. That's not what I was suggesting. The compositor won't pick it's blending gamma space per surface. It's either completely linear or sRGB. So all clients with the same alpha values (and colors) will look equal independent of their gamma encoding. We should probably expose the blending gamma space, so clients have a chance to adjust their translucent parts, even if most of them will ignore it. Actually what you say is EXACTLY what I was suggesting. If all the clients have identical-looking shadows, it is because they all wrote the same numerical values to their images in the shadow area. Even if they use different compositing rules for the opaque regions. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Gamma correct rendering with Wayland and Weston
Can we have a tool like 'xgamma' now? On Sun, Sep 30, 2012 at 4:10 PM, Kai-Uwe Behrmann wrote: > In reply to John Kåre Alsaker Fri Sep 28 08:52:17 PDT 2012 > >> - srgb: >> Rendering in linear gamma: >> If the hardware supports sRGB textures: >> EGL: Use sRGB textures and present it as linear >> gamma to shaders. >> If the hardware doesn't support sRGB textures: >> Shader: Convert from sRGB to linear gamma. >> - rgb: >> Rendering in sRGB gamma: >> Shader: Convert from linear to sRGB gamma. > > > "sRGB textures" implies supporting the sRGB colour space on textures. > Is such a texture meant to tell the display system to do final colour > conversion from sRGB to monitor colour space? Are non sRGB colour spaces > still possible like CIE*XYZ or LStar-RGB.icc for "sRGB textures"? > > However you write only about gamma. That is confusing. > sRGB is defined with colour primaries inside the CIE*XYZ space + gamma > encoding, that is what you appear to be referring to, and exact viewing > conditions [1]. Gamma is only one part of the sRGB standard. If you realy > refere to just gamma, then your functions can not be standard compliant and > logical you should avoid sRGB or make clear that you only refere to a subset > of that standard. The term "sRGB texture" would be highly inappropriate for > gamma encoding. > > Gamma, including the sRGB gamma flavor, belongs to a logical layer called > gamma correction [2]. On the opposite, colour management needs proper > knowledge of the used gamma, in order to work properly. > > kind regards > Kai-Uwe Behrmann > -- > developing for colour management www.behrmann.name + www.oyranos.org > > [1] http://en.wikipedia.org/wiki/SRGB > [2] http://en.wikipedia.org/wiki/Gamma_correction > > ___ > 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: Gamma correct rendering with Wayland and Weston
In reply to John Kåre Alsaker Fri Sep 28 08:52:17 PDT 2012 - srgb: Rendering in linear gamma: If the hardware supports sRGB textures: EGL: Use sRGB textures and present it as linear gamma to shaders. If the hardware doesn't support sRGB textures: Shader: Convert from sRGB to linear gamma. - rgb: Rendering in sRGB gamma: Shader: Convert from linear to sRGB gamma. "sRGB textures" implies supporting the sRGB colour space on textures. Is such a texture meant to tell the display system to do final colour conversion from sRGB to monitor colour space? Are non sRGB colour spaces still possible like CIE*XYZ or LStar-RGB.icc for "sRGB textures"? However you write only about gamma. That is confusing. sRGB is defined with colour primaries inside the CIE*XYZ space + gamma encoding, that is what you appear to be referring to, and exact viewing conditions [1]. Gamma is only one part of the sRGB standard. If you realy refere to just gamma, then your functions can not be standard compliant and logical you should avoid sRGB or make clear that you only refere to a subset of that standard. The term "sRGB texture" would be highly inappropriate for gamma encoding. Gamma, including the sRGB gamma flavor, belongs to a logical layer called gamma correction [2]. On the opposite, colour management needs proper knowledge of the used gamma, in order to work properly. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org [1] http://en.wikipedia.org/wiki/SRGB [2] http://en.wikipedia.org/wiki/Gamma_correction ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Comment on global shortcuts security
On Wed, 26 Sep 2012 09:14:15 +0300 Pekka Paalanen wrote: > On Tue, 25 Sep 2012 18:07:51 +0200 > Piotr Rak wrote: > > > Hi, > > > > 2012/9/25 Pekka Paalanen : > > > Hi Piotr, > > > > > > it sounds like you make a fundamental assumption on something, that > > > makes global shortcuts insecure, and so you set out to solve these > > > problems. > > > > > > What is it that you assume? > > > What is the root of the problems? > > > What are the problems you are trying to solve? > > > > > > > I should have state this more clearly, but the problem is - how to do > > global shortcuts in application in secure way. The issue was raised > > during XDC. Video of talk can be watched online > > http://www.youtube.com/watch?v=hJpiJii44oo&feature=relmfu - discussion > > about wayland input handling starts around 23:30s. > > > > Those are my thoughts/comments after watching it, on one questions > > that was left open there. > > > > > Sorry, but I just couldn't understand anything you wrote. > > > > Hope that explaination is sufficient. > > Ok, thank you for the pointer. :-) > I'll listen that through when I find a suitable time. > > My first thought would of course be to define protocol extensions on > case-by-case basis: mixer controls, playback controls, etc, and allow > only one client to subscribe to an interface at a time, per seat. > Anything outside of those would be server configuration for misc > hotkeys. But I guess these were already raised in the talks, so I > really better listen to those first. Hi Piotr! I have now watched the XDC video on the graphics stack security. Everyone seems to assume, that there would be a generic interface to register all kinds of global shortcuts, and no-one brought up any different ideas. The semantic approach suggested was quite near, though, but not really tailored to Wayland (how could it be, yet). I also realised, that there likely are lots of use cases for global shortcuts that I cannot even imagine. That undermines my personal proposal above, but I still stick to it. Defining case by case protocol extensions is very close to the semantic approach, if I understood right. I would divide keys into functional categories, that you could subscribe to by simply binding to a specific Wayland protocol interface, per seat. Two examples of such interfaces would be the above mentioned mixer controls, and playback controls. Each corresponds to a set of keys. Such interfaces could be used by zero or one client at a time. If an interface is already taken, the client just receives a "no, cannot give you that". If an interface is bound, those keys are never sent anywhere else. If it is not bound, you could send them to the client in kbd focus, or not, whatever makes sense. A catch-all misc global shortcuts mechanism would be the server configuration, which is not exposed to normal clients at all. There you could assign things like WWW-key for browser, since those typically launch a new application anyway. Note, that window management global shortcuts would not use either of these mechanisms. Since the window manager is *in* the server, it can hook into the key-combos directly. The above idea is very simple, and I believe should avoid most security concerns, but I also fear it is not enough for some use cases I don't know about. I am knowingly ignoring any possibility for a normal client to bind a global shotcut like "AltGr+a" on its own will. So, take this as just food for thought on what could be done. I hope this could replace the "printable key combination" and other complex heuristics with a much simpler scheme, since you do not need a single generic interface for all ever imaginable shortcuts. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Comment on global shortcuts security
On Wed, 26 Sep 2012 08:21:44 +0200 Daniel wrote: > El dt 25 de 09 de 2012 a les 11:15 -0400, en/na Kristian Høgsberg va > escriure: > > On Mon, Sep 24, 2012 at 04:53:20PM -0700, Bill Spitzak wrote: > > > Keystrokes should be sent to the application first. Only if the > > > application refuses them should they be considered global shortcuts. > > > > No. > > Could you elaborate a little bit the logic leading to this decission, > please? It is a roundtrip, which is already bad in itself. Furthermore, it allows clients override global shortcuts of the compositor, which means that it would be impossible to have secure shortcuts, e.g. "kill this client" or "switch sessions". Third, if the client hangs, it would mean global shortcuts would stop working, and you could not e.g. alt-tab away from a frozen window, which might be even fullscreen. It would also mean, that every application would need additional code to cooperate with the compositor. Missing that code would by default stop all global shortcuts from working. Programmers would have to spend effort to not break the *whole* desktop, instead of just having their app working right with the desktop by no effort. You might invent elaborate schemes to overcome the latter cons, but even the roundtrip argument alone is a serious one, and there would have to be a serious benefit in doing so. This would just bring a lot more problems than it would solve. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
