Re: [PATCH] xdg-shell: remove constraints for fullscreen
To be clear, the patch does break backwards compatibility with compositor behavior -- it only weakens a guarantee by saying that transparent fullscreen content is undefined. Existing compositor behavior is still allowed. However, it does mean that clients might not get the output they desire under new rules. It also does not make any new guarantees for a client -- a fullscreen transparent terminal might show surfaces underneath, or it might not. That hardly seems useful to me from a client perspective. That said, adding a new request does not seem like a good solution to me -- if the user presses a compositor key shortcut, should the app be in transparent or opaque fullscreen mode? It might make sense to have a special "set_fullscreen_blend_mode" that clients can use to configure their fullscreen appearance in all cases. I do not imagine this will change often, so it likely does not need to be a state. On Fri, Jun 21, 2019, 8:43 PM Michael Blumenkrantz < michael.blumenkra...@gmail.com> wrote: > Hi, > > Some compositors and client toolkits do rely on the existing wording. > Occlusion culling is used for (obvious) performance reasons in fullscreen > cases. If the fullscreen surface is not opaque, clients can still rely on > the compositor's handling of fullscreen states using the current wording > and prioritize resources for this fullscreen surface even if there are > other surfaces which are visible behind it. This is especially true for > embedded cases. > > Given that releases and products have already shipped that rely on this > language, and that the terminology and language used here is a core > functionality of the feature, it absolutely cannot be changed. > > > Regards, > Mike > > On Fri, 21 Jun 2019 14:32:34 -0400 > "Drew DeVault" wrote: > > > On Wed Jun 19, 2019 at 10:41 PM Jonas Ådahl wrote: > > > This changes the semantics in a non-backward compatible way; clients > > > relying on the currently defined behavior would break, so I'll have to > > > nack this change. You'd have to add a `set_fullscreen_translucent` or > > > something like that if the described behavior is needed. > > > > To re-use an argument that was brought up in the xdg-decoration > > discussion: compositors are just going to do whatever they want here, > > and this sets up expectations accordingly. Wayfire already disregards > > this clause, and consider this an announcement of Sway's intentions do > > to the same. > > > > In any case, I don't think this grossly affects the behavior clients > > have come to rely on. I sought some feedback on this patch privately > > before posting it to consider these concerns upfront. The main use-case > > for the original wording was found to be media players which rely on > > this behavior for letterboxing when the aspect ratio between the output > > and the video differs - which is addressed in the proposed wording. > > > > Additionally, the original wording never made any promises as to the > > relationship between the fullscreened surface and the output its shown > > on. One notable example is that the unreliability of wl_output's > > width/height specifications forces (correctly so) users to continue to > > use configure events to communicate the desired size. This is especially > > necessary with non-traditional outputs like VR headsets. Implementation > > details like direct scan-out, which is only possible given the > > constraints in the original wording, aren't actually guaranteed - but > > are not ruled out by the new wording. > > > > What do you think? Does that rationale make more sense? > > ___ > > wayland-devel mailing list > > wayland-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] xdg-shell: remove constraints for fullscreen
Hi, Some compositors and client toolkits do rely on the existing wording. Occlusion culling is used for (obvious) performance reasons in fullscreen cases. If the fullscreen surface is not opaque, clients can still rely on the compositor's handling of fullscreen states using the current wording and prioritize resources for this fullscreen surface even if there are other surfaces which are visible behind it. This is especially true for embedded cases. Given that releases and products have already shipped that rely on this language, and that the terminology and language used here is a core functionality of the feature, it absolutely cannot be changed. Regards, Mike On Fri, 21 Jun 2019 14:32:34 -0400 "Drew DeVault" wrote: > On Wed Jun 19, 2019 at 10:41 PM Jonas Ådahl wrote: > > This changes the semantics in a non-backward compatible way; clients > > relying on the currently defined behavior would break, so I'll have to > > nack this change. You'd have to add a `set_fullscreen_translucent` or > > something like that if the described behavior is needed. > > To re-use an argument that was brought up in the xdg-decoration > discussion: compositors are just going to do whatever they want here, > and this sets up expectations accordingly. Wayfire already disregards > this clause, and consider this an announcement of Sway's intentions do > to the same. > > In any case, I don't think this grossly affects the behavior clients > have come to rely on. I sought some feedback on this patch privately > before posting it to consider these concerns upfront. The main use-case > for the original wording was found to be media players which rely on > this behavior for letterboxing when the aspect ratio between the output > and the video differs - which is addressed in the proposed wording. > > Additionally, the original wording never made any promises as to the > relationship between the fullscreened surface and the output its shown > on. One notable example is that the unreliability of wl_output's > width/height specifications forces (correctly so) users to continue to > use configure events to communicate the desired size. This is especially > necessary with non-traditional outputs like VR headsets. Implementation > details like direct scan-out, which is only possible given the > constraints in the original wording, aren't actually guaranteed - but > are not ruled out by the new wording. > > What do you think? Does that rationale make more sense? > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] xdg-shell: remove constraints for fullscreen
On Wed Jun 19, 2019 at 10:41 PM Jonas Ådahl wrote: > This changes the semantics in a non-backward compatible way; clients > relying on the currently defined behavior would break, so I'll have to > nack this change. You'd have to add a `set_fullscreen_translucent` or > something like that if the described behavior is needed. To re-use an argument that was brought up in the xdg-decoration discussion: compositors are just going to do whatever they want here, and this sets up expectations accordingly. Wayfire already disregards this clause, and consider this an announcement of Sway's intentions do to the same. In any case, I don't think this grossly affects the behavior clients have come to rely on. I sought some feedback on this patch privately before posting it to consider these concerns upfront. The main use-case for the original wording was found to be media players which rely on this behavior for letterboxing when the aspect ratio between the output and the video differs - which is addressed in the proposed wording. Additionally, the original wording never made any promises as to the relationship between the fullscreened surface and the output its shown on. One notable example is that the unreliability of wl_output's width/height specifications forces (correctly so) users to continue to use configure events to communicate the desired size. This is especially necessary with non-traditional outputs like VR headsets. Implementation details like direct scan-out, which is only possible given the constraints in the original wording, aren't actually guaranteed - but are not ruled out by the new wording. What do you think? Does that rationale make more sense? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland-protocols scope and governance
Followed-up off-list while fixing issues with my mail client, copying summary here for posterity: On Wed Jun 19, 2019 at 5:08 PM Jonas Ådahl wrote: > Lets not be childish; noone is trying to weasel anything here, and I > don't understand what you're trying to accomplish by implying that. I didn't mean weasel wording in a pejorative way, just as a metaphor for trying to nail down a precise definition which includes the protocols the speaker wants and excludes those they don't (myself included). > On Wed, Jun 19, 2019 at 10:52:32AM -0400, Drew DeVault wrote: > > How does xdg-foreign fit into this definition? > > xdg-foreign is an edge case but IMHO it fits in the definition. > xdg-shell deals with stacking order of the dialogs of an application. > xdg-foreign extends this behaviour by allowing two clients to "act as > one". The current users are the xdg-desktop-portal backend, but it's > something that's needed for e.g. modal dialogs for out-of-process > plugins and similar things. > > It's far from task bar like functionality, if that's what you are trying > to compare it to. I don't think xdg-foreign is especially different from xdg-toplevel-management so far as the applicability of this definition is concerned. It comes across as seeing XDG as suitable for anything GNOME et al needs it for, and unsuitable for things wlroots et al needs it for (though perhaps unconsciously). I think this is derived from the fundamental philosophical differences between our design approaches, but not necessarily from the definition of "XDG". Put another way, what are some protocols GNOME would implement which are (1) useful for other compositors and (2) more suited to the ext namespace than the xdg namespace? > Again, I believe the definition should make it clear that it's for > applications, not desktop components. I'm not trying to weasel anything > here, I'm trying to avoid making anyone believe writing a task bar is > the same thing as writing an application that is expected to work > everywhere. Again referring to the xdg-foreign protocol, an argument could be made that the sandboxing tooling it was designed for is a feature of the compositor. After all, the sandboxing mechanism holds a privileged position on the desktop model, and xdg-foreign is a mechanism it uses for plumbing its way around self-imposed constraints, rather than an inherent property of application windows. I'm not arguing that xdg-foreign isn't suitable for the XDG namespace, but rather showing that a similar argument against xdg-toplevel-management's inclusion can be applied to xdg-foreign. I guess, in short, I feel that xdg-toplevel-management is a fit for the XDG namespace because: - It's more or less a direct extension of the xdg-shell protocol - It deals entirely with the management of application windows The argument against comes across as: - It's not something fully integrated desktops would use Which to me feels like gatekeeping the xdg namespace. I want to establish namespaces based on consistent rationale that we can all incorporate our work into, and that's probably going to mean being somewhat more lenient than we have been in the past. That's a necessary concession for this governance overhaul's success as a whole. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: EXT: Multiple touchscreen environment with Weston
On Fri, 21 Jun 2019 07:40:12 + Theo BUENO wrote: > Yes, unfortunately it is unlikely that open-source drivers with DRM > support will happen anytime soon for my use-case. > > Do you have an idea of the amount of work required to make multi-seat > and touchscreen binding work on the fbdev backend ? Hi Theo, I believe the only thing you need is to have the fbdev backend actually provide more than one output and name each uniquely. Everything about the input side, e.g. WL_OUTPUT for touch input devices, is in code shared with the DRM-backend, so I think it should just work. My memory is hazy, but you might even find some patches in the mailing list archives making fbdev-backend open all fbdev devices instead of just one. I forget if that was just talk or if there actually were patches. That is, if you mean one physical seat with multiple outputs. If you mean multiple physical seats one output each, then it's possible you don't need code changes. > More generally what > are the plans for this backend in future versions of Weston ? The plan is to remove it. It was already suggested around the previous release, but one user wished for it to stay, so it stayed. The maintenance burden on the fbdev-backend is low, so there is no hurry in removing it, but further development of it is discougared. If you wrote patches for it, they might not get merged. > I am well > aware that fbdev is obsolete and should be replaced by DRM but a lot of > legacy hardware will never see that change. Indeed, yet writing a DRM driver providing the same feature set as an fbdev device should be very easy today, thanks to all the helpers aimed for that exact use case in the kernel DRM. If you want to know more about this, reach out on dri-devel mailing list or ask e.g. Daniel Vetter for pointers. Mind that I'm not talking about EGL on fbdev. That bit of code was removed from Weston upstream a long time ago. If you need GPU acceleration and a FOSS driver project does not exist already then there is no easy way forward. Thanks, pq pgpx30vHmI0oW.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: EXT: Multiple touchscreen environment with Weston
On Thu, 2019-06-20 at 12:22 +0300, Pekka Paalanen wrote:
> On Thu, 20 Jun 2019 05:19:09 +
> "Ray, Ian (GE Healthcare)" wrote:
>
> > > On 17 Jun 2019, at 17.45, Theo BUENO wrote:
> > >
> > > Hello everyone,
> > >
> > > I am (relatively) new Weston user working with industrial
> > > embedded
> > > Linux systems. I am seeking for advice regarding a Weston use
> > > case.
> > >
> > > I have been trying to understand how would one map touchscreens
> > > to
> > > unique displays on a system which has several touchscreen
> > > displays.
> > > It is my understanding that prior to Weston 1.7, it could be done
> > > via the WL_OUTPUT udev variable for each touchscreen.
> >
> > We are using Weston 6 with libinput 1-13.0 and we use WL_OUTPUT for
> > this purpose.
> >
> > Sample log output:
> >
> > Jun 19 14:17:48 GE0040973102BC weston[305]: [14:17:48.764]
> > event1 -
> > DIALOGUE INC PenMount USB: is tagged by udev as: Touchscreen Jun 19
> > 14:17:48 GE0040973102BC weston[305]: [14:17:48.765] event1 -
> > DIALOGUE INC PenMount USB: device is a touch device : Jun 19
> > 14:17:48
> > GE0040973102BC weston[305]: [14:17:48.913] associating input device
> > event1 with output LVDS-1 (LVDS-1 by
> > udev)
> >
> > And UDEV rule:
> >
> > SUBSYSTEM=="input", KERNEL=="event[0-9]*",
> > ATTRS{modalias}=="usb:v14E1p6000*", … , ENV{WL_OUTPUT}="LVDS-1"
> >
> >
> > > Now with more recent versions of Weston, by reading through
> > > documentation and code, it is also my understanding that such a
> > > use
> > > case is addressed via logical seats (WL_SEAT) or through physical
> > > seats (ID_SEATS) on a multi-compositor/GPU design.
> > >
> > > Problem is, on the embedded platform I am working on (NXP i.MX6),
> > > there can only be one compositor instance bound to the GPU
> > > driving
> > > multiple displays. With DRM support, I believe assigning a "seat"
> > > option to each "output" entry in weston configuration is enough
> > > to
> > > constrain each touchscreen to their respective displays.
> > > Unfortunately, on i.MX6 there is no DRM support with proprietary
> > > drivers. The only available backend is fbdev, which after code
> > > review does not seem to allow for multiple seat configuration on
> > > the same weston instance.
> > >
> > > Am I correct to assume that my only option from here is either
> > > to:
> > > 1) Bring multi-seat support to fbdev backend
> > > 2) Move to free drivers with DRM support
> > >
> > > Have I missed something / Are my assumptions correct ?
>
> Hi,
>
> Ian already provided you the solution, but I want to explain a little
> more.
>
> Physical seats will have a separate compositor instance running for
> each. This means each physical seat may have a different user
> logged in, doing their very own work securely isolated from the other
> physical seats. Since DRM devices cannot the "split" at the kernel
> UAPI
> level, you will need one DRM device for each physical seat. Physical
> seats are intended to give the feeling of using completely separate
> machines.
>
> Inside one physical seat, you can have one or more logical seats. A
> logical seat means more or less a set of input devices that belong
> together and share the same keyboard focus, pointer cursor, and
> touches. Logical seats do not really concern outputs, because one can
> (at least in the current implementation) simply move e.g. pointer
> from
> one output to another. If you have two logical seats, you may have
> two
> independent pointers on screen, each acting independently on the same
> application windows.
>
> If you want to have a single physical seat with multiple
> touchscreens,
> you do what Ian explained. If you wanted each touchscreen to be a
> part
> of a different physical seat, then you'd use ID_SEAT to tag them
> accordingly. If any physical seat may have more than one output, then
> you really should set WL_OUTPUT to ensure the touch input gets mapped
> correctly.
Thank you both to you and Ian for the great explanation. I was able to
validate all of that on my test setup, with mainline kernel and drivers
and a DRM backend.
> If you wanted each touchscreen to be independent from each other but
> still part of the same physical seat, you would tag them with
> WL_SEAT.
> I think Weston does not handle setting outputs of a DRM device to
> different WL_SEATs, so you still need the WL_OUTPUT property on the
> touch devices to associate them with the right output.
That was my initial confusion here, I thought WL_OUTPUT disappeared
because I could not find any reference in the code after Weston 1.6,
but instead the feature had just been moved to libinput.
Indeed both WL_OUTPUT and WL_SEAT were needed for each touchscreen in
order for my setup to work correctly.
> When you have two touchscreens in the same logical seat, and you have
> one finger down on one touchscreen and another finger down on another
> touchscreen, it will count as if you had two fingers down on o
