Re: Window positioning
On Wed, 3 Jan 2018 01:37:08 + "Han, Guowei" said: > Thanks Jasper. Do u know if there's a demo i can learn from? Currently i am > creating a bigger surface bigger than screen size. and make subsurface so i > can posion them as i want. Really don't think its a good way to do it. that is the intended design. it's a very good thing not allowing clients to arbitrarily position themselves on a screen. a very good idea. wayland has gotten it right here (and ivi-shell i think is just being wrong and not understanding the mountain of history behind such a decision to disallow manual explicit positioning). > Sent from my iPhone > > On Jan 2, 2018, at 4:25 PM, Jasper St. Pierre > mailto:jstpie...@mecheye.net>> wrote: > > *EXTERNAL EMAIL* > > Hi Han, > > You cannot position surfaces absolutely using the traditional xdg-shell > protocol. However, for embedded cases, there are protocols like ivi-shell > which provide that functionality. > > On Fri, Dec 29, 2017 at 10:09 AM, Han, Guowei > mailto:guowei@johnsonoutdoors.com>> > wrote: Hi, > > Wonder if there’s a way we can position window to anywhere we want using > wayland or maybe weston? > > Thanks, > > The information in this email and any attachments may contain proprietary and > confidential information that is intended for the addressee(s) only. If you > are not the intended recipient, you are hereby notified that any disclosure, > copying, distribution, retention or use of the contents of this information > is prohibited. If you have received this email in error, please immediately > contact the sender and delete the email. > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org<mailto:wayland-devel@lists.freedesktop.org> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > > > -- > Jasper -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Window positioning
On Wed, 3 Jan 2018 13:23:49 + "Han, Guowei" said: > We are running a multi process application. And GUI is act as a transparent > top layer. All other process rendering by them self underneath. So its > important for other process to place the window at right potion. Then you want to probably use process to process buffer sharing (e.g. like a nested wayland compositor), and maybe subsurfaces. Then you have a main process that acts as a gateway for other processes and their buffers and input etc. and this process manages your policies within its window and relative positioning space. Never rely on the system compositor for this. What if the system compositor didn't have a rectangular screen but displays on a globe? Or a hemisphere? Or it wrapped the display around a 3d bunny rabbit? What if it was a compositor for a mobile-like UI where it decided every app window is to be "fullscreen" and mutually exclusive to other apps, displaying only 1 at a time? Relying on and demanding global positioning files in the face of implementing man common UI policies you see today across many devices. Wayland (and xdg-shell) are designed to be as agnostic as possible to the final display policy and thus limit things like positioning to only be subsurface based (relative to main surface). > Sent from my iPhone > > On Jan 3, 2018, at 2:58 AM, Kai-Uwe > mailto:ku.b-l...@gmx.de>> wrote: > > > Maybe you are after a full screen application then. With that you should be > able to decide about the positioning on the whole output. > > Am 03.01.2018 um 02:37 schrieb Han, Guowei: > Thanks Jasper. Do u know if there's a demo i can learn from? Currently i am > creating a bigger surface bigger than screen size. and make subsurface so i > can posion them as i want. Really don't think its a good way to do it. > > Sent from my iPhone > > On Jan 2, 2018, at 4:25 PM, Jasper St. Pierre > mailto:jstpie...@mecheye.net>> wrote: > > *EXTERNAL EMAIL* > > Hi Han, > > You cannot position surfaces absolutely using the traditional xdg-shell > protocol. However, for embedded cases, there are protocols like ivi-shell > which provide that functionality. > > On Fri, Dec 29, 2017 at 10:09 AM, Han, Guowei > mailto:guowei@johnsonoutdoors.com>> > wrote: Hi, > > Wonder if there’s a way we can position window to anywhere we want using > wayland or maybe weston? > > Thanks, > > The information in this email and any attachments may contain proprietary and > confidential information that is intended for the addressee(s) only. If you > are not the intended recipient, you are hereby notified that any disclosure, > copying, distribution, retention or use of the contents of this information > is prohibited. If you have received this email in error, please immediately > contact the sender and delete the email. > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org<mailto:wayland-devel@lists.freedesktop.org> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > > > -- > Jasper > > > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org<mailto:wayland-devel@lists.freedesktop.org> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: HDR support in Wayland/Weston
On Wed, 6 Mar 2019 16:37:55 +1100 Graeme Gill said: > Carsten Haitzler (The Rasterman) wrote: > > apps should not have exclusive access. we're re-doing the whole horrid > > "install colormap" thing from the x days of 256 color (or > > paletted/colormapped displays). > > It's not quite the same thing in all cases. it involves a screen or set of screens "flashing" between different colorspaces. it's much the same kind of effect of ye olde colormap installs. not as extreme, but still the entire screen content changing appearance as one client is taking control. > A game doing this - yes, it's setting it up just for its > private use. a game should not either. it's a window (surface) within a larger ecosystem and doesn't own the display. the compositor's job is to ensure that everyone plays nice together and to ensure the user has as seamless an experience as possible. the client can provide colorspace info/lut's alongside a surface/buffer and then leave it up to the compositor to implement it or not (alongside perhaps the ability to query for such extended features if they exist in the compsitor at all - this is a question though of what is the baseline featureset we expect from compositors) but it shouldn't CONTROL the output (via any explicit or implicit protocol and specs). if the compositor chooses to remap everything on screen so that the appearance remains constant based on the focused surface (surface A with colorspace X and other surfaces with colorspace Y it can transform to a single colrospace based on what the screen is configured to display at the time to provide visually a constant experience if possible). for the purposes of calibration, imho a calibration tool should just use drm/kms directly and run in a console outside of wayland. it then owns the display. it's not like it's a commonly used tool (likely once on purchase of a gpu and/or a monitor). it shouldn't even be needed for pre-calibrated monitors. it can calibrate alongside appropriate colorimeter tools and work out some profile screen by screen to be given to the compositor in a standard well documented format. the compositor then can use that profile to know the true color output of that screen and can appropriately adjust content. > Color calibration or "blue light filter" not really - they > are using it as a mechanism for deliberately altering > the color of the whole display so that it affects the appearance > of all other applications. blue light filter is a "compositor problem". it may or may not farm it off to a client but it's not something that should be allowed by clients in general - these are at best speciality clients that work closely with a compositor, or more likely something compositor specific via whatever extension mechanisms that compositor supports. implementing any such protocol for clients is just going back in time to clients messing with key repeat and users wondering why their key repeat is now broken as the client doesn't do it right or colormap installs forcibly being done by clients, or clients messing with screensaver params to try force it to turn off then users complaining that screen blanking is broken and it ends up being some random client they didn't know about, or the screen resolution changing and multi-monitor config being nuked because some dumb client decided to use xf86vidmode to change screen res not knowing that people might have multiple screens configured via xinerama or xrandr and then not even bothering to restore things afterwards either. i've seen many of the outcomes and problems of giving clients direct control over the screen over my decades in x11, and it's a bad thing. we shouldn't repeat the same mistakes. once you open up these doors, they are impossible to close because you now need them for compatibility. > Whether the latter two are in conflict is an interesting question. > > For the purposes of getting a known color behavior they are > in conflict. But then they could also co-operate :- the > "blue light filter" could make use of color management > to implement a specific transform, and do it in such a way > that the white point relative color behavior remains unchanged. > > Cheers, > Graeme Gill. > > _______ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Best practices for client side buffer management
On Mon, 22 Jun 2020 11:46:41 +0300 Pekka Paalanen said: > On Fri, 19 Jun 2020 11:21:34 +0100 > Carsten Haitzler (The Rasterman) wrote: > > > On Fri, 19 Jun 2020 13:24:12 +1000 Brad Robinson > > said: > > > > > Hi All, > > > > > > I'm fairly new to Wayland and Linux GUI programming in general, but doing > > > some experiments to figure out how to integrate it into my custom UI > > > toolkit library and have a couple of questions about client side buffer > > > management. > > > > > > Firstly, this is how I'm allocating the backing memory for client side > > > buffer pools. This is C# p-invoking to libc, and basically it's using > > > mkstemp() to get a temp file, ftruncate() to set its length, mmap() to map > > > it and then unlink() once mapped so temp files aren't left behind. Any > > > issues with this approach? > > > > > > // Get temp file > > > var sb = new > > > StringBuilder(System.IO.Path.Join(System.IO.Path.GetTempPath(), > > > "mmXX")); > > > int fd = mkstemp(sb); > > > ftruncate(fd, (ulong)capacity); > > > > i assume GetTempPath() will be looking at /tmp ... and /tmp may not be a > > ramdisk. it may be a real disk... in which case your buffers may be getting > > written to an actual disk. don't use /tmp. > > Hi, > > that's true. The trick we have been using is create the file in > $XDG_RUNTIME_DIR which is practically always a tmpfs, but OTOH it might > not be the best place to store large pixel buffers. correct. also just opening files in /dev/shm ... but shm_open acts as a portable front-end to that. > > you might wan to to loop at shm_open or memfd > > Right. > > > or libdrm for specific drivr > > allocation calls like drm_intel_bo_alloc_tiled, drm_intel_bo_map/unmap etc. > > the > > No, please do not do that! > > That will make your program specific to a certain hardware driver, > which makes it specific to that hardware. Plus, you will have to learn how > to program specifically for that driver. It's not worth it. we do... but we also have other paths to alloc memory so this is a "if on intel and that works, then use this". also have one for vc4... :) it certainly should not be the only method :) > The wl_shm Wayland interface is for software rendering anyway. No-one > expects a wl_shm-based buffer to be directly usable by a display or a > GPU driver, it will always be copied by a compositor. So trying to > shove "hardware buffers" through wl_shm is only picking the worst of > all options, as direct CPU access to them is often sub-optimal, perhaps > even prohibitively slow. oh this wont be for wl-shm ... :) sorry. i didn't mention that. > > latter libdrm ones wo9uld allow your buffers to possibly be scanned out > > directly to the screen or used as textures directly without copies, but will > > need careful handling, so do this only as an advanced step. > > If you want to use hardware acceleration or allow direct scanout, use > the proper APIs intended for them: GBM, EGL, Vulkan; if you need to > pass hardware buffers manually through Wayland, use zwp_linux_dmabuf_v1 > extension instead of wl_shm. yeah. we use linux-dmabuf protocol with these intel and vc4 buffers, not wl_shm. :) > > > > > // Map it > > > var addr = mmap(IntPtr.Zero, (ulong)capacity, Prot.Read | > > > Prot.Write, Map.Shared, fd, 0); > > > > > > // Unlink it (so temp files not left behind) > > > unlink(sb.ToString()); > > > > > > Secondly I'm wondering about practical strategies for managing client side > > > buffers. The toolkit in question basically needs arbitrarily sized > > > buffers to render whatever size the window happens to be. Seems like to > > > use a buffer pool for this would require some sort of heap manager to > > > manage what's in each pool. I'm wondering if there's any recommendations > > > or best practices for how to deal with this. eg: create one big pool and > > > explicitly manage what's in there as a heap, use lots of little pools with > > > one buffer in each, a combination of both, something else? > > > > resizes of windows are less common (in general) than rendering to them. here > > i'd go for a scheme of N buffers in a ring per window. so you have buffers > > A, B, C and you first render to A then display it, then next frame B, then > > C, then A, then B, t
Re: Best practices for client side buffer management
On Wed, 24 Jun 2020 14:28:18 +0300 Pekka Paalanen said: > On Wed, 24 Jun 2020 10:58:41 +0100 > Carsten Haitzler (The Rasterman) wrote: > > > you keep a sliding window of the last 2 frames with of rect regions you > > union (merge with) the current frame's update rects... then render that. > > you can play tricks like copy back some regions from a previous frame > > instead of re-rendering them (as it's a read from, not a write to that > > buffer it's safe.. > > Yes, copying from a busy buffer is safe. > > > but beware that readbacks may have issues especially if regions are not > > mapped as non-cachable because they are being scanned out/displayed for > > example. it depends on hardware entirely so the safe thing is to their > > shadow them and make a copy before you display or just re-render them. it > > turns out the just re-render is simpler to do and generally performant). > > You said you were going to cover only software-rendering, but here you > go. ;-) you can software render to hardware mappable buffers... quite common if you have a system with no GPU - just a simple display processor with a single fraembuffer output or maybe a few layers/sprites or perhaps just a 2d accel unit (blitter funtimes)... :) my point was more that you have explicit control over the ABC buffer ordering as opposed to going via gl (egl) where you don't have control and have to query and hope for sanity... :) > IOW, the caching thing applies to hardware buffers (some of which can > be written to by CPU). But a usual desktop application or a toolkit > should not use hardware buffers for software rendering. The performance > hit you refer to can also happen in the compositor! correct. so it depends on the situation, but also how to map the buffer at the time and other hardware constraints. i've had to beat some interesting hardware into shape before. if 99% of the time the compositor just displays a frame (assigns the buffer to a hw scanout) then the readback problem is not bad and only hits you sometimes. it's a whole ymmv and just something to know about if you are poking around in this world. :) -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Dual-head kiosk/embedded application
On Thu, 06 Aug 2020 09:02:49 +0200 Nicolas Jeker said: path a. > Hi All, > > I'm currently working on a solution to run two instances of a full > screen application on separate screens with separate touch screen > input. This is pretty easy if the application has Wayland support by > using a pair of wl_seats, one for each output and touch screen. Multi- > seat with X11 on a single graphics card is as far as I understand > impossible. > > Unfortunately, the application in question is written in WinForms and > is running through mono, which only has an X11 backend on Linux. > There's XWayland as a bridge to Wayland, but a mechanism for input > separation seems to be inexistent. I stumbled upon cage [1] in a > discussion from July on this list, but that has neither multiple output > support nor input separation. > > So I implemented a very rough Wayland backend for WinForms on mono as a > first POC, which works surprisingly well. It's software-only (wl_shm) > and abuses subsurfaces for widgets. So far I'm using weston as the > compositor. > > The long-term solution to this problem will be a rewrite of the > application with another GUI toolkit. I have three possible mid-term > solutions in mind, but I am unsure about how I should proceed and which > approach is the most reasonable. > > Solution a) is continuing to develop a Wayland backend for mono. This > would mean implementing proper buffer handling on the client side > instead of abusing subsurfaces. There was a discussion about client > side buffer management on this mailing list in June. My conclusion is > that it's possible, but not an easy task judged from my experience with > the X-centric backend abstraction in mono. > > Solution b) is trying to extend XWayland to support separate wl_seats. > My other concern is positioning the windows as this needs to be client- > driven, but if I'm not completely mistaken newer versions of weston > support that already. I already digged a bit into the XWayland source > and find it pretty hard to read, so I'm not sure how easy that is. This > will probably also lead to changes on the compositor side. > > Solution c) is implementing my own compositor on top of wlroots or > building upon something like cage. > > My thoughts are: > a) is somewhat time-consuming and will probably need many smaller bug > fixes later > b) is easier to get right but is harder for me to do because of my > unfamiliarity with and the readability of the X source code > c) is probably the most time consuming > > So, trying to formulate a question: What do you think is the best way > forward regarding maintainability, stability and time consumption? Did > I miss something? I'm very grateful for any hints in the right > direction. > > Thanks, > Nicolas > > [1]: https://github.com/Hjdskes/cage > > _______ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Rethinking the clipboard?
On Mon, 28 Dec 2020 14:51:26 -0500 Aaron Hillegass said: > I'm a Mac programmer who has been spending more and more time on Linux, and I > have become frustrated with the way clipboards work on Linux applications. > > As a proof-of-concept, I have been implementing a stand-alone clipboard > server and a client library for that server. The only dependency is the > sd-bus functions from libsystemd: https://github.com/hillegass/clipboard > > Has the idea of pulling clipboard functionality out of the window server been > considered by this group? Is someone else working on this problem? What is bad about it that it needs the entire ecosystem of apps, toolkits to adapt to a new protocol/API etc. ? Remember that moving an entire ecosystem is a mammoth job of getting buy-in from a critical mass of players - you cannot force it on them. The fact that Wayland has gotten to where it is now is quite an amazing job in this regard. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Buffer Damage
On Mon, 4 Jan 2021 15:05:12 +0200 Vlad Zahorodnii said: > On 1/4/21 2:48 PM, Simon Ser wrote: > > OK, this still doesn't explain which/how/why existing clients would > > benefit from the optimization, and how much performance will really > > improve in practice. > > > > This will benefit only the compositor. > > If buffer data is being uploaded to a texture asynchronously, you can't > use the texture since you are most likely going to see junk. Every > buffer must be attached to a separate texture. > > On the other hand, the surface damage cannot be used to decide what > parts of the texture must be updated because it doesn't include the area > of the buffer that got repaired. Either the client has to indicate the > buffer damage or the compositor has to determine it by itself, e.g. by > accumulating surface damages. Just accumulate surface damages over N frames (where N is based on the client using single/double/triple etc. buffering). It's good enough. Other solutions exist on the client side: Qt could move to a fully "GL/vulkan" accelerated rendering model for ye olde Qt widgets... if it wanted to. It'd be a chunk of work but it's possible. It'd have to implement everything on top of GL client-side with a layer there instead of software rendering. Qt could also do its own PBO/texture uploads client-side and then use GL just as a compositing step, doing these uploads async on the client-side. It also could use DMABUFs to render to in software (EFL does this with SW rendering if it can). Even if it's just a final "memcpy" from a tmp CPU-side memory buffer to the DMABUF to bypass any cache performance issues in the DMABUF. It would equate in the end to the same thing the compositor has to do, but client-side. So I see other possibly better solutions to this done client-side and for "everything else" the accumulation would be good enough IMHO. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: absolute positioning and other "missing features" of Wayland
On Mon, 22 Feb 2021 12:14:56 +0200 Pekka Paalanen said: > On Fri, 19 Feb 2021 11:46:56 -0800 > Dima Ryazanov wrote: > > > Most Wayland compositors support XWayland, and therefore, are ok with > > applications using absolute positioning > > Hi, > > I don't think that is exactly true. With rootless Xwayland (the usual > case), the Wayland compositor also takes the explicit role of the X11 > window manager through X11 protocol. This is even how X11 is intended > to work and not some backdoor. Therefore, the Wayland compositor is > still in full control of all window management, including positioning, > even if X11 exposes a global coordinate system to X11 applications that > the Wayland compositor needs to fake. Kind of true... but override-redirect windows will bypass that positioning control the WM has... it's common to abuse these for all sorts of fun and games. > If Wine could really benefit from some optional hand-holding, I think > it would be okay to have a Windows-specific interface to help fill the > gaps. It wouldn't be that different from what Wayland compositors need > to do today to support Xwayland; a foreign window system integration. I also would want to avoid baking explicit absolute positioning into wayland protocol - be it as a core agreed to add-on to xdg-shell or even a "commonly supported extension". What I'd like it some better solution. For example - if an app wants to absolute position a window because it's doing a custom "my own notification popup" much like Chrome and Firefox now like to do in X11, then I'd prefer this be explicitly exposed as a "notification surface with requested screen location hints" and so the compositor can decide to do something more intelligent with it. I am sure this list of use cases will probably be extensive and also depend on the API in wine that is being wrapped and intercepted - the higher level it is, the more it knows about the intended use case. > Even better if that's not necessary. > > > Thanks, > pq -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: absolute positioning and other "missing features" of Wayland
On Mon, 22 Feb 2021 12:10:08 +0100 Jonas Ådahl said: > On Mon, Feb 22, 2021 at 10:49:33AM +, Simon Ser wrote: > > On Monday, February 22nd, 2021 at 11:44 AM, Carsten Haitzler > > wrote: > > > > > I also would want to avoid baking explicit absolute positioning into > > > wayland protocol - be it as a core agreed to add-on to xdg-shell or even > > > a "commonly supported extension". What I'd like it some better solution. > > > For example - if an app wants to absolute position a window because it's > > > doing a custom "my own notification popup" much like Chrome and Firefox > > > now like to do in X11, then I'd prefer this be explicitly exposed as a > > > "notification surface with requested screen location hints" and so the > > > compositor can decide to do something more intelligent with it. I am sure > > > this list of use cases will probably be extensive and also depend on the > > > API in wine that is being wrapped and intercepted - the higher level it > > > is, the more it knows about the intended use case. > > > > I'd like to avoid making this general, if we go down this road. Make it > > specific to the win32 API and wine. Wayland-native toolkits don't need > > it. > > Sounds potentially not horrible in theory, but is it remotely possible? > There are these approaches I can think of: It's still open to abuse eventually for the wrong reasons no matter where it is. > * Add a "wl_win32" to wayland-protocols > > Adoption by anyone wanting to bypass the Wayland windowing model can use > it trivially, and we have a X11 like situation where everything grabs > everything and arbitrary client driven window self management. > > * Make "wine" distribute a "wl_win32.xml" and make compositors depend on >on wine-devel, implementing the protocol. > > Practically the same as above, just a 'cp ~/wine/protocols/wl-win32 > protocols' away, and we're back with wierd grabs and client managing > their own surfaces again. > > * A libwine-wayland, a wineBindWaylandDisplay() with some kind of half >assed authentication. > > I assume noone wants this (including me). But client developers would > have to be really obnoxious to work around it which might be enough to > not make it general. > > A "allow/deny" nag/query (aka "Do you want this application you > installed to work or want me to break it for you?") I wouldn't call a > reasonable option either. I think the nag is probably the way to go. Or specifically the compositor should ask once and remember the response (or have an option to never ask and always allow this if users so desire). > So, how would we make it not de-facto general? > > Not to meantion the head ache of letting clients in on configuring their > window positions when any kind of HiDPI scaling, fractional or nat, is > done. Indeed this is the problem as well as odd displays like circular ones as well. It opens the doors to clients making assumptions that may not be true given various methods a compositor might use to handle multiple screens with differing DPI/scaling etc. > > > > Notifications popups are part of the desktop environment and clients > > shouldn't try to display them directly. But they do. Give them an inch and they take a mile. :) > Agreed. > > > Jonas > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Keyboard issues w/Orca screen reader
On Wed, 24 Feb 2021 15:59:59 -0600 (CST) Mike Gorse said: > As part of the GNOME project, we have Orca. It is a screen reader that reads > what an application is displaying out loud, or sends it to a Braille display. > It allows a blind user to interact with GNOME. There are currently several > issues with Orca on Wayland, since it (and AT-SPI, the accessibility API that > it uses) were originally designed for X11, without regard to the kind of > security constraints that Wayland has. > > Traditionally, Orca has used what amounts to a key filter implemented by > AT-SPI. The toolkit (gtk, qt, etc) would make a dbus method call to AT-SPI > when a key is pressed, passing on the keycode, keysym, and text associated > with the key (Orca uses the latter to announce the key that was just > pressed). The AT-SPI registry daemon would make a method call to Orca, Orca > would return a boolean to indicate whether it consumed the key or not, and > AT-SPI would return the result to the toolkit. This is no longer supported by > gtk 4, so I am trying to solve things another way. There is a good amount of > discussion at https://gitlab.gnome.org/GNOME/gtk/-/issues/1739 In this case, your issue would be with gtk. It should still support this. In a wayland world, security-wise this would hand the decision to talk to orca via at-spi and if that app wants to leak input somewhere else - it is that app's decision. It can leak only a subset of keys too and selectively pass or don't pass depending on the situation (e.g. if entering text in a password field. the client can choose to not pass the key input to at-spi and instead maybe just pass some dummy key much like password entries display *** instead of the letters). The compositor does not need to be involved. This would IMHO be certainly the best way to do this. > Orca uses this key filter for a few things. It wants to announce the key that > the user just pressed. If the user presses the control key, then Orca will > stop reading whatever it is reading. It also implements commands in this way > (the user can press a key to have it read the current line, to give one > example). For X11, I can have AT-SPI/Orca watch for XI_KeyPress events and > call XIGrabKeycode when Orca wants to grab a key, but I'm struggling to > figure out what to do on Wayland. I think that I would need to propose a new > protocol or two, but I foresee security being a challenge/concern, so I'm > wondering if anyone has any advice in particular. Xwayland-keyboard-grab > looks like it would do part of what I need, if Orca ran as an xwayland > client, but it wouldn't help in terms of passing key press notifications on > to Orca for the purposes of key echoing and interrupting speech, unless a > grab was active for the particular key. If I enable my X11 code for Wayland, > then I don't see XI_KeyPress events for keys going to other applications, > which I think is expected given Wayland's security model. As above - the client should do this. Keep in mind that I also do not exclude the compositor itself from being an AT-SPI client. If the compositor wishes to pass its own keybindings/shortcuts selectively etc.. It may be a compositor has it's own "blind" mode where it may actually directly output some information to both speakers and a braille keyboard to send feedback/information to the user and thus not need orca or AT-SPI. > Thanks, > -Mike > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Call for an EDID parsing library
On Wed, 7 Apr 2021 11:44:04 +0300 Pekka Paalanen said: > Hi all, > > with display servers proliferating thanks to Wayland, and the Linux > kernel exposing only a very limited set of information based on EDID > (rightfully so!), the need to interpret EDID blobs is spreading even > more. I would like to start the discussion about starting a project to > develop a shared library for parsing EDID blobs. This is not the first > time either, other people have suggested it years and years ago already, > but apparently it didn't quite materialise as far as I know. > > Right now, it seems that more or less every display server and other > KMS application is hand-rolling its own EDID parsing code, even for the > most trivial information (monitor make, model, and serial number). With > HDR and color management support coming to Wayland, the need to parse > more things out of EDID will only increase. These things are not > exposed by the kernel, and most of these things have no use for the > kernel either. > > My personal motivation for this is that I don't want to be developing > or reviewing yet another partial EDID parser implementation in Weston. > > I recall ponderings about sharing the same EDID parsing code between > the kernel and userspace, but I got the feeling that it would be a > hindrance in process more than a benefit from sharing code. It would > need to live in the kernel tree, to be managed with the kernel > development process, use the kernel "standard libraries", and adhere to > kernel programming style - all which are good and fine, but maybe also > more restricting than useful in this case. Therefore I would suggest a > userspace-only library. > > Everyone hand-rolling their own parsing code has the obvious > disadvantages. In the opposite, I would expect a new shared EDID > parsing library and project to: > - be hosted under gitlab.freedesktop.org > - be MIT licensed > - offer at least a C ABI > - employ mandatory Gitlab CI to ensure with sample EDID blobs that it > cannot regress > > Prior art can be found in various places. I believe Xorg xserver has > its battle-tested EDID parsing code. Ajax once played with the idea in > https://cgit.freedesktop.org/~ajax/libminitru/ . Then we have > https://git.linuxtv.org/edid-decode.git too which has code and test > data but not a C ABI (right?). > > It does not necessarily need to be a new project. Would edid-decode > project be open to adding a C library ABI? > > edid-decode is already MIT licensed and seems to have a lot of code, > too, but that's all I know for now. > > Would there be anyone interested to take lead or work on a project like > this? > > Personally I don't think I'd be working on it, but I would be really > happy to use it in Weston. > > Should it be a new project, or grow inside edid-decode or something > else? > > I believe MIT license is important to have wide adoption of it. C ABI > similarly. Also that it would be a "small" library without heavy > dependencies. I'd say it needs nothing more than libc - I can't see the justification for more than that. If this is the case along with the above you have given, then I see no reason for it to not be used by everyone other than the usual user complaint of "too many dependencies (of a compositor)". :) I'd definitely consider using it. > What do you think? Could anyone spare their time for this? > > Who would be interested in using it if this library appeared? > > > Thanks, > pq -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland and window position/size
On Tue, 25 May 2021 16:24:30 -0500 Igor Korot said: > Hi, list, > Couple of questions about Wayland, since more and more distros switching ;-) > > If I understand correctly window positioning/sizing is based on the > compositor/window content. > > 1. Is there a way to select where each individual program will start? The compositor decides this. It may place it randomly, somewhere intelligently with minimum overlap, relative to some parent surface/window or perhaps it might store the position it saw that named window at last and restore it to that position. The compositor may expose such settings to the user, or maybe not. It's between the compositor and the user and the idea is that it will be consistent with all windows. > 1a. If not - will there be one? > 2. I am working on the program that should start up with the empty > window - only the toolbar > and the very basic menu. > Then when the user chooses some action from the toolbar some child > windows appear. > I think such program will always start up with very minimal size, > basically the size of the toolbar > under Wayland. Am I wrong? That is up to your program. It could create a very wide and narrow window with just menu bar and toolbar. That's perfectly possible - the buffer you provide will determine this. Generally for most applications the toolkit you use will handle all of this for you, unless you are making your own toolkit or you are nutty enough to avoid a toolkit entirely and try and write everything "bare metal" in which case essentially your app includes a toolkit and thus the work that toolkits normally do becomes your work. > 3. How can one write a cross-platform application that should behave > the same on the different > platforms when the developer doesn't have control over window position/size. Don't try and position a window. I write applications and I simply don't go positioning the window in my own code. I leave it to the system to decide. It just so happens my apps work on multiple platforms too because the toolkit handles that. I expect the system to provide some sensible window positioning of its own. I know full well that this falls apart quickly unless you spend a lot of effort doing things like adapting the position you want to the current resolution, and avoiding putting your window under other obstacles like panels/taskbars and other elements. I just let the WM/compositor handle that. If a user has a tiling WM/compositor or a WM capable of tiling modes then trying to position your window instantly falls apart and assuming/expecting this works is a recipe for pain. > 4. How can a developer write a program that should connect to the database? That has nothing to do with Wayland or display systems in general - that's your job. What kind of database, where it is, how it's dealt with is up to you. A separate problem entirely. > 5. I know there was a plan to respect a save/restore window > positioning/size. Is it implemented? This is up to compositors to do. Your job is to provide a name for your window(s) in Wayland so a compositor can implement this sanely. > 6. How complete is Wayland API currently in terms of window > positioning/sizing? Positioning - Don't position and Wayland discourages it by not having such an API. Sizing - do whatever you like. > Thank you. > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland and window position/size
On Tue, 25 May 2021 22:10:38 -0500 Igor Korot said: > Hi, Carsten, > > On Tue, May 25, 2021 at 8:51 PM Carsten Haitzler wrote: > > > > On Tue, 25 May 2021 16:24:30 -0500 Igor Korot said: > > > > > Hi, list, > > > Couple of questions about Wayland, since more and more distros > > > switching ;-) > > > > > > If I understand correctly window positioning/sizing is based on the > > > compositor/window content. > > > > > > 1. Is there a way to select where each individual program will start? > > > > The compositor decides this. It may place it randomly, somewhere > > intelligently with minimum overlap, relative to some parent surface/window > > or perhaps it might store the position it saw that named window at last and > > restore it to that position. The compositor may expose such settings to the > > user, or maybe not. It's between the compositor and the user and the idea > > is that it will be consistent with all windows. > > OK, so there is no "per-program" settings anywhere. > > Understood. > > > > > > 1a. If not - will there be one? > > > 2. I am working on the program that should start up with the empty > > > window - only the toolbar > > > and the very basic menu. > > > Then when the user chooses some action from the toolbar some child > > > windows appear. > > > I think such program will always start up with very minimal size, > > > basically the size of the toolbar > > > under Wayland. Am I wrong? > > > > That is up to your program. It could create a very wide and narrow window > > with just menu bar and toolbar. That's perfectly possible - the buffer you > > provide will determine this. Generally for most applications the toolkit > > you use will handle all of this for you, unless you are making your own > > toolkit or you are nutty enough to avoid a toolkit entirely and try and > > write everything "bare metal" in which case essentially your app includes a > > toolkit and thus the work that toolkits normally do becomes your work. > > Well, I'm using wxWidgets (cross-platform library) with GTK underneath. > But that should be irrelevant to the problem. > > My understanding is that the size of the TLW is determined by the content of > it I can't just call window->SetSize( 100, 100 ); and the window will > obey my command > and will be created with the size 100x100. > Or can I? that is between you and xwwidgets. wayland as such doesn't care and will allow you to create a buffer for a surface (window) of any size you like. the toolkit in a wayland world should then probably expand this to actually be bigger to contain the decorations (titlebars, resize handles, shadow regions etc.). > > > 3. How can one write a cross-platform application that should behave > > > the same on the different > > > platforms when the developer doesn't have control over window > > > position/size. > > > > Don't try and position a window. I write applications and I simply don't go > > positioning the window in my own code. I leave it to the system to decide. > > It just so happens my apps work on multiple platforms too because the > > toolkit handles that. I expect the system to provide some sensible window > > positioning of its own. I know full well that this falls apart quickly > > unless you spend a lot of effort doing things like adapting the position > > you want to the current resolution, and avoiding putting your window under > > other obstacles like panels/taskbars and other elements. I just let the > > WM/compositor handle that. If a user has a tiling WM/compositor or a WM > > capable of tiling modes then trying to position your window instantly falls > > apart and assuming/expecting this works is a recipe for pain. > > I understand. > As I said I believe that the window sizing is based on the window content. > So all I am doing is calling: that is normal for toolkits - the window size will at least have a minimum size that is determined by the layout and minimum size of widget content. e.g. Length of labels and font size and other factors. Toolkits will generally allow you to resize the window given appropriate widget packing flags/options etc. > window->Maximize(); > > which actually works on all 3 major platforms (Windows, *nix+X, OSX). > > However, my understanding is that it will not work under Wayland. Maximized state is a special state for a window. This can work on Wayland. Compositors may choose to ignore this state as being special. E.g. if you have a tiling compositor like sway i
Re: Wayland and window position/size
On Thu, 27 May 2021 17:02:24 -0500 Igor Korot said: > Hi, Pekka, > > On Wed, May 26, 2021 at 4:30 AM Pekka Paalanen wrote: > > > > On Tue, 25 May 2021 22:10:38 -0500 > > Igor Korot wrote: > > > > > Hi, Carsten, > > > > > > On Tue, May 25, 2021 at 8:51 PM Carsten Haitzler > > > wrote: > > > > > > > > On Tue, 25 May 2021 16:24:30 -0500 Igor Korot said: > > > > > > > > > Hi, list, > > > > > Couple of questions about Wayland, since more and more distros > > > > > switching ;-) > > > > > > > > > > If I understand correctly window positioning/sizing is based on the > > > > > compositor/window content. > > > > > > > > > > 1. Is there a way to select where each individual program will start? > > > > > > > > The compositor decides this. It may place it randomly, somewhere > > > > intelligently with minimum overlap, relative to some parent > > > > surface/window or perhaps it might store the position it saw that named > > > > window at last and restore it to that position. The compositor may > > > > expose such settings to the user, or maybe not. It's between the > > > > compositor and the user and the idea is that it will be consistent with > > > > all windows. > > > > > > OK, so there is no "per-program" settings anywhere. > > > > Not by "the Wayland standard", assuming such a standard was even > > defined. > > ;-) > > > > > But a compositor or a DE may or may not offer per-program settings to > > the end user. I literally mean to the end user, not to the application. > > But then I, as a developer, will not be able to produce truly > cross-platform software. > Because it will behave differently in different environments. that... is life. :) you need to just be aware of where your abilities or responsibilities lie and where they stop and where something else becomes responsible. different platforms have different boundaries here. that is normal and how it works. > So, if I have Ubuntu with Wayland and the user is set to compositor 1, > the software will behave > according to scenario 1. > But if the user uses Debian with comp[ositor 2, the software will > behave by scenario 2. correct. this has ALWAYS been the case on *nix (unixes/bsd's/linuxes etc. with x11). you have no idea of all the little and even large behavior differences. within x11 this continues. the whole point of x11 separating mechanism and policy with the xserver dealing with the mechanism and the window manager dealing with policy. different wm's can have vastly different policies. for example. you may ask to maximize a window and the wm may go "no - you may not. i do not allow maximized windows". that is perfectly legal - and that will be the case because the user chose that option/policy in that wm or they chose that wm because it implements this policy. i've been writing x11 wm's for 25 years and now wayland compositors too. most app devs know very little of the standards which wm and compositor devs need to know very well. trust me when i say that assuming a single kind of behaviour across all wms is a huge mistake quite a few apps make. they don't understand what they can expect to control and what they can't. even in x11 there is no guarantee you can place your window. tiling wm's are one of the more extreme examples where a wm will enforce a specific sizing and placement policy (if you don't know what these are - look them up but once you realize what they do you will realise how bad your assumptions on placement are). tiling wm's will actively force your window to place where they want, not where you want, even if you ask it to be placed somewhere even in x11. wayland has learned mistakes from the x11 world and by design is avoiding many mistakes. placement is one of those. that is the entire point of their layout policy and what a tiling wm does. if it didn't do this users would be incredibly annoyed that they didn't get the behaviour they want - and they want all their windows to tile and not place themselves wherever the author of that app thought they should go. (i won't get into override-redirect windows which allow you to bypass a wm but then life gets very tough). you can have a kiosk-style wm's that force a window to fill the screen and only have one visible at a time and will refuse to allow windows to place themselves too because this is the point of the wm - they have a policy specifically to implement a kiosk ui. my favorite examples though are "what if your window is wrapped around a 3d bunny rabbit
Re: accessibility: implementation of zoom/invert on Wayland?
On Thu, 1 Jul 2021 14:11:23 -0700 Patrick Pelletier said: > Hi, > > I'm new to Wayland and only have a fairly basic understanding of how the > different parts fit together. I'm trying to find out more about how the > following two accessibility features (for visually impaired users) are > implemented and how I might be able to contribute to them: > > * Zoom > * Invert colors > > For example, these features are described in the Ubuntu documentation here: > > https://help.ubuntu.com/stable/ubuntu-help/a11y-mag.html.en > > I'm assuming zoom and invert are implemented in the Wayland compositor? > Is there any code for this in the reference implementation (Weston) or > does each desktop environment have to implement these features from > scratch in their own compositor? In both X11 and Wayland this is something to implement int he compositor as part of the compositor rendering. It doesn't require something to be implemented in Weston as it doesn't require a protocol agreement with applications as it's an entirely "internal to compositor" feature. If you have issues with the implementation of this on Linux, you need to talk to the developers of the compositor you are using. Requesting features or improvements there would be the right course of action. Keep in mind that e.g. on MacOS there is only one compositor - it is part of MacOS. If you have issues with it you complain to apple. In the OSS world there are many compositors/WM's etc. and thus you will have to deal with multiple groups and pieces of software. The freedom of choice brings complexity like this. That's how the cookie crumbles. > Background/motivation: I have a visually impaired friend who is > currently "trapped" on MacOS because Linux's implementation of zoom and > invert does not have feature parity with MacOS's implementation. (For > example, keyboard or keyboard+mouse shortcuts for changing the zoom > factor on the fly.) I'd like for her to be able to use Linux, so I'm > interested in finding out how I can contribute to solving the following > problems: > > * Some desktop environments (such as Xfce) don't seem to support zoom > and invert at all. > > * The default desktop environment for Ubuntu (see link above) implements > zoom and invert in a very clunky way. To change the zoom factor, you > have to go to the settings application. (Versus just being able to use > a modifier key and the scroll gesture to be able to zoom in and out on > MacOS.) Also, it appears that there is no way to invert without also > turning on zoom. > > Is this a battle that has to be fought on a per-desktop environment > basis, or would it be possible to contribute some code to Weston that > would make a good implementation of zoom and invert available to all > desktop environments? > > Thanks for any information, -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proxying Wayland for security
On Tue, 27 Jul 2021 19:29:45 + Alyssa Ross said: > Hi! I'm Alyssa and I'm working on Spectrum[1], which is a project > aiming to create a compartmentalized desktop Linux system, with high > levels of isolation between applications. > > One big issue for us is protecting the system against potentially > malicious Wayland clients. It's important that a compartmentalized > application can't read from the clipboard or take a screenshot of the > whole desktop without user consent. (The latter is possible in > wlroots compositors with wlr-screencopy.) > > So an idea I had was to was to write a proxy program that would sit > in front of the compositor, and receive connections from clients. If > a client sent a wl_data_offer::receive, for example, the proxy could > ask for user confirmation before forwarding that to the compositor. The above is intended to be the job of the compositor. I would expect compositors to implement this. The only decisions to be made is which clients do they "lock down" and ask questions for (eg like allow copy yes/no) and which they do not. The compositor has a socket to the client and can use that to figure out all about the client that it wants to. > I could just implement this stuff in a compositor, but doing it with a > proxy would mean that a known subset of the protocol could be used > with any compositor, with appropriate access controls. It would also > be a reusable component that could be customised to have different > access control policy depending on the needs of a distributor or user. You could - but then the compositor thinks your proxy is the client, not the actual client. This leads to lots of un-fun like if a compositor uses the client socket to query what PID and then what executable etc. that is and does things like shows icons based on the executable found (what desktop file that maps to) etc. ... If the compositor implements some kind of load balancing of rendering/updates based on PID. e.g. it may renice the PID of the client based on if its on a visible virtual desktop or not. I can go on... > Which brings me to the reason I'm bringing this all up on > wayland-devel. I'd be grateful for any input about this idea, > especially: > > * Is this a sensible idea? Is there something I haven't considered >which would make this unworkable, and force me to do a >compositor-specific implementation instead? See above. I can come up with more things that will be problematic. Sure. it *CAN* be done. In some cases like a "vnc proxy" whose job it is to display remote clients it deals with over vnc to a local wayland compositor... it's pretty much necessary. The above socket -> pid -> exe etc. isn't going to be valid/useful and you can't really do that due to the real client being "off machine". But for the vast vast majority of cases, they will be real local clients with real PIDs etc. > * Is this something that would be likely to be generally useful, >outside of our project? Would it make sense as something to >collaborate on / have as a freedesktop.org project? What I think would be of value is a standardized method to decide which wayland clients should be locked down and which should not be. This is currently "undecided". Something a compositor can easily look up given the client socket and then decide which protocol requests it will handle in which way. > [1]: https://spectrum-os.org/ > > Alyssa Ross -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proxying Wayland for security
On Wed, 28 Jul 2021 09:08:03 + Alyssa Ross said: > Hi Carsten, thanks for the detailed reply. > > Carsten Haitzler writes: > > > On Tue, 27 Jul 2021 19:29:45 + Alyssa Ross said: > > > >> Hi! I'm Alyssa and I'm working on Spectrum[1], which is a project > >> aiming to create a compartmentalized desktop Linux system, with high > >> levels of isolation between applications. > >> > >> One big issue for us is protecting the system against potentially > >> malicious Wayland clients. It's important that a compartmentalized > >> application can't read from the clipboard or take a screenshot of the > >> whole desktop without user consent. (The latter is possible in > >> wlroots compositors with wlr-screencopy.) > >> > >> So an idea I had was to was to write a proxy program that would sit > >> in front of the compositor, and receive connections from clients. If > >> a client sent a wl_data_offer::receive, for example, the proxy could > >> ask for user confirmation before forwarding that to the compositor. > > > > The above is intended to be the job of the compositor. I would expect > > compositors to implement this. The only decisions to be made is which > > clients do they "lock down" and ask questions for (eg like allow copy > > yes/no) and which they do not. The compositor has a socket to the client > > and can use that to figure out all about the client that it wants to. > > > >> I could just implement this stuff in a compositor, but doing it with a > >> proxy would mean that a known subset of the protocol could be used > >> with any compositor, with appropriate access controls. It would also > >> be a reusable component that could be customised to have different > >> access control policy depending on the needs of a distributor or user. > > > > You could - but then the compositor thinks your proxy is the client, not the > > actual client. This leads to lots of un-fun like if a compositor uses the > > client socket to query what PID and then what executable etc. that is and > > does things like shows icons based on the executable found (what desktop > > file that maps to) etc. ... If the compositor implements some kind of load > > balancing of rendering/updates based on PID. e.g. it may renice the PID of > > the client based on if its on a visible virtual desktop or not. I can go > > on... > > Hmm, yes, that would be a shame. In general, I saw the proxy as a way > to move some policy decisions out of the compositor. It would still > technically be possible to do those sorts of things by having the > compositor asking the proxy to do it, but that would require buy-in from > compositors. > > It's frustrating that there's no way to implement this sort of thing, > which doesn't feel particularly compositor-dependent, without > implementing it seperately for every compositor my users might want to > use. Especially when it's likely not upstreamable to at least some of > them -- e.g. I doubt Sway, which AIUI aims to avoid adding features > beyond what's needed for i3 compatibility, would be interested in it. > But I understand that that ship has probably sailed, and there's not > really anything I can do about it without breaking the expectations of > other things in the ecosystem. > > >> Which brings me to the reason I'm bringing this all up on > >> wayland-devel. I'd be grateful for any input about this idea, > >> especially: > >> > >> * Is this a sensible idea? Is there something I haven't considered > >>which would make this unworkable, and force me to do a > >>compositor-specific implementation instead? > > > > See above. I can come up with more things that will be problematic. Sure. it > > *CAN* be done. In some cases like a "vnc proxy" whose job it is to display > > remote clients it deals with over vnc to a local wayland compositor... it's > > pretty much necessary. The above socket -> pid -> exe etc. isn't going to be > > valid/useful and you can't really do that due to the real client being "off > > machine". But for the vast vast majority of cases, they will be real local > > clients with real PIDs etc. > > > >> * Is this something that would be likely to be generally useful, > >>outside of our project? Would it make sense as something to > >>collaborate on / have as a freedesktop.org project? > > > > What I think would be of value is a standardized
Re: Proxying Wayland for security
On Wed, 28 Jul 2021 09:51:53 + Simon Ser said: > Please read the (lengthy) discussion at [1]. > > [1]: https://gitlab.freedesktop.org/wayland/weston/-/issues/206 > > In particular, the "get_credentials → PID → executable path" lookup is > racy. PID re-use allows a malicious process to be recognized as another > executable. That is true - but only at cusp points - e.g. PID has exited, but socket has not been detected as dead yet and PID was recycled. I you do the lookup then, it'd be a problem. If you do the lookup first on initial connect, then ensure you do at least one round-trip to client (send something, it sends back a reply), then that lookup would be valid (and continue to be valid for the duration of that connection) because the PID lookup is sandwiched between a connect and an active round-trip (thus the socket didn't die with the process). The round trip does need to be some kind of ping that the compositor sends some UUID it generates with random content and the reply is a pong with that UUID back - thus it can't be spoofed. Indeed using systemd to get cgroup info from a client fd is also possible. The point does remain that adding a proxy in becomes problematic. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proxying Wayland for security
On Wed, 28 Jul 2021 11:05:11 + Simon Ser said: > On Wednesday, July 28th, 2021 at 12:30, Carsten Haitzler > wrote: > > > On Wed, 28 Jul 2021 09:51:53 + Simon Ser cont...@emersion.fr said: > > > > > Please read the (lengthy) discussion at 1. > > > In particular, the "get_credentials → PID → executable path" lookup is > > > racy. PID re-use allows a malicious process to be recognized as another > > > executable. > > > > That is true - but only at cusp points - e.g. PID has exited, but socket has > > not been detected as dead yet and PID was recycled. I you do the lookup > > then, it'd be a problem. > > > > If you do the lookup first on initial connect, then ensure you do at least > > one round-trip to client (send something, it sends back a reply), then that > > lookup would be valid > > Nope. The PID returned by libwayland is the one that bound the socket. > So if you create the socket, fork, bind it in the child, exit the > child, then on the compositor side you'll see a socket which belongs to > a PID which no longer exists. Wait until a privileged client re-uses > that PID, and boom. oooh i see. the rogue process waits for a lucky pid replace. it can set this up. i was going to say "forking and keeping your fd alive is madness and unless you have a very funky thing you generally close the fd before passing it off to any child eg between fork and the exec". but yes - this can be abused to wait for ANOTHER unrelated privileged client to slide into that pid slot. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proxying Wayland for security
On Wed, 28 Jul 2021 10:56:40 + Alyssa Ross said: > Carsten Haitzler writes: > > >> > What I think would be of value is a standardized method to decide which > >> > wayland clients should be locked down and which should not be. This is > >> > currently "undecided". Something a compositor can easily look up given > >> > the client socket and then decide which protocol requests it will handle > >> > in which way. > >> > >> Do I understand correctly that you're saying you'd like there to be some > >> sort of oracle, outside of the compositor, that the compositor could ask > >> what restrictions should be applied to a client? > > > > Yes. or more specifically I'd like it to be as simple and basic as possible. > > E.g. a file in /etc/wayland/security/securityinfo.cfg - imagine this is > > a .ini file format much like .desktop files so we can re-use parsers that > > most things have to eventually implement (how do you display sensible > > application info e.g. while alt-tab switching and icons for apps without > > doing some kind of .desktop file handling at some point? You can choose to > > never do this but then you may then not bother with more security either). > > > > Imagine there are 1 or more files that perhaps describe black or white > > lists in a fairly simple way that allow the compositor to limit functions. > > > > Personally, if I was going to lock security down 9have not gotten there yet > > - have other things to do before then). I'd be happy to support something > > like the above, but before that I'd do some of the following: > > > > 1 query UID/GID of the remote client. If it's not UID 0 and not UID of user > > running the compositor, auto-lock-down anything like copy & paste (eg behind > > such "are you sure" dialogs). We already do not support the screenshot > > protocol as it can be abused .. and the compositor has it's own ability to > > do screenshots and save them out to disk anyway. If we did support it, then > > it'd also do a "are you sure" thing too if UID/GID are not approved. I'd > > consider adding extensions to query SMACK label too if that was more widely > > used (or accept patches). > > > > 2. I'd also then after this add a custom "for my compositor only" white and > > black list of executable paths (probably a simple text file with a list of > > file globs per line like: > > > > deny /usr/bin/firefox > > deny /usr/bin/zoom > > allow /bin/screenshoot-tool > > allow /usr/bin/* > > allow /usr/local/bin/* > > deny /* > > > > So simple walk the list from top to bottom finding first rule that matches. > > this is simple allow/deny but could make these custom rules like: > > > > rule allow=cnp,screenshot > > rule deny= > > rule allow-cnp=cnp > > > > Then use allow-cnp to allow clients to just do cnp. Of course this would > > just be me - but it's simple to maintain and reason about and flexible > > enough to do what is needed. Would have this file per user for sure (e.g. > > ~/.config/mycompositor/security/rules.cfg). The user local file parsed > > first for allow/deny rules then parse the system file for a master list for > > the whole system). Yes - it is coarse and only allows approval based on > > fill file paths. Yes - a binary could be written to /tmp/ or $HOME/ then > > deleted or renamed (vector of attack) which is why I'd have the last rule > > be a deny /* (everything) unless explicitly allowed and only explicitly > > allow known good directories of tools which have other system controls to > > limit abuse (writing of trojans there -= eg /usr/bin will be limited to > > root to write to). > > > > I am sure you spend far more time on all of this than I do and are more > > aware of the problem space, so I think you are much better positioned to > > create standards that are both simple to implement and powerful and secure. > > If all compositors agreed on the same ruleset to load and even used the > > same simple small security library to do this (e.g. you make a small lib > > that can be given a socket fd and then return a list of allowed actions - > > eg cnp,screenshot, ...) this would go a long way to perhaps having a > > standard everyone agrees on and is minimal effort to implement. > > This sort of thing sounds good to me, especially paired with Simon's > secure context proposal[1]. I think it would be important to have it be > a little more complex th
Re: Proxying Wayland for security
(e.g. imagine every app in future has some 1024bit UUID or such generated the first time it is launched by some launcher and forever after that, that app in that context uses that UUID and advertises it to the compositor - well behaved clients then get ongoing behavior across sessions. Bad clients that ignore this get reset when they die and reconnect. As it's a massive UUID its not able to be faked and it is somehow stored so malicious clients can't harvest someone else's UUID). So given the general view that sandboxed clients are untrusted, the sandboxing mechanism can store the UUID inside the sandbox only that client can access. Regular apps just have the UUID stored in ~/.config somewhere which the sandboxed clients cannot read. > How do you intend to handle or waive that problem? > > > > > Did you check > > > https://github.com/mupuf/libwsm ? > > > > > > That was linked from the Weston issue. I don't know if it applies, and > > > as you can see, it never took off and has been dormant for years. > > > > I only just saw it -- thanks for bringing it to my attention. It looks > > like it could do the job, but it also looks like it would be difficult > > to implement in compositors, since they seem to be responsible for > > prompting the users for permission / notifying them of things that have > > happened. > > > > Since this morning, I've been thinking about investigating polkit for > > this, since this is (at least roughly) within its scope, it's already > > present on just about every free desktop system, and desktop > > environments already have the appropriate integrations with it. > > The me to first and foremost problem is what Simon McVittie wrote: > How do you define and recognise a client's identity. > > > Thanks, > pq -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: xrandr and xwayland
On Fri, 30 Jul 2021 16:28:02 + David Deyo said: No - this is up to the compositor itself to do in its own internal ways. Far too many abuses have happened over the years with xrandr available to any client anywhere. While in theory a wayland compositor could create an extension that works like xrandr, it'd be problematic to make it general-access like xrandr. > > Hello everyone, > > I need to rotate my screen 90 degrees and back to normal in xwayland on an > iMX8 running gatesgarth distro. > > Does anyone know if xrandr can be coerced/modified to make rotations work? > I’m in the middle of xserver, libX11, libxrandr and xrandr source. > > How would a client communicating to Xwayland as the xserver request a > rotation? Does Xwayland listen to a unix socket and pass commands on to the > kernel? > > (Thanks Hans,) > > -dwd > David > Deyo [cid:image002.png@01D78535.F4D09430] > > Firmware Engineer > TPI- Tire Profiles > O: 214-396-3063 > E: dd...@tireprofiles.com<mailto:dd...@tireprofiles.com> | W: > www.tireprofiles.com<http://www.tireprofiles.com/> A: 3010 Story Rd W, > Irving, TX 75038 > > > From: Hans de Goede<mailto:hdego...@redhat.com> > Sent: Friday, July 30, 2021 11:16 AM > To: David Deyo<mailto:dd...@tireprofiles.com> > Subject: Re: xrandr and xwayland > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > Hi, > > On 7/30/21 4:24 PM, David Deyo wrote: > > Hello Hans, > > > > > > > > Please help. > > > > > > > > I found your name in a git log. > > > > > > > > Do you know if xrandr is expected to work in xwayland? We really need to > > find some way to make it work. > > xrandr is not really expected to work in xwayland, monitor resolution > configuration is done by the compositor under Wayland, not through xrandr. > > There is some emulation for when apps create a single fullscreen window > and then call xrandr to change the resolution, in that case the apps > window will be sized to the requested resoution and Xwayland will > scale the window to fill the entire monitor. This does rely on > the compositor implementing the viewport extension. > > I hope this helps, if you need more info please send any > follow up emails to wayland-devel@lists.freedesktop.org > so that the entire Wayland community sees the email and can > help you. > > Regards, > > Hans > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com
Re: Professional services on Wayland / LINUX Display Server
On Fri, 30 Jul 2021 16:28:10 +0200 Stephane Tosoni said: > Hello, > > > > I am in charge of a new LINUX Desktop project, we are trying to find an > expert (professional service) on Wayland / LINUX Display Server. > > > > We are looking for a Linux expert on graphical environments (Desktop) to > provide us a technical analyze on what it's possible to implement on LINUX > Desktop to supervise it, on the graphical side. > > > > Attended is to validate the sustainability of the approach for the next > releases of the Linux under Desktop. > > I’m trying to find a technical analysis to answer these kinds of questions: > > > > How to analyze under "Wayland,” > >- all the windows and the Window in the foreground (and binary ) user >process associated with it and running under "Wayland". You are not meant to know this. the idea with Wayland is to sandbox this away from clients and only the compositor knows this. It's privileged information. >- the duration of user interaction each window from the "Wayland client" As above. I n X11 you could figure this out - any X client could. Not Wayland. By design for security and privacy reasons. > If you are able to provide this expertise, or you know someone who has > skills on these topics, please contact us. > > > > *Stéphane TOSONI* > > R&D Manager > > +(33) 6 07 40 91 52 > > stephane.tos...@interact-software.com > > www.interact-software.com > > <https://www.linkedin.com/company/interact-software/> > <https://www.youtube.com/channel/UCsukAMM8wp6yjfktyBNpN0g> -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com
Re: FW: xrandr and xwayland
On Tue, 3 Aug 2021 13:04:11 + David Deyo said: > > > From: David Deyo<mailto:dd...@tireprofiles.com> > Sent: Monday, August 2, 2021 3:53 PM > To: Pekka Paalanen<mailto:ppaala...@gmail.com> > Subject: RE: xrandr and xwayland > > On Fri, 30 Jul 2021 23:30:38 +0100 > Carsten Haitzler wrote: > > > On Fri, 30 Jul 2021 16:28:02 + David Deyo said: > > > > No - this is up to the compositor itself to do in its own internal ways. Far > > too many abuses have happened over the years with xrandr available to any > > client anywhere. While in theory a wayland compositor could create an > > extension that works like xrandr, it'd be problematic to make it > > general-access like xrandr. > > >>>Indeed. > > > > > > > Hello everyone, > > > > > > I need to rotate my screen 90 degrees and back to normal in xwayland on > > > an iMX8 running gatesgarth distro. > > >>>Maybe you could explain your top-level use case for this, and the > >>>general system architecture (which relevant programs are running and > >>>what their responsibilities are)? > > Distro: > I am working on a product that our company is creating. It uses an imx8 som > from Boundary. The system is not a normal desktop. The DISTRO is created by > yocto using the gatesgarth branch. Just recently we were notified that > Xwayland was working, so I don’t expect we will be removing it just yet. > > > Use case: > We will have a kiosk-looking desktop. Some of our pages will have the option > for the end user to enter text from an on-screen keyboard. Since our display > will be so small (68.04mm (2.68") x 120.96mm (4.76")), we will have to turn > our unit sideways to make the keyboard fit. We have already done this on a > smaller screen (1.0). On our 1.0 product, we used Segger as our graphics > library. Compared to Android, and the like, it seems like rotating the > screen would be a standard capability. > > I believe our compositor (Weston) can do it, transform=90, but to use this > method, it has to be restarted; causing our gui app to crash and lose all > entered data. The client probably needs to drive the orientation. > Considering our gui will likely be in python3/tkinter, I will need some way > create a page and rotate the display. > > I am somewhat limited by the packages available to me in my distro. The right way here is to modify Weston to do on-the-fly rotation without a restart. You also will want a custom protocol from client to compositor to indicate when a client surface wants rotation. This way the compositor can correctly rotate the client content and any other on-screen content at the time (e.g. keyboard) when that client surface is the active visible one (as a kiosk style only one will be active/visible at a time - except for things like keyboard etc.). When you switch which surface is the active one then the compositor can re-evaluate how to draw on the screen based on what that client has requested rotation-wise. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com
Re: FW: xrandr and xwayland
On Tue, 3 Aug 2021 13:40:25 + David Deyo said: > From: Carsten Haitzler<mailto:ras...@rasterman.com> > Sent: Tuesday, August 3, 2021 8:13 AM > To: David Deyo<mailto:dd...@tireprofiles.com> > Cc: > wayland-devel@lists.freedesktop.org<mailto:wayland-devel@lists.freedesktop.org> > Subject: Re: FW: xrandr and xwayland > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > On Tue, 3 Aug 2021 13:04:11 + David Deyo said: > > > > > > > From: David Deyo<mailto:dd...@tireprofiles.com> > > Sent: Monday, August 2, 2021 3:53 PM > > To: Pekka Paalanen<mailto:ppaala...@gmail.com> > > Subject: RE: xrandr and xwayland > > > > On Fri, 30 Jul 2021 23:30:38 +0100 > > Carsten Haitzler wrote: > > > > > On Fri, 30 Jul 2021 16:28:02 + David Deyo > > > said: > > > > > > No - this is up to the compositor itself to do in its own internal ways. > > > Far too many abuses have happened over the years with xrandr available to > > > any client anywhere. While in theory a wayland compositor could create an > > > extension that works like xrandr, it'd be problematic to make it > > > general-access like xrandr. > > > > >>>Indeed. > > > > > > > > > > Hello everyone, > > > > > > > > I need to rotate my screen 90 degrees and back to normal in xwayland on > > > > an iMX8 running gatesgarth distro. > > > > >>>Maybe you could explain your top-level use case for this, and the > > >>>general system architecture (which relevant programs are running and > > >>>what their responsibilities are)? > > > > Distro: > > I am working on a product that our company is creating. It uses an imx8 som > > from Boundary. The system is not a normal desktop. The DISTRO is created by > > yocto using the gatesgarth branch. Just recently we were notified that > > Xwayland was working, so I don’t expect we will be removing it just yet. > > > > > > Use case: > > We will have a kiosk-looking desktop. Some of our pages will have the > > option for the end user to enter text from an on-screen keyboard. Since our > > display will be so small (68.04mm (2.68") x 120.96mm (4.76")), we will have > > to turn our unit sideways to make the keyboard fit. We have already done > > this on a smaller screen (1.0). On our 1.0 product, we used Segger as our > > graphics library. Compared to Android, and the like, it seems like > > rotating the screen would be a standard capability. > > > > I believe our compositor (Weston) can do it, transform=90, but to use this > > method, it has to be restarted; causing our gui app to crash and lose all > > entered data. The client probably needs to drive the orientation. > > Considering our gui will likely be in python3/tkinter, I will need some way > > create a page and rotate the display. > > > > I am somewhat limited by the packages available to me in my distro. > > > > > >The right way here is to modify Weston to do on-the-fly rotation > > > > >without a restart. You also will want a custom protocol from client to > > > > >compositor to indicate when a client surface wants rotation. This way > > > > >the compositor can correctly rotate the client content and any other > > > > >on-screen content at the time > > > > > (e.g. keyboard) when that client surface is the active visible one > > > > > (as a kiosk > > > > >style only one will be active/visible at a time - except for things > > > > >like keyboard etc.). When you switch which surface is the active one > > > > >then the compositor can re-evaluate how to draw on the screen based on > > > > >what that client has requested rotation-wise. > Thank you, > A custom protocol makes sense. > > 1. What’s the best way to communicate with Weston, socket, message, > function call? Wayland protocol. You can create extensions as XML files and use wayland-scanner to generate C code to handle that protocol. > 2. How would Weston actually rotate the display, in particular on the fly? > In the Weston documentation, it states that a super-kbd key and middle mouse > button should rotate the display (if supported). I’d like to find where that > is, as well. Any number of ways. It could modify the KMS device properties for that output to rotate. It could render rotated (in GL transform the triangle coordinates when rendering) or in software render the pixels rotated as you read and write them from one place to another (various algorithms can be used here). Weston already can do these so it's just a matter of gluing together the code with your protocol and some logic. > -dwd > -- > - Codito, ergo sum - "I code, therefore I am" -- > Carsten Haitzler - ras...@rasterman.com > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com
Re: FW: xrandr and xwayland
On Tue, 3 Aug 2021 15:00:44 + David Deyo said: > > > From: Carsten Haitzler<mailto:ras...@rasterman.com> > Sent: Tuesday, August 3, 2021 9:38 AM > To: David Deyo<mailto:dd...@tireprofiles.com> > Cc: > wayland-devel@lists.freedesktop.org<mailto:wayland-devel@lists.freedesktop.org> > Subject: Re: FW: xrandr and xwayland > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > On Tue, 3 Aug 2021 13:40:25 + David Deyo said: > > > From: Carsten Haitzler<mailto:ras...@rasterman.com> > > Sent: Tuesday, August 3, 2021 8:13 AM > > To: David Deyo<mailto:dd...@tireprofiles.com> > > Cc: > > wayland-devel@lists.freedesktop.org<mailto:wayland-devel@lists.freedesktop.org> > > Subject: Re: FW: xrandr and xwayland > > > > CAUTION: This email originated from outside of the organization. Do not > > click links or open attachments unless you recognize the sender and know the > > content is safe. > > > > > > On Tue, 3 Aug 2021 13:04:11 + David Deyo said: > > > > > > > > > > > From: David Deyo<mailto:dd...@tireprofiles.com> > > > Sent: Monday, August 2, 2021 3:53 PM > > > To: Pekka Paalanen<mailto:ppaala...@gmail.com> > > > Subject: RE: xrandr and xwayland > > > > > > On Fri, 30 Jul 2021 23:30:38 +0100 > > > Carsten Haitzler wrote: > > > > > > > On Fri, 30 Jul 2021 16:28:02 + David Deyo > > > > said: > > > > > > > > No - this is up to the compositor itself to do in its own internal ways. > > > > Far too many abuses have happened over the years with xrandr available > > > > to any client anywhere. While in theory a wayland compositor could > > > > create an extension that works like xrandr, it'd be problematic to make > > > > it general-access like xrandr. > > > > > > >>>Indeed. > > > > > > > > > > > > > Hello everyone, > > > > > > > > > > I need to rotate my screen 90 degrees and back to normal in xwayland > > > > > on an iMX8 running gatesgarth distro. > > > > > > >>>Maybe you could explain your top-level use case for this, and the > > > >>>general system architecture (which relevant programs are running and > > > >>>what their responsibilities are)? > > > > > > Distro: > > > I am working on a product that our company is creating. It uses an imx8 > > > som from Boundary. The system is not a normal desktop. The DISTRO is > > > created by yocto using the gatesgarth branch. Just recently we were > > > notified that Xwayland was working, so I don’t expect we will be removing > > > it just yet. > > > > > > > > > Use case: > > > We will have a kiosk-looking desktop. Some of our pages will have the > > > option for the end user to enter text from an on-screen keyboard. Since > > > our display will be so small (68.04mm (2.68") x 120.96mm (4.76")), we > > > will have to turn our unit sideways to make the keyboard fit. We have > > > already done this on a smaller screen (1.0). On our 1.0 product, we used > > > Segger as our graphics library. Compared to Android, and the like, it > > > seems like rotating the screen would be a standard capability. > > > > > > I believe our compositor (Weston) can do it, transform=90, but to use this > > > method, it has to be restarted; causing our gui app to crash and lose all > > > entered data. The client probably needs to drive the orientation. > > > Considering our gui will likely be in python3/tkinter, I will need some > > > way create a page and rotate the display. > > > > > > I am somewhat limited by the packages available to me in my distro. > > > > > > > >The right way here is to modify Weston to do on-the-fly rotation > > > > > >without a restart. You also will want a custom protocol from client > > > > > >to compositor to indicate when a client surface wants rotation. This > > > > > >way the compositor can correctly rotate the client content and any > > > > > >other on-screen content at the time > > > > > > (e.g. keyboard) when that client surface is the active visible one > > > > > > (as a kiosk > > > > > >style only one w
Re: Compositor handoffs: Switching clients between compositors
s > behaves as expected. > > ## What about window size/position/stacking order > > Because everything is treated as new windows (from a compositor POV) > stacking order and positioning is effectively random. Size is often > maintained as the clients do know their original size. Session > managment > (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18) > is a possible solution to this. > > ## Could it be done without toolkit changes via a magic proxy? > > Possibly, but I don't think it adds anything. Clients are the > canonical source of what a client needs, and knows how to handle any > sudden changes the best. There is also zero overhead this way. > > ## What if the EGLDisplay capabilities change? > > My mesa change keeps the same connection to the card specified by the > first wl_drm.device event from the first wayland connection. If the > new compositor passes a different device it is ignored. > That definitely has some theoretical quirks, but none that have come > up in practice for the immediate task at hand. > > ## What if the compositor has no support? > > Then the socket on the file system will disappear and clients will > fail to reconnect and quit. We also use this in clients to detect a > graceful kwin exit and just exit accordingly. > > ## What about vulkan? > > It will need similar changes to what we've done for OpenGL. > > ## That was too much text > > There will be an XDC talk > (https://indico.freedesktop.org/event/1/contributions/20/) where I > will describe everything mentioned here. > > # Next steps > > The changes to libwayland is the most invasive, and the most > potentially controversial. I wanted to send an overview email and get > a discussion going before I submitted merge requests. Unfortunately > it's the blocker on everything else. > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com
Re: Compositor handoffs: Switching clients between compositors
On Tue, 17 Aug 2021 22:58:53 +0100 David Edmundson said: > > FYI we did this a few years back for efl and enlightenment... on a loss of > > the > > Yeah, it's good stuff. > I'm forced to go a bit lower as I'm trying to retroactively support > applications that have some pre-existing assumptions, but overall the > idea is the same. h. ok - we took a "everyone support the protocol please and re-connect... thanks" idea. clients that do not will not recover. > > we added an extended protocol for the compositor to send a UUID to the > > client per surface and clients on reconnect provide that UUID to the > > compositor - this allows the compositor to fix all the stacking and other > > state when the surfaces come back. :) > > > > https://git.enlightenment.org/core/enlightenment.git/tree/src/protocol/session-recovery.xml > > > Thanks. We had taken a look at that. > The Xdg session protocol that I mention we hope to expand on is built > on top of this with the same base principle. > We haven't yet tried really making use of it. excellent. we might be able to merge then at some point - at least you have another toolkit and compositor already implementing some of this. > > i think in theory efl apps should then work with your hand-off (for us its > > session recovery but that is your intent too - handling compositor crashes > > >i think in theory efl apps should then work with your hand-off > > I gave it a go with efl git and the enlightenment terminal. > It unfortunately crashes, but I didn't look into the cause. > Based on the trace, it did look like it was trying to reconnect. hmm. will have to look into it. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com
Re: Any protocol documentation about premultiplied alpha?
On Tue, 28 Sep 2021 13:16:36 + "Hoosier, Matt" said: premultiplpied is the base assumption. you don't need shaders to deal with it - the gl blend func does... the only time you want a shader to deal with "premultiplied" is if the source buffer is NOT premultiplied - you now have to do the extra multiply in-shader (or switch blend func). premultiplied is the sane colorspace for compositing/rendering where things just work out nicely. > Hi there, > > > > Is there any definitive word about whether or not clients should be expected > or allowed to premultiply alpha the alpha channels in the normal EGL and > linux-dmabuf buffers they send to a compositor? > > > I have never seen this practice used with Wayland -- the shaders in the > gl-renderer certainly don't seem to expect clients to premultiply. But I > stumbled on a comment or two that maybe gnome-calculator [1] does this and > that Sway settled on that convention [2]. > > > > I see hardly any mention of premult in the Weston codebase. In fact, the only > real reference to it occurs at a site dealing with Pixman color formats. In > this location, it's a prominent warning to the reader that Pixman does use > premultiplication; this seems to carry the meaning that Pixman's premult > usage stands apart from the rest of Weston. > > > To me, it seems that Wayland's adoption of the DRM_FORMAT_xxx identifiers in > the wire protocols (e.g., dmabuf) combined with drm_fourcc.h's complete > stonewalled silence on the subject, seems to be a fairly strong indicating > that premultiplication should not be used. > > > > -Matt > > > [1] https://github.com/swaywm/wlroots/issues/984#issue-324334642 > > > [2] https://github.com/swaywm/wlroots/issues/984#issuecomment-390221778 > > > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com
Re: [RFC] drm/kms: control display brightness through drm_connector properties
provided a minimum (non 0) duty-cycle below which the driver will > never go. > > bl_brightness_control_method: ro, enum, possible values: > none: The GPU driver expects brightness control to be provided by another > driver and that driver has not loaded yet. > unknown: The underlying control mechanism is unknown. > pwm: The brightness property directly controls the duty-cycle of a PWM > output. > firmware: The brightness is controlled through firmware calls. > DDC/CI: The brightness is controlled through the DDC/CI protocol. > gmux: The brightness is controlled by the GMUX. > Note this enum may be extended in the future, so other values may > be read, these should be treated as "unknown". > > When brightness control becomes available after being reported > as not available before (bl_brightness_control_method=="none") > a uevent with CONNECTOR= and > PROPERTY= will be generated > at this point all the properties must be re-read. > > When/once brightness control is available then all the read-only > properties are fixed and will never change. > > Besides the "none" value for no driver having loaded yet, > the different bl_brightness_control_method values are intended for > (userspace) heuristics for such things as the brightness setting > linearly controlling electrical power or setting perceived brightness. > > Regards, > > Hans > > > 1) The need to be able to map the backlight device to a specific display > has become clear once more with the recent proposal to add DDCDI support: > https://lore.kernel.org/lkml/20220403230850.2986-1-yusisameri...@gmail.com/ > > 2) > https://lore.kernel.org/all/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/ > Note this proposal included a method for userspace to be able to tell the > kernel if the native/acpi_video/vendor backlight device should be used, but > this has been solved in the kernel for years now: > https://www.spinics.net/lists/linux-acpi/msg50526.html An initial > implementation of this proposal is available here: > https://cgit.freedesktop.org/~mperes/linux/log/?h=backlight > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com
Re: [RFC] drm/kms: control display brightness through drm_connector properties
On Mon, 11 Apr 2022 12:27:37 +0200 Hans de Goede said:
> Hi,
>
> On 4/7/22 20:58, Carsten Haitzler wrote:
> > On Thu, 7 Apr 2022 17:38:59 +0200 Hans de Goede said:
> >
> > Below you covered our usual /sys/class/backlight device friends... what
> > about DDC monitor controls? These function similarly but just remotely
> > control a screen via I2C and also suffer from the same problems of "need
> > root" and "have to do some fun in mapping them to a given screen".
>
> Right, supporting this definitely is part of the plan, this is why my original
> email had the following footnote:
Yay!
> 1) The need to be able to map the backlight device to a specific display
> has become clear once more with the recent proposal to add DDCDI support:
> https://lore.kernel.org/lkml/20220403230850.2986-1-yusisameri...@gmail.com/
Oh gee - I missed that. my bad!
> :)
>
> > Otherwise I welcome this de-uglification of the backlight device and
> > putting it together with the drm device that controls that monitor.
>
> Thx.
Having to deal with the backlight device madness is a big pain (have already
done it - DDC included) and properly exposing these things attached to the
proper KMS device is absolutely the right thing. Admittedly this punts the job
of matching a backlight device to the right video output in KMS to the kernel
so at least it gets solved in one place rather than it being re-invented again
and again per wm/desktop/compositor.
> > Just to make life more fun ... DDC does much more than backlight controls.
> > It can control essentially anything that is in the OSD for your monitor
> > (contrast, brightness, backlight, sharpness, color temperatures, input to
> > display (DP vs HDMI vs DVI etc.), an for extra fun points can even tel you
> > the current rotation state of your monitor. All of these do make sense to
> > live as drm connector properties too. Perhaps not a first iteration but
> > something to consider in this design.
>
> One thing which I do want to take into account is to make sure that userspace
> can still do DDC/CI for all the other features. I know there is demand for
> adding brightness control over DDC/CI. I'm not aware of any concrete use-cases
> for the other DDC/CI settings. Also DDC/CI can include some pretty crazy
> stuff like setting up picture in picture using 2 different inputs of the
> monitor, which is very vendor specific. So all in all I think that we should
> just punt most of the DDC/CI stuff to userspace.
Having spent some time with DDC you're right - it can have some interesting
properties, but a wide number seem to be highly common between monitors and
make total sense to regularly use if available. Backlight/brightness is just
the immediate focus here.
> With that said I agree that it would be good to think about possibly other
> some of the other settings in case some use-case does show up for those.
>
> The biggest problem with doing this is coming up with some prefix to
> namespace things. I've gone with bl_brightness to avoid a conflict
> with the existing TV specific properties which have plain "brightness"
> put if we want to e.g. also add DDC/CI contrast as a property later
> then it might be good to come up with another more generic prefix
> which can be shared between laptop-panel-brightness, DDC/CI-brightness
> and DDC/CI-contrast ... ?
>
> So any suggestions for a better prefix?
Well here is my take. Have DDC properties separate from a build-in backlight
device. Userspace code will have to essentially do something like:
if (built_in_backlight_exists(output)) // built in backlight device
set_backlight_brightness(output, val);
else if (ddc_prop_exists(output, 0x10)) // 0x10 is ddc brightness/backlight
set_ddc_int_val(output, 0x10, val);
else // fallback for ye olde setuid tooling
{ ...
}
DDC properties are quite simple in essence so just exposing the set so you can
read/write them (and check if they exist at all) would do the right thing - tie
DDC to the output visa KMS, (you still could use I2C directly if you like and
go behind KMS's back) but it'd then punt the policy decision of which
properties are common/sane to userspace without adding a possibly "endless" set
of "let's now adopt/abstract this DDC property" discussions. Wayland
compositors can adopts the properties they see as most useful for their uses.
Xorg could expose them via XRR output properties. So my take at least is to give
DDC it's own property namespace/set that allows an arbitrary set of numbered
properties and leave it pretty raw.
> Regards,
>
> Hans
>
>
>
>
>
> >
> >> As discussed already several times in the past:
> >> https://www.x.org/wiki/Even
Re: Window positions under wayland
On Thu, 4 Aug 2022 13:32:36 -0500 Igor Korot said: > Hi, > > On Thu, Aug 4, 2022 at 12:58 PM samuel ammonius wrote: > > > > Dude, I'm trying to persuade the wayland devs to change this, not have an > > argument about how much wayland sucks. Thanks for explaining that this was > > supposed to be a feature though. I hadn't known that before. > > You most welcome. > And like I said - you are not the only one. Others tried and failed. > > They think its a feature and will tell you "Its by design". It is by design. And it's right. From decades of apps being able to position in X11 and expecting to be able to and then screwing it up again and again and again... Wayland got it right. If you allow positioning then apps RELY on it. They act is totally broken ways when the compositor refuses to allow that. The right thing to do is to remove their expectation of such control. Apps can use subsurfaces which can position RELATIVE to a parent (e.g. used for menu popups etc. but could be used for dialogs). You could also just draw a dialog inline inside your main window and do whatever you want inside of that. This is up to your app (and whatever toolkit it may use if it uses one). It is the apps' job to indicate a dialog is a dialog for a parent surface. if they do then the compositor SHOULD place that dialog relative to that surface sensibly (e.g. centered). If it doesn't do something sensible OR do what the user has explicitly configured it to do because the user wants something broken (and the compositor allows it), then that compositor needs improving/fixing. It's easier to fix a few compositors than it is to fix the endless chain of 100's of broken applications. > Thank you. > > > > > On Thu, Aug 4, 2022 at 3:14 PM Igor Korot wrote: > >> > >> Hi, > >> > >> On Thu, Aug 4, 2022 at 12:37 PM samuel ammonius > >> wrote: > >> > > >> > Compositors can prevent apps from doing this if they want to, but there > >> > needs to be some built-in way for windows to set their positions. Not > >> > having this isn't a feature. > >> > >> I am not a Wayland developer. > >> > >> But based on the multiple replies here and there - it is the main > >> feature of the Wayland. > >> It will never allow the application to set its position/size. > >> It will however allow the end-user (a human) to configure Wayland > >> (compositor) in any waythey want > >> and however stupid they want. > >> > >> And Wayland developers consider it to be "BIG WAYLAND FEATURE". > >> > >> So forget about cross-platform applications behaving the same, forget > >> about even writing sane application on Linux. > >> Wayland (compositor) will be set up by the user (a human) in such a > >> way so that the application could become > >> completely unusable. > >> > >> Thank you. > >> > >> > > >> > On Thu, Aug 4, 2022 at 2:57 PM Igor Korot wrote: > >> >> > >> >> On Thu, Aug 4, 2022 at 12:06 PM Simon Ser wrote: > >> >> > > >> >> > On Thursday, August 4th, 2022 at 19:00, samuel ammonius > >> >> > wrote: > >> >> > > >> >> > > apps such as popups and dialogs are usually supposed to start either > >> >> > > at the center of the screen or the center of their parent app > >> >> > >> >> You are barking at the wrong tree. > >> >> > >> >> Apparently this is the main feature of the Wayland - do not let the > >> >> developers set up the position of the TLW. > >> >> > >> >> > > >> >> > That's usually what compositors do: center apps by default. But it's > >> >> > to the compositor and user preference. > >> >> > > >> >> > > apps often want to remember where they were when they closed so they > >> >> > > can open there again > >> >> > > >> >> > This is what [1] addresses. > >> >> > > >> >> > [1]: > >> >> > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18 > >> >> > >> >> Finally!! ;-) > >> >> Now if only Wayland can respect the calls such as > >> >> CenterOnScreen()/CenterOnParent() > >> >> for the dialog-like windows it would be great. > >> >> > >> >> Unfortunately it looks like this will never happen and the application > >> >> developers will > >> >> have to throw away their software, because apparently dialogs can be > >> >> put anywhere > >> >> on the screen. > >> >> > >> >> Something like a dialog asking for credentials to login to the DB that > >> >> shows up in the > >> >> top left corner, because some idiot user set it this way. > >> >> > >> >> Thank you. > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com
Re: Window positions under wayland
On Thu, 4 Aug 2022 14:46:40 -0500 Igor Korot said:
> Hi, Carsten,
>
> On Thu, Aug 4, 2022 at 2:31 PM Carsten Haitzler wrote:
> >
> > On Thu, 4 Aug 2022 13:32:36 -0500 Igor Korot said:
> >
> > > Hi,
> > >
> > > On Thu, Aug 4, 2022 at 12:58 PM samuel ammonius
> > > wrote:
> > > >
> > > > Dude, I'm trying to persuade the wayland devs to change this, not have
> > > > an argument about how much wayland sucks. Thanks for explaining that
> > > > this was supposed to be a feature though. I hadn't known that before.
> > >
> > > You most welcome.
> > > And like I said - you are not the only one. Others tried and failed.
> > >
> > > They think its a feature and will tell you "Its by design".
> >
> > It is by design. And it's right. From decades of apps being able to
> > position in X11 and expecting to be able to and then screwing it up again
> > and again and again... Wayland got it right.
>
> I'm not sure what you mean.
> Can you give an example of "screwing again and again and again...", please?
>
> If my code expects the window to be placed at 1 monitor position (100, 100) -
> what is wrong with that?
>
> All I can do as a developer is to write:
>
> [pseudo-code]
> MyApp:MyApp()
> {
> myTLW = new Frame( NULL, ID, "My Beautiful Window", position(
> 100, 100 ), defaultsize, tlwstyles );
> mytklw-> Show( true );
> }
> [/pseudo-code]
>
> What is wrong with that?
>
> Thank you.
let me begin with just a few examples:
1. window outer frame is decided by wm at runtime. not client (in x11 - you are
asking about broken examples so they all come from x11). application has no idea
what frame the wm may choose this time. user may have changed what frame they
use by default. they may have changed theme which changes frame sizes. they may
have changed fonts, other sizing factors in wm config which then result in the
border being put off-screen or in a weird place. clients start to make
assumptions that wm's will reparent windows in specific ways and add larger
frames that are immediate children of root when a wm could do anything but they
all decided to assume this which was a false assumption. they go figuring out
their inner frame client window vs the immediate child of root to guess frame
size. this has broken any wm that tries to create a frame that holds multiple
client windows that are not basically stacked on top of each other. the whole
idea of icccm and wm policies in theory allow this but invalid client
assumptions have broken the ability to make experiences better for users.
2. clients are almost all dumb when it comes to dynamic changes. they remember
their position relative to 0,0 of root generally, but then many forget to
remember it relative to an xrandr screen and adapt when that xrandr screen
changes. there is no way to say "put my window at x,y relative to THIS screen"
only to ask for specific global geometry relative to root, so if screen layout
changed between invocations - the client gets all their remembered geometry
wrong. i've seen this countless times and it is the norm for clients - they do
not adapt to screen layout changes pretty much at all. change resolution,
rotation, if your monitors are laid out left to right, top to bottom etc. ...
they just dumbly decide they need to be at 100,213 and want to be there again
regardless of what changed with screens in the mean time.
3. specifically just resolution changes - i've never seen a client properly
decide to re-scale their window position if resolutions changed and/or anchor
the window to the nearest screen corner to e.g. if window was near bottom-right
corner now ant now it's 1024x768 and later the screen is 2560x1440 - the window
stays at bottom-right corner - it will instead now open in the center of the
screen as the client just remembered its position relative to 0,0 and asks for
that.
4. the wm has a smart placement policy like centering dialogs on the parent,
but i have seen clients be dumb enough to just remember position of dialog as an
absolute (relative to root 0,0) and not relative to their parent window so the
client parent win was near bottom-right but this time it's near top-left -
dialog pops up and opens up bottom-right of screen because that is where it was
centered over the parent window before but now the parent is not there anymore.
client failed to account for the parent having moved this run.
5. some wm's are good at dynamically adapting to new screen layouts and changes
as you plug and unplug. they may re-index your screens based on a priority
mechanism and thus your app belongs either on a logical screen (the 2nd highest
priority of 5 screens) OR it may belong on a physi
Re: Wayland configurations and user tools
On Sun, 24 Sep 2017 13:51:20 +0200 Narcis Garcia said: > Hello, is there some other list (or documentation) about user space > tools and environment setup? > > I'm trying to select VGA/HDMI output in Debian 9 +Gnome but I don't find > Wayland's configuration files ot other things that help me in this. there are no wayland configuration files for this. wayland is nothing like x. the configuration will be specific to gnome shell. look there. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Lightweight desktop environments for Wayland?
On Tue, 5 Sep 2017 22:04:38 +0800 lan lan said: > Hi, > > weston doesn't seem to have any kind of "settings manager", regular > desktop controls, > or task-bar. Is there a lightweight desktop environments for Wayland? Probably the lightest weight might be enlightenment if it's a regular window manager you're after. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Enabling Android-style per application user ids
n libwayland-client. > > wl_display_connect_to_fd() would allow clients to connect to arbitrary > sockets, but I understand that to be an unattractive solution in > general, because it would need modifying client toolkits to use it. > There is also WAYLAND_SOCKET, but it is probably not often possible to > arrange an already open connection in a general case. > > The suggestion to automatically look for a fallback socket > at /run/wayland/$WAYLAND_DISPLAY with WAYLAND_DISPLAY defaulting to > "wayland-0" sounds reasonable to me, but I wouldn't feel comfortable > making that review decision alone. I do know some people are eager to > avoid mandatory environment variables if something can be found by > convention. > > > Thanks, > pq -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: New paths for Wayland sockets (Re: Enabling Android-style per application user ids)
On Fri, 3 Nov 2017 09:33:47 +0200 Pekka Paalanen said: > The last proposed patch for absolute paths is probably > https://lists.freedesktop.org/archives/wayland-devel/2015-August/023838.html > which looks like it got ignored mostly because of a damaged submission > and mixed-up (nowadays probably unwanted) server-side changes. The > patch also lacks the rationale and justification in the commit message. > This is FYI for anyone wanting to carry on that work. I pretty much like that patch as-is. It's simple. It does the job. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: New paths for Wayland sockets (Re: Enabling Android-style per application user ids)
On Fri, 3 Nov 2017 09:38:46 +0100 (CET) Jan Engelhardt said:
>
> On Friday 2017-11-03 08:33, Pekka Paalanen wrote:
> >> > >
> >> > > wl_display_connect() always attempts to contact a server socket living
> >> > > at ${XDG_RUNTIME_DIR}/${WAYLAND_DISPLAY}.
> >
> >> > Modifying the meaning of WAYLAND_DISPLAY environment variable to
> >> > support also absolute paths has been proposed before IIRC. Maybe
> >> > resurrecting that work could be a way forward? Can anyone see a problem
> >> > with that?
> >>
> >> This would definitely work, so I don't object if this is the preference of
> >> other reviewers. I would prefer (for the reasons coming below) the
> >> /run/wayland/$WAYLAND_DISPLAY suggestion though.
> >>
> >> One note about this: this would contain a subtle change in behavior to
> >> existing users of $WAYLAND_DISPLAY. If somebody sets
> >> WAYLAND_DISPLAY="/wayland-0" currently, this works okay. The concatenation
> >> logic in wl_display_connect() results in a string
> >> "/run/user///wayland-0", which is valid despite the duplicate '/'. If
> >> $WAYLAND_DISPLAY is now examined for absolute-pathiness, the logic would
> >> probably see "/wayland-0" as an absolute path reference, and the connection
> >> attempt would fail.
>
> So, for comparison, the X11 DISPLAY variable is an abstract identifier only.
> libX11 checks that $DISPLAY matches /^:[0-9]+$/ and rejects attempts to use
> e.g. "/../"-kind of injection attacks.
>
> And I would think that the intent of WAYLAND_DISPLAY was very similar in that
> its creators saw it as an identifier rather than a path component. (It
> certainly has that _ring_ to it, given its proximity to X11's "DISPLAY" name.)
>
> As such, WAYLAND_DISPLAY maybe should be hardened to reject any '/',
> and consequently, a new variable ("WAYLAND_SOCKET"?) be introduced that,
> if set, 1. overrides WAYLAND_DISPLAY, 2. decidedly allows path specs
> to the desired effect so as to use /run/wayland/wayland-N.
how would it be "attacked"? so if we're just talking regular user processes,
the user would be exploiting themselves. right? by telling the app to connect
to another socket and compositor (fake or real... does it matter?). if it's a
setuid process (privileged) then ... this env var will not exist when run (or
should not and any other environment that escalates privilege should set or
sanitize this env var). yes - they could let's say create a proxy cpmpositor
and listen to all i/o or even fake it... but they can do this withotu full
paths. just
export WAYLAND_DISPLAY=myproxy
and have $XDG_RUNTIME_DIR/myproxy be your "exploit" server proxy. it can be
done without full paths. xdg runtime dir is intended to be written and used by
the user... you could make this dir not writable by any user launching
processes... this would be entirely strange and probably break a lot of apps
that have ipc sockets. ?
i'm curious as to the attack vector.
> Summary of (individual) proposals follows.
>
> >- modify WAYLAND_DISPLAY to support absolute paths which overrides
> > any search paths
>
> - introduce new WAYLAND_SOCKET
> - modify WAYLAND_DISPLAY to reject '/'
>
> >- when the current socket search fails, add one more place to look
> > in: /run/wayland/$WAYLAND_DISPLAY with the default "wayland-0" if
> > WAYLAND_DISPLAY is not set.
>
> - WAYLAND_SOCKET always overrides WAYLAND_DISPLAY
> - at most, automatic fallback if only if both WAYLAND_SOCKET and
>WAYLAND_DISPLAY are unset
>
--
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: New paths for Wayland sockets (Re: Enabling Android-style per application user ids)
On Fri, 3 Nov 2017 11:04:27 +0100 (CET) Jan Engelhardt said: > > On Friday 2017-11-03 10:37, Pekka Paalanen wrote: > > > >> Summary of (individual) proposals follows. > >> > >> >- modify WAYLAND_DISPLAY to support absolute paths which overrides > >> > any search paths > >> > >> - introduce new WAYLAND_SOCKET > >> - modify WAYLAND_DISPLAY to reject '/' > > > >What would be the functional difference to WAYLAND_DISPLAY accepting > >absolute paths? Why would a different environment variable make a > >difference? > > Well because you cannot establish for certain that people have or have not > already used WAYLAND_DISPLAY=/newsock in the concatenation sense. I think we can just call it a day on this and say anyone doing that has fundamentally made a mistake. They likely dont set the env var at all in fact. Wayland is still young and I think can tolerate this kind of change at this point. > (Depending on who you ask and how much weight they give to it, > breaking application interfaces is out of the question. That's all.) > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: New paths for Wayland sockets (Re: Enabling Android-style per application user ids)
On Fri, 3 Nov 2017 12:47:39 +0200 Pekka Paalanen said: > On Fri, 3 Nov 2017 11:04:27 +0100 (CET) > Jan Engelhardt wrote: > > > On Friday 2017-11-03 10:37, Pekka Paalanen wrote: > > > > > >> Summary of (individual) proposals follows. > > >> > > >> >- modify WAYLAND_DISPLAY to support absolute paths which overrides > > >> > any search paths > > >> > > >> - introduce new WAYLAND_SOCKET > > >> - modify WAYLAND_DISPLAY to reject '/' > > > > > >What would be the functional difference to WAYLAND_DISPLAY accepting > > >absolute paths? Why would a different environment variable make a > > >difference? > > > > Well because you cannot establish for certain that people have or have not > > already used WAYLAND_DISPLAY=/newsock in the concatenation sense. > > > > (Depending on who you ask and how much weight they give to it, > > breaking application interfaces is out of the question. That's all.) > > Ah, that, ok. I thought this was about the security stuff you referred > to. But given the same rationale, we cannot forbid / in WAYLAND_DISPLAY > either. security here i think is a red herring. i can effectively trick libwayland-client to connect to an abs path by setting XDG_RUNTIME_DIR AND WAYLAND_DISPLAY. so ... effectively same thing. it will force all xdg runtime stuff to be in that same dir... but i think abs path for wl display specifically being a security issue is a red herring, unless there is something none of us can think of. then we have the problem already with runtime dir env var and wl display too like above. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Position set/get prototype template
On Mon, 8 Aug 2022 16:42:02 +0100 Daniel Stone said: > Igor, > > On Mon, 8 Aug 2022 at 15:54, Igor Korot wrote: > > Or even better - when one of you will need to quickly create a > > "proof-of-concept" application that will jump all over the places on every > > startup... > > We've written applications for years. We know how to make it work. > We've explained to you how to make it work. It may not work in the > exact way you have in your head, but the real usecases can and do > work, even if you won't listen to patient explanations. > > This discussion has more than run its course by now. Unfortunately as > you seem hellbent on continuing to repeat the same thing over and over > without listening to anything else being said, your posts will now be > moderated. What Daniel said. My mistake for putting fuel on the fire and explaining why Wayland does not have explicit positioning. I hoped to provide some explaining of the history of pain that led up to things being this way (and there are decades of experience per experienced Wayland developer who supports this). We've all done everything from display servers to window managers to compositors, toolkits, applications and more for many decades. Solve the corner cases not already solved. Don't do "give me a sledgehammer to break the world with" with explicit positioning. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com
Re: Weston backend support for non gpu boards
On Wed, 24 Apr 2024 14:06:17 +0530 Akshaya Maran said: > Hi, > > I am using the Weston 11 version. fbdev backend i s dropped in weston 11 . > Is there any alternative to the fb-dev backend since there is no drm device > in my custom board. add kms/drm driver for your display unit? the expectation is anything sensible should have one. if you have fbdev then there is some kind of driver there and a framebuffer of some sort. adapt it so it also exposes a drm device for the display unit. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com
Re: Wayland design principles (Re: wayland and gambas)
sson. > It is unacceptable for the many who have customized their Linux world with > their own work. > > There is worry in our community that Wayland is going to take over and x11 > will become obsolete. It's inevitable. We're just arguing on timescales (I think Wayland will need more time to mature but it'll get there). > And because nobody at Wayland seems to care to provide a means of placement > choice, should you want/need it. > > I hope you understand. We understand... better than you know. As someone who has built all the things you are complaining about... Many times over... I agree with the Wayland approach. I've sat on all sides of this fence. The WM/compositor side, the app and toolkit side. I've written them all and Wayland is making the right choices. > > The Wayland philosophy on this has been that the compositor knows best > > where > > to place the windows for regular applications. That does not include fixed > > desktop components, such as the task bar or desktop wallpapers, but those > > need > > to communicate directly with the compositor they are a desktop for. > > > > For the most part, sure why not? > > For the case detailed above. Most definitely not mine and many others > philosophy. See above. :) It's the compositors job to invisibly do what you want - remember where to put your windows. It's your job to make this sane/possible with sensible unique naming. > > Someone may have said they had a need to grab the keyboard and obtain key > > events even when the window wasn't focused. But why is that? X11 uses > > keyboard-grabbing to implement dismissal of popup menus, something that > > Wayland solved properly instead. Another use-case was to ensure that focus > > couldn't be stolen while typing a password... again, Wayland can solve > > that by > > the window describing itself as "I'm recording a password" so the > > compositor > > can implement a higher focus-stealing threshold or other > > attention-grabbing > > techniques (how many of us have typed passwords in the wrong window?). > > > > Other things are done for security: you can't inject events into other > > windows, so we lose the auto-type feature in KeyPassXC. You can't perform > > arbitrary screengrabs any more, but instead screensharing applications > > must > > ask the compositor to let the user choose which window(s) to share. > > > > -- > > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org > >Principal Engineer - Intel DCAI Cloud Engineering > > > > Yes I forgot the screen grabs not being available is a downgrade for us. > For example simple colour picker routines many of us have don't work now. > Eg. > PickedColour = Desktop.Screenshot(Mouse.x, Mouse.y).Image[0, 0] Yup - but there are good privacy/security reasons for this. The old world of X11 didn't give a hoot about this. These days people do. Imagine all the people going "I remember the days of clear-text internet protocols. I just had to sniff the wire and I could inspect what was going on and shape/route traffic based on content". Now everyone goes "No - we encrypt it - no more of that for you. Too bad". Priorities have changed. Wayland is built/designed to allow for a world where every app on your desktop is not fully trusted to be "nice". It's is hard to undo designs without breaking a lot. It's easier to carefully open up specific features on an as-needed basis where really needed. > It was that simple. > > Mostly Wayland seems okay. > But paranoid it seems as mostly citing "security" for all it's misgivings. > I'm not a govt agency my computer has no nasty secrets I need to hide and > is secure enough for me. You might not be, but you may run some app you download from some random place on the internet you THINK is nice (some sodoku game trinket thing) but it's actually trying to steal your banking details... This is only getting worse in a world of snaps/flatpaks ... See above. It's easier to design to be restrictive first then solve the specific special cases of need carefully than be unrestricted and then clamp down. And it's not just about security. It's about handling all the cases you don't think of (see above the remembering size/position - if you only thought that far, then you didn't think enough). > I hope you understand our dilemma here. > > With respects > Bruce Steers -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com
Re: Wayland design principles (Re: wayland and gambas)
On Wed, 1 May 2024 09:35:30 +0200 (CEST) Jan Engelhardt said: > > On Tuesday 2024-04-30 07:23, Carsten Haitzler wrote: > >> > >> Although gambas provides a Settings.Write(window_name) / > >> Settings.Read(window_name) that saves/restores the window placement and > >> size. It's bearable Wayland does not handle this. > > > >YOU should never be handling this. It's like saying "I'm used to having to > >hand-crank my car's motor for it to start... why can't I keep doing that?". > > In keeping with the car analogy: one *can* handcrank the motor, one just > needs a vehicle that implements *that*, so like youtu.be/4SZExEgLT_0 or, > indeed, running gambas on an X11 interface (xorg-server, Xnest, > Xwayland...) > > >If all you do is the above, you've barely scratched the surface of > >"remembering my window". Things you don't handle above: > > > >1. Stacking remembering (relative to other things you may know nothing about > >like someoene else's windows) > > I do not think anybody seriously uses overlaps, because searching > in stacks (Alt-Tab or whatever method) is kinda inefficient. People > either go big screen, workspaces/virtual desktops, or (say) temporarily > exiting/suspending an editor to run the compiler. In the case mentioned here these "desktop gadgets" once you resize/scale the screen if you then scale the sizes/coords and deal with minimum surface sizes you may end up with overlaps between multiple process gadget windows (Each gadget is 1 window for 1 client/app) and the compositor can solve this by guessing they are aligned in a row and "line the up again". Apps can't do this - they don't know the other windows even exist. This also can happen with regular windows. I actually often tile my windows by hand (it's easy in E due to window resistance making it a doddle). If i e.g. switched from 3840x1440 to a 2560x144 monitor - I'd not rescale but I'd have to re-position and re-size as I had not adjusted scaling but adjusted screen aspect ratio. Each terminal of the set of 15 I have is a different window and process. Admittedly E doesn't quite realize it is a perfect grid. It's policy on such screen resizes is to remember window positions based on nearest screen anchor (top-left, top-middle, top-right, left-middle, center, right-middle, bottom-left, bottom-middle, bottom-right). This handles going up in size nicely. Down leaves some manual fiddling still but may lead to overlaps. Something I probably can fix for sure. :) -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com
Re: Wayland design principles (Re: wayland and gambas)
On Tue, 30 Apr 2024 17:21:41 -0700 Thiago Macieira said: > On Monday 29 April 2024 22:23:44 GMT-7 Carsten Haitzler wrote: > > > There is worry in our community that Wayland is going to take over and x11 > > > will become obsolete. > > > > It's inevitable. We're just arguing on timescales (I think Wayland will need > > more time to mature but it'll get there). > > I used to too, but I think we'll see X.org removed from non-LTS distros by > the end of the decade. At a minimum, I don't see it being offered as a > default for desktop distros; you'll need to install with Wayland and then > later switch to X11. We probably mostly agree here - X will be around for another 5-10y imho in distros but it'll become an optional extra install towards the end of that. At some point - maybe in 10-15 it might enter "Xwayland only" mode. But in braod strokes I think we agree. > > You might not be, but you may run some app you download from some random > > place on the internet you THINK is nice (some sodoku game trinket thing) > > but it's actually trying to steal your banking details... This is only > > getting worse in a world of snaps/flatpaks ... > > And even if most people on this list don't do that, there are people who do. > I refuse to run proprietary code as much as I can, and when I can't I want it > to run as a separate user (thus non-graphical) with very strong system > protections in the systemd .service file. 100%. I also avoid these like the plague wherever I can, but it does not remove the obligation for us to build a Wayland universe for the long term future than CAN be sandboxed and apps have limit ability to cause havoc/problems. > But I have several colleagues who download flatpaks and similars. Wayland has > to be designed with that in mind. > > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org >Principal Engineer - Intel DCAI Cloud Engineering > > > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com
Re: req x11 keyboard shortcuts
On Tue, 3 Dec 2024 00:54:07 + (UTC) G said: > hi, > > let me please apologize in advance for either not following some message > protocol or inadvertently starting some war / battle war / ug. i am only the > disconnected end user. > > > people who know keyboard shortcuts, use & love them for its just quicker. is > it possible to please incorporate the standard x11 (and microsoft windows) > keyboard shortcuts to run a command (alt+f2), manipulate window attributes > (alt+space), etc, etc. this has nothing to do with wayland. it also has nothing to do with x11 (it has no standard key bindings.. i'm going to ignore vt switching). these are entirely handled by your wm/desktop setup of choice, whatever that is. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com
Re: [RFC] Feature proposal to speed up the computer when the display is turned off.
On Sun, 9 Feb 2025 22:52:12 -0500 Vitalii said: > Basically, the kernel freezes the GUI tasks when > the display is turned off so that they don't run but > also don't exit. When the display is turned back on > again or a command returns any exit code, all GUI > tasks are unfrozen. And this loads right before the > first process that the init system launches. this has nothing to do with wayland... it's a matter for your desktop environment or daemons below that in the stack to have such policies. if by freeze you mean SIGSTOP then you're likely in for trouble too as many apps will need to do little things in the background - like an email client poll for email. an irc client simply read its tcp connection for irc messages. without doing this eventually buffers will fill and connections and thus messages get lost. but again - not a wayland matter. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com
