Re: [RFC] Interface for injection of input events
On Wed, 2017-03-22 at 11:00 +0800, Jonas Ådahl wrote: > On Wed, Mar 22, 2017 at 12:23:46PM +1000, Peter Hutterer wrote: > > > > == Authentication/Identification == > > The goal is to filter clients based on some white/blacklist, so > > that e.g. > > xdotool can access this interface but others cannot. > > > > This is a big ¯\_(ツ)_/¯ for now, I don't now how to do this > > reliably. > > It's trivial to do per user, but per-process is difficult. DBus > > filters > > are largely limited to per-users. It's possible to get the process > > ID of a > > sender but going beyond that is unreliable (kernel doesn't > > guarantee comm > > being accurate). > > > > Requiring applications to bind to a bus name merely restricts them > > to being > > a singleton, there is no guarantee the application that binds > > org.freedesktop.org.WoodoTool.auth.xdotool is actually xdotool. > > > > The option that comes closest so far is some pre-shared key between > > compositor and application. That would need to be worked into the > > API, but > > it also relies on all participants to keep the key encrypted in > > memory and > > the various configuration files. > > > > So it's not clear whether we can do anything beyond a basic on/off > > toggle on > > whether to allow events from fake input devices. Debatable if such > > a crude > > mechanism is useful. > > > > > > Either way, this is a problem that *must* be solved but not > > necessarily one > > that affects the API itself (beyond what is required to make it > > technically feasable, e.g. passing cookies around) > > This could be left up to flatpak et.al, couldn't it? Coming up with a > authentication mechanism that likely can be worked around without > proper > sandboxing doesn't sound relaible. CC:ing Alex regarding this. Flatpak does indeed handle this, but it would really only work if all the apps on your system are sandboxed. I.e, we can identify a flatpak due to how we set it up when starting it, which the app cannot change from inside the sandbox. However, any app not launched that way can pretend to be someone else. Essentially there are two tiers of app trust. Anything not flatpak (and snappy, etc) is considered trusted on the user bus, and can do "anything". So, in the golden future where all normal apps are sandboxed this could work, but for current distros there is no secure way to authenticate apps. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an ungodly guitar-strumming paramedic gone bad. She's a cosmopolitan paranoid safe cracker with only herself to blame. They fight crime! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Weird dispatch ordering of display events
I just spent some time debugging the wrong thing due to a weird change in wayland 1.5. A new queue was introduced for the display itself, handling things like delete_id. This queue is always dispatched, independent of what other queues are dispatched. However, it is always dispatched *before* the regular queue. This can look pretty weird in the client side WAYLAND_DEBUG output, because if you do an operation like bind()+display_roundtrip, you will see the delete_id for the roundtrip callback before you see any results from the bind. This doesn't seem to be a problem in practice, because we resolve the ids at event queue time, not dispatch time, so the events dispatch to the right place anyway, but it is very confusing when debugging. Maybe we can move the dispatching of the display queue to after dispatching the regular queue in wayland-client.c:dispatch_queue(), to make this a bit less confusing? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a Nobel prize-winning neurotic dwarf with a winning smile and a way with the ladies. She's a radical insomniac bounty hunter who inherited a spooky stately manor from her late maiden aunt. They fight crime! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weird dispatch ordering of display events
On tis, 2015-04-21 at 14:23 +0300, Pekka Paalanen wrote: > On Tue, 21 Apr 2015 11:17:17 +0200 > Alexander Larsson wrote: > > > I just spent some time debugging the wrong thing due to a weird change > > in wayland 1.5. A new queue was introduced for the display itself, > > handling things like delete_id. This queue is always dispatched, > > independent of what other queues are dispatched. > > > > However, it is always dispatched *before* the regular queue. This can > > look pretty weird in the client side WAYLAND_DEBUG output, because if > > you do an operation like bind()+display_roundtrip, you will see the > > delete_id for the roundtrip callback before you see any results from the > > bind. > > > > This doesn't seem to be a problem in practice, because we resolve the > > ids at event queue time, not dispatch time, so the events dispatch to > > the right place anyway, but it is very confusing when debugging. > > > > Maybe we can move the dispatching of the display queue to after > > dispatching the regular queue in wayland-client.c:dispatch_queue(), to > > make this a bit less confusing? > > Hi, > > but that would only solve it for the default queue, right? If you had > another user wl_event_queue, then looking at those events would still > be confusing. True. And it would still reorder the events, just move delete_id later rather than earlier. > I can't say off-hand whether that change would be ok. Instead, I'd like > to suggest other forms of protocol dumping (see to the end): > http://wayland.freedesktop.org/extras.html Yeah, i'll use these from now on instead. Thanks. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a short-sighted umbrella-wielding vagrant plagued by the memory of his family's brutal murder. She's a scantily clad antique-collecting archaeologist who believes she is the reincarnation of an ancient Egyptian queen. They fight crime! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
cross-client surface references
I understand the ideas behind not allowing one client to access a surface from another client. However, there are cases where we really want one client to refer to a surface (typically a xdg_surface) from another client. In particular, I have a need for this in my sandboxing work. Consider a setup where a sandboxed application wants to open a file. This will happen by the app doing a dbus work to a "portal" which will open a file chooser dialog outside the app, and then everything is done will return the file contents (not pathname) to the app. In this case we want the file chooser dialog to be parented to the proper window. Right now there is no way to do this, as the reference to the toplevel is client specific. What I would like is for some kind of opt-in request to the compositor where I would take an existing xdg_surface reference and create a "global" reference that i can serialize (over e.g. dbus) and restore in another process and use as an argument for xdg_surface.set_parent(). Obviously such a reference would be limited in what it could be used for, the other app should not be able to call any methods on it like changing/reading contents or state. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an oversexed skateboarding hairdresser with a winning smile and a way with the ladies. She's a virginal impetuous soap star with an incredible destiny. They fight crime! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: cross-client surface references
On fre, 2015-07-03 at 17:24 +0800, Jonas Ådahl wrote: > > As an option prior to ending up with taking the nested compositing > path, > I had a proposal that sounds similar to what you are talking about: > > http://lists.freedesktop.org/archives/wayland-devel/2013 > -March/008093.html > > What it does is allowing mapping a wl_surface with another client > pushes content to. In the linked RFC, the intention was to allow > mapping > it only as a subsurface, having the clients have some private method > for > doing size synchronization. Doing the same by allowing mapping an > xdg_surface is more complicated I imagine, since one cannot control > the > commit timing of the foreign surface if its not a subsurface, but > maybe > a wl_foreign_surface could solve that some other way. > > Another issue with the linked RFC is that it creates a wl_surface > from > some other object than wl_compositor, so that would have to change. > > When it was brought up, there were also ideas by using file > descriptors > some how as handles, passing around that instead, without having to > have > a global "surface ID" namespace of some kind. > > Other limitations with this is that such a surface wouldn't be able > to > create popup menus (xdg_popup) or sub windows (xdg_surface), so maybe > that is a deal breaker. How to direct input was another unsolved > question. Yes, this is a deal breaker. You can't write a file selector dialog without menus. Also, overall this seems to be the wrong design. The more privileged client in this case is the file selector part, so we should give minimal access to it from the file-requestor. I.e. it seems wrong that the sandboxed client should map the out-of-sandbox file dialog. > Maybe what is needed is an xdg_foreign. The Open File dialog provider > client (I don't think it should be part of the server process) would > create a xdg_surface, but before committing it, it'd "export" it > similar > to the linked RFC and some how share it with another client via D > -Bus. > The client wanting to open a file would then import the xdg_surface > by > creating a xdg_foreign from the shared handle. The xdg_foreign would > have > functionality that should be provided, for example set_parent but not > configure_ack. This would work, but it still feels wrong to me. It has the same priority-inversion as before (the less privileged clients gets to see the more privileged one). It also limits what the "open file dialog" client can do. For instance it can't open two (consecutive) surfaces both with the other surface as the parent. I think the sandboxed app should create a xdg_foreign for *its* toplevel, and then the "open file dialog" should be able to use this as a parent for its xdg_surfaces. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an uncontrollable albino senator with a secret. She's a bloodthirsty thirtysomething safe cracker with a knack for trouble. They fight crime! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: cross-client surface references
On Fri, 2015-07-03 at 18:10 +0800, Jonas Ådahl wrote: > > With "see" I suppose you mean "be aware and map", because it wouldn't > see the content. Sure, there is no need for the other client to ever see (or change) the contents of the window (or get events or whatever). This is purely about being able to refer to the other clients window when specifying relationships between surfaces. > For the record, the original foreign surface idea was about putting > less > privileged clients's surfaces inside a more privileged client's > parent > surface, which indeed is quite the opposite of whats the intention > here. > I think this is better handled by a sub-compositor. In fact, i took Jaspers initial wakefield proof of concept and extended it to be a generic such sub-compositor for Gtk: https://github.com/alexlarsson/wakefield This is interesting because its even cross-backend. I.e. you can run the wakefield compositor on the gdk X11 backend, spawn a child process that uses the wayland gdk backend and embedd it. (I know you know about this but others on the list may not.) ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: cross-client surface references
On Wed, 2015-07-08 at 12:47 +0100, Daniel Stone wrote: > Hi, > None of them will really work. > > This thread has sadly degenerated into: 'what if Wayland's object > model was totally different? what if some of its explicit core design > principles were thrown out the window?'. Realistically, that is not > something that will happen in the Wayland 1.x timeframe, if ever. > Where this thread started was, 'what's a good sandboxing model for > clients which must be explicitly separated for security reasons?', > and > the answer to that is the same answer to the same issue within WebKit > 2 (UI process distrusts render processes), which is that your more > trusted client itself becomes a Wayland compositor. Which is exactly > what Jasper did with Wakefield, almost exactly for this usecase, a > few > months ago. If there are issues with that design, then great, let's > chase that up. > I'm not at all interested in the change that bill is talking about, and I think it is unfortunate that it takes this thread off-topic, but this is a mischaracterization of the problem. Yes, using a subcompositor is a good idea for the case where a more privileged process needs to contain some subclient. In fact, I took Jaspers wakefield work and extended it for use in the case of e.g. embedding a file previewer out of process. However, the problem I have now is different, in that it involves an existing, less privileged client initiating a higher privileged operation (in a controlled fashion) and the higher privileged client needing to refer to the lower privileged one. In particular, I need the compositor to get toplevel parenting right (higher priv dialog has a parent that is a lower priv toplevel). This case can not really be solved using subcompositors. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: cross-client surface references
On Thu, 2015-07-09 at 10:00 +0100, Daniel Stone wrote: > > However, the problem I have now is different, in that it involves > > an > > existing, less privileged client initiating a higher privileged > > operation (in a controlled fashion) and the higher privileged > > client > > needing to refer to the lower privileged one. In particular, I need > > the > > compositor to get toplevel parenting right (higher priv dialog has > > a > > parent that is a lower priv toplevel). > > > > This case can not really be solved using subcompositors. > > Fair enough; that does help. > > Is that the absolute limit of what you require: that the higher-priv > dialog must be a child of the lower-priv window, and that's it? > Without an interface that was very strictly limited to that exact > usecase, I can see no end of issues for manipulation. > I don't have a full implementation of this, but the usecase is to be able to support "portals" out of the sandbox. For instance, one such portal would be the "file/content chooser". The sandboxed app would activate (via a filtered session bus) that the user select some file, and then the portal would do the user interaction, and return the final selected data. In this case we need to be able to display the file chooser dialog (and possibly other dialogs too if you want different kind of contents). Such a dialog should at least be parented to the sandboxed app toplevel, and possibly also modal (although that could be handled by the app itself given a good enough portal api). I guess it may also be useful for the portal to get told when the client toplevel was unmapped. Are there other things that could possibly be useful? I guess perhaps one could imagine allowing the higher privileged process creating an XdpPopup with the sandboxed app as parent. This would allow a right -click on some selected text to bring up a menu with different sharing options. This is a much more complex interaction though, and I'm not sure if it can be made useful and safe. > Even with that, I'm struggling to think of how to do it in a truly > secure fashion. My base idea would be for the lower-priv client to > create an fd referring to its xdg_surface, which when passed to the > higher-priv client (having its own separately-initiated connection to > the compositor), allowed it to use a special interface to create a > modal dialog as a child of that surface, and nothing else. But the > wider we drag the surface area, the more difficult it gets to design > out really unpleasant races. > You want a fd instead of a plain global identifier to make it impossible to guess it from another client? There are some inherent risks with passing fds around. For instance, you can block the recipient forever by passing it a fuse fd which blocks forever in close() (and close will be implicitly called if you don't read the fd even!). Of course, once you have a dbus connection between the two clients that can happen anyway. Another approach would be to create an identifier for a particular other client. That would require the higher privileged client to pass some kind of client identifier to the lower priv client though, which requires a more complex setup for doing the out-of-sandbox handover. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: cross-client surface references
On Thu, 2015-07-09 at 02:19 -0700, Jasper St. Pierre wrote: > My issue with this is that you're tying two things together. You want > access to """a surface""", and you think you can do this by having > global cross-client objects and handles and such. I don't see a need > for this. We can just add a new protocol that does what we want. > I don't understand your disagreement. The protocol you sketch out is exactly the same as the one Jonas sketched, only with different names (sandboxed_surface instead of xdg_foreign), and it is very much a global cross-client object handle. I obviously don't want the actual XdgSurface object from the other client, that would be insane. I just want a reference/handle/name for it in my client so that i can pass it as an argument to my_xdg_surface.set_parent() ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: cross-client surface references
On Thu, 2015-07-09 at 13:38 +0300, Pekka Paalanen wrote: > On Thu, 09 Jul 2015 11:37:06 +0200 > Alexander Larsson wrote: > > > On Thu, 2015-07-09 at 02:19 -0700, Jasper St. Pierre wrote: > > > My issue with this is that you're tying two things together. You > > > want > > > access to """a surface""", and you think you can do this by > > > having > > > global cross-client objects and handles and such. I don't see a > > > need > > > for this. We can just add a new protocol that does what we want. > > > > > > > I don't understand your disagreement. The protocol you sketch out > > is > > exactly the same as the one Jonas sketched, only with different > > names > > (sandboxed_surface instead of xdg_foreign), and it is very much a > > global cross-client object handle. > > > > I obviously don't want the actual XdgSurface object from the other > > client, that would be insane. I just want a reference/handle/name > > for > > it in my client so that i can pass it as an argument to > > my_xdg_surface.set_parent() > > It makes a huge difference whether you call > xdg_surface.set_parent(xdg_surface *foreign) or > sandboxed_surface.set_as_child(xdg_surface *owned). > So, you disagree with xdg_surface.set_parent accepting both xdg_surface and xdg_foreign objects? One could add xdg_surface.set_foreign_parent() then to make it explicit what is meant. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: cross-client surface references
On Thu, 2015-07-09 at 20:58 +0800, Jonas Ådahl wrote: > On Thu, Jul 09, 2015 at 01:26:09PM +0100, Daniel Stone wrote: > > Or rather, xdg_foreign.reparent_as_dialog_into(xdg_surface). I like > > the idea of limiting the surface area as much as possible, to not > > only > > make it explicit as to what is and isn't possible, but also because > > it > > makes it easier for compositors to implement. > > Yea, an inverse of xdg_surface.set_parent on xdg_foreign sounds like > the > best option to me too. We can't be too specific though, adding too > much > DE design into the protocol (like making it modal or other things > that > might not apply to non-GNOME(?)). Not adding too much new terminology > might be preferable as well. There is no such thing as a "dialog" > anywhere yet for example; is it different from a xdg_surface with a > parent, and if so in what ways? > xdg_foreign.set_parent_of(xdg_surface)? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 0/2] Support for high DPI outputs via scaling
On ons, 2013-05-08 at 10:43 -0400, Todd Showalter wrote: > On Wed, May 8, 2013 at 6:51 AM, wrote: > > There are problems with this. > > We're moving to a "HiDPI" world. With 3DTV failing in the market, > it's looking like the TV manufacturers are going to push hard on 4K, > and once 4K panels are widely available they'll work their way down to > PCs fairly quickly. By the time Wayland is moving into mainstream > adoption, if 4K isn't the standard yet for 20" - 24" monitors it will > be imminent. I disagree, external monitors will be not be commonly HiDPI for a long time, so having a mix of "Hi" and "Low" DPI monitors will be common for a long time. > We're at that point in iOS now; with the exception of legacy > hardware, the iPad Mini and the (presumably soon to be discontinued) > iPad 2, everything is "retina" and has a 2.0 scale factor. We're > probably less than a year away from the end of Apple selling any iOS > devices with a 1.0 scale factor, and two to three years at most from > the point where support for 1.0 scale devices is a consideration for > developers. Apple needed something to bridge the gap between the > devices, but that gap is just about behind us now, and the scale > factor is going to remain as a minor programming wart for a long time > to come; something that trips up new developers. I don't think we can assume everything is high dpi for a loong time. There is both the external monitor case and old/non-apple hardware to consider. So apps and things like themes must specify coordinates in a scaled coordinate space, or things will just not work on hidpi displays (i have one, its unusable without it). And, for various technical as well as visual (non-aligned/integer width borders in e.g. buttons look *really* bad) we need this scaling factor to be an integer. > Windows blew it with their DPI adjustments; in my experience > changing the DPI significantly on Windows (up to and including win7) > breaks things. Even OS tools render wrong, and many times I've run > into games that don't handle mouse positions properly when the DPI is > changed. If you run Stardock's Fallen Enchantress at double DPI, for > example, the mouse pointer can move across the entire screen, but as > far as the game is concerned the actual location of the pointer is > scaled by 0.5, constrained to the upper left quarter of the screen. > This is not an uncommon problem. This is due to the way microsoft handled this, enforcing apps to do the scaling. This solution is completely different. All input will be pre-scaled and appear in "lodpi", and upscaling will be fully automatic by wayland and/or the toolkit. > The angle subtended by a pixel to the viewer is the problem. I disagree. I mean, in practice that is what any kind of DPI boils down to, yes. But its not the *problem*. The problem is that we don't have any way to cope with large changes in this value. For a traditional setup you'd have multiple monitors with somewhat different DPIs, but it'd still work pretty well because the angular density was approximately the same. But suddenly we have displays where the resolution is large enough that it matters, your 1 pixel button borders become almost invisible. This is what we need to fix, not magically match exact scale factors so that your 1 angular degree wide line is exactly 1 angular degree wide on another display. Its true that the monitor DPI itself doesn't necessarily map directly to whether the monitor is HiDPI or not. We may very well need to scale the UI up on your 46" TV, but that can be done as well with buffer scaling, and it will work automatically with all apps, and scale icons/borders/padding, etc as well as fonts. > Ultimately, the answer may just be to do what you're planning and > make sure that there's some sort of simple tool to let the user set > their view distance. Whatever we do, though, it needs to deal with > this problem. Exactly. The compositor is in full control of the buffer scale for any output, so users will be able to override it. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/2] protocol: Allow versioned message arguments
On ons, 2013-05-08 at 15:40 -0500, Jason Ekstrand wrote:
>
> In short, I think this is far too complex for what it achieves. In
> the case of scaling factor stuff, you can just do it with a second
> event.
I agree that what I posted have some open issues, and it was mostly
meant as a start of a discussion of how to handle this. But I completely
disagree with this. Adding a second event is totally a bad thing. I'll
try to explain my reasoning in this case, but also consider that over
time this will happen in other events too, so the complexity will
accumulate over time.
So, wl_output. This API is meant to be used to find out the initial
monitor geometry and later dynamic updates of it. One of the primary
consumers of this will be GdkScreen/GdkMonitor which is the Gtk+ api
that gives this information. We never want Gtk+ to report some partial
state to the application, so a multi-event geometry notification means
that Gtk+ would have to have some code like:
// just got a geometry event
if (wl_output.version <= 2)
update GdkMonitor based on event
screeen.emit("changed");
else
// Can't update the data or notify until we have all parts
screen.saved_geometry_event_data = event;
screen.waiting_for_geometry_scaling_factor = 1;
There are multiple issues here:
* The code becomes much more complex (imagine a third event added later)
* Message ordering suddenly becomes important
* The client depends on a complex behaviour of the server (send the 2nd
event if wl_output.version > 2) which some compositors may not
implement (due to a bug or mistake) which leads to client
"livelocks".
Or maybe I misunderstood you? Did you mean that the new event would be a
copy of the first event with the extra field added? So, there would be
geometry & geometry2. That would be a lot easier on the client side, all
you have to do is listen to both and fill in a default value for the new
fields in the handler for the old one. There are still some minor issues
in this apprach though:
* You need to send both messages over the wire. (Technically there is
some version negotiation when you bind the wl_output, but I don't think
it seems right that incrementing the output version breaks old code that
used the old geometry event.)
* The two events are separate things that we force the compositor to
handle in the right way, introducing uncertainty in behaviour. With my
patch an old server with a new client will automatically work, and a
compositor building against a newer server library will fail to build
until its fixed to pass the new event members. Without this you may get
compositors that build against the new server version but still don't
emit the new signals.
Now, that doesn't mean we have to implement versioned events the way my
patch does. Its important that we get event versioning right though,
because this is gonna show up more in the future. I think the basic
properties we want from this are:
* It should be easy to update compositors to the new event, just switch
to the new marshaller call with no need to manually handle back compat.
* Old clients should keep working on the new server even though the
server just calls the new event version marshaller.
* New clients should be able to listen to *either* the new event version
or the old version (i.e. allow being lazy on version update), without
having to somehow care about which version the server is.
This can be implemented several ways though, and I agree that the way
the patch did it is very rough on non-C languages. Another approach is
to add a new event that "extends" the old one. I.e. like the "copy the
event and extend it" approach above, but with support from the wayland
machinery itself. That way the client can demarshal old events as the
new one, and the dispatching of the new events can be done for all the
versions of the event. This way we can avoid servers and clients having
to manually support backwards compatibility.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/2] protocol: Add buffer_scale to wl_surface and wl_output
On ons, 2013-05-08 at 12:07 -0700, Bill Spitzak wrote: > Output scaling should be merged with the existing "buffer_transform" > (the 8-value enumeration describing 90 degree rotations/reflections). In effect they are parts of the same thing, yeah. I don't know if ABI compat allows us to just change buffer_transform though. > I think in the end Wayland is going to have to have arbitrary affine > transforms in the api, and it might make sense to decide a standard for > these now, so that they are not split up amoung several apis like what > is happening now. Apparently there is worry about using floating point > in the api, but I think the following proposal that only uses integers > or fixed point works: > > Translation are given as 2 24.8 fixed-point numbers. > > Scale is 4 unsigned numbers: w,h,W,H. You can think of these as the size > of the source and destination, or w/W and h/H are the scaling factors. > > Rotation and skew are 4 integers: x0,y0,x1,y1. The X and Y axis are > rotated to point at these positions. To avoid skew use x1==-y0 and > y1==x0. Flipping the signs can be used to make reflections. > > This setup allows some useful numbers with somewhat intuitive results, > and avoids trying to specify irrational numbers using integers. I'm not sure this generality is useful for this? When would you ever store the pixel data for your window pre-skewed? I mean, I don't think in practice its ever gonna useful to have windows displayed rotated and skewed on the screen, but I can see the conceptual nicety in allowing this (i.e. wobbly windows with input working). But I don't *ever* think an app is gonna supply the surface data for the window in such a way. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 0/2] Support for high DPI outputs via scaling
On ons, 2013-05-08 at 14:51 -0500, Jason Ekstrand wrote: > Is there a way to bypass the scaling? When I'm using the > mouse in > a game, I want to know the pixel position of the pointer, with > no > scaling applied. I'm going to be drawing the gui at native > res, and I > want the mouse to interact with it at native res. > > I think that's supposed to be solved by wl_pointer giving sub-pixel > accuracy. Yeah, input will have (already has) sub-pixel accuracy, so you need only handle that. > I don't know that I'm opposed to some sort of scaling factor on > principle. Android has pixels (px) vs. display pixels (dp) and that > seems to work fairly well. I guess I'm still a little confused as to > exactly what roles the compositor and the toolkit play and what the > "scaling factor" means. Is the compositor's part simply to scale the > surface for the lower/higher res monitor? On a wl_output, a scaling factor of means that the mapping from surface coordinates/size to the output framebuffer scales the content of a "normal" surface by 2. Its very similar to the existing transform method with can say that when outputting a buffer its content will be rotated 90 degrees. Similarly, scaling factor on a surface is very much like the existing buffer_transform on the window. It says that this window is already pre-scaled (vs. pre-rotated) by the amount specified. If the surface scaling and rotation matches what the output has then we don't need to apply the scaling/rotation. It also means that the client can supply subpixel precision which would not be available if the server had to do the upscale. If the surface doesn't have the right scaling factor, then the compositor needs to scale the surface up or down while rendering it to the output. > Also, what happens if you have three monitors with factors 1, 2, and > 3? Can you render at 2 or 3? I guess I'm concerned that we're going > to lock ourselves into a system where monitor sizes have to come in > powers of 2 or we won't be able to make sense of them. Then again, > there may be no better solution. I'm not sure what you think is a problem with having these factors? Its not any different from the current state with 3 monitors at 3 different rotations. The client supplies *one* buffer for the surface, and it picks the scaling factor for it. The compositor then has to scale it the right amount when rendering it on any particular monitor. Generally the app will track which output the window is "mostly on" and use that to determine what resolution to pick for the buffer, but it must always handle that a window can overlap multiple outputs, so the compositor needs to be able to render it at multiple sizes. There is some ambiguity in the case of mirrored outputs at different scales. What resolution should the client pick then? If we pick the larger one it will look better on the higher resolution one, and if we pick the smaller it will look better on the lower resolution one. Both are valid choices, depending on how you are using the displays, so this should imho be up to the user. In order to allow the compositor to tell the client of the user choice I added the output priority field to the geometry. > For reference, this has already been discussed at some length on the > list. The first post to the effect is here: > http://lists.freedesktop.org/archives/wayland-devel/2013-March/007941.html When I first showed my HiDPI work to kristian he said that we could also allow a client to supply per-output buffers for the surface so that a window overlapping two monitor of different scale could look good in both. There is certainly nothing wrong about that, and we could allow it. However, I think it is severe overkill. Very few windows span monitors, and I don't think any toolkits will take advantage of this (in fact, it would be hard to make this work reliably in Gtk+ due to how the widget APIs work). Making the client pick a single format seems good enough in practice. > Also, we need to figure out how this interacts with the proposed > scaling extension. Information can be found here: > http://lists.freedesktop.org/archives/wayland-devel/2013-April/008927.html I don't think it needs much extension. It works as is, although the docs refering to wl_surface.set_buffer_transform also needs to mention the scaling factor. Of course, there is also the question of if we could use the wl_surface_scaler interface to do the HiDPI scaling. And, while this would be technically possible it seems the wrong approach to me. The surface scaler API is much more demanding of the compositor with non-integer scaling factors, cropping and aspect ratio changing. I don't think we want to force compositors to always support all of that in order to work on HiDPI displays where a much simpler subset is needed. Also, its a much more complex API to use for something so basic that every window will use it. Basically, wl_surf
Re: [PATCH 0/2] Support for high DPI outputs via scaling
On ons, 2013-05-08 at 22:58 +0200, John Kåre Alsaker wrote: > I think we should allow fractional scale factors. Clients which only > support integer scale factors should round the scale factor they get > to a whole number. I don't see how this is useful? The scaling has two main benefits: 1) It defines a common global coordinate system in which to specify global things like window sizes, mouse speed, pointer size, relative monitor positions, etc. For these it doesn't necessarily matter that the DPI of these match exactly, only that they are "of the same magnitude". I personally have a desktop setup with two different monitors of different DPI, which works fine. However, I also have a chromebook pixel with 239 dpi, and using the same settings for these things *definately* is a problem on that. 2) It allows reusing all existing code and assets that specify things in pixels. The fact that the theme specifying a one-pixel border on buttons end up with a 3% wider line on some displays is not really a problem. However, on the pixel it is again a real problem. Surface scaling lets us fix this without modifying and duplicating all widget code, themes, svgs, etc. A fractional scale factor is always going to cause visually poor experience due to nr 2. I.e. themes will use an integer multiple wide lines and padding in order to look good on current resolution screens, which will always end up looking blurry if you then scale by a fraction. In fact, if the scaling factor is e.g. 1.5, there is no way for a theme to get crisp button borders. It could specify a line of width 0.6667 and hope it gets rounded to exactly 1 on the output, but if some padding above it made it accidentally end up on an uneven row it would become blurred between two rows on the screen. It also causes issues because buffers are by necessity of integer sizes, and an integer buffer size times a fractional scale will cause the surface to have a fractional size in the global coordinate space. How would you handle this if the window overlaps an output with a different scaling factor? You'll end up with either a cut off window not showing the last row or a blurred partial pixel rendered with AA. How would you maximize a window when the interger output size results in a fractional buffer size for the window? > I don't think we need a scale priority on wl_outputs, clients should > pick the highest scale factor of the outputs it's on. I don't agree. This is a policy decision, as it will always result in the best looking output on the highest dpi monitor. The lower one would get a downscale of the hires rendering, which will look worse than e.g. a properly hinted text rendered for the lower resolution, and I can easily imagine situations where you want the output to look sharpest on the lower resolution monitor, like when you're using a projector. What to pick in this case should be up to the user and/or compositor/desktop-environment, so we should allow the compositor to tell clients what to do in this case. This is what e.g. OSX does (i.e. you get a popup that asks if you want best looking result on the monitor or on the laptop display). ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/2] protocol: Allow versioned message arguments
On mån, 2013-05-13 at 12:19 +0300, Pekka Paalanen wrote:
> On Mon, 13 May 2013 10:23:44 +0200
> Alexander Larsson wrote:
>
> > On ons, 2013-05-08 at 15:40 -0500, Jason Ekstrand wrote:
> >
> > >
> > > In short, I think this is far too complex for what it achieves. In
> > > the case of scaling factor stuff, you can just do it with a second
> > > event.
> >
> > I agree that what I posted have some open issues, and it was mostly
> > meant as a start of a discussion of how to handle this. But I completely
> > disagree with this. Adding a second event is totally a bad thing. I'll
> > try to explain my reasoning in this case, but also consider that over
> > time this will happen in other events too, so the complexity will
> > accumulate over time.
> >
> > So, wl_output. This API is meant to be used to find out the initial
> > monitor geometry and later dynamic updates of it. One of the primary
> > consumers of this will be GdkScreen/GdkMonitor which is the Gtk+ api
> > that gives this information. We never want Gtk+ to report some partial
> > state to the application, so a multi-event geometry notification means
> > that Gtk+ would have to have some code like:
> >
> > // just got a geometry event
> > if (wl_output.version <= 2)
> >update GdkMonitor based on event
> >screeen.emit("changed");
> > else
> >// Can't update the data or notify until we have all parts
> >screen.saved_geometry_event_data = event;
> >screen.waiting_for_geometry_scaling_factor = 1;
>
> This is the way to do it. As another way, rather than expecting a
> specific event and pending on that indefinitely, you could issue a
> roundtrip; when it returns, you are guaranteed to have received all the
> additional events related to this event. OTOH, roundtripping is not
> nice to use like this.
I don't think this is particularly nice, its just pushing complexity
unnecessarily on everyone else. It means over time there will be more
and more cruft accumulating in the wayland apis that applications need
to handle in complex ways like this. Its fine for a single one, but
imagine how it will look in 10 years, when every client needs to have a
spaghetti nest of version checks with different behaviour depending on
the server version. Its much nicer if the protocol implementation itself
can handle this (as far as possible).
> There is a slightly racy way to achieve the same, though: wait for
> idle. You wait for idle in any case before re-drawing the GUI, right?
I don't see how this would reliably work. If we get an event and handle
it, we're idle immediately. So it will constantly race with the second
event showing up in the pipe.
> In any case, a compositor can be assumed to send all related events in
> a burst, without interleaving other events. We can even specify the
> order in the protocol. We already do that for other things.
Relying on the burstiness is racy, so we need to define an exact order
and version behaviour, and every client and server need to open code
these exactly right or we'll get problems. This is certainly doable and
it makes things a lot easier for me to do this patch (although it makes
me cry as a gtk backend developer).
I guess in this particular case we can define that a new scale for a
wl_output must be sent before the matching geometry event. That way it's
easier for clients to handle. Just keep any scale events until you get
the next geometry event and then apply it with that data.
> > * The client depends on a complex behaviour of the server (send the 2nd
> >event if wl_output.version > 2) which some compositors may not
> >implement (due to a bug or mistake) which leads to client
> >"livelocks".
>
> This is the standard way to implement augmented protocol. If some
> compositors don't do it right, they are buggy and need to be fixed.
> Automatically and silently papering over the problem would make things
> only harder to debug.
Its certainly always what happens on *some* level. But it need not be
how it is visible to client applications. I guess its something of a
design decision of how high-level the wayland client library wants to
be. Does it match the bits in the wire protocol, or is it a slightly
higher level.
> > Or maybe I misunderstood you? Did you mean that the new event would be a
> > copy of the first event with the extra field added? So, there would be
> > geometry & geometry2. That would be a lot easier on the client side, all
> > you have to do is listen to both and fill in a default value for the new
> > fields in the handler for the old one. There are still some minor issues
> > in this appra
Re: [PATCH 0/2] Support for high DPI outputs via scaling
On mån, 2013-05-13 at 13:12 +0300, Pekka Paalanen wrote: > On Mon, 13 May 2013 11:16:07 +0200 > Alexander Larsson wrote: > > > On ons, 2013-05-08 at 14:51 -0500, Jason Ekstrand wrote: > > > > > Also, we need to figure out how this interacts with the proposed > > > scaling extension. Information can be found here: > > > http://lists.freedesktop.org/archives/wayland-devel/2013-April/008927.html > > > > I don't think it needs much extension. It works as is, although the docs > > refering to wl_surface.set_buffer_transform also needs to mention the > > scaling factor. > > > > Of course, there is also the question of if we could use the > > wl_surface_scaler interface to do the HiDPI scaling. And, while this > > would be technically possible it seems the wrong approach to me. The > > surface scaler API is much more demanding of the compositor with > > non-integer scaling factors, cropping and aspect ratio changing. I don't > > think we want to force compositors to always support all of that in > > order to work on HiDPI displays where a much simpler subset is needed. > > Also, its a much more complex API to use for something so basic that > > every window will use it. > > > > Basically, wl_surface_scaler is for scaling of subsurfaces with video, > > and I don't think we should mix the two up. > > I agree with your reasoning here. > > I haven't read this whole thread in detail, because it seems to contain > so much "marketing speak" and complicated explanations of things that > should be straightforward. So, am I getting the following right? > > You basically want a default scaling factor for all surfaces, per > output. And, you want a way for clients to opt-out from that default > scaling. No, that doesn't seem quite right, although maybe I misunderstood it. Lemme try to define it similarly. Each output has a scaling factor set, and all surfaces on that output is scaled by it. However, clients can supply pre-scaled buffers, which co-incidentally allows sub-pixel accuracy in the "scaling" by just rendering at a higher resolution. Basically, compare it to the current wl_surface.set_buffer_transform(). Its essentially that, but the transform extended with scale-by-integer in addition to the rotations. > Is it really that simple? I'm asking because I didn't see it put that > clearly anywhere, but maybe it got lost in between all the 3DTV > discussion and coordinate transforms. Sure, its pretty simple in the end. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 0/2] Support for high DPI outputs via scaling
On mån, 2013-05-13 at 12:40 +0200, John Kåre Alsaker wrote: > The scaling factor should not have any affect of any coordinate system > or anything else in the protocol. It should only affect the size in > pixels of the surfaces of the clients. Clients should do any > transformations of coordinates they want themselves. I'm not sure if we agree or not here. But, lemme have an example. If you have a setup with two monitors using mirrored mode, one with scale == 2. Then I want both monitors to show the same thing, one with more detail. If I then put the mouse cursor over the bottom right corner of the surface i want to get one mouse event, and the coordinates of it should be the size of the window in the unscaled coordinates, i.e. the width/height of the window in the lower resolution. Is this what you meant? > Clients can easily scale larger features like icons, padding and fonts > and round them to pixel sizes and draw sharp output even with a > fractional scaling factor. This allows users to pick a size suitable > for them. The difference between a 1 and 2 scaling factor is too huge. Some things can be easily scaled. Like text and photorealistic images. Other things can't necessarily be scaled and still look nice. Like line art or solid line borders (like e.g. the boxes around a button). Sure, you can round everything to "nearest int", but that will cause unevenness in the rounding (buttons sometimes get a 1 pixel border, sometimes 2 depending on the fractional part of the button coords, etc). So, I don't think this is every useful in practice. > I think the case when a window is displayed on multiple monitors is > pretty rare or short in duration (the dragging across monitor case > when not using a workspace per monitor). I suppose we could leave this > up to the compositor. Totally, i don't mean that the priority is useful for that case. Normally clients should just pick the scale based on which output the surface has the "most" pixels in. However, the one case where that breaks is mirrored/clone mode, where two monitors show the same thing. This is where the priority can be useful. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/2] protocol: Allow versioned message arguments
On mån, 2013-05-13 at 13:26 +0200, John Kåre Alsaker wrote: > For the wl_output case I suggest we add a 'done' event which signals > that the compositor is done sending a batch of events for an wl_output > and related extension objects (which versioned message arguments won't > handle). This would be analogous to wl_surface.commit, only coming > from the server side. As i said in another mail, an even easier approach is to use the gemetry event itself as the "done" event, and just send the additions (if any) *before* the geometry event. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/2] protocol: Allow versioned message arguments
On mån, 2013-05-13 at 13:49 +0200, John Kåre Alsaker wrote: > On Mon, May 13, 2013 at 1:28 PM, Alexander Larsson > wrote: > On mån, 2013-05-13 at 13:26 +0200, John Kåre Alsaker wrote: > > For the wl_output case I suggest we add a 'done' event which > signals > > that the compositor is done sending a batch of events for an > wl_output > > and related extension objects (which versioned message > arguments won't > > handle). This would be analogous to wl_surface.commit, only > coming > > from the server side. > > > As i said in another mail, an even easier approach is to use > the gemetry > event itself as the "done" event, and just send the additions > (if any) > *before* the geometry event. > That would also work, but is uglier. The geometry event is rather > large too. Since currently events can happen at any time, adding a > done event won't break backwards compatibility. No, but it means you have to special-case the versions that don't send a done event. And in practice the geometry is emitted seldom and the two probably almost always change at the same time, so i don't think you'll ever see just scale changed + done. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 0/2] Support for high DPI outputs via scaling
On mån, 2013-05-13 at 14:00 +0200, John Kåre Alsaker wrote: > > Clients can easily scale larger features like icons, padding > and fonts > > and round them to pixel sizes and draw sharp output even > with a > > fractional scaling factor. This allows users to pick a size > suitable > > for them. The difference between a 1 and 2 scaling factor is > too huge. > > > Some things can be easily scaled. Like text and photorealistic > images. > Other things can't necessarily be scaled and still look nice. > Like line > art or solid line borders (like e.g. the boxes around a > button). Sure, > you can round everything to "nearest int", but that will cause > unevenness in the rounding (buttons sometimes get a 1 pixel > border, > sometimes 2 depending on the fractional part of the button > coords, etc). > So, I don't think this is every useful in practice. > Even if things aren't perfectly even, it will still be much better > than the alternative which is round up to the next scaling factor and > let the compositor scale the surface down to a suitable size again. > This is what you have to do on Mac OS X to get a reasonable workspace > on higher DPI displays. Windows gets 4 times bigger from scaling > factor 1 to 2. That isn't near enough granular. I don't think this will work in practice. I know for sure that e.g. Gtk is not set up to do any reasonable non-integer scaling. It will just scale up all drawing by a fractional factor without any rounding anywhere, causing everything to become fuzzy. We will eventually have alternative icons for higher resolutions, but these will be at 2x scale, not at generic fractional factor (that is not really doable without using pure-vector icons with some complex hinting method). Although, I guess that in the case of text the scaling will be ok, so for some usecases it might be OK. So, it's my opinion that supporting fractional scaling is an unnecessary burden on compositors for something that is not very useful in practice. Thats just my opinion though, and the proposal as such can handle fractional scaling fine by just changing the scale factors to fixed type. > In mirrored/clone mode only a single wl_output would be presented to > clients with a single scale factor, so priorities won't matter in that > case. That is not necessarily so. We might very well want to know that there are two displays, with say different RGB subpixel order, etc. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 0/2] Support for high DPI outputs via scaling
On mån, 2013-05-13 at 14:40 +0200, John Kåre Alsaker wrote: > > I don't think this will work in practice. I know for sure that > e.g. Gtk > is not set up to do any reasonable non-integer scaling. It > will just > scale up all drawing by a fractional factor without any > rounding > anywhere, causing everything to become fuzzy. We will > eventually have > alternative icons for higher resolutions, but these will be at > 2x scale, > not at generic fractional factor (that is not really doable > without > using pure-vector icons with some complex hinting method). > Although, I > guess that in the case of text the scaling will be ok, so for > some > usecases it might be OK. > It will work very well for things designed to be scalable, browsers > are an example. GTK could just fall back to integer scaling. Browsers are not really scalable like that, css page layout is generally based on the CSS "Px" definition, and per e.g. http://static.zealous-studios.co.uk/projects/web_tests/PPI%20tests.html: For lower-resolution devices [i.e. non-print], and devices with unusual viewing distances, it is recommended instead that the anchor unit be the pixel unit. For such devices it is recommended that the pixel unit refer to the whole number of device pixels that best approximates the reference pixel. I.e. "whole number of pixels" => scale by integer matches best what CSS wants. > So, it's my opinion that supporting fractional scaling is an > unnecessary > burden on compositors for something that is not very useful in > practice. > Thats just my opinion though, and the proposal as such can > handle > fractional scaling fine by just changing the scale factors to > fixed > type. > It is of no burden on compositors at all, only for clients which > choose to implement it. It is, as long as clients are allowed to specify a fractional scaling factors compositors need to be able to handle scaling by that (for instance if the window appears partially on a non-highres monitor. > > In mirrored/clone mode only a single wl_output would be > presented to > > clients with a single scale factor, so priorities won't > matter in that > > case. > > > That is not necessarily so. We might very well want to know > that there > are two displays, with say different RGB subpixel order, etc. > The compositor could unify this information into a single wl_output. And what would it then report for physical width/height, subpixel, make, model, etc? Seems pretty weird. > I suggest we send 3 scaling factors to clients. A lower bound where > factors lower will be scaled up. The desired scaling factor. A upper > bound where factors above will be scaled down. Clients should find the > scaling factor in lower bound to upper bound they are able to render > at which is closes to the desired factor. Failing that they should > find the first factor they are able to render at above the upper > bound. When displayed on multiple monitors it could try to remain > sharp on as many monitors as possible. I don't quite understand this. Any factor lower than the "desired" factor has to be scaled up, no? Lets take a concrete example. The macbook pro 15" has a 2880 x 1800 native panel. This is "normally" driven as 1440 x 900 with a scale factor of 2. On OSX you can also select a 1920x1200 resolution, which is nominally a scale factor of 1.5. However, on OSX what they do is that apps render to a framebuffer at twice the resolution (3840x2400) and its then scaled it down to 2880x1800 to make it look reasonable. On such a setup in wayland the wl_output would be 1920x1200, with a scaling factor of 1.5. For a 800x601 window a hidpi applications could then either pick a buffer of 1600x1202 buffer and set a scaling factor of 2 causing the compositor to downscale it (similar to OSX above), or it could create a buffer at 1200x902 (nearest to the true 901.5) and and set scaling factor to 902/600 (i.e. 1.50333..) and have the compositor not scale it (which is a minor issue due to the 1.5 != 1.50333..). In this case the desired scaling factor would be 1.5. What do you expect the upper and lower bounds to be? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 0/2] Support for high DPI outputs via scaling
On tis, 2013-05-14 at 07:11 +0200, John Kåre Alsaker wrote: > > While this isn't a huge problem on GL-based compositors it > will cause a problem for software compositors. Any scaling > for that matter is a potential problem there. However, a > factor of two or something shouldn't be too bad in software. > > Compositors do not have to scale anything at all. Even with fractional > scaling factors a compositor could limit itself to just scaling with > integer factors. I don't think software compositor is a case worth > considering either. Nobody wants to have those, especially with > high-DPI displays. I don't think it should really be allowed to not apply the scaling. Right now buffer sizes define surface sizes, and that makes surface sizes not really well defined. For instance, if you maximize a surface, or resize it you will get a configure request with a surface size specified. You then want to make your surface that size, so you create a buffer with that size, scaled by the factor you pick. If the compositor chooses not the given factor but rather a somewhat smaller one then your surface will be larger than expected, and extend outsize of the monitor in the maximized case, or not hit the pointer in the drag resize case. Also, it makes surfaces different sizes on different monitors. If an output has some specified size/scale factor (1400x900@1.5x say) and you move a 1400x900 surface from that monitor (fully or partially) to another with a different scale (1400x900@1x) you want the window to be the same size, so the scaling factor shouldn't affect surface sizes. > And what would it then report for physical > width/height, subpixel, make, > model, etc? Seems pretty weird. > Even if two wl_outputs would be presented, they would have the same > resolution and scaling factor so priorities still won't matter. You mean the compositor could "lie" about the scaling factor on one of the outputs? I guess that is one possibility. > I don't quite understand this. Any factor lower than > the "desired" > factor has to be scaled up, no? > I expect a compositor to render deviations of the desired scaling > factor without scaling windows. The range when this is allowed is > reported to clients so they can try to render at a size which will > avoid scaling. I don't think this is really a good idea, as per the above. > Lets take a concrete example. The macbook pro 15" has > a 2880 x 1800 > native panel. This is "normally" driven as 1440 x 900 > with a scale > factor of 2. On OSX you can also select a 1920x1200 > resolution, which is > nominally a scale factor of 1.5. However, on OSX what > they do is that > apps render to a framebuffer at twice the resolution > (3840x2400) and its > then scaled it down to 2880x1800 to make it look > reasonable. > Rendering at 3840x2400 then scaling down to 2880x1800 is bad for > performance and makes the result unsharp. It is much preferable that > clients render into 2880x1800 directly with a 1.5 scaling factor (for > clients that are capable of doing that). Well, which is best should be up to the app, but i guess we want to allow a fractional scaling factor to allow apps to scale by 1.5 themselves if they can. > We can't really downscale with integer multipliers, just upscale. If > we downscale, rendering at a (much) higher resolution doesn't really > help much. We want to avoid upscaling though. Upscaling is important for backwards compat with apps not supporting scaling. For instance, we likely need it for old X clients. But yeah, generally we want to avoid that. > I don't know if the upper/lower limits is the solution, but > this is certainly an issue. In a case like that, I would say > that the application simply works in the coordinates of the > "prefered" output. This includes input events etc. This may > mean that the size of the window in points isn't an integer. > If the toolkit doesn't want to deal with that, they can come > up with a solution (maybe just require a multiple of 2 for the > size in this case). > > The size of a window should always be in pixels at the protocol level. What do you mean by window and pixel here. There are multiple pixels and sizes here: compositor pixels: The 'compositor coordinate system' is an global space where the wl_outputs are laid out. framebuffer pixels: These correspond to the native LCD panel pixel. buffer pixels: These are the individual pixels the clients rendered surface pixels: These are "pixels" in what the protocol calls "surface local coordinates". Note th
Re: [PATCH 0/2] Support for high DPI outputs via scaling
On tis, 2013-05-14 at 07:22 +0200, John Kåre Alsaker wrote: > We may also allow scaling factors below 1. When 0 clients should draw > using the smallest amount of pixels possible while still being > understandable. I doubt that will be very useful and clients could > just have 1 as a lower bound. Scaling < 1 could make sense for the case of windows that are (atm) only visible as some form of thumbnail. However, I can't think of a way for the compositor to tell the client of this. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] protocol: Add buffer_scale to wl_surface and wl_output
On tis, 2013-05-14 at 13:44 +0200, John Kåre Alsaker wrote: > I'd only accept a proposal which makes the clients tell the compositor > how much they increased the size of their window. If the compositor > wants to resize anything it should resize the entire window and not > individual surfaces/buffers. This also avoids having to position > subsurfaces and have configure requests at fractional surface pixels. I don't quite understand what you mean by this (like, how is "window" different from "surface"). Can you give an example of how the API would look for what you mean. > set_buffer_scale should be renamed to set_scaling_factor. Otherwise it > could be easily confused with the scaling extension which just scales > up buffers. My suggestion also renders it unrelated to buffers. The > geometry2 event should be named scaling_factor. A done event should > also be added. I'd also like a lower and upper bound for the scaling > factor as argument to that. I think a done event is silly, as it is not needed and complicates clients (since the done event is not always sent for older servers), but sure I can add one. > On Tue, May 14, 2013 at 12:26 PM, wrote: > > From: Alexander Larsson > > This adds wl_surface_set_buffer_scale() to set the buffer > scale of a > surface. > > It is similar to set_buffer_transform that the buffer is > stored in a > way that has been transformed (in this case scaled). This > means that > if an output is scaled we can directly use the pre-scaled > buffer with > additional data, rather than having to scale it. > > It also adds a geometry2 event with a scale member to > wl_output that > specifies the scaling of an output. > > This is meant to be used for outputs with a very high DPI to > tell the > client that this particular output has subpixel precision. > Coordinates > in other parts of the protocol, like input events, relative > window > positioning and output positioning are still in the compositor > space > rather than the scaled space. However, input has subpixel > precision > so you can still get input at full resolution. > > This setup means global properties like mouse > acceleration/speed, > pointer size, monitor geometry, etc can be specified in a > "mostly > similar" resolution even on a multimonitor setup where some > monitors > are low dpi and some are e.g. retina-class outputs. > --- > protocol/wayland.xml | 41 > +++-- > 1 file changed, 39 insertions(+), 2 deletions(-) > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > index 3bce022..e5744c7 100644 > --- a/protocol/wayland.xml > +++ b/protocol/wayland.xml > @@ -876,7 +876,7 @@ > > > > - > + > >A surface is a rectangular area that is displayed on > the screen. >It has a location, size and pixel contents. > @@ -1110,6 +1110,30 @@ > > > > + > + > + > + > + > + This request sets an optional scaling factor on how > the compositor > + interprets the contents of the buffer attached to the > surface. A > + value larger than 1, like e.g. 2 means that the buffer > is 2 times the > + size of the surface. > + > + Buffer scale is double-buffered state, see > wl_surface.commit. > + > + A newly created surface has its buffer scale set to 1. > + > + The purpose of this request is to allow clients to > supply higher resolution > + buffer data for use on high-resolution outputs where > the output itself > + has a scaling factor set. For instance, a laptop with > a high DPI > + internal screen and an low DPI external screen would > have two outputs > + with different scaling, and a wl_surface rendered on > the scaled output > + would normally be scaled up. To avoid this upscaling > the app can supply > + a pre-scaled version with more detail by using >
Re: [PATCH 0/2] Support for high DPI outputs via scaling
On tis, 2013-05-14 at 13:19 +0200, John Kåre Alsaker wrote: > On Tue, May 14, 2013 at 11:25 AM, Alexander Larsson > > > I don't think it should really be allowed to not apply the > scaling. > Users may want to disable scaling as it's not very good looking. I > don't think we should enforce a policy about that. What do you mean? Scaling is done by the compositor. The user is who tells the compositor to use scaling (by setting a scale on the wl_outputs), just like he sets the resolution. > Right now buffer sizes define surface sizes, and that makes > surface > sizes not really well defined. > They're defined as the same as buffer sizes (ignoring the trivial > transformations). They should still be the same if the scaling factor > is not 1.0. Clients should scale both buffers and surfaces. The only > thing that should decouple these sizes more are the scaling extension. Obviously they are defined as such right now, since there is no scaling. But, the patch I proposed changes this, because otherwise we can't cleanly handle backwards compatibility (and also it makes sense). In the canonical example of 2x scaling you have some lcd panel at say 2000x2000, and we want naive apps to be automatically upscaled as if it was a 1000x1000 monitor. If a window in the naive app is maximized this means it must get a configure reply from maximize that says 1000x1000, which cause it to attach a buffer of 1000x1000 (with scale factor 1) to it. This is how existing wayland clients work. Now, a non-naive client will get the same maximize reply of 1000x1000, but in this case we want it to create a buffer of 2000x2000 (with scale 2) since it knows the window is on a high-dpi monitor. So, there is a natural separation of the surface size (1000x1000) and the buffer size (2000x2000). We can't have the configure event say 2000x2000, because then old clients will not be auto-upscaled as we want. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 0/2] Support for high DPI outputs via scaling
On tis, 2013-05-14 at 17:00 +0200, John Kåre Alsaker wrote: > Obviously they are defined as such right now, since there is > no scaling. > But, the patch I proposed changes this, > > because otherwise we can't > cleanly handle backwards compatibility (and also it makes > sense). > Backwards compatibility with what? With existing wayland clients that don't do sbupixel accuracy. Did you ever try a current wayland app on a 240 dpi display? > How would you handle subsurfaces with different scaling factors? What > coordinates would the subsurface's position be in? All positions are in the global compositor coordinate space. The one that e.g. different outputs are positioned in, etc. > We can't have the configure event say 2000x2000, because then > old > clients will not be auto-upscaled as we want. > In this case our proposals differs. The compositor knows it's not > resizing the window so it simply passes 2000x2000 along to the > configure arguments. How can the compositor know its not resizing the window? Only the app knows if it can render at a different scaling factor, as it is the app that allocates and draws to the buffer. Anyway, its pretty obvious that you're talking about a different design. I'm growing tired of this discussion, I will just shut up and implement my design in weston. If you want to implement a competing desing, feel free. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] protocol: Add buffer_scale to wl_surface and wl_output
On tis, 2013-05-14 at 13:43 -0700, Bill Spitzak wrote: > al...@redhat.com wrote: > > > + > > + > > + > > > > Fixed is not a good idea for scaling factors. You cannot accurately > represent values like 2/3 or 1/fixed. For an actual problem with > scaling, if the accurate scaling is an odd fixed number, the client > cannot specify that their scale is exactly 1/2 that, thus losing the > ability to get a 2x scale done by the compositor. > > I would specify the scale as two integers defining a rational fraction. > > This would also allow completely lossless multiplication with the > rational numbers used by the scaler proposal. > > You may also want to allow different horizontal and vertical scales, > mostly because all plausable implementations can do this with no loss of > speed, and the scaler api allows this. You will need to define if this > is before or after the buffer transform... In fact, working on this in weston a bit it seems that in general, scale is seldom used by itself but rather its used to calculate the buffer and screen size which are then used, and we want both of these to be integers. So, it seems to me that we should specify scaling by giving the width/heigh of the surface, which in combination with the buffer size gives the exact scaling ratios, plus it guarantees that the scaling maps integers to integers. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] protocol: Add buffer_scale to wl_surface and wl_output
On ons, 2013-05-15 at 11:13 +0300, Pekka Paalanen wrote: > On Tue, 14 May 2013 12:26:48 +0200 > al...@redhat.com wrote: Lots of good stuff snipped. I'll try to fix things up based on that. Some responses below. > > + > > + > > Are you sure you really want fixed as the type? > Integer scaling factors sounded a lot more straightforward. When we are > dealing with pixel buffers, integers make sense. > > Also, I do not buy the argument, that integer scaling factors are not > finely grained enough. If an output device (monitor) has such a hidpi, > and a user wants the default scaling, then we will simply have an > integer scaling factor >1, for example 2. Clients will correspondingly > somehow see, that the output resolution is "small", so they will adapt, > and the final window size will not be doubled all the way unless it > actually fits the output. This happens by the client choosing to draw a > smaller window to begin with, not by scaling, when compared to what it > would do if the default scaling factor was 1. Fractional scaling factors > are simply not needed here, in my opinion. I agree that fixed is a poor choice here. The alternative is to always use an int scaling factor, or allow the client to separately specify the surface size and the buffer size. Both of these guarantee that both buffer and surface are integers, which I agree with you that they have to be. Of course, the later means that the actual scaling factor differs slightly from window to window for fractional scaling due to rounding. Having started a bit on the implementation in gtk+ and weston it seems that allowing fractional scales increases the implementation complexity quite a bit. For instance, having widgets end on non-whole-integer positions makes clipping and dirty region tracking harder. Another example is that damage regions on a buffer need not correspond to a integer region in global coordinates (or vice versa if we define damage to be in surface coordinates). On the other hand, It seems that a few OSX users seem to want to use fractional scaling (in particular the 1.5 scaling from 2880x1800 to 1920x1200 seems very popular even if its not as nice looking as the 2x one), so there seems to be a demand for it. I'm more and more likeing the way OSX solves this, i.e. only allow and expose integer scaling factors in the APIs, but then do fractional downscaling in the compositor (i.e. say the output is 1920x1200 in global coords with a scaling factor of two, but actually render this by scaling the user-supplied buffer by 0.75). It keeps the implementation and APIs very simple, it does the right thing for the "nice" case of 2x scaling and it allows the fractional scaling. > Can we have any use for scales less than one? I don't think so. > Also, one issue raised was that if an output has a scaling factor A, > and a buffer has a scaling factor B, then final scaling factor is > rational. To me that is a non-issue. It can only occur for a > misbehaving client, in which case it gets what it deserves, or in a > multi-output case of one surface spanning several non-identical > monitors. I think the latter case it not worth caring about. > Non-identical monitors are not identical, and you get what you happen > to get when you use a single buffer to composite to both. Yeah, i don't think this is really a practical problem. It'll look somewhat fuzzy in some construed cases. > The important thing is to make all client-visible coordinate systems > consistent and logical. Yeah, i'll try to use these names in the docs and be more clear which coordinate spaces different requests/events work in. > And now the questions. > > If an output has a scaling factor f, what does the wl_output > report as the output's current and supported video modes? I believe it should report the resolution in global coordinates. Although we should maybe extend the mode with scale information. This is the right thing to do in terms of "backwards compatibility", but it is also useful for e.g. implementing the fractional scaling. So, a 2880x1800 panel would report that there exists a 1920x1200@2x mode, which wouldn't be possible if we had to report the size in output coordinates. It also seems right from a user perspective. The list of resolutions would be "2880x1800, 1920x1200, 1400x900", which is to a first degree what users will experience with these modes. Furthermore, this will allow us to expose "fake" modes for lower resolutions that maybe some LCD panels don't support (or do with a bad looking scaling), which some games may want. > What about x,y in the wl_output.geometry event (which I think are just a > global coordinate space leak that should not be there)? Yeah, this is in global coords, and seems like a leak. > The video modes are important because of the > wl_shell_surface.set_fullscreen with method DRIVER. A fullscreen > surface with method DRIVER implies, that the client wants the > compositor to change the video mode to match
Re: [PATCH 2/2] protocol: Support scaled outputs and surfaces
On tor, 2013-05-16 at 10:57 -0700, Bill Spitzak wrote: > al...@redhat.com wrote: > > > Coordinates > > in other parts of the protocol, like input events, relative window > > positioning and output positioning are still in the compositor space > > rather than the scaled space. However, input has subpixel precision > > so you can still get input at full resolution. > > If I understand this correctly, this means that a client that is aware > of the high-dpi is still unable to make a surface with a size that is > not a multiple of the scale, or to move the x/y by an amount that is not > a multiple of the scale, or position subsurfaces at this level of accuracy. You can make a surface of any integer size (and it has to be integer due to existing APIs on surface coordinates/sizes), however the *buffer* has to be an integer multiple of the surface size. In other words, surface sizes and positions are described in the global compositor space, with integer sizes. (This is already true, although currently the buffer<->surface mapping is just reflections and rotations.) Its true that this limits subsurface positioning, but i'm not sure that is a huge issue. If nothing else it makes it so that subsurfaces are always positioned on integer positions on non-scaled displays, which makes things easier when monitor of differen scales are mixed. > The only way I can see to make it work is that all protocol must be in > buffer space (or perhaps in buffer space after the rotation/reflection > defined by buffer_transform). This also has the advantage (imho) of > getting rid of one of the coordinate spaces a client has to think about. I see it the other way. We currently have *two* coordinate spaces that the client has to think about. The buffer coordinates (it has to know this when rendering), and the surface coordinates (these are basically what all wayland APIs atm use, like in damage, positioning and input). The transform between two is currently the buffer_transform only. With the buffer_scale the transform is extended to also scale, but no additional coordinate space is added. However, if we make the protocol work in post-translation but pre-scale space we're adding a new coordinate space. And, we can't make the protocol work in fully buffer coordinates, because that would break existing clients since current APIs work in post-translation coordinates. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/2] protocol: Support scaled outputs and surfaces
On tor, 2013-05-16 at 10:05 -0500, Jason Ekstrand wrote: > I still think we can solve this problem better if the clients, instead > of providing some sort of pre-scaled buffer that matches the output's > arbitrary scale factor, simply told the compositor which output they > rendered for. Then everything will be in that outputs coordinates. If > the surface ever lands on a different output, the compositor can scale > everything relative to the selected output. Surfaces which do not > specify an output would just get scaled by the factor. This has three > advantages. I don't like this. First of all, there is no way to know the outputs coordinates other than reading the wl_output transform and scale from the events. In fact, the output coordinate space is intentinally "hidden" from the client, as pekka said "The surface transform, that is private to the compositor, could warp the surface along a curve for all we care". Furthermore, claiming that a client renders in output space means that we lock down the specification of the output transform, as old clients are claiming to be rendering for a given output. I.e. if we had used this model before (say we rendered for an output, rather than give a specific buffer_transform) we wouldn't be able to extend the output transform by adding a buffer_scale. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/2] protocol: Allow output changes to be treated atomically
On mån, 2013-05-20 at 09:51 +0300, Pekka Paalanen wrote: > On Thu, 16 May 2013 15:49:35 +0200 > al...@redhat.com wrote: > > > From: Alexander Larsson > > > > This add a wl_output.done event which is send after every group > > of events caused by some property change. This allows clients to treat > > changes touching multiple events in an atomic fashion. > > Hi, > > why did you end up deciding that this is better than using the geometry > event as the end signal? Some other people wanted it. I don't know which is best, they are essentially identical. Although one advantage of "done" is that it allows us to extend e.g. the "mode" event also. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/2] protocol: Support scaled outputs and surfaces
On tis, 2013-05-21 at 20:57 +0300, Pekka Paalanen wrote: > On Tue, 21 May 2013 08:35:53 -0700 > Bill Spitzak wrote: > > This proposal does not actually restrict widget positions or line sizes, > > since they are drawn by the client at buffer resolution. Although > > No, but I expect the toolkits may. Gtk very much will do this at least. > > annoying, the outside buffer size is not that limiting. The client can > > just place a few transparent pixels along the edge to make it look like > > it is any size. > > > > However it does restrict the positions of widgets that use subsurfaces. > > > > I see this as a serious problem and I'm not sure why you don't think it > > is. It is an arbitrary artificial limit in the api that has nothing to > > do with any hardware limits. > > It is a design decision with the least negative impact, and it is > not serious. Sub-surfaces will not be that common, and they > certainly will not be used for common widgets like buttons. Yeah, this is a simple solution to an actual real-life problem that is easy to implement (I've got weston and gtk+ mostly working). If you want to do something very complicated then just don't use scaling and draw however you want. We don't want to overcomplicate the normal case with fractional complexity and extra coordinate spaces. > > The reason you want to position widgets at finer positions is so they > > can be positioned evenly, and so they can be moved smoothly, and so they > > can be perfectly aligned with hi-resolution graphics. > > But why? You have a real, compelling use case? Otherwise it just > complicates things. Exactly. > A what? No way, buffer_scale is private to a surface, and does not > affect any other surface, not even sub-surfaces. It is not > inherited, that would be insane. Yes, buffer_transform and buffer_scale only define how you map the client supplied buffer pixels into the surface coordinates. It does not really change the size of the surface or affect subsurfaces. (Well, technically it does since we don't separatately specify the surface size but derive it from the buffer and its transform, but after that the surface is what it is in an abstract space). > There is no "compositor coordinate space" in the protocol. There > are only surface coordinates, and now to a small extent we are > getting buffer coordinates. Very small extent. I think the only place in the protocol where they are used is when specifying the size of the surface. > > >>> The x,y do not > > >>> describe how the surface moves, they describe how pixel rows and > > >>> columns are added or removed on the edges. > > > > > > No, it is in the surface coordinate system, like written in the patch. > > > > Then I would not describe it as "pixel rows and columns added or removed > > on the edges". If the scaler is set to 70/50 than a delta of -1,0 is > > adding 1.4 pixels to the left edge of the buffer. I agree that having it > > in the parent coordinates works otherwise. > > We use the units of "pixels" in the surface coordinate system, even > if they do not correspond exactly to any "real" pixels like > elements in a buffer or on screen. Actually this is sort of a problem. Maybe the docs would be clearer if we just used a different name for these? "points"? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/2] protocol: Support scaled outputs and surfaces
On mån, 2013-05-20 at 13:56 -0500, Jason Ekstrand wrote: > On Mon, May 20, 2013 at 4:00 AM, Pekka Paalanen > wrote: > On Thu, 16 May 2013 16:43:52 -0500 > Jason Ekstrand wrote: > > > The point of this soi is to allow surfaces to render the > same size on > > different density outputs. > > > Are you serious? Really? Same size measured in meters? > > > No, measured in inches. :-P > > > Seriously though. While we can't make it *exactly* the same on all > your displays, we should be able to make it usably close. Having the exact physical size (be it in inches or steradians) of a window on two different monitors is *not* a goal of my work. Its already the case that windows are different sizes on different monitor, and that has been ok for users since the first a CRT was used with a computer. People have been bikeshedding about solving this "problem" for ages, and I'm not interested in that. No, I have an *actual* problem, which is that its super hard to see or hit widgets on a high dpi monitor, and a single "DPI" setting for the whole desktop is a nonstarter since you may be using mixed monitors. This is a practical problem I have on my pixel laptop and which will only get more common as hw moves on. The solution required is not exact size matches, but rather "make it the same ballpark", which my proposal solves in a very simple fashion. > What I would like in the end is a per-output slider bar (or something > of that ilk) that let's the user select the interface size on that > output. Sure, they probably won't be able to select *any* resolution > (the compositor may limit it to multiples of 24 dpi or something). > And they can certainly make an ugly set-up for themselves. However, I > want them to be able to make something more-or-less reasonable and I > see no reason why the compositor shouldn't coordinate this and why > this "scale factor" can't be used for that. The compositor is free to scale the final result to any fraction it wants, which will get you this kind of behavior. It will not be "perfect", but the other solution (adding complexity of fractional surface sizes, multiple coordinate spaces, etc) also will also not look very nice (i.e. widget clipping on fractional coordinates will look ugly, non-integer-width lines will *never* look good, etc), and in fact, internal details makes it unlikely that toolkits like Gtk will ever be able to support fractional scaling, so it has little practical use. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/2] protocol: Support scaled outputs and surfaces
On ons, 2013-05-22 at 09:11 +0300, Pekka Paalanen wrote: > > > What I would like in the end is a per-output slider bar (or something of > > that ilk) that let's the user select the interface size on that output. > > Sure, they probably won't be able to select *any* resolution (the > > compositor may limit it to multiples of 24 dpi or something). And they can > > certainly make an ugly set-up for themselves. However, I want them to be > > able to make something more-or-less reasonable and I see no reason why the > > compositor shouldn't coordinate this and why this "scale factor" can't be > > used for that. > > I think that is an orthogonal issue. That would be a DE thing, just > like choosing font sizes. Buffer_scale OTOH is a Wayland core feature, > and is best kept as simple as possible. > > The slider would control window and widget sizes, while buffer_scale > only controls the resolution they are rendered in. Or... This is doable, but slightly problematic as you would need a way to coordinate between all clients how to combine these... > > My primary concern is that integer multiples of 96 DPI isn't going to be > > enough granularity. I don't know whether we can really accomplish a higher > > granularity in a reasonable way. > > For the cases where buffer_scale cannot offer a usable resolution, we > can still fall back to arbitrary scaling in the compositor by > private surface or output transformations. That does not allow > pixel-accurate/high-resolution presentation of windows like > buffer_scale, but I believe is an acceptable compromise. Didn't OS X or > something do similar for the 1.5 factor? I recall someone mentioning > about that, but couldn't find it. So, in practice I think this is the more reasonable way to do it, and it is indeed how OSX does it. In some theoretical way doing it by drawing at 2x and downscaling to 1.5x is looks "worse", but neither is going to look really "good" anyway, and the integer surface scaling makes the implementation vastly simpler. > Naturally the units in slider would be scaling factors, not DPI, since > DPI is meaningless to a user. I can imagine how hilarious it would be > to have "Please, try to use integer multiples of 96 DPI for the best > performance and look" in the GUI. ;-) I don't think a slider for scaling factor is the right UI at all. What you want is to just list various "resolutions" and let the user pick one. Some resolution are native, some are scaled by an integer and some are scaled by an fraction. You want to somehow mark out in the UI that some resolutions are "worse" than others, but otherwise this is generally how most end user would think of this anyway. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland surface units (Re: [PATCH 2/2] protocol: Support scaled outputs and surfaces)
On ons, 2013-05-22 at 12:11 +0300, Pekka Paalanen wrote: > On Wed, 22 May 2013 10:12:00 +0200 > Alexander Larsson wrote: > > > On tis, 2013-05-21 at 20:57 +0300, Pekka Paalanen wrote: > > > > > We use the units of "pixels" in the surface coordinate system, even > > > if they do not correspond exactly to any "real" pixels like > > > elements in a buffer or on screen. > > > > Actually this is sort of a problem. Maybe the docs would be clearer if > > we just used a different name for these? "points"? > > That is a good idea, but choosing a name is hard. I think points will > get too easily confused with font sizes or the 1/72 inches unit and all > that mess. > > Follow Android with "dp"? > http://developer.android.com/guide/topics/resources/more-resources.html#Dimension > > I'm not sure that is exactly the definition we want to use, with just > 160 dpi changed to 96 dpi. I feel uneasy mentioning dpi at all. So > maybe not "dp", then. Yeah, i'd rather have it disconnected from some physical notion of size. > We need a name for the surface length unit, since the surface local > coordinate system is such a central concept in Wayland. > > I just can't seem to come up with anything serious. > - wayland units, wu > - wayland pixels, wp, wpx > - surface units, su > - surface unit pixels, sux > - surface pixels, sp, spx > - wayland surface units, wsu > - wayland atomic units, wau > - pips, pip > ehhh... Yeah, names are hard. But "sux" is awesome! Other alternatives: - compositor units, cu - pels, pel - dots, dot - surface element, surfel, sel none of these are great either... ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland surface units (Re: [PATCH 2/2] protocol: Support scaled outputs and surfaces)
On ons, 2013-05-22 at 11:42 +0200, Alexander Larsson wrote: > On ons, 2013-05-22 at 12:11 +0300, Pekka Paalanen wrote: > > - wayland units, wu > > - wayland pixels, wp, wpx > > - surface units, su > > - surface unit pixels, sux > > - surface pixels, sp, spx > > - wayland surface units, wsu > > - wayland atomic units, wau > > - pips, pip > > ehhh... > > Yeah, names are hard. But "sux" is awesome! > > Other alternatives: > - compositor units, cu > - pels, pel > - dots, dot > - surface element, surfel, sel > > none of these are great either... For the record, Microsoft uses "DIP", for Device-independent-pixels, and Apple uses "Points" for the non-hardware coordinates (in the app level APIs). ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland surface units (Re: [PATCH 2/2] protocol: Support scaled outputs and surfaces)
On ons, 2013-05-22 at 13:01 +0300, Pekka Paalanen wrote: > > For the record, Microsoft uses "DIP", for Device-independent-pixels, and > > Apple uses "Points" for the non-hardware coordinates (in the app level > > APIs). > > And we have no well-known equivalent in the FOSS or Linux world? Not that I know of. > DIP would sound fine otherwise, except Microsoft seems to tie it to the > physical units via dpi again. Meh. > > "pel" sounds nice... pel is from "Picture ELement", and was historically used equivalently to "pixel". But "pixel" won that fight and nobody remembers "pel". So, by now we can probably use them as two not-quite-equivalent units without risking confusion. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On ons, 2013-05-22 at 20:57 -0400, Kristian Høgsberg wrote:
> * Don't send out new wl_output events to clients that bind with
>version 1. For this I think we want to extend wl_resource with an
>int version; field.
Somewhat related, and I mentioned this earlier in the thread, we have a
problem with versioning of the *server* too. For instance, if you build
the new wayland server libs and run the old weston on it then you will
get server crashes if some client uses the new wayland ops.
It happens this way:
The old weston client did:
wl_client_add_resource(client, &surface->resource);
However, here resource.object.interface points to wl_surface_interface,
which is:
extern const struct wl_interface wl_surface_interface;
So, the wl_surface_interface is not in the client, but rather in
libwayland-server, as:
WL_EXPORT const struct wl_interface wl_surface_interface = {
"wl_surface", 3,
9, wl_surface_requests,
2, wl_surface_events,
};
This here hardcodes the version (3) into the *server* library rather
than the compositor, so when the compositor is later run with a newer
server library the request dispatcher assumes that the compositor
handles surface version 3, which means it will accept the new requests
and call into the vfunc in the compositor. But that vfunc doesn't
contain the new request, so we call into hyperspace and crash.
Similar things happens in the client if the compositor sends an event
that is later than the version the client bound as. This is clearly a
bug in the compositor though, so its not really as important.
I see two possibilities here. Either we add a version to
wl_client_add_resource() and encode version information into
wl_surface_requests. Then the dispatch machinery can check the version
and only dispatch the right requests. Or we could set up the headers so
that each compositor gets the wl_surface_interface linked into the
compositor itself. Of course, the second version has a similar behavior
to the current in the sense that if you accidentally rebuild the old
weston against the new wayland library you'd still get the crash, so the
first version seems more correct.
I'll have a look at this.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On ons, 2013-05-22 at 20:36 -0500, Jason Ekstrand wrote: > I hate to rain on the parade, but it's not going to be that simple. I > already tried adding a field to wl_resource and, as it currently > stands, it causes major issues. As a reminder, this is because > wl_buffer has a wl_resource field which means that altering > wl_resource breaks binary compatibility for EGL implementations. > > I've been trying to figure out how to do this with my java stuff and I > really think adding a version flag to wl_resource is the way to do it. > Unfortunately, but it's not going to be easy. Both wl_resource and wl_buffer are server internals though. And the server API/ABI is not yet frozen. (In fact we just massively broke it.) wl_buffer does appear in the client header, but just as a declaration, not the type definition. So, this doesn't necessary seem that hard. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] compositor-x11: fix default output scale
- Original Message - > From: Pekka Paalanen > > Default output scale of 256 makes little sense. Actually this is a type > mismatch between wl_fixed and int, probably a leftover from when the > scale factor was proposed as a fixed point number. > > Scale 256 probably causes the Window creation to fail, but that actually > leads to a segfault in Mesa libEGL later: > > Program received signal SIGSEGV, Segmentation fault. > 0 dri2_create_window_surface (drv=0x645060, disp=0x646610, conf= out>, window=, attrib_list=) > at platform_x11.c:291 > > 291 surf->SwapInterval = 1; Ooops. Sorry about that. I guess i never tried to run without a configured output. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
- Original Message - > On Thu, 23 May 2013 10:55:08 +0200 > Alexander Larsson wrote: > > > On ons, 2013-05-22 at 20:36 -0500, Jason Ekstrand wrote: > > > > > > > I hate to rain on the parade, but it's not going to be that simple. I > > > already tried adding a field to wl_resource and, as it currently > > > stands, it causes major issues. As a reminder, this is because > > > wl_buffer has a wl_resource field which means that altering > > > wl_resource breaks binary compatibility for EGL implementations. > > > > > > I've been trying to figure out how to do this with my java stuff and I > > > really think adding a version flag to wl_resource is the way to do it. > > > Unfortunately, but it's not going to be easy. > > > > Both wl_resource and wl_buffer are server internals though. And the > > server API/ABI is not yet frozen. (In fact we just massively broke it.) > > > > wl_buffer does appear in the client header, but just as a declaration, > > not the type definition. > > > > So, this doesn't necessary seem that hard. > > libEGL contains server-side code, too, for implementing > EGL_WL_bind_wayland_display. > > http://cgit.freedesktop.org/mesa/mesa/tree/src/egl/wayland/wayland-drm/wayland-drm.h > > struct wl_drm_buffer will break. Ugh, this is really bad. It also uses the scanner and code generator to create wl_interface structs like wl_drm_interface. This means we can't extend wl_interface, etc, so we can't add a "since version" field to wl_message. So, how can we fix the crash in the server when it gets sent a new request that it doesn't yet handle? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/2] protocol: Support scaled outputs and surfaces
> What if a client sets scale=0? I guess we should forbid that, as it risks things dividing by zero. > Maybe the scale should also be signed here? I think all sizes are > signed, too, even though a negative size does not make sense. We seem > to have a convention, that numbers you compute with are signed, and > enums and flags and bitfields and handles and such are unsigned. And > timestamps, since there we need the overflow behaviour. I > believe it's due to the C promotion or implicit cast rules more than > anything else. Yeah, we should change it to signed. > > @@ -1548,6 +1596,8 @@ > > summary="indicates this is the current mode"/> > > > summary="indicates this is the preferred mode"/> > > + > +summary="indicates that this is a scaled mode"/> > > What do we need the "scaled" flag for? And what does this flag mean? > How is it used? I mean, can we get duplicate native modes that differ > only by the scaled flag? > > Unfortunately I didn't get to answer that thread before, but I had some > disagreement or not understanding there. Yeah, this is the area of the scaling stuff that is least baked. Right now what happens is that the modes get listed at the scaled resolution (i.e. divided by to two, etc), and such scaled mode gets reported with a bit set so client can tell they are not native size. However, this doesn't seem quite right for a few reasons: * We don't report rotated/flipped modes, nor do we swap the width/height for these so this is inconsistent * The clients can tell what the scale is anyway, so what use is it? However, listing the unscaled resolution for the modes is also somewhat problematic. For instance, if we listed the raw modes and an app wanted to go fullscreen in a mode it would need to create a surface of the scaled width/heigh (with the right scale), as otherwise the buffer size would not match the scanout size. For instance, if the output scale is 2 and there is a 800x600 native mode then the app should use a 400x300 surface with a 800x600 buffer and a buffer_scale of 2. Hmmm, I guess if the app used a 800x600 surface with buffer scale 1 we could still scan out from it. Although we'd have to be very careful about how we treat input and pointer position then, as its not quite the same. I'll have a look at changing this. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] wl_resource: Add version field and getter/setter
On tor, 2013-05-23 at 15:54 -0500, Jason Ekstrand wrote: > > > wl_signal_get might be better here. It's more robust in (somewhat > odd) case the user code decides to manually put a listener at the > beginning. It's also more readable and almost just as fast (different > by an if). Yeah, sure, thats probably better. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] wayland-server: Version check requests
On tor, 2013-05-23 at 15:58 -0500, Jason Ekstrand wrote: > > On Thu, May 23, 2013 at 3:20 PM, wrote: > From: Alexander Larsson > > If an interface has any messages and its version is larger > than 1 > then we emit a method counts array which lists the number of > methods > for each version of the interface. This can be used in > addition > to the normal method_count to reject requests that the > server doesn't support. This allows the wayland server library > to be upgraded and still safely run oler compositors that > don't > implement the new requests. > > Since there is no other space in the wm_interface we add the > method count array at the end of the events array. We then > add some warnings to the event sending code so that we never > accidentally trigger these events. > > > Would it possibly be better to use the upper bits of method_count (or > method_count < 0) to signal that a method_counts array is appended to > methods? This keeps methods with methods and also allows us to > optionally do the same thing with events client-side to protect > clients from broken newer-version compositors. It depends on what kind of guarantees we want to make. My hack is 100% backwards compatible in that a library that generates protocol descriptions using the scanner will still work with an older libwayland-server. If the scanner starts producing method_counts with the high bit set then old versions of libwayland-server will handle these as if there was a lot of methods and break the check for invalid requests. Of course, for the case of the core wayland protocol this is not a problem as they are in the same library as the dispatcher. However, one could imagine e.g. weston or libEGL being built with a newer version of scanner and then deployed on an older libwayland-server. Or we could just ignore this case... ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/9] shell: Position DRIVER fullscreen surfaces at origin
On tis, 2013-05-28 at 16:10 -0400, Kristian Høgsberg wrote:
> On Tue, May 28, 2013 at 04:23:32PM +0200, al...@redhat.com wrote:
> > From: Alexander Larsson
> >
> > When a window is fullscreened with DRIVER method and we succeeded
> > in changing mode we need to actually move the surface to the
> > origin of the output, or it won't be used for scanout.
> > ---
> > src/shell.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/src/shell.c b/src/shell.c
> > index 1443328..07be564 100644
> > --- a/src/shell.c
> > +++ b/src/shell.c
> > @@ -1802,6 +1802,9 @@ shell_configure_fullscreen(struct shell_surface
> > *shsurf)
> > shsurf->fullscreen.framerate};
> >
> > if (weston_output_switch_mode(output, &mode) == 0) {
> > + weston_surface_set_position(surface,
> > + output->x -
> > surf_x,
> > + output->y -
> > surf_y);
> >
> > weston_surface_configure(shsurf->fullscreen.black_surface,
> >output->x - surf_x,
> >output->y - surf_y,
>
> Is that not done by this weston_surface_configure() call?
No, they apply to different surfaces, one the client surface, the other
the black surface.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/9] input: Fix possible crash in clip_pointer_motion
On tis, 2013-05-28 at 17:25 -0400, Kristian Høgsberg wrote: > On Tue, May 28, 2013 at 04:23:33PM +0200, al...@redhat.com wrote: > > From: Alexander Larsson > > > > It was erronously using output->current->height in one > > place where it should use output->height. This may cause > > it to create an invalid clipped coordinate in case of output > > scaling or transform, because the next round "prev" would > > end up NULL. > > This an remaining patches look good. The policy change in case of > switching away from a DRIVER fullscreen buffer, is fine, it was always > a bit rough the way it worked before. You applied the weston side, but not the corresponding protocol side: http://lists.freedesktop.org/archives/wayland-devel/2013-May/009498.html ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On tis, 2013-05-28 at 18:33 -0700, Bill Spitzak wrote: > On 05/28/2013 06:40 AM, Pekka Paalanen wrote: > > > If you really need an output scaling factor like 1.5, then you report it > > as either 1 or 2, and do a compensating scaling in the compositor to > > achieve 1.5. That is the best compromize I can imagine, since to be > > honest, 1.5 does not work for the protocol nor the clients' rendering. > > Then it is impossible for the client to render 1:1 with this output's > pixels. All it can do is set the scale to 1 and have it scaled up by 1.5 > to get the output pixels, or set the scale to 2 and have it scaled down > to .75 to get the pixels. > > I don't think you can avoid non-integer scaling. What happens if a > client says it's scale is 3 and the output has a scale of 2? This is not > just hypothetical, it will certainly happen if there is both a scale 3 > and scale 2 output on the device. Yes, the actual scaling that the compositor has to apply from the buffer to a given output may be fractional. However, the scaling factor between the buffer and the surface (i.e. in pels or in global compositor relative sizes) is an integer. This means that any integer position in surface space corresponds to an integer in buffer space, so for instance a pixman region (in ints) damage or clip region in surface space corresponds to an exact pixman region in buffer coordinates. And, this is the transformation that the compositor really cares about internally (e.g. for input scaling, clipping, dirty tracking, etc) rather than the final drawing translation. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On ons, 2013-05-29 at 07:55 -0700, Bill Spitzak wrote: > On 05/29/2013 12:31 AM, Alexander Larsson wrote: > > >> I don't think you can avoid non-integer scaling. What happens if a > >> client says it's scale is 3 and the output has a scale of 2? This is not > >> just hypothetical, it will certainly happen if there is both a scale 3 > >> and scale 2 output on the device. > > > > Yes, the actual scaling that the compositor has to apply from the buffer > > to a given output may be fractional. However, the scaling factor between > > the buffer and the surface (i.e. in pels or in global compositor > > relative sizes) is an integer. This means that any integer position in > > surface space corresponds to an integer in buffer space, so for instance > > a pixman region (in ints) damage or clip region in surface space > > corresponds to an exact pixman region in buffer coordinates. And, this > > is the transformation that the compositor really cares about internally > > (e.g. for input scaling, clipping, dirty tracking, etc) rather than the > > final drawing translation. > > The compositor will produce regions that are not integers in surface > space. For instance the damage from an overlapping window atop a surface > who's scale is not an integer will produce a region that is fractional > in that lower surface's space. Damage from clients is in surface space, which will be in integer fraction of the output space. Its true that it may be a fractional coordinate of the buffer space of a window below it, but it will be an integer coordinate in both windows *surface* space and the output space. So, you can clip the output drawing to integer coordinates (well, you have to, can't draw half an output pixel) and let the actual scaling to fractional coordinates happen purely in the implementation of the drawing operation. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC v2] surface crop & scale protocol extension
On ons, 2013-11-13 at 11:54 +0200, Pekka Paalanen wrote: > On Tue, 12 Nov 2013 16:14:36 -0800 > Bill Spitzak wrote: > > > Pekka Paalanen wrote: > > > > >> The source rectangle *must* be in buffer pixels. Putting it in > > >> buffer_scale units makes absolutely no sense, as the buffer_scale is in > > >> effect ignored for this surface, overridden entirely by the scaling. > > > > > > That means that dst_width and dst_height will be required to be in > > > multiples of buffer_scale. > > > > I am rather confused about this and possibly misunderstanding what > > Wayland is doing. Here is an example of what I think the current design is: > > > > Imagine there is an output_scale of 3 (chosen to not be a power of 2). A > > client is aware of this and wishes to draw a full-resolution display > > that is 2000x2000 pixels and make a subwindow that scales a 512x512 > > picture to fill a 1000x1000 pixel square. > > Is your whole issue based on the premise, that the output resolution is > not a multiple of output_scale? > > Just like you deduced, it won't work. It not working has nothing to do > with crop & scale state. > > Alexander, did you have any ideas for the case when someone sets > output_scale so that output resolution is not divisible by it? The output scale is a hint to the client what kind of pre-scaling it should apply to the buffer to best match the real output. There is no real guarantee that this is an exact match, because the compositor may be projecting it on a 3d-rotated spherical monitor or whatever. It is *commonly* the case that we have a regular rectangular output where the output scale is an integer divisor of the real output resolution such that the buffer can be used unscaled in the scanout framebuffer. I.e. the case of a 2560x1600 native display is typically run with a output scale of 2, which gives a maximized window a surface coordinate space of 1280x800. However, a compositor is also free to do something else, for instance like OSX it can allow using a 1440x900 global coordinate space, while saying output scale is 2. This would result in the client sending 2880x1800 buffers for fullscreen windows that the compositor will have to downscale (by a non-integer scaling factor) to draw to the framebuffer. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
