GNOME.org
 

Re: Collaboration on standard Wayland protocol extensions

On 2016-03-29 11:31 AM, Carsten Haitzler wrote:

my take on it is that it's premature and not needed at this point. in fact i
wouldn't implement a protocol at all. *IF* i were to allow special access, i'd
simply require to fork the process directly from compositor and provide a
socketpair fd to this process and THAT fd could have extra capabilities
attached to the wl protocol. i would do nothing else because as a compositor i
cannot be sure what i am executing. i'd hand over the choice of being able to
execute this tool to the user to say ok to and not just blindly execute
anything i like.


I don't really understand why forking from the compositor and bringing
along the fds really gives you much of a gain in terms of security. Can
you elaborate on how this changes things? I should also mention that I
don't really see the sort of security goals Wayland has in mind as
attainable until we start doing things like containerizing applications,
in which case we can elimitate entire classes of problems from this
design.


all a compositor has to do is be able to capture a video stream to a file. you
can ADD watermarking, sepia, and other effects later on in a video editor. next
you'll tell me gimp is incapable of editing image files so we need programmatic
access to a digital cameras ccd to implement effects/watermarking etc. on
photos...


I'll remind you again that none of this supports the live streaming
use-case.


currently possible with ffmpeg. How about instead we make a simple
wayland protocol extension that we can integrate with ffmpeg and OBS and
imagemagick and so on in a single C file.


i'm repeating myself. there are bigger fish to fry.


I'm repeating myself. Fry whatever fish you want and backlog this fish.


eh? ummm that is what happens - unless you close the lid, then internal display
is "disconnected".


I'm snipping out a lot of the output configuration related stuff from
this response. I'm not going to argue very hard for a common output
configuration protocol. I've been trying to change gears on the output
discussion towards a discussion around whether or not the
fullscreen-shell protocol supports our needs and whether or how it needs
to be updated wrt permissions. I'm going to continue to omit large parts
of your response that I think are related to the resistance to output
configuration, let me know if there's something important I'm dropping
by doing so.


a protocol with undefined metadata is not a good protocol. it's now goes blobs
of data that are opaque except to specific implementations., this will mean
that other implementations eventually will do things like strip it out or damage
it as they don't know what it is nor do they care.


It doesn't have to be undefined metadata. It can just be extensions. A
protocol with extensions built in is a good protocol whose designers had
foresight, kind of like the Wayland protocol we're all already making
extensions for.


but it isn't the user - it's some game you download that you cannot alter the
code or behaviour of that then messes everything up because its creator only
ever had a single monitor and didn't account for those with 2 or 3.


But it _is_ the user. Let the user configure what they want, however
they want, and make it so that they can both do this AND deny crappy
games the right to do it as well. This applies to the entire discussion
broadly, not necessarily just to the output configuration bits (which I
retract).


because things like output configuration i do not see as needing a common
protocol. in fact it's desirable to not have one at all so it cannot be abused
or cause trouble.


Troublemaking software is going to continue to make trouble. Further
news at 9. That doesn't really justify making trouble for users as well.


In practice the VAST majority of our users are going to be using one or
more rectangular displays. We shouldn't cripple what they can do for the
sake of the niche. We can support both - why do we have to hide
information about the type of outputs in use from the clients? It
doesn't make sense for an app to get fullscreened in a virtual reality
compositor, yet we still support that. Rather than shoehorning every
design to meet the least common denominator, we should be flexible.


they are not crippled. that's the point. in virtual reality fullscreen makes
sense as a "take over thew world", not take over the output to one eye.for
monitors on a desktop it makes sense to take over that monitor but not others.
so it depends on context and the compositors job is to interpret/manage/deal
with that context.


I don't really understand what you're getting at here.


sorry. neither in x11 nor in wayland does a wm/compositor just have the freedom
to resize a window to any size it likes WITHOUT CONSEQUENCES. in x11 min/max
size hints tell the wm the range of sizes a window can be sensibly drawn/laid
out with. in wayland it's communicated by buffer size. if you choose to ignore
this then you get to deal with the consequences as in your screenshot.


Here's gnome-calculator running on x with a tiling window manager:

https://fuwa.se/f/YIkvDi.png

Here's the wayland screenshot again for comparison:

https://sr.ht/Ai5N.png

Most apps are fine with being told what resolution to be, and they
_need_ to be fine with this for the sake of my sanity. But I understand
that several applications have special concerns that would prevent this
from making sense, and for those it's simply a matter of saying that
they'd prefer to be floating. This is actually one of the things in the
X ecosystem that works perfectly fine and has worked perfectly fine for
a long time.


i would not just blindly ignore such info. i'd either pad with black/background
and keep to the buffer size or at least scale while retaining aspect ratio (and
pad as needed but likely less).


Eww.


interestingly now you complain about clients having EXPLICIT control and you
say "oh well no ... this is bad for tiling wm's" ... yet when i explain that
having output configuration control etc. etc. is harmful it's something that
SHOULD be allowed for clients... (and where the output isn't even a client
resource unlike the buffers that they render which is one).


What I really want is _users_ to have control. I don't like it that
compositors are forcing solutions on them that doesn't allow them to be
in control of how their shit works.


Users should be free to choose the tools they want. dmenu is much more
flexible and scriptable than anything any of the DEs offer in its place


that is your wm's design. that is not the design of others.



they want something integrated...


okay


...and don't want external tools.


Bullshit. Give them something integrated and they'll use it. However,
there's no reason why the integrated solution and the external tools
couldn't both exist. The users don't give a fuck about whether or not
the external tools exist. They are apathetic about it, they don't
actively "not want it", and their experience is in no way worsened by
the availablility of external tools. Those who do want external tools,
however, have a worsened experience if we design ourselves into a black
box that no one can extend.


- you just pipe in a list of things and the user picks one. Don't be
fooled into thinking that whatever your DE does for a given feature is
the mecca of that feature. Like you were saying to make other points -


no - but i'm saying that this is not a COMMON feature among all DEs. different
ones will work differently. gnome 3's chosen design these days is to put it
into gnome shell via js extensions, not the gnome 2 way with a separate panel
process (ala dmenu). enlightenment does it internally too and extend
differently. my point is that what you want here is not universal.


I'm not suggesting anything radical to try and cover all of these use
cases at once. Sway has a protocol that lets a surface indicate it wants
to be docked somewhere, which allows for custom taskbars and things like
dmenu and so on to exist pretty easily, and this protocol is how swaybar
happens to be implemented. This doesn't seem very radical to me, it
doesn't enforce anything on how each of the DEs choose to implement
their this and that.


there are fewer contributors to each DE than you might imagine. DEs are


that is exactly what i said in response to you saying that "we have all the
resources to do all of this" when i said we don't... :/ we don't - resources
are already expended elsewhere.


We've both used this same argument from each side multiple times, it's
getting kind of old. But I think these statements hold true:

There aren't necessarily enough people to work on the features I'm
proposing right now. I don't think anyone needs to implement this _right
now_. There also aren't ever enough people to give every little feature
of their DE the attention that leads to software that is as high quality
as a similar project with a single focus on that one feature.


Be flexible enough for users to pick the tools they want.


a lifetime of doing wm's has taught me that this approach is not the best. you
end up with a limiting and complex protocol to then allow taskbars, pagers and
so on to be in "dmenus" of this world. this is how gnome 1.x and 2.x worked. i
added the support in e long ago. i learned that it was a limiter in adding
features as you had to conform to someone elses idea of what virtual desktops
are etc.


A lifetime of using and customizing and scripting WMs that are more
composable and configurable than e, gnome, kde, and most of the other
Big Ones has led me to the opposite conclusion. I'm not suggesting we do
these sorts of efforts ad nauseum. I don't think we're heading towards a
situation where we're agreeing on the implementation of virtual
desktops. I'm putting forth a small handful of important, core features
that we are all going to have to support in some way or another to even
qualify as wayland compositors and subvert X's domainance over the
desktop.


these panels/taskbars/shelves/whatever are best being closely integrated into
the wm.


You don't provide any justification for this, you just say it like it's
gospel, and it's not. I will again remind you that not everyone wants to
buy into a desktop environment wholesale. They may want to piece it
together however they see fit and it's their god damn right to. Anything
else is against the spirit of free software.


These features have to get done at some point. Backlog your
implementation of these protocols if you can't work on it now.


that's what i'm saying. :)


In this case, I'm not seeing how your points about what order things
need to be done in matters. Now is the right time for me to implement
this in Sway. The major problems you're trying to solve are either
non-issues or solved issues on Sway, and it makes sense to do this now.
I'd like to do it in a way that works for everyone.


You misunderstand me. I'm not suggesting that these apps be crippled.
I'm suggesting that, during the negotiation, they _object_ to having the
server draw their decorations. Then other apps that don't care can say
so.


aaah ok. so compositor adapts. then likely i would express this as a "minimize
your decorations" protocol from compositor to client, client to compositor then
responds similarly like "minimize your decorations" and compositor MAY choose
to not draw a shadow/titlebar etc. (or client responds with "ok" and then
compositor can draw all it likes around the app).


I think Jonas is on the right track here. This sort of information could
go into xdg_*. It might not need an entire protocol to itself.


I don't want to rehash this old argument here. There's two sides to this
coin. I think everyone fully understands the other position. It's not
hard to reach a compromise on this.


it's sad that we have to have this disagreement at all. :) go on. join the dark
side! :) we have cookies!


Never! I want my GTK apps and my Qt apps to have the same decorations,
dammit :) Too bad I don't have much hope for making my cursor theme
consistent across my entire desktop...


What, do you expect to tell libavcodec to switch pixel formats
mid-recording? No one is recording their screen all the time. Yeah, you
might hit performance issues. So be it. It may not be ideal but it'll
likely be well within the limits of reason.


you'll appreciate what i'm getting at next time you have to do 4k ... or 8k
video and screencast/capture that. :) and have to do miracast... on a 1.3ghz
arm device :)


I'll go back to the earlier argument of "we shouldn't cripple the
majority for the sake of the niche". Who on Earth is going to drive an
8K display on a 1.3ghz ARM device anyway :P

--
Drew DeVault
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]