Re: Gamepad focus model (Re: Input and games.)
Daniel Stone daniel@... writes: I know I've had some trouble expressing my problems with the every-gamepad-in-a-seat proposal, but this pretty much hits the nail on the head. How does the gamepad's focus get assigned (and change) if it's in its own seat? Does it always follow the focus of another wl_seat? If so, why have we created another wl_seat? Is it only to contain a wl_gamepad and nothing else - if so, why are we using seats as an indirection layer? Or do some gamepads go into the seat with the pointer and keyboard and others go into their own seats - if so, isn't that totally arbitrary and more than a little confusing? Okay, so the most common configuration would be one seat with a mouse, keyboard, and gamepad. If you only ever play single player games, this is all you would see. When you have multiplayer games, you just want to be able to launch the game and have everybody automatically in it. You don't want your extra players to have to think about focusing the app or anything like that. That's the crux of the problem: how do you have one focus for multiple players? The many-gamepads-per-seat model solves this, but it has a couple problems: 1) Some compositors may put every gamepad in one seat, and some compositors may assign one gamepad per seat. The game programmer has to support both code paths. And unfortunately, when game programmers inevitably neglect to do that, the gamers are going to blame the compositors rather than the games. Wayland will get a reputation as a display server where you have to configure your gamepads differently for different games. 2) Gamepads aren't the only scenario where you want to have one focus for multiple players. Here's a couple scenarios that are complicated by breaking the seat == user model: A) You're playing split-screen Halo. Two users have a mouse/keyboard, and two users have gamepads. In the seat == user world, we know how this is set up: seat 1 has a mouse/keyboard, seat 2 has a mouse/keyboard, seat 3 has a gamepad, and seat 4 has a gamepad. In the many-gamepads-per-seat model, I don't know how to set this up. The first two players would have to have their own seats, but since the player ID is in the gamepad, where do we get their player numbers from? And what about players 3 and 4? Where do their gamepads go? They can go in seat 1, but then how do you distinguish player 1 from players 3 and 4? And why does player 2 have to manually focus the game? (I don't believe this scenario is inherently exotic. Lemmings, Settlers, and Hired Guns all did this back in the DOS and Amiga days, before OSs made it harder to distinguish mice from each other.) B) Imagine that, with the current trend of adding touchpads to gamepads, Fruit Ninja releases a multi-player version. All players play on the same field, but it tracks their scores independently; whomever slashes the fruit first gets the points. Let's imagine we have player 1 with a separate touchpad, and players 2 and 3 with gamepads that have touchpads built in. In the seat == user model, it's obvious how this should be set up: seat 1 gets a touchpad, seat 2 gets a gamepad with the associated touchpad, and so does seat 3. In the many-gamepads-per-seat model, the question rises again of where you put the gamepads. Do they go in the same seat as the touchpad they're attached to? Or do they all end up in seat 1? If they're all in seat 1, does the player indicator on their controller match up with their actual player number? And again, they all have to individually focus the game. If the focus can be changed independently, how does this happen? Focus can only be changed independently for collaborative seats. Collaborative mode means I want to interact with the desktop independently. When collaborative mode is turned off, your focus is derived from a seat which *is* in collaborative mode. If the keyboard/pointer seat switches focus to another game, do both seats switch, or does the other stay behind? Assuming seat 2 is following seat 1, they both switch. If both switch - why are we complicating the focus model rather than just adding both to a seat? Because this problem doesn't start and end with gamepads. If we take the multiple-gamepads-per-seat model to its logical conclusion, then to support the scenarios above, you would also need multiple mice/keyboards/touchpads per seat. And then how do you determine which devices belong to which players? The wl_seat == one player idea is a nice little mental model, but it's not in any way worth complicating our core input/focus management model for. I believe we're both trying to avoid complication :) -Rick- ___ 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 Mon, May 13, 2013 at 8:52 PM, Jason Ekstrand ja...@jlekstrand.netwrote: On Mon, May 13, 2013 at 9:54 AM, Alexander Larsson al...@redhat.comwrote: 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. My point was that browsers can scale up websites by fractional amounts even though it will look somewhat better with integer factors. 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. 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. 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. Even if two wl_outputs would be presented, they would have the same resolution and scaling factor so priorities still won't matter. 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? 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. For example a compositor may want to use a 1-1.2 range with 1.1 as the desired scaling factor. A clients which are only able to draw at integer scaling factor would round that up to 2 and let the compositor downscale it. When the range for which compositor won't scale is send to clients we can avoid this. Lets take a concrete example. The macbook pro 15 has a 2880 x 1800 native
Re: [PATCH 0/2] Support for high DPI outputs via scaling
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. For example a compositor may want to use a 1-1.2 range with 1.1 as the desired scaling factor. A clients which are only able to draw at integer scaling factor would round that up to 2 and let the compositor downscale it. When the range for which compositor won't scale is send to clients we can avoid this. Giving this range to clients also tells when if they will be scaled on the targeted output. If they are they can ignore information about the pixel layout of the output. 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. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] move subsurface-server-protocol.h include out of compositor.h
On Mon, 13 May 2013 15:55:47 -0700
U. Artie Eoff ullysses.a.e...@intel.com wrote:
From: U. Artie Eoff ullysses.a.e...@intel.com
The subsurface-server-protocol.h header should not be included
by any headers that are part of the SDK since it is not exported.
Otherwise, SDK consumers will break during compilation.
Move this include from compositor.h to compositor.c.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=64537
Signed-off-by: U. Artie Eoff ullysses.a.e...@intel.com
---
src/compositor.c | 1 +
src/compositor.h | 1 -
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compositor.c b/src/compositor.c
index c1f90ca..c16bf0c 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -56,6 +56,7 @@
#include wayland-server.h
#include compositor.h
+#include subsurface-server-protocol.h
#include ../shared/os-compatibility.h
#include git-version.h
#include version.h
diff --git a/src/compositor.h b/src/compositor.h
index d7aa005..99468a1 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -35,7 +35,6 @@ extern C {
#include version.h
#include matrix.h
#include config-parser.h
-#include subsurface-server-protocol.h
#define ARRAY_LENGTH(a) (sizeof (a) / sizeof (a)[0])
Looks good to me!
Thanks for fixing this,
pq
___
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 Mon, 13 May 2013 19:02:34 -0700 Bill Spitzak spit...@gmail.com wrote: Alexander Larsson wrote: On ons, 2013-05-08 at 12:07 -0700, Bill Spitzak wrote: 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. I think it may be useful for clients to compensate for odd transforms that a compositor applies to thumbnails, etc. They could produce a much higher-fidelity image by drawing the transformed image directly. The One could, but we don't. compositor would tell the client I am applying this transform to this surface and the client could re-render the surface using that transform and set the inverse as the transform. The compositor would then multiply these to get an identity and know that it does not have to apply any You cannot get an identity by multiplying real-valued transformations together, other than by accident. Also, we still do not have any floating point formats in the protocol, making transmitting these in the first place a pain. transform to the surface. In fact this is exactly how the buffer_transform works today. (ps: the compositor would only report the fractional part of xy translate, thus preserving the clients don't know where the windows are design feature). buffer_transform works like this only, because the transforms are enumerated, and therefore accurate in the strict mathematical sense. It won't help for wobbly windows unless transform is much more complicated that just the 6-number affine I propose. But at least being able to describe a transform as a single object means that it may be possible to enhance it this way in the future. No. - pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Mon, 13 May 2013 17:26:28 -0500 Jason Ekstrand ja...@jlekstrand.net wrote: On Mon, May 13, 2013 at 4:14 PM, Rafael Antognolli antogno...@gmail.comwrote: Hi Jason, On Wed, May 8, 2013 at 9:26 PM, Jason Ekstrand ja...@jlekstrand.net wrote: Hi Rafael, On Wed, May 8, 2013 at 6:04 PM, Rafael Antognolli antogno...@gmail.com wrote: Hello, I've been looking the Weston code relative to maximized windows, and it seems that the respective code for minimized windows wouldn't be hard to implement. The questions are: are there any plans to add it? Is there someone already working on it? If not, would it be OK if I start submitting patches to try to add support for this? A month or two ago, Scott Morreau was working on it. However, his work never made into weston for a variety of reasons. Personally, I'm glad to see someone interested in working on it again because it's something that wayland will need eventually. The place to start on it is probably with the following e-mail and the long string of replies: http://lists.freedesktop.org/archives/wayland-devel/2013-March/007814.html There was quite a bit of discussion about how to handle it from a protocol level, but Scott never made an actual version 2. I'd suggest you start by reading the chain of e-mails (it goes into April, not just March). There were quite a few suggestions in there that could be incorporated. Hopefully, you can pick through the e-mail discussion and figure out what the consensus was. It'd be good to have a pair of fresh eyes look at it. Thanks for pointing that out. I just went through the chain of e-mails, but I don't think there was a consensus there. It also seems that the minimize implementation is a little more complex than just hiding surfaces and marking some flags. Which makes me not so comfortable doing an implementation without a consensus about what should be implemented, and with some orientation. That said, I'm not sure I'm really going to take this task. I didn't intend to scare you off. Honestly, I don't know for 100% certain how much weston machinery is needed to implement it. It would require some sort of set of flags to keep the compositor and shell plugin in sync. That said, I don't know if its quite as difficult as Scott made it sound. As far as direction goes, the first thing is to think through use-cases and settle on a protocol. Unfortunately, the discussion I linked you to seemed to go nowhere. However, a lot of that was Scott saying, This is the way I want to do it and I'm not going to change. If you look at the other comments, I think there was some consensus in there (at least in a general direction). Feel free to throw some XML together and we can re-start the discussion. For that matter, if you can come up with a way to do it as a weston extension for now (with the hopes of putting it in wayland core later), things can be a lot more flexible and we can play around with protocol concepts as we go. Once a basic protocol is in place, then the client-side needs to be implemented in tinytk (window.c) and the server-side needs to be implemented in weston. I'm sorry I want to add X feature isn't simpler. Basically every new major protocol piece goes through a long mailing list discussion and a lot of revision. Also worth noting, that there are actually two different pieces of protocol involved with minimized windows: - the public protocol, likely part of wl_shell_surface, which all applications use to communicate with the server. This is the important part that will go under strict review, but it is probably also the simpler of the two. You could also check what DE projects have done on this (Gnome/gtk, KDE/Qt, EFL, ...). - the private protocol between Weston and weston-desktop-shell specifically. As we have chosen to let weston-desktop-shell client do all the GUI drawing, and minimized windows will need some GUI (a task bar button, a menu list of windows) to be able to get them back, we need protocol to inform weston-desktop-shell about the windows so it can draw the GUI. But these should not be complicated, once you understand how the basics of a Wayland protocol work. And you don't need to have any complex foreign surface passing protocol to get window thumbnails by hovering the pointer over a taskbar button. Thumbnails can be added later, as it does not concern the public protocol at all. Cheers, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Gamepad focus model (Re: Input and games.)
On Tue, 14 May 2013 04:49:39 + (UTC) Rick Yorgason r...@firefang.com wrote: Daniel Stone daniel@... writes: I know I've had some trouble expressing my problems with the every-gamepad-in-a-seat proposal, but this pretty much hits the nail on the head. How does the gamepad's focus get assigned (and change) if it's in its own seat? Does it always follow the focus of another wl_seat? If so, why have we created another wl_seat? Is it only to contain a wl_gamepad and nothing else - if so, why are we using seats as an indirection layer? Or do some gamepads go into the seat with the pointer and keyboard and others go into their own seats - if so, isn't that totally arbitrary and more than a little confusing? Okay, so the most common configuration would be one seat with a mouse, keyboard, and gamepad. If you only ever play single player games, this is all you would see. When you have multiplayer games, you just want to be able to launch the game and have everybody automatically in it. You don't want your extra players to have to think about focusing the app or anything like that. That's the crux of the problem: how do you have one focus for multiple players? The many-gamepads-per-seat model solves this, but it has a couple problems: 1) Some compositors may put every gamepad in one seat, and some compositors may assign one gamepad per seat. The game programmer has to support both code paths. And unfortunately, when game programmers inevitably neglect to do that, the gamers are going to blame the compositors rather than the games. Wayland will get a reputation as a display server where you have to configure your gamepads differently for different games. 2) Gamepads aren't the only scenario where you want to have one focus for multiple players. Here's a couple scenarios that are complicated by breaking the seat == user model: A) You're playing split-screen Halo. Two users have a mouse/keyboard, and two users have gamepads. In the seat == user world, we know how this is set up: seat 1 has a mouse/keyboard, seat 2 has a mouse/keyboard, seat 3 has a gamepad, and seat 4 has a gamepad. In the many-gamepads-per-seat model, I don't know how to set this up. The first two players would have to have their own seats, but since the player ID is in the gamepad, where do we get their player numbers from? And what about players 3 and 4? Where do their gamepads go? They can go in seat 1, but then how do you distinguish player 1 from players 3 and 4? And why does player 2 have to manually focus the game? (I don't believe this scenario is inherently exotic. Lemmings, Settlers, and Hired Guns all did this back in the DOS and Amiga days, before OSs made it harder to distinguish mice from each other.) B) Imagine that, with the current trend of adding touchpads to gamepads, Fruit Ninja releases a multi-player version. All players play on the same field, but it tracks their scores independently; whomever slashes the fruit first gets the points. Let's imagine we have player 1 with a separate touchpad, and players 2 and 3 with gamepads that have touchpads built in. In the seat == user model, it's obvious how this should be set up: seat 1 gets a touchpad, seat 2 gets a gamepad with the associated touchpad, and so does seat 3. In the many-gamepads-per-seat model, the question rises again of where you put the gamepads. Do they go in the same seat as the touchpad they're attached to? Or do they all end up in seat 1? If they're all in seat 1, does the player indicator on their controller match up with their actual player number? And again, they all have to individually focus the game. If the focus can be changed independently, how does this happen? Focus can only be changed independently for collaborative seats. Collaborative mode means I want to interact with the desktop independently. When collaborative mode is turned off, your focus is derived from a seat which *is* in collaborative mode. If the keyboard/pointer seat switches focus to another game, do both seats switch, or does the other stay behind? Assuming seat 2 is following seat 1, they both switch. If both switch - why are we complicating the focus model rather than just adding both to a seat? Because this problem doesn't start and end with gamepads. If we take the multiple-gamepads-per-seat model to its logical conclusion, then to support the scenarios above, you would also need multiple mice/keyboards/touchpads per seat. And then how do you determine which devices belong to which players? The wl_seat == one player idea is a nice little mental model, but it's not in any way worth complicating our core input/focus management model for. I believe we're both trying to avoid complication :) Rick, this makes sense to me, FWIW. Having proper concepts for describing how a server could assign foci is what was missing. The protocol is a separate thing
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 that all these exists already, even without scaling due to the
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
[PATCH] protocol: Add buffer_scale to wl_surface and wl_output
From: Alexander Larsson al...@redhat.com 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 @@ /event /interface - interface name=wl_surface version=2 + interface name=wl_surface version=3 description summary=an onscreen surface A surface is a rectangular area that is displayed on the screen. It has a location, size and pixel contents. @@ -1110,6 +1110,30 @@ /description arg name=transform type=int/ /request + +!-- Version 3 additions -- + +request name=set_buffer_scale since=3 + description summary=sets the buffer scale + 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 set_buffer_scale. + /description + arg name=scale type=fixed/ +/request /interface interface name=wl_seat version=1 @@ -1467,7 +1491,7 @@ /event /interface - interface name=wl_output version=1 + interface name=wl_output version=2 description summary=compositor output region An output describes part of the compositor geometry. The compositor works in the 'compositor coordinate system' and an @@ -1520,6 +1544,8 @@ The geometry event describes geometric properties of the output. The event is sent when binding to the output object and whenever any of the properties change. + +Some additional properties were later added, see wl_output.geometry2. /description arg name=x type=int summary=x position within the global compositor space/ @@ -1565,6 +1591,17 @@ arg name=height type=int summary=height of the mode in pixels/ arg name=refresh type=int summary=vertical refresh rate in mHz/ /event + +event name=geometry2 since=2 + description summary=additional properties of the output + This event contains additional geometric information +that are not in the geometry event. Whenever it is sent +it will be followed by a geometry event. This way you can +tell by the time the geometry event is recieved whether a +geometry2 event will be seen or not. + /description + arg name=scale type=fixed summary=scaling factor of output/ +/event /interface interface name=wl_region version=1 -- 1.8.1.4 ___ 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 Tue, May 14, 2013 at 11:25 AM, Alexander Larsson al...@redhat.comwrote: 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. Users may want to disable scaling as it's not very good looking. I don't think we should enforce a policy about that. 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. 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. You can't scale the input from configure. You are required to create a surface of that size in surface pixels in order for it to match the screen. Clients should still scale content based on the scaling factor even if it isn't in control of the surface size. 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. It is much much more important that the input remains sharp than exactly the same size. When the client is moved to another output it can resize itself to better suit the scaling factor of it, if it's able to. 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. Most things in the protocol uses surface pixels which is what I usually mean by pixels. ___ 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, al...@redhat.com wrote: From: Alexander Larsson al...@redhat.com 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 @@ /event /interface - interface name=wl_surface version=2 + interface name=wl_surface version=3 description summary=an onscreen surface A surface is a rectangular area that is displayed on the screen. It has a location, size and pixel contents. @@ -1110,6 +1110,30 @@ /description arg name=transform type=int/ /request + +!-- Version 3 additions -- + +request name=set_buffer_scale since=3 + description summary=sets the buffer scale + 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 set_buffer_scale. + /description + arg name=scale type=fixed/ +/request /interface
Re: [PATCH] protocol: Add buffer_scale to wl_surface and wl_output
On Tue, May 14, 2013 at 2:51 PM, Alexander Larsson al...@redhat.com wrote: 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. A window can have multiple surfaces (see the subsurface extension). The API would be the same, the documentation different. 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. Clients can easily require a compositor which implements the done event, although they may also support older versions. It's just the compositor that has to take care not sending done (and geometry2) to the old clients. If you add one, it should be in a separate commit as it's unrelated to this work. On Tue, May 14, 2013 at 12:26 PM, al...@redhat.com wrote: From: Alexander Larsson al...@redhat.com 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 @@ /event /interface - interface name=wl_surface version=2 + interface name=wl_surface version=3 description summary=an onscreen surface A surface is a rectangular area that is displayed on the screen. It has a location, size and pixel contents. @@ -1110,6 +1110,30 @@ /description arg name=transform type=int/ /request + +!-- Version 3 additions -- + +request name=set_buffer_scale since=3 + description summary=sets the buffer scale + 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
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 al...@redhat.com 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 weston] shell: Add a lock binding
On Mon, May 13, 2013 at 11:49 PM, Bill Spitzak spit...@gmail.com wrote: Kristian Høgsberg wrote: The problem then is that the key release of the binding will now count as activity and undo the lock. I think we'll need a custom grab (see weston_compositor_run_key_binding()) that triggers the lock on release of the last key in the binding. Or maybe add a virtual modifier, say MODIFIER_RELEASE, to make the binding code trigger the binding on release instead. Could you just have all release events not count as activity? Hmm, maybe... they way it works now is that pressing and holding a key (or button) inhibits the idle timer and when you then release we reset it. I think the expected behavior is that if you hold down a button long enough for the idle time to expire, releasing the button doesn't immediately trigger the screensaver. That's arguably a corner case of course, but I think that behavior is worth preserving. Kristian ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] config-parser: Honor the XDG_CONFIG_DIRS environment variable
On Mon, May 13, 2013 at 11:41 PM, Othman, Ossama
ossama.oth...@intel.com wrote:
Hi Kristian,
I think it's good to go - however, inlining the patch messed up the
whitespace. Ideally, send patches using git send-email, which can be
configured to use smtp servers, and you can pass --annotate if you
want to add a message or comment to the patch (put it after the ---
that indicates the end of the commit message). Or as a last resort,
attach the patch.
I forgot to attach the patch this last time around. Sorry about that. I'll
just resend the patch with git send-email, as you suggest.
As for the next thing, good catch. I'd do something like
for (p = config_dirs; p != NULL; p = next) {
next = strchrnul(p, ':');
if (*next == ':')
next++;
...
to keep the for (...) more readable.
Changing the loop termination to p != NULL causes an infinite loop since
strchnul() returns a pointer to the null character '\0', not the NULL
Yeah, sorry for the confusion, for a second while writing the email I
was thinking that we could just use strchr instead and test for p !=
NULL, but that doesn't work for getting the end of the last path
element.
pointer. Also, the moving the next pointer past the colon must be done
after path construction, other the colon ends up at the end of the path.
How's this instead:
for (p = config_dirs; *p != '\0'; p = next) {
next = strchrnul(p, ':');
snprintf(path, sizeof path,
%.*s/weston/%s, (int)(next - p), p, name);
fd = open(path, O_RDONLY | O_CLOEXEC);
if (fd = 0)
return fd;
if (*next == ':')
next++;
}
Note that I also had to cast next - p in the snprintf() call to int since
the format specifier %*.s wants an int but the pointer difference on my 64
bit Ubuntu box is a long int, at least according to the format specifier
warning I get:
foo.c: In function ‘open_config_file’:
foo.c:53:5: warning: field precision specifier ‘.*’ expects argument of type
‘int’, but argument 4 has type ‘long int’ [-Wformat]
foo.c in this case is a simple test program I wrote. I assume the cast is
safe since next - p should always fall within the range of type int.
Anyway, I'll resend the patch with the above changes with git send-email.
Yup, that all sounds good.
thanks,
Kristian
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] move subsurface-server-protocol.h include out of compositor.h
On Mon, May 13, 2013 at 03:55:47PM -0700, U. Artie Eoff wrote:
From: U. Artie Eoff ullysses.a.e...@intel.com
The subsurface-server-protocol.h header should not be included
by any headers that are part of the SDK since it is not exported.
Otherwise, SDK consumers will break during compilation.
Move this include from compositor.h to compositor.c.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=64537
Thanks Artie, that's good.
Kristian
Signed-off-by: U. Artie Eoff ullysses.a.e...@intel.com
---
src/compositor.c | 1 +
src/compositor.h | 1 -
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compositor.c b/src/compositor.c
index c1f90ca..c16bf0c 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -56,6 +56,7 @@
#include wayland-server.h
#include compositor.h
+#include subsurface-server-protocol.h
#include ../shared/os-compatibility.h
#include git-version.h
#include version.h
diff --git a/src/compositor.h b/src/compositor.h
index d7aa005..99468a1 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -35,7 +35,6 @@ extern C {
#include version.h
#include matrix.h
#include config-parser.h
-#include subsurface-server-protocol.h
#define ARRAY_LENGTH(a) (sizeof (a) / sizeof (a)[0])
--
1.7.11.7
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Add a colord implementation of a CMS plugin for weston
On Sat, May 11, 2013 at 09:48:22AM +0100, Richard Hughes wrote:
This allows users to change the assigned display profile in GNOME (using
gnome-control-center) or KDE (using colord-kde) and also allows the profiling
tools to correctly inhibit the calibration state whilst measuring the native
screen response.
---
configure.ac | 10 +
src/Makefile.am | 11 ++
src/cms-colord.c | 550
+++
weston.ini | 2 +-
4 files changed, 572 insertions(+), 1 deletion(-)
create mode 100644 src/cms-colord.c
Looks good, committed. Only briefly reviewed this time, but the
interaction with core weston looks good and we don't even have to
touch the core API.
Kristian
diff --git a/configure.ac b/configure.ac
index b71038d..109afee 100644
--- a/configure.ac
+++ b/configure.ac
@@ -277,6 +277,16 @@ AC_ARG_ENABLE(tablet-shell,
AM_CONDITIONAL(ENABLE_TABLET_SHELL,
test x$enable_tablet_shell = xyes)
+# CMS modules
+AC_ARG_ENABLE(colord,
+ AS_HELP_STRING([--disable-colord],
+ [do not build colord CMS support]),,
+ enable_colord=yes)
+AM_CONDITIONAL(ENABLE_COLORD,
+test x$enable_colord = xyes)
+if test x$enable_colord = xyes; then
+ PKG_CHECK_MODULES(COLORD, colord = 0.1.8)
+fi
AC_ARG_ENABLE(wcap-tools, [ --disable-wcap-tools],, enable_wcap_tools=yes)
AM_CONDITIONAL(BUILD_WCAP_TOOLS, test x$enable_wcap_tools = xyes)
diff --git a/src/Makefile.am b/src/Makefile.am
index 92d9e38..2d71e48 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -95,6 +95,7 @@ module_LTLIBRARIES =\
$(desktop_shell)\
$(tablet_shell) \
$(cms_static) \
+ $(cms_colord) \
$(x11_backend) \
$(drm_backend) \
$(wayland_backend) \
@@ -261,6 +262,16 @@ cms_static_la_SOURCES = \
cms-static.c\
cms-helper.c\
cms-helper.h
+if ENABLE_COLORD
+cms_colord = cms-colord.la
+cms_colord_la_LDFLAGS = -module -avoid-version
+cms_colord_la_LIBADD = $(COMPOSITOR_LIBS) $(COLORD_LIBS)
+cms_colord_la_CFLAGS = $(GCC_CFLAGS) $(COMPOSITOR_CFLAGS) $(COLORD_CFLAGS)
+cms_colord_la_SOURCES = \
+ cms-colord.c\
+ cms-helper.c\
+ cms-helper.h
+endif
endif
BUILT_SOURCES = \
diff --git a/src/cms-colord.c b/src/cms-colord.c
new file mode 100644
index 000..33f23b2
--- /dev/null
+++ b/src/cms-colord.c
@@ -0,0 +1,550 @@
+/*
+ * Copyright © 2013 Richard Hughes
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and
+ * its documentation for any purpose is hereby granted without fee, provided
+ * that the above copyright notice appear in all copies and that both that
+ * copyright notice and this permission notice appear in supporting
+ * documentation, and that the name of the copyright holders not be used in
+ * advertising or publicity pertaining to distribution of the software
+ * without specific, written prior permission. The copyright holders make
+ * no representations about the suitability of this software for any
+ * purpose. It is provided as is without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+ * SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+ * FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+ * SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
+ * RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
+ * CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
+ * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+#define _GNU_SOURCE
+#include fcntl.h
+#include unistd.h
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include colord.h
+
+#include compositor.h
+#include cms-helper.h
+
+struct cms_colord {
+ struct weston_compositor*ec;
+ CdClient*client;
+ GHashTable *devices; /* key = device-id, value =
cms_output */
+ GHashTable *pnp_ids; /* key = pnp-id, value =
vendor */
+ gchar *pnp_ids_data;
+ GMainLoop *loop;
+ GThread *thread;
+ GList *pending;
+ GMutex pending_mutex;
+ struct wl_event_source *source;
+ int readfd;
+ int
Re: Gamepad focus model (Re: Input and games.)
(Still digesting the rest of the thread.) On 14 May 2013 08:11, Peter Hutterer peter.hutte...@who-t.net wrote: the other thing that made me thing about your approach: with the gamepad_manager, you've got an extra layer in the tree for gamepads that pointers/keyboards don't have. that's not a bad thing and focus handling is easier this way, but now you could also look at pointers and keyboards and see if that extra layer is useful for those two. And I think it would be - e.g. wacom devices share their focus with the pointer, but also have their device-specific stuff that clients may need. The reason that's there is because Wayland is heavily object-driven. Rather than firing out event selections, you mostly register for events by binding to interfaces which send them. So, you need wl_gamepad_manager to support more than one gamepad per seat; you could have the seat send out new gamepad events directly, but then you don't have any way to unregister for those events - so we use wl_gamepad_manager, and when it's destroyed, you don't get new events from it. Cheers, Daniel ___ 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 Tue, May 14, 2013 at 3:19 PM, Alexander Larsson al...@redhat.com wrote: 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 al...@redhat.com 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. I might have been unclear. Users may want to disable resizing of buffer pixels in the compositor. However clients which able to draw at the correct scaling factor should still do so and appear pixel perfect. 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). Backwards compatibility with what? How would you handle subsurfaces with different scaling factors? What coordinates would the subsurface's position be in? 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. In my proposal the compositor will scale down configure arguments by the same amount it resizes the window up. 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. 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. It's also worth considering the edge cases when pixels doesn't scale down so easily. Say we have a workspace of 2000x1901 and we have a scaling factor of 2 and we want to maximize the client. With a scale factor unaware legacy client we'd have to send 1000x950.5 which would have to be rounded to 1000x951. We could compensate by cropping or stretching to fill the workspace. With a client using a scaling factor of 2 I'd send 2000x1901 which the client might be able to fill exactly or it might just pretend it's 2000x1902 and crop the result. In your proposal this would still have to be rounded to 1000x951 and clients able to fill 2000x1901 exactly would render at 2000x1902 instead. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] text: Respawn input method process if it exits
From: Eduardo Lima (Etrunko) eduardo.l...@intel.com
Just the same as it is done in shell.c, if the input method process exits
for any reason, we relaunch it automatically, as it is not possible to
launch a standalone application outside of the weston process.
Signed-off-by: Eduardo Lima (Etrunko) eduardo.l...@intel.com
---
src/text-backend.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/src/text-backend.c b/src/text-backend.c
index d7ce31c..52c0814 100644
--- a/src/text-backend.c
+++ b/src/text-backend.c
@@ -23,6 +23,7 @@
#include stdlib.h
#include string.h
+#include time.h
#include compositor.h
#include text-server-protocol.h
@@ -91,6 +92,9 @@ struct text_backend {
struct wl_resource *binding;
struct weston_process process;
struct wl_client *client;
+
+ unsigned deathcount;
+ uint32_t deathstamp;
} input_method;
struct wl_listener seat_created_listener;
@@ -819,14 +823,33 @@ input_method_init_seat(struct weston_seat *seat)
seat-input_method-focus_listener_initialized = 1;
}
+static void launch_input_method(struct text_backend *text_backend);
+
static void
handle_input_method_sigchld(struct weston_process *process, int status)
{
+ uint32_t time;
struct text_backend *text_backend =
container_of(process, struct text_backend,
input_method.process);
text_backend-input_method.process.pid = 0;
text_backend-input_method.client = NULL;
+
+ /* if input_method dies more than 5 times in 10 seconds, give up */
+ time = weston_compositor_get_time();
+ if (time - text_backend-input_method.deathstamp 1) {
+ text_backend-input_method.deathstamp = time;
+ text_backend-input_method.deathcount = 0;
+ }
+
+ text_backend-input_method.deathcount++;
+ if (text_backend-input_method.deathcount 5) {
+ weston_log(weston-desktop-shell died, giving up.\n);
+ return;
+ }
+
+ weston_log(input_method died, respawning...\n);
+ launch_input_method(text_backend);
}
static void
--
1.8.1.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Gamepad focus model (Re: Input and games.)
Hi, On 14 May 2013 05:49, Rick Yorgason r...@firefang.com wrote: Okay, so the most common configuration would be one seat with a mouse, keyboard, and gamepad. If you only ever play single player games, this is all you would see. When you have multiplayer games, you just want to be able to launch the game and have everybody automatically in it. You don't want your extra players to have to think about focusing the app or anything like that. Yes, 100%. That's the crux of the problem: how do you have one focus for multiple players? The many-gamepads-per-seat model solves this, but it has a couple problems: 1) Some compositors may put every gamepad in one seat, and some compositors may assign one gamepad per seat. The game programmer has to support both code paths. And unfortunately, when game programmers inevitably neglect to do that, the gamers are going to blame the compositors rather than the games. Wayland will get a reputation as a display server where you have to configure your gamepads differently for different games. Compositors can implement maximise badly too, or multi-display support. But it's not an argument to push the complexity out. It's an argument for not running broken compositors. 2) Gamepads aren't the only scenario where you want to have one focus for multiple players. Here's a couple scenarios that are complicated by breaking the seat == user model: It's not seat == user, it's seat == focus. A) You're playing split-screen Halo. Two users have a mouse/keyboard, and two users have gamepads. In the seat == user world, we know how this is set up: seat 1 has a mouse/keyboard, seat 2 has a mouse/keyboard, seat 3 has a gamepad, and seat 4 has a gamepad. We know how it's set up, but we don't know how it works. How does the compositor know to focus 3 and 4 at Halo, rather than at the browser or whatever else is running at the time? You can't have the keyboard and mouse tell you, because they're different seats. So it's just manual then? Or the compositor making random guesses? In the many-gamepads-per-seat model, I don't know how to set this up. The first two players would have to have their own seats, but since the player ID is in the gamepad, where do we get their player numbers from? And what about players 3 and 4? Where do their gamepads go? They can go in seat 1, but then how do you distinguish player 1 from players 3 and 4? And why does player 2 have to manually focus the game? The gamepads go to whichever seat it is that's directing their focus. If their focus is entirely manually set, then they go in their own seat. Simple, no? Or am I totally missing something, and do gamepads under Wayland typically not follow keyboard/mouse focii? (I don't mean in really contrived theoretical cases, I mean in the overwhelming majority of situations.) (I don't believe this scenario is inherently exotic. Lemmings, Settlers, and Hired Guns all did this back in the DOS and Amiga days, before OSs made it harder to distinguish mice from each other.) Yes, that's the tradeoff you get for multitasking, and having the OS know where your mice are, rather than having to tell every single game where every single mouse is. B) Imagine that, with the current trend of adding touchpads to gamepads, Fruit Ninja releases a multi-player version. All players play on the same field, but it tracks their scores independently; whomever slashes the fruit first gets the points. Let's imagine we have player 1 with a separate touchpad, and players 2 and 3 with gamepads that have touchpads built in. In the seat == user model, it's obvious how this should be set up: seat 1 gets a touchpad, seat 2 gets a gamepad with the associated touchpad, and so does seat 3. In the many-gamepads-per-seat model, the question rises again of where you put the gamepads. Do they go in the same seat as the touchpad they're attached to? Or do they all end up in seat 1? If they're all in seat 1, does the player indicator on their controller match up with their actual player number? And again, they all have to individually focus the game. Again, how does the focus get changed? Where are the gamepads deriving their focus from? Put them in that seat, and add a wl_touch object for every gamepad. If the focus can be changed independently, how does this happen? Focus can only be changed independently for collaborative seats. Collaborative mode means I want to interact with the desktop independently. When collaborative mode is turned off, your focus is derived from a seat which *is* in collaborative mode. OK, so what's the downside from having the gamepad embedded inside the seat it derives its focus from? If the keyboard/pointer seat switches focus to another game, do both seats switch, or does the other stay behind? Assuming seat 2 is following seat 1, they both switch. If both switch - why are we complicating the focus model rather than just adding both to a seat?
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 0/2] Support for high DPI outputs via scaling
On Tue, May 14, 2013 at 5:49 PM, Alexander Larsson al...@redhat.com wrote: 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? I thought you were referring to something else since there's still won't be any scaling from buffer to surface coordinates in the legacy client case. 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. That won't work. Currently a subsurface's position is relative to the parent surface in the parent's surface coordinates. 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. The compositor knows if it's drawing pixels at a 1:1 rate or if it's doing resizing. 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] text: Respawn input method process if it exits
On 05/14/2013 12:47 PM, Michael Hasselmann wrote:
On Tue, 2013-05-14 at 12:16 -0300, Eduardo Lima (Etrunko) wrote:
+static void launch_input_method(struct text_backend *text_backend);
+
static void
handle_input_method_sigchld(struct weston_process *process, int status)
{
+uint32_t time;
struct text_backend *text_backend =
container_of(process, struct text_backend,
input_method.process);
text_backend-input_method.process.pid = 0;
text_backend-input_method.client = NULL;
+
+/* if input_method dies more than 5 times in 10 seconds, give up */
+time = weston_compositor_get_time();
+if (time - text_backend-input_method.deathstamp 1) {
+text_backend-input_method.deathstamp = time;
+text_backend-input_method.deathcount = 0;
+}
+
+text_backend-input_method.deathcount++;
+if (text_backend-input_method.deathcount 5) {
+weston_log(weston-desktop-shell died, giving up.\n);
Wrong log message, should be input_method died, giving up.\n
Ah the wonders of copy and paste, thanks for the spot. :) I am sending
the patch with the proper message again.
+return;
+}
+
+weston_log(input_method died, respawning...\n);
+launch_input_method(text_backend);
I am not smart enough to figure out whether this could be abused to
launch a (possibly untrusted) 3rd party input method at runtime, say by
manipulating some cached config and then triggering a crash in the input
method.
Yes, this is something that should concern not only the input method,
but also other plugins, such as the desktop shell itself.
Regards, Etrunko
--
Eduardo de Barros Lima (Etrunko)
Software Engineer, Open Source Technology Center
Intel Corporation
São Paulo, Brazil
eduardo.l...@linux.intel.com
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Gamepad focus model (Re: Input and games.)
On Tue, May 14, 2013 at 10:18 AM, Daniel Stone dan...@fooishbar.org wrote: Hi, On 14 May 2013 05:49, Rick Yorgason r...@firefang.com wrote: Okay, so the most common configuration would be one seat with a mouse, keyboard, and gamepad. If you only ever play single player games, this is all you would see. When you have multiplayer games, you just want to be able to launch the game and have everybody automatically in it. You don't want your extra players to have to think about focusing the app or anything like that. Yes, 100%. That's the crux of the problem: how do you have one focus for multiple players? The many-gamepads-per-seat model solves this, but it has a couple problems: 1) Some compositors may put every gamepad in one seat, and some compositors may assign one gamepad per seat. The game programmer has to support both code paths. And unfortunately, when game programmers inevitably neglect to do that, the gamers are going to blame the compositors rather than the games. Wayland will get a reputation as a display server where you have to configure your gamepads differently for different games. Compositors can implement maximise badly too, or multi-display support. But it's not an argument to push the complexity out. It's an argument for not running broken compositors. 2) Gamepads aren't the only scenario where you want to have one focus for multiple players. Here's a couple scenarios that are complicated by breaking the seat == user model: It's not seat == user, it's seat == focus. A) You're playing split-screen Halo. Two users have a mouse/keyboard, and two users have gamepads. In the seat == user world, we know how this is set up: seat 1 has a mouse/keyboard, seat 2 has a mouse/keyboard, seat 3 has a gamepad, and seat 4 has a gamepad. We know how it's set up, but we don't know how it works. How does the compositor know to focus 3 and 4 at Halo, rather than at the browser or whatever else is running at the time? You can't have the keyboard and mouse tell you, because they're different seats. So it's just manual then? Or the compositor making random guesses? In the many-gamepads-per-seat model, I don't know how to set this up. The first two players would have to have their own seats, but since the player ID is in the gamepad, where do we get their player numbers from? And what about players 3 and 4? Where do their gamepads go? They can go in seat 1, but then how do you distinguish player 1 from players 3 and 4? And why does player 2 have to manually focus the game? The gamepads go to whichever seat it is that's directing their focus. If their focus is entirely manually set, then they go in their own seat. Simple, no? Or am I totally missing something, and do gamepads under Wayland typically not follow keyboard/mouse focii? (I don't mean in really contrived theoretical cases, I mean in the overwhelming majority of situations.) (I don't believe this scenario is inherently exotic. Lemmings, Settlers, and Hired Guns all did this back in the DOS and Amiga days, before OSs made it harder to distinguish mice from each other.) Yes, that's the tradeoff you get for multitasking, and having the OS know where your mice are, rather than having to tell every single game where every single mouse is. B) Imagine that, with the current trend of adding touchpads to gamepads, Fruit Ninja releases a multi-player version. All players play on the same field, but it tracks their scores independently; whomever slashes the fruit first gets the points. Let's imagine we have player 1 with a separate touchpad, and players 2 and 3 with gamepads that have touchpads built in. In the seat == user model, it's obvious how this should be set up: seat 1 gets a touchpad, seat 2 gets a gamepad with the associated touchpad, and so does seat 3. In the many-gamepads-per-seat model, the question rises again of where you put the gamepads. Do they go in the same seat as the touchpad they're attached to? Or do they all end up in seat 1? If they're all in seat 1, does the player indicator on their controller match up with their actual player number? And again, they all have to individually focus the game. Again, how does the focus get changed? Where are the gamepads deriving their focus from? Put them in that seat, and add a wl_touch object for every gamepad. If the focus can be changed independently, how does this happen? Focus can only be changed independently for collaborative seats. Collaborative mode means I want to interact with the desktop independently. When collaborative mode is turned off, your focus is derived from a seat which *is* in collaborative mode. OK, so what's the downside from having the gamepad embedded inside the seat it derives its focus from? If the keyboard/pointer seat switches focus to another game, do both seats switch, or does the
Re: [PATCH] config-parser: Honor the XDG_CONFIG_DIRS environment variable
Hi Kristian,
I've attached the patch since the patch I sent through git send-mail was
sent through an e-mail account that isn't subscribed to this list (waiting
for moderator approval), and to make sure the spacing isn't munged again.
This patch was generated against weston master as of this morning.
Sorry for the churn.
-Ossama
On Tue, May 14, 2013 at 7:05 AM, Kristian Høgsberg hoegsb...@gmail.comwrote:
On Mon, May 13, 2013 at 11:41 PM, Othman, Ossama
ossama.oth...@intel.com wrote:
Hi Kristian,
I think it's good to go - however, inlining the patch messed up the
whitespace. Ideally, send patches using git send-email, which can be
configured to use smtp servers, and you can pass --annotate if you
want to add a message or comment to the patch (put it after the ---
that indicates the end of the commit message). Or as a last resort,
attach the patch.
I forgot to attach the patch this last time around. Sorry about that.
I'll
just resend the patch with git send-email, as you suggest.
As for the next thing, good catch. I'd do something like
for (p = config_dirs; p != NULL; p = next) {
next = strchrnul(p, ':');
if (*next == ':')
next++;
...
to keep the for (...) more readable.
Changing the loop termination to p != NULL causes an infinite loop
since
strchnul() returns a pointer to the null character '\0', not the NULL
Yeah, sorry for the confusion, for a second while writing the email I
was thinking that we could just use strchr instead and test for p !=
NULL, but that doesn't work for getting the end of the last path
element.
pointer. Also, the moving the next pointer past the colon must be done
after path construction, other the colon ends up at the end of the path.
How's this instead:
for (p = config_dirs; *p != '\0'; p = next) {
next = strchrnul(p, ':');
snprintf(path, sizeof path,
%.*s/weston/%s, (int)(next - p), p, name);
fd = open(path, O_RDONLY | O_CLOEXEC);
if (fd = 0)
return fd;
if (*next == ':')
next++;
}
Note that I also had to cast next - p in the snprintf() call to int
since
the format specifier %*.s wants an int but the pointer difference on
my 64
bit Ubuntu box is a long int, at least according to the format specifier
warning I get:
foo.c: In function ‘open_config_file’:
foo.c:53:5: warning: field precision specifier ‘.*’ expects argument of
type
‘int’, but argument 4 has type ‘long int’ [-Wformat]
foo.c in this case is a simple test program I wrote. I assume the cast
is
safe since next - p should always fall within the range of type int.
Anyway, I'll resend the patch with the above changes with git send-email.
Yup, that all sounds good.
thanks,
Kristian
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
0001-config-parser-Honor-XDG_CONFIG_DIRS.patch
Description: Binary data
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2] text: Respawn input method process if it exits
On Tue, May 14, 2013 at 01:09:31PM -0300, Eduardo Lima (Etrunko) wrote:
From: Eduardo Lima (Etrunko) eduardo.l...@intel.com
Just the same as it is done in shell.c, if the input method process exits
for any reason, we relaunch it automatically, as it is not possible to
launch a standalone application outside of the weston process.
In v2:
- Proper error message when giving up.
That looks good, thanks Eduardo.
Kristian
Signed-off-by: Eduardo Lima (Etrunko) eduardo.l...@intel.com
---
src/text-backend.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/src/text-backend.c b/src/text-backend.c
index d7ce31c..5be4a67 100644
--- a/src/text-backend.c
+++ b/src/text-backend.c
@@ -23,6 +23,7 @@
#include stdlib.h
#include string.h
+#include time.h
#include compositor.h
#include text-server-protocol.h
@@ -91,6 +92,9 @@ struct text_backend {
struct wl_resource *binding;
struct weston_process process;
struct wl_client *client;
+
+ unsigned deathcount;
+ uint32_t deathstamp;
} input_method;
struct wl_listener seat_created_listener;
@@ -819,14 +823,33 @@ input_method_init_seat(struct weston_seat *seat)
seat-input_method-focus_listener_initialized = 1;
}
+static void launch_input_method(struct text_backend *text_backend);
+
static void
handle_input_method_sigchld(struct weston_process *process, int status)
{
+ uint32_t time;
struct text_backend *text_backend =
container_of(process, struct text_backend,
input_method.process);
text_backend-input_method.process.pid = 0;
text_backend-input_method.client = NULL;
+
+ /* if input_method dies more than 5 times in 10 seconds, give up */
+ time = weston_compositor_get_time();
+ if (time - text_backend-input_method.deathstamp 1) {
+ text_backend-input_method.deathstamp = time;
+ text_backend-input_method.deathcount = 0;
+ }
+
+ text_backend-input_method.deathcount++;
+ if (text_backend-input_method.deathcount 5) {
+ weston_log(input_method died, giving up.\n);
+ return;
+ }
+
+ weston_log(input_method died, respawning...\n);
+ launch_input_method(text_backend);
}
static void
--
1.8.1.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Gamepad focus model (Re: Input and games.)
Rick Yorgason wrote: When you have multiplayer games, you just want to be able to launch the game and have everybody automatically in it. You don't want your extra players to have to think about focusing the app or anything like that. That's the crux of the problem: how do you have one focus for multiple players? I feel the underlying function should be this: 1. The game can enumerate all the gamepads. 2. The game can grab the focus for any gamepads it wants. Once it is grabbed, the pointer motion makes NO difference, removing a lot of the questions people are asking here. If the device was moving the pointer, it stops moving the pointer. If another device like a mouse moves the pointer, it continues to do so, but it does not matter if the mouse is moved outside the game and clicked elsewhere: the mouse works like normal sending clicks to that other client, and the gamepad events continue going to the game. The only complexity is to prevent clients from grabbing the gamepad when they should not. For this the grab the focus does not work unless the shell allows it to. As I see it the gamepad is attached to at most one pointer. The gamepad can be grabbed if the client has that pointer's focus. The gamepad can also be attached to any number of other devices. It can also be grabbed if the event that triggered the grab request is a focus-in or event for a related device (this is so keyboard keys can cause a gamepad grab). Specifying this attachement is where the seat and hierarchy comes in. I very much agree that the seat==user idea is best. Otherwise it seems like seats are pretty useless, and users would have to be added to wayland anyway, making it more complex for no good reason. To get the one seat per gamepad but they all share the same pointer the parent-seat proposal seems like as easy fit. I am having a hard time coming up with a plausible setup that this would not cover. Grabbing a gamepad does not change this parenting in any 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
John Kåre Alsaker wrote: The size of a window should always be in pixels at the protocol level. Note that this is in direct contradiction to the proposed scaler api. In it the size of the window is in transformed pixels. I think now the scaler proposal should be changed. ___ 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
Pekka Paalanen wrote: You cannot get an identity by multiplying real-valued transformations together, other than by accident. This is why I propose sending the inverse of the matrix, so the identity can be checked accurately. It also happens that the inverse matrix is the same matrix that is needed to tell cairo to draw the image correctly. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Extremly interesting career opportunity for Wayland Project Committers/Contributors
Hi, I'm a Head-hunter dedicated to the European Mobile and Consumer Technology space and representing a hugely impressive mobile consumer technology innovator to help them create an exciting new open source lab to ensure that their business is positioned at the forefront of leading edge open source software engineering. The lab (split across various European locations) is to be made up of software engineers that will continue to be focused on and contribute to external open source community projects (70-80% of the team's work will be external/community focused). Wayland is one of the priority projects for the lab alongside other projects including LLVM, Linux Kernel Web technologies (groups include Webkit, Chromium node.js). This is an exciting new group being invested in and there are no limits to how significant and influential these team roles will be both within the global business as well as externally. As well as the chance to be one of the founding members of an exciting new team set for real expansion, on offer for every position is fantastic career potential extremely attractive salaries benefits packages. Whilst the teams are being grown from specific European locations, there is also scope for flexible/remote or home working for highly capable individuals with regular Wayland project contributions/commits. If you could be interested in a Wayland focused position within this new open source team, I would be delighted to share further information with you. Any approach and subsequent dialogue will of course be treated 100% confidentially by me. My contact details are: Phone:+44 845 605 1785 Email: ch...@bigpondsolutions.com My company's website is www.bigpondsolutions.com If you are still reading at this stage, thank you for your time and I hope to hear from you soon. Yours faithfully, Chris Chris Bower Director - Executive Search Tel: +44 (0) 845 605 1785 (DD) FAX: +44 (0) 845 605 1781 Skype: 'chrisbower' Email: mailto:ch...@bigpondsolutions.com ch...@bigpondsolutions.com Web:http://www.bigpondsolutions.com/ www.bigpondsolutions.com Description: Description: cid:image001.jpg@01C8956D.D869B7C0 Big Pond Solutions is a leading Search Selection Consultancy within the Wireless and Consumer Technology marketplace covering Europe, North America and the Asia-Pacific region. Since 2001 we have delivered tailored recruitment solutions across both Commercial and Technical disciplines, partnering with innovative companies from emerging and rapid-growth start-ups to established multi-nationals. _ Big Pond Solutions operate both as an employment business and an employment agency. All personal details received by the Company in relation to the conduct of these businesses are treated as strictly private and confidential. Personal data regarding qualifications, work experience and history is supplied, as necessary, to clients for temporary or permanent placements, and generally as provided in the Company's registration under the Data Protection Act. All personal data supplied to the Company will be dealt with fairly and in accordance with the requirements of the Data Protection Act. image001.jpg___ 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
Alexander Larsson wrote: 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. The compositor can use the scaling factor of the surface to send all events to in, including maximize. So it can send 2000x2000 to the hi-res client and 1000x1000 to the client that did not set the scaling factor. In fact this is going to be necessary if you want to support maximize sizes that are not a multiple of the scale. ___ 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
al...@redhat.com wrote: + /description + arg name=scale type=fixed/ +/request /interface 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... ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] config-parser: Honor the XDG_CONFIG_DIRS environment variable
On Tue, May 14, 2013 at 09:55:19AM -0700, Othman, Ossama wrote:
Hi Kristian,
I've attached the patch since the patch I sent through git send-mail was
sent through an e-mail account that isn't subscribed to this list (waiting
for moderator approval), and to make sure the spacing isn't munged again.
This patch was generated against weston master as of this morning.
Cool, looks good now, committed. I did catch a corner case in the
spec that we could handle better. As far as I can see,
XDG_CONFIG_HOME, if set, overrides ~/.config. That means if it's set
and we don't find a config file there, we shouldn't fall back and try
~/.config/weston.ini. Similarly, only if XDG_CONFIG_DIRS is not set
do we fall back to /etc/xdg, but we do handle correctly with your
patch. Also the spec says not set or empty, so we should be
checking !config_dirs || *config_dirs == '\0'.
Finally, I didn't see a reason for adding weston/ to the path when
iterating the XDG_CONFIG_DIRS? I guess many applications put their
config file in a subdirectory of the config dir, but at least for
~/.config/weston.ini we don't do that.
I committed a small patch to fix up these issues - let me know if you
see a problem.
Sorry for the churn.
No that's fine, we usually go through a couple of revisions of review
before committing the patch.
Thanks,
Kristian
On Tue, May 14, 2013 at 7:05 AM, Kristian Høgsberg hoegsb...@gmail.comwrote:
On Mon, May 13, 2013 at 11:41 PM, Othman, Ossama
ossama.oth...@intel.com wrote:
Hi Kristian,
I think it's good to go - however, inlining the patch messed up the
whitespace. Ideally, send patches using git send-email, which can be
configured to use smtp servers, and you can pass --annotate if you
want to add a message or comment to the patch (put it after the ---
that indicates the end of the commit message). Or as a last resort,
attach the patch.
I forgot to attach the patch this last time around. Sorry about that.
I'll
just resend the patch with git send-email, as you suggest.
As for the next thing, good catch. I'd do something like
for (p = config_dirs; p != NULL; p = next) {
next = strchrnul(p, ':');
if (*next == ':')
next++;
...
to keep the for (...) more readable.
Changing the loop termination to p != NULL causes an infinite loop
since
strchnul() returns a pointer to the null character '\0', not the NULL
Yeah, sorry for the confusion, for a second while writing the email I
was thinking that we could just use strchr instead and test for p !=
NULL, but that doesn't work for getting the end of the last path
element.
pointer. Also, the moving the next pointer past the colon must be done
after path construction, other the colon ends up at the end of the path.
How's this instead:
for (p = config_dirs; *p != '\0'; p = next) {
next = strchrnul(p, ':');
snprintf(path, sizeof path,
%.*s/weston/%s, (int)(next - p), p, name);
fd = open(path, O_RDONLY | O_CLOEXEC);
if (fd = 0)
return fd;
if (*next == ':')
next++;
}
Note that I also had to cast next - p in the snprintf() call to int
since
the format specifier %*.s wants an int but the pointer difference on
my 64
bit Ubuntu box is a long int, at least according to the format specifier
warning I get:
foo.c: In function ‘open_config_file’:
foo.c:53:5: warning: field precision specifier ‘.*’ expects argument of
type
‘int’, but argument 4 has type ‘long int’ [-Wformat]
foo.c in this case is a simple test program I wrote. I assume the cast
is
safe since next - p should always fall within the range of type int.
Anyway, I'll resend the patch with the above changes with git send-email.
Yup, that all sounds good.
thanks,
Kristian
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Gamepad focus model (Re: Input and games.)
Hi Bill, In reply to everything below, I don't think there's anything in any of the proposals that prevents compositors from implementing pointer emulation for gamepads, or from suspending that emulation when a game has the gamepad's focus. -Rick- On 2013-05-14 15:08, Bill Spitzak wrote: I feel the underlying function should be this: 1. The game can enumerate all the gamepads. 2. The game can grab the focus for any gamepads it wants. Once it is grabbed, the pointer motion makes NO difference, removing a lot of the questions people are asking here. If the device was moving the pointer, it stops moving the pointer. If another device like a mouse moves the pointer, it continues to do so, but it does not matter if the mouse is moved outside the game and clicked elsewhere: the mouse works like normal sending clicks to that other client, and the gamepad events continue going to the game. The only complexity is to prevent clients from grabbing the gamepad when they should not. For this the grab the focus does not work unless the shell allows it to. As I see it the gamepad is attached to at most one pointer. The gamepad can be grabbed if the client has that pointer's focus. The gamepad can also be attached to any number of other devices. It can also be grabbed if the event that triggered the grab request is a focus-in or event for a related device (this is so keyboard keys can cause a gamepad grab). Specifying this attachement is where the seat and hierarchy comes in. I very much agree that the seat==user idea is best. Otherwise it seems like seats are pretty useless, and users would have to be added to wayland anyway, making it more complex for no good reason. To get the one seat per gamepad but they all share the same pointer the parent-seat proposal seems like as easy fit. I am having a hard time coming up with a plausible setup that this would not cover. Grabbing a gamepad does not change this parenting in any 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 Tue, May 14, 2013 at 9:16 PM, Bill Spitzak spit...@gmail.com wrote: John Kåre Alsaker wrote: The size of a window should always be in pixels at the protocol level. Note that this is in direct contradiction to the proposed scaler api. In it the size of the window is in transformed pixels. I think now the scaler proposal should be changed. I was referring to surface pixels here, which is what you get after the transformation of the scaler extension. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
