Re: Gamepad focus model (Re: Input and games.)
On Mon, 13 May 2013 09:12:03 +1000 Peter Hutterer peter.hutte...@who-t.net wrote: On Fri, May 10, 2013 at 10:41:45AM +0300, Pekka Paalanen wrote: On Thu, 9 May 2013 16:44:09 +1000 Peter Hutterer peter.hutte...@who-t.net wrote: On Mon, May 06, 2013 at 03:36:20PM +0300, Pekka Paalanen wrote: [...] I had a private chat with Daniel, and we came to an understanding, which I try to describe below. The interface names below are more like placeholders for now. Into wl_seat, we should add a capability bit for gamepad. When the bit is set, a client can send wl_seat::get_gamepad_manager request, which creates a new wl_gamepad_manager object. (Do we actually need a capability bit?) A wl_gamepad_manager will send an event for each physical gamepad (as it dynamically appears, if hotplugged later) associated with this particular wl_seat, creating a wl_gamepad object for each. A wl_gamepad object will send an event about the player id as the first thing, and also if it later changes. do you expect the player ID to be exposed on the protocol? what does it contain and who manages the association? is it related to any physical ID of the gamepad, and if not, can such ID be provided (if the device supports it)? I imagined the player ID to be sent explicitly in the protocol, with its very own event. The server would manage the association between physical devices and the player ID, according to built-in heuristics and user preferences. E.g. if one goes from 0 gamepads to 1 gamepad, it will always be player 1; or maybe take the first player slot that does not have a gamepad, unless we identify the device as the same that was recently unplugged in which case take the player slot that it used to have. Or something, with user preferences, and some UI to fix the association in the rare case when the heuristics choose wrong. Recognizing a gamepad could be done via physical identification, if one is available, or by usb port/hub, or whatever platform specific way. The clients would not have to care, they would only work with unique player IDs, which are integers created in sequence starting from 1 (or 0). first - I agree with player ID being assigned to a gamepad for the simple reason of giving all clients a baseline. I think that phys information should be exposed in some way. use-case here is a specific controller that is always owned by the same human player. the game could then associate this automatically with the player. this could be a later addition to the protocol though, because right now I have no idea how to do this sensibly. Wouldn't that be better configured in the server, rather than in every game? But yeah, I don't even have any idea what should be exposed as physical info. Using integers starting from 1 makes it trivial for the server to update the player ID display on the gamepads, if they have one. The server could also implement a global UI to reassing gamepads. For instance, press the famous home button for 5 secs on any gamepad, get some gamepad controllable GUI to reassing them, or maybe just a request to press the home button again on each gamepad in sequence. this UI could also handle the seat assignment, see below. Doing all this client side would mean we need to find a way to communicate all the device and platform specific hints for the gamepad assignment heuristics somehow, and each client instance would have its own gamepad assignments. is the player ID not better represented through a wl_seat? - if you're playing a full-screen game, both seats can safely have the same focus, otherwise, players can play games independently. plus, if both players have a separate seat, they can use their keyboard independently for data entry. Those were exactly my thoughts in the beginning, however during the way long email thread, I got convinced otherwise for now. There are a few issues that come mind: - how to know, when one seat should follow the keyboard(?) focus of another seat? I wonder when this is necessary. unless I'm misunderstanding something this should only be of concern when both users want to change games (or otherwise between clients)? I would imagine, that two players each with own gamepads is a more common case when playing the same game on split-screen or alike, than playing two different games. Therefore, when the game is started, the display server would ideally somehow know to assing both gamepad foci to the game window. The basic assumption with seats is that each is independent, but the server is of course free to assign foci as it chooses. This is just a server implementation detail. But I guess it does not really matter how it is on the protocol level, there would need to be a focus group configuration in the server anyway; either by protocol allowing several gamepad in one
Re: [PATCH weston v4 1/4] shell: Use relative layers for lock/unlock
On Sun, 12 May 2013 11:09:32 +0200
Quentin Glidic sardemff7+wayl...@sardemff7.net wrote:
From: Quentin Glidic sardemff7+...@sardemff7.net
The commit message here should state why this change is needed, and
what it does on a high level. I can guess, but I'd like it written out
also for posterity.
Thanks,
pq
Signed-off-by: Quentin Glidic sardemff7+...@sardemff7.net
---
src/shell.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/src/shell.c b/src/shell.c
index 135eaa5..456e911 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -2501,19 +2501,16 @@ resume_desktop(struct desktop_shell *shell)
terminate_screensaver(shell);
- wl_list_remove(shell-lock_layer.link);
- wl_list_insert(shell-compositor-cursor_layer.link,
+ wl_list_insert(shell-lock_layer.link,
shell-fullscreen_layer.link);
+ wl_list_remove(shell-lock_layer.link);
wl_list_insert(shell-fullscreen_layer.link,
shell-panel_layer.link);
- if (shell-showing_input_panels) {
+ wl_list_insert(shell-panel_layer.link,
+ws-layer.link);
+ if (shell-showing_input_panels)
wl_list_insert(shell-panel_layer.link,
shell-input_panel_layer.link);
- wl_list_insert(shell-input_panel_layer.link,
-ws-layer.link);
- } else {
- wl_list_insert(shell-panel_layer.link, ws-layer.link);
- }
restore_focus_state(shell, get_current_workspace(shell));
@@ -2983,12 +2980,12 @@ lock(struct desktop_shell *shell)
* input events while we are locked. */
wl_list_remove(shell-panel_layer.link);
- wl_list_remove(shell-fullscreen_layer.link);
if (shell-showing_input_panels)
wl_list_remove(shell-input_panel_layer.link);
wl_list_remove(ws-layer.link);
- wl_list_insert(shell-compositor-cursor_layer.link,
+ wl_list_insert(shell-fullscreen_layer.link,
shell-lock_layer.link);
+ wl_list_remove(shell-fullscreen_layer.link);
launch_screensaver(shell);
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/2] protocol: Allow versioned message arguments
On ons, 2013-05-08 at 15:40 -0500, Jason Ekstrand wrote: In short, I think this is far too complex for what it achieves. In the case of scaling factor stuff, you can just do it with a second event. I agree that what I posted have some open issues, and it was mostly meant as a start of a discussion of how to handle this. But I completely disagree with this. Adding a second event is totally a bad thing. I'll try to explain my reasoning in this case, but also consider that over time this will happen in other events too, so the complexity will accumulate over time. So, wl_output. This API is meant to be used to find out the initial monitor geometry and later dynamic updates of it. One of the primary consumers of this will be GdkScreen/GdkMonitor which is the Gtk+ api that gives this information. We never want Gtk+ to report some partial state to the application, so a multi-event geometry notification means that Gtk+ would have to have some code like: // just got a geometry event if (wl_output.version = 2) update GdkMonitor based on event screeen.emit(changed); else // Can't update the data or notify until we have all parts screen.saved_geometry_event_data = event; screen.waiting_for_geometry_scaling_factor = 1; There are multiple issues here: * The code becomes much more complex (imagine a third event added later) * Message ordering suddenly becomes important * The client depends on a complex behaviour of the server (send the 2nd event if wl_output.version 2) which some compositors may not implement (due to a bug or mistake) which leads to client livelocks. Or maybe I misunderstood you? Did you mean that the new event would be a copy of the first event with the extra field added? So, there would be geometry geometry2. That would be a lot easier on the client side, all you have to do is listen to both and fill in a default value for the new fields in the handler for the old one. There are still some minor issues in this apprach though: * You need to send both messages over the wire. (Technically there is some version negotiation when you bind the wl_output, but I don't think it seems right that incrementing the output version breaks old code that used the old geometry event.) * The two events are separate things that we force the compositor to handle in the right way, introducing uncertainty in behaviour. With my patch an old server with a new client will automatically work, and a compositor building against a newer server library will fail to build until its fixed to pass the new event members. Without this you may get compositors that build against the new server version but still don't emit the new signals. Now, that doesn't mean we have to implement versioned events the way my patch does. Its important that we get event versioning right though, because this is gonna show up more in the future. I think the basic properties we want from this are: * It should be easy to update compositors to the new event, just switch to the new marshaller call with no need to manually handle back compat. * Old clients should keep working on the new server even though the server just calls the new event version marshaller. * New clients should be able to listen to *either* the new event version or the old version (i.e. allow being lazy on version update), without having to somehow care about which version the server is. This can be implemented several ways though, and I agree that the way the patch did it is very rough on non-C languages. Another approach is to add a new event that extends the old one. I.e. like the copy the event and extend it approach above, but with support from the wayland machinery itself. That way the client can demarshal old events as the new one, and the dispatching of the new events can be done for all the versions of the event. This way we can avoid servers and clients having to manually support backwards compatibility. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/2] protocol: Add buffer_scale to wl_surface and wl_output
On ons, 2013-05-08 at 12:07 -0700, Bill Spitzak wrote: Output scaling should be merged with the existing buffer_transform (the 8-value enumeration describing 90 degree rotations/reflections). In effect they are parts of the same thing, yeah. I don't know if ABI compat allows us to just change buffer_transform though. I think in the end Wayland is going to have to have arbitrary affine transforms in the api, and it might make sense to decide a standard for these now, so that they are not split up amoung several apis like what is happening now. Apparently there is worry about using floating point in the api, but I think the following proposal that only uses integers or fixed point works: Translation are given as 2 24.8 fixed-point numbers. Scale is 4 unsigned numbers: w,h,W,H. You can think of these as the size of the source and destination, or w/W and h/H are the scaling factors. Rotation and skew are 4 integers: x0,y0,x1,y1. The X and Y axis are rotated to point at these positions. To avoid skew use x1==-y0 and y1==x0. Flipping the signs can be used to make reflections. This setup allows some useful numbers with somewhat intuitive results, and avoids trying to specify irrational numbers using integers. I'm not sure this generality is useful for this? When would you ever store the pixel data for your window pre-skewed? I mean, I don't think in practice its ever gonna useful to have windows displayed rotated and skewed on the screen, but I can see the conceptual nicety in allowing this (i.e. wobbly windows with input working). But I don't *ever* think an app is gonna supply the surface data for the window in such a way. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 0/2] Support for high DPI outputs via scaling
On ons, 2013-05-08 at 14:51 -0500, Jason Ekstrand wrote: Is there a way to bypass the scaling? When I'm using the mouse in a game, I want to know the pixel position of the pointer, with no scaling applied. I'm going to be drawing the gui at native res, and I want the mouse to interact with it at native res. I think that's supposed to be solved by wl_pointer giving sub-pixel accuracy. Yeah, input will have (already has) sub-pixel accuracy, so you need only handle that. I don't know that I'm opposed to some sort of scaling factor on principle. Android has pixels (px) vs. display pixels (dp) and that seems to work fairly well. I guess I'm still a little confused as to exactly what roles the compositor and the toolkit play and what the scaling factor means. Is the compositor's part simply to scale the surface for the lower/higher res monitor? On a wl_output, a scaling factor of means that the mapping from surface coordinates/size to the output framebuffer scales the content of a normal surface by 2. Its very similar to the existing transform method with can say that when outputting a buffer its content will be rotated 90 degrees. Similarly, scaling factor on a surface is very much like the existing buffer_transform on the window. It says that this window is already pre-scaled (vs. pre-rotated) by the amount specified. If the surface scaling and rotation matches what the output has then we don't need to apply the scaling/rotation. It also means that the client can supply subpixel precision which would not be available if the server had to do the upscale. If the surface doesn't have the right scaling factor, then the compositor needs to scale the surface up or down while rendering it to the output. Also, what happens if you have three monitors with factors 1, 2, and 3? Can you render at 2 or 3? I guess I'm concerned that we're going to lock ourselves into a system where monitor sizes have to come in powers of 2 or we won't be able to make sense of them. Then again, there may be no better solution. I'm not sure what you think is a problem with having these factors? Its not any different from the current state with 3 monitors at 3 different rotations. The client supplies *one* buffer for the surface, and it picks the scaling factor for it. The compositor then has to scale it the right amount when rendering it on any particular monitor. Generally the app will track which output the window is mostly on and use that to determine what resolution to pick for the buffer, but it must always handle that a window can overlap multiple outputs, so the compositor needs to be able to render it at multiple sizes. There is some ambiguity in the case of mirrored outputs at different scales. What resolution should the client pick then? If we pick the larger one it will look better on the higher resolution one, and if we pick the smaller it will look better on the lower resolution one. Both are valid choices, depending on how you are using the displays, so this should imho be up to the user. In order to allow the compositor to tell the client of the user choice I added the output priority field to the geometry. For reference, this has already been discussed at some length on the list. The first post to the effect is here: http://lists.freedesktop.org/archives/wayland-devel/2013-March/007941.html When I first showed my HiDPI work to kristian he said that we could also allow a client to supply per-output buffers for the surface so that a window overlapping two monitor of different scale could look good in both. There is certainly nothing wrong about that, and we could allow it. However, I think it is severe overkill. Very few windows span monitors, and I don't think any toolkits will take advantage of this (in fact, it would be hard to make this work reliably in Gtk+ due to how the widget APIs work). Making the client pick a single format seems good enough in practice. Also, we need to figure out how this interacts with the proposed scaling extension. Information can be found here: http://lists.freedesktop.org/archives/wayland-devel/2013-April/008927.html I don't think it needs much extension. It works as is, although the docs refering to wl_surface.set_buffer_transform also needs to mention the scaling factor. Of course, there is also the question of if we could use the wl_surface_scaler interface to do the HiDPI scaling. And, while this would be technically possible it seems the wrong approach to me. The surface scaler API is much more demanding of the compositor with non-integer scaling factors, cropping and aspect ratio changing. I don't think we want to force compositors to always support all of that in order to work on HiDPI displays where a much simpler subset is needed. Also, its a much more complex API to use for something so basic that every window will use it. Basically, wl_surface_scaler is for scaling of
Re: [PATCH 1/2] protocol: Allow versioned message arguments
On Mon, 13 May 2013 10:23:44 +0200 Alexander Larsson al...@redhat.com wrote: On ons, 2013-05-08 at 15:40 -0500, Jason Ekstrand wrote: In short, I think this is far too complex for what it achieves. In the case of scaling factor stuff, you can just do it with a second event. I agree that what I posted have some open issues, and it was mostly meant as a start of a discussion of how to handle this. But I completely disagree with this. Adding a second event is totally a bad thing. I'll try to explain my reasoning in this case, but also consider that over time this will happen in other events too, so the complexity will accumulate over time. So, wl_output. This API is meant to be used to find out the initial monitor geometry and later dynamic updates of it. One of the primary consumers of this will be GdkScreen/GdkMonitor which is the Gtk+ api that gives this information. We never want Gtk+ to report some partial state to the application, so a multi-event geometry notification means that Gtk+ would have to have some code like: // just got a geometry event if (wl_output.version = 2) update GdkMonitor based on event screeen.emit(changed); else // Can't update the data or notify until we have all parts screen.saved_geometry_event_data = event; screen.waiting_for_geometry_scaling_factor = 1; This is the way to do it. As another way, rather than expecting a specific event and pending on that indefinitely, you could issue a roundtrip; when it returns, you are guaranteed to have received all the additional events related to this event. OTOH, roundtripping is not nice to use like this. There is a slightly racy way to achieve the same, though: wait for idle. You wait for idle in any case before re-drawing the GUI, right? In any case, a compositor can be assumed to send all related events in a burst, without interleaving other events. We can even specify the order in the protocol. We already do that for other things. There are multiple issues here: * The code becomes much more complex (imagine a third event added later) Versioning arguments of events and requests is even more complex and fragile, and introduces automatic papering over problems with default values. * Message ordering suddenly becomes important Message ordering *is* important in general. * The client depends on a complex behaviour of the server (send the 2nd event if wl_output.version 2) which some compositors may not implement (due to a bug or mistake) which leads to client livelocks. This is the standard way to implement augmented protocol. If some compositors don't do it right, they are buggy and need to be fixed. Automatically and silently papering over the problem would make things only harder to debug. You negotiate the version of an interface at bind time for a reason, by taking min(server_version, client_version). Or maybe I misunderstood you? Did you mean that the new event would be a copy of the first event with the extra field added? So, there would be geometry geometry2. That would be a lot easier on the client side, all you have to do is listen to both and fill in a default value for the new fields in the handler for the old one. There are still some minor issues in this apprach though: * You need to send both messages over the wire. (Technically there is some version negotiation when you bind the wl_output, but I don't think it seems right that incrementing the output version breaks old code that used the old geometry event.) It does not break. That's why the version used by both sides is negotiated. Servers need to honour the negotiated version number regardless. And, there is no need to send both events, if a new event is designed to replace an old one. Just send the event corresponding to the negotiated version number. * The two events are separate things that we force the compositor to handle in the right way, introducing uncertainty in behaviour. With my Umm, what uncertainty? patch an old server with a new client will automatically work, and a compositor building against a newer server library will fail to build until its fixed to pass the new event members. Without this you may get compositors that build against the new server version but still don't emit the new signals. How is it a problem, if a server builds or links against a newer libwayland-server than it was written for? It is supposed to be the server deciding the maximum interface version that it is going to support, not libwayland-server. Again, taking the min() of the two. For events, it works fine. For requests, I'm not too sure whether a buggy client could cause a server crash by sending a request from a later interface version than it negotiated. We need a unit test for that. Also, with your proposal, what happens if a server is built with an old libwayland-server, but at runtime links to a new libwayland-server? Now, that doesn't mean we have to
Re: [PATCH 0/2] Support for high DPI outputs via scaling
On ons, 2013-05-08 at 22:58 +0200, John Kåre Alsaker wrote: I think we should allow fractional scale factors. Clients which only support integer scale factors should round the scale factor they get to a whole number. I don't see how this is useful? The scaling has two main benefits: 1) It defines a common global coordinate system in which to specify global things like window sizes, mouse speed, pointer size, relative monitor positions, etc. For these it doesn't necessarily matter that the DPI of these match exactly, only that they are of the same magnitude. I personally have a desktop setup with two different monitors of different DPI, which works fine. However, I also have a chromebook pixel with 239 dpi, and using the same settings for these things *definately* is a problem on that. 2) It allows reusing all existing code and assets that specify things in pixels. The fact that the theme specifying a one-pixel border on buttons end up with a 3% wider line on some displays is not really a problem. However, on the pixel it is again a real problem. Surface scaling lets us fix this without modifying and duplicating all widget code, themes, svgs, etc. A fractional scale factor is always going to cause visually poor experience due to nr 2. I.e. themes will use an integer multiple wide lines and padding in order to look good on current resolution screens, which will always end up looking blurry if you then scale by a fraction. In fact, if the scaling factor is e.g. 1.5, there is no way for a theme to get crisp button borders. It could specify a line of width 0.6667 and hope it gets rounded to exactly 1 on the output, but if some padding above it made it accidentally end up on an uneven row it would become blurred between two rows on the screen. It also causes issues because buffers are by necessity of integer sizes, and an integer buffer size times a fractional scale will cause the surface to have a fractional size in the global coordinate space. How would you handle this if the window overlaps an output with a different scaling factor? You'll end up with either a cut off window not showing the last row or a blurred partial pixel rendered with AA. How would you maximize a window when the interger output size results in a fractional buffer size for the window? I don't think we need a scale priority on wl_outputs, clients should pick the highest scale factor of the outputs it's on. I don't agree. This is a policy decision, as it will always result in the best looking output on the highest dpi monitor. The lower one would get a downscale of the hires rendering, which will look worse than e.g. a properly hinted text rendered for the lower resolution, and I can easily imagine situations where you want the output to look sharpest on the lower resolution monitor, like when you're using a projector. What to pick in this case should be up to the user and/or compositor/desktop-environment, so we should allow the compositor to tell clients what to do in this case. This is what e.g. OSX does (i.e. you get a popup that asks if you want best looking result on the monitor or on the laptop display). ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 0/2] Support for high DPI outputs via scaling
On Mon, 13 May 2013 11:16:07 +0200 Alexander Larsson al...@redhat.com wrote: On ons, 2013-05-08 at 14:51 -0500, Jason Ekstrand wrote: Also, we need to figure out how this interacts with the proposed scaling extension. Information can be found here: http://lists.freedesktop.org/archives/wayland-devel/2013-April/008927.html I don't think it needs much extension. It works as is, although the docs refering to wl_surface.set_buffer_transform also needs to mention the scaling factor. Of course, there is also the question of if we could use the wl_surface_scaler interface to do the HiDPI scaling. And, while this would be technically possible it seems the wrong approach to me. The surface scaler API is much more demanding of the compositor with non-integer scaling factors, cropping and aspect ratio changing. I don't think we want to force compositors to always support all of that in order to work on HiDPI displays where a much simpler subset is needed. Also, its a much more complex API to use for something so basic that every window will use it. Basically, wl_surface_scaler is for scaling of subsurfaces with video, and I don't think we should mix the two up. I agree with your reasoning here. I haven't read this whole thread in detail, because it seems to contain so much marketing speak and complicated explanations of things that should be straightforward. So, am I getting the following right? You basically want a default scaling factor for all surfaces, per output. And, you want a way for clients to opt-out from that default scaling. Is it really that simple? I'm asking because I didn't see it put that clearly anywhere, but maybe it got lost in between all the 3DTV discussion and coordinate transforms. If that is the basic problem statement, then we can start looking at the protocol and coordinate system details. Now that I'm re-reading your protocol patch, it's starting to make sense conceptually. Thanks, pq ___ 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 11:56 AM, Alexander Larsson al...@redhat.comwrote: On ons, 2013-05-08 at 22:58 +0200, John Kåre Alsaker wrote: I think we should allow fractional scale factors. Clients which only support integer scale factors should round the scale factor they get to a whole number. I don't see how this is useful? The scaling has two main benefits: 1) It defines a common global coordinate system in which to specify global things like window sizes, mouse speed, pointer size, relative monitor positions, etc. For these it doesn't necessarily matter that the DPI of these match exactly, only that they are of the same magnitude. I personally have a desktop setup with two different monitors of different DPI, which works fine. However, I also have a chromebook pixel with 239 dpi, and using the same settings for these things *definately* is a problem on that. The scaling factor should not have any affect of any coordinate system or anything else in the protocol. It should only affect the size in pixels of the surfaces of the clients. Clients should do any transformations of coordinates they want themselves. 2) It allows reusing all existing code and assets that specify things in pixels. The fact that the theme specifying a one-pixel border on buttons end up with a 3% wider line on some displays is not really a problem. However, on the pixel it is again a real problem. Surface scaling lets us fix this without modifying and duplicating all widget code, themes, svgs, etc. A fractional scale factor is always going to cause visually poor experience due to nr 2. I.e. themes will use an integer multiple wide lines and padding in order to look good on current resolution screens, which will always end up looking blurry if you then scale by a fraction. In fact, if the scaling factor is e.g. 1.5, there is no way for a theme to get crisp button borders. It could specify a line of width 0.6667 and hope it gets rounded to exactly 1 on the output, but if some padding above it made it accidentally end up on an uneven row it would become blurred between two rows on the screen. It also causes issues because buffers are by necessity of integer sizes, and an integer buffer size times a fractional scale will cause the surface to have a fractional size in the global coordinate space. How would you handle this if the window overlaps an output with a different scaling factor? You'll end up with either a cut off window not showing the last row or a blurred partial pixel rendered with AA. How would you maximize a window when the interger output size results in a fractional buffer size for the window? Clients can easily scale larger features like icons, padding and fonts and round them to pixel sizes and draw sharp output even with a fractional scaling factor. This allows users to pick a size suitable for them. The difference between a 1 and 2 scaling factor is too huge. I don't think we need a scale priority on wl_outputs, clients should pick the highest scale factor of the outputs it's on. I don't agree. This is a policy decision, as it will always result in the best looking output on the highest dpi monitor. The lower one would get a downscale of the hires rendering, which will look worse than e.g. a properly hinted text rendered for the lower resolution, and I can easily imagine situations where you want the output to look sharpest on the lower resolution monitor, like when you're using a projector. What to pick in this case should be up to the user and/or compositor/desktop-environment, so we should allow the compositor to tell clients what to do in this case. This is what e.g. OSX does (i.e. you get a popup that asks if you want best looking result on the monitor or on the laptop display). I think the case when a window is displayed on multiple monitors is pretty rare or short in duration (the dragging across monitor case when not using a workspace per monitor). I suppose we could leave this up to the compositor. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/2] protocol: Allow versioned message arguments
On mån, 2013-05-13 at 12:19 +0300, Pekka Paalanen wrote: On Mon, 13 May 2013 10:23:44 +0200 Alexander Larsson al...@redhat.com wrote: On ons, 2013-05-08 at 15:40 -0500, Jason Ekstrand wrote: In short, I think this is far too complex for what it achieves. In the case of scaling factor stuff, you can just do it with a second event. I agree that what I posted have some open issues, and it was mostly meant as a start of a discussion of how to handle this. But I completely disagree with this. Adding a second event is totally a bad thing. I'll try to explain my reasoning in this case, but also consider that over time this will happen in other events too, so the complexity will accumulate over time. So, wl_output. This API is meant to be used to find out the initial monitor geometry and later dynamic updates of it. One of the primary consumers of this will be GdkScreen/GdkMonitor which is the Gtk+ api that gives this information. We never want Gtk+ to report some partial state to the application, so a multi-event geometry notification means that Gtk+ would have to have some code like: // just got a geometry event if (wl_output.version = 2) update GdkMonitor based on event screeen.emit(changed); else // Can't update the data or notify until we have all parts screen.saved_geometry_event_data = event; screen.waiting_for_geometry_scaling_factor = 1; This is the way to do it. As another way, rather than expecting a specific event and pending on that indefinitely, you could issue a roundtrip; when it returns, you are guaranteed to have received all the additional events related to this event. OTOH, roundtripping is not nice to use like this. I don't think this is particularly nice, its just pushing complexity unnecessarily on everyone else. It means over time there will be more and more cruft accumulating in the wayland apis that applications need to handle in complex ways like this. Its fine for a single one, but imagine how it will look in 10 years, when every client needs to have a spaghetti nest of version checks with different behaviour depending on the server version. Its much nicer if the protocol implementation itself can handle this (as far as possible). There is a slightly racy way to achieve the same, though: wait for idle. You wait for idle in any case before re-drawing the GUI, right? I don't see how this would reliably work. If we get an event and handle it, we're idle immediately. So it will constantly race with the second event showing up in the pipe. In any case, a compositor can be assumed to send all related events in a burst, without interleaving other events. We can even specify the order in the protocol. We already do that for other things. Relying on the burstiness is racy, so we need to define an exact order and version behaviour, and every client and server need to open code these exactly right or we'll get problems. This is certainly doable and it makes things a lot easier for me to do this patch (although it makes me cry as a gtk backend developer). I guess in this particular case we can define that a new scale for a wl_output must be sent before the matching geometry event. That way it's easier for clients to handle. Just keep any scale events until you get the next geometry event and then apply it with that data. * The client depends on a complex behaviour of the server (send the 2nd event if wl_output.version 2) which some compositors may not implement (due to a bug or mistake) which leads to client livelocks. This is the standard way to implement augmented protocol. If some compositors don't do it right, they are buggy and need to be fixed. Automatically and silently papering over the problem would make things only harder to debug. Its certainly always what happens on *some* level. But it need not be how it is visible to client applications. I guess its something of a design decision of how high-level the wayland client library wants to be. Does it match the bits in the wire protocol, or is it a slightly higher level. Or maybe I misunderstood you? Did you mean that the new event would be a copy of the first event with the extra field added? So, there would be geometry geometry2. That would be a lot easier on the client side, all you have to do is listen to both and fill in a default value for the new fields in the handler for the old one. There are still some minor issues in this apprach though: * You need to send both messages over the wire. (Technically there is some version negotiation when you bind the wl_output, but I don't think it seems right that incrementing the output version breaks old code that used the old geometry event.) It does not break. That's why the version used by both sides is negotiated. Servers need to honour the negotiated version number regardless. I think its nice that negotiating version lets us
Re: [PATCH 0/2] Support for high DPI outputs via scaling
On mån, 2013-05-13 at 13:12 +0300, Pekka Paalanen wrote: On Mon, 13 May 2013 11:16:07 +0200 Alexander Larsson al...@redhat.com wrote: On ons, 2013-05-08 at 14:51 -0500, Jason Ekstrand wrote: Also, we need to figure out how this interacts with the proposed scaling extension. Information can be found here: http://lists.freedesktop.org/archives/wayland-devel/2013-April/008927.html I don't think it needs much extension. It works as is, although the docs refering to wl_surface.set_buffer_transform also needs to mention the scaling factor. Of course, there is also the question of if we could use the wl_surface_scaler interface to do the HiDPI scaling. And, while this would be technically possible it seems the wrong approach to me. The surface scaler API is much more demanding of the compositor with non-integer scaling factors, cropping and aspect ratio changing. I don't think we want to force compositors to always support all of that in order to work on HiDPI displays where a much simpler subset is needed. Also, its a much more complex API to use for something so basic that every window will use it. Basically, wl_surface_scaler is for scaling of subsurfaces with video, and I don't think we should mix the two up. I agree with your reasoning here. I haven't read this whole thread in detail, because it seems to contain so much marketing speak and complicated explanations of things that should be straightforward. So, am I getting the following right? You basically want a default scaling factor for all surfaces, per output. And, you want a way for clients to opt-out from that default scaling. No, that doesn't seem quite right, although maybe I misunderstood it. Lemme try to define it similarly. Each output has a scaling factor set, and all surfaces on that output is scaled by it. However, clients can supply pre-scaled buffers, which co-incidentally allows sub-pixel accuracy in the scaling by just rendering at a higher resolution. Basically, compare it to the current wl_surface.set_buffer_transform(). Its essentially that, but the transform extended with scale-by-integer in addition to the rotations. Is it really that simple? I'm asking because I didn't see it put that clearly anywhere, but maybe it got lost in between all the 3DTV discussion and coordinate transforms. Sure, its pretty simple in the end. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/2] protocol: Allow versioned message arguments
For the wl_output case I suggest we add a 'done' event which signals that the compositor is done sending a batch of events for an wl_output and related extension objects (which versioned message arguments won't handle). This would be analogous to wl_surface.commit, only coming from the server side. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 0/2] Support for high DPI outputs via scaling
On mån, 2013-05-13 at 12:40 +0200, John Kåre Alsaker wrote: The scaling factor should not have any affect of any coordinate system or anything else in the protocol. It should only affect the size in pixels of the surfaces of the clients. Clients should do any transformations of coordinates they want themselves. I'm not sure if we agree or not here. But, lemme have an example. If you have a setup with two monitors using mirrored mode, one with scale == 2. Then I want both monitors to show the same thing, one with more detail. If I then put the mouse cursor over the bottom right corner of the surface i want to get one mouse event, and the coordinates of it should be the size of the window in the unscaled coordinates, i.e. the width/height of the window in the lower resolution. Is this what you meant? Clients can easily scale larger features like icons, padding and fonts and round them to pixel sizes and draw sharp output even with a fractional scaling factor. This allows users to pick a size suitable for them. The difference between a 1 and 2 scaling factor is too huge. Some things can be easily scaled. Like text and photorealistic images. Other things can't necessarily be scaled and still look nice. Like line art or solid line borders (like e.g. the boxes around a button). Sure, you can round everything to nearest int, but that will cause unevenness in the rounding (buttons sometimes get a 1 pixel border, sometimes 2 depending on the fractional part of the button coords, etc). So, I don't think this is every useful in practice. I think the case when a window is displayed on multiple monitors is pretty rare or short in duration (the dragging across monitor case when not using a workspace per monitor). I suppose we could leave this up to the compositor. Totally, i don't mean that the priority is useful for that case. Normally clients should just pick the scale based on which output the surface has the most pixels in. However, the one case where that breaks is mirrored/clone mode, where two monitors show the same thing. This is where the priority can be useful. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/2] protocol: Allow versioned message arguments
On mån, 2013-05-13 at 13:26 +0200, John Kåre Alsaker wrote: For the wl_output case I suggest we add a 'done' event which signals that the compositor is done sending a batch of events for an wl_output and related extension objects (which versioned message arguments won't handle). This would be analogous to wl_surface.commit, only coming from the server side. As i said in another mail, an even easier approach is to use the gemetry event itself as the done event, and just send the additions (if any) *before* the geometry event. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/2] protocol: Allow versioned message arguments
On Mon, May 13, 2013 at 1:28 PM, Alexander Larsson al...@redhat.com wrote: On mån, 2013-05-13 at 13:26 +0200, John Kåre Alsaker wrote: For the wl_output case I suggest we add a 'done' event which signals that the compositor is done sending a batch of events for an wl_output and related extension objects (which versioned message arguments won't handle). This would be analogous to wl_surface.commit, only coming from the server side. As i said in another mail, an even easier approach is to use the gemetry event itself as the done event, and just send the additions (if any) *before* the geometry event. That would also work, but is uglier. The geometry event is rather large too. Since currently events can happen at any time, adding a done event won't break backwards compatibility. ___ 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, 13 May 2013 13:14:29 +0200 Alexander Larsson al...@redhat.com wrote: On mån, 2013-05-13 at 13:12 +0300, Pekka Paalanen wrote: On Mon, 13 May 2013 11:16:07 +0200 Alexander Larsson al...@redhat.com wrote: On ons, 2013-05-08 at 14:51 -0500, Jason Ekstrand wrote: Also, we need to figure out how this interacts with the proposed scaling extension. Information can be found here: http://lists.freedesktop.org/archives/wayland-devel/2013-April/008927.html I don't think it needs much extension. It works as is, although the docs refering to wl_surface.set_buffer_transform also needs to mention the scaling factor. Of course, there is also the question of if we could use the wl_surface_scaler interface to do the HiDPI scaling. And, while this would be technically possible it seems the wrong approach to me. The surface scaler API is much more demanding of the compositor with non-integer scaling factors, cropping and aspect ratio changing. I don't think we want to force compositors to always support all of that in order to work on HiDPI displays where a much simpler subset is needed. Also, its a much more complex API to use for something so basic that every window will use it. Basically, wl_surface_scaler is for scaling of subsurfaces with video, and I don't think we should mix the two up. I agree with your reasoning here. I haven't read this whole thread in detail, because it seems to contain so much marketing speak and complicated explanations of things that should be straightforward. So, am I getting the following right? You basically want a default scaling factor for all surfaces, per output. And, you want a way for clients to opt-out from that default scaling. No, that doesn't seem quite right, although maybe I misunderstood it. Lemme try to define it similarly. Each output has a scaling factor set, and all surfaces on that output is scaled by it. However, clients can supply pre-scaled buffers, which co-incidentally allows sub-pixel accuracy in the scaling by just rendering at a higher resolution. Yup, that is exactly it, you just added some details on how to implement the idea with protocol. Henceforth, if a compositor implements this feature, unmodified old clients will show up scaled automatically and just work. Clients that know this feature may choose to take advantage of the available higher resolution. Sounds cool. Basically, compare it to the current wl_surface.set_buffer_transform(). Its essentially that, but the transform extended with scale-by-integer in addition to the rotations. Is it really that simple? I'm asking because I didn't see it put that clearly anywhere, but maybe it got lost in between all the 3DTV discussion and coordinate transforms. Sure, its pretty simple in the end. I'll wait for the protocol interface versioning issues to be solved, and assume you will then send a revised version. It will be easier for me to get on board then, unless I'm again caught in a busy project. Cheers, pq ___ 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
Mon, May 13, 2013 at 1:26 PM, Alexander Larsson al...@redhat.com wrote: On mån, 2013-05-13 at 12:40 +0200, John Kåre Alsaker wrote: The scaling factor should not have any affect of any coordinate system or anything else in the protocol. It should only affect the size in pixels of the surfaces of the clients. Clients should do any transformations of coordinates they want themselves. I'm not sure if we agree or not here. But, lemme have an example. If you have a setup with two monitors using mirrored mode, one with scale == 2. Then I want both monitors to show the same thing, one with more detail. If I then put the mouse cursor over the bottom right corner of the surface i want to get one mouse event, and the coordinates of it should be the size of the window in the unscaled coordinates, i.e. the width/height of the window in the lower resolution. The client should get the width and height of the surface in pixels. If the compositor doesn't display pixels in a 1:1 ratio on the monitor, it should translate events into pixels in surface coordinates before sending them to a client. The scaling factor should have no effect on anything (from a protocol perspective) other than which pixel sizes the client picks. Is this what you meant? Clients can easily scale larger features like icons, padding and fonts and round them to pixel sizes and draw sharp output even with a fractional scaling factor. This allows users to pick a size suitable for them. The difference between a 1 and 2 scaling factor is too huge. Some things can be easily scaled. Like text and photorealistic images. Other things can't necessarily be scaled and still look nice. Like line art or solid line borders (like e.g. the boxes around a button). Sure, you can round everything to nearest int, but that will cause unevenness in the rounding (buttons sometimes get a 1 pixel border, sometimes 2 depending on the fractional part of the button coords, etc). So, I don't think this is every useful in practice. Even if things aren't perfectly even, it will still be much better than the alternative which is round up to the next scaling factor and let the compositor scale the surface down to a suitable size again. This is what you have to do on Mac OS X to get a reasonable workspace on higher DPI displays. Windows gets 4 times bigger from scaling factor 1 to 2. That isn't near enough granular. I think the case when a window is displayed on multiple monitors is pretty rare or short in duration (the dragging across monitor case when not using a workspace per monitor). I suppose we could leave this up to the compositor. Totally, i don't mean that the priority is useful for that case. Normally clients should just pick the scale based on which output the surface has the most pixels in. However, the one case where that breaks is mirrored/clone mode, where two monitors show the same thing. This is where the priority can be useful. 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. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/2] protocol: Allow versioned message arguments
On mån, 2013-05-13 at 13:49 +0200, John Kåre Alsaker wrote: On Mon, May 13, 2013 at 1:28 PM, Alexander Larsson al...@redhat.com wrote: On mån, 2013-05-13 at 13:26 +0200, John Kåre Alsaker wrote: For the wl_output case I suggest we add a 'done' event which signals that the compositor is done sending a batch of events for an wl_output and related extension objects (which versioned message arguments won't handle). This would be analogous to wl_surface.commit, only coming from the server side. As i said in another mail, an even easier approach is to use the gemetry event itself as the done event, and just send the additions (if any) *before* the geometry event. That would also work, but is uglier. The geometry event is rather large too. Since currently events can happen at any time, adding a done event won't break backwards compatibility. No, but it means you have to special-case the versions that don't send a done event. And in practice the geometry is emitted seldom and the two probably almost always change at the same time, so i don't think you'll ever see just scale changed + done. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 0/2] Support for high DPI outputs via scaling
On mån, 2013-05-13 at 14:00 +0200, John Kåre Alsaker wrote: Clients can easily scale larger features like icons, padding and fonts and round them to pixel sizes and draw sharp output even with a fractional scaling factor. This allows users to pick a size suitable for them. The difference between a 1 and 2 scaling factor is too huge. Some things can be easily scaled. Like text and photorealistic images. Other things can't necessarily be scaled and still look nice. Like line art or solid line borders (like e.g. the boxes around a button). Sure, you can round everything to nearest int, but that will cause unevenness in the rounding (buttons sometimes get a 1 pixel border, sometimes 2 depending on the fractional part of the button coords, etc). So, I don't think this is every useful in practice. Even if things aren't perfectly even, it will still be much better than the alternative which is round up to the next scaling factor and let the compositor scale the surface down to a suitable size again. This is what you have to do on Mac OS X to get a reasonable workspace on higher DPI displays. Windows gets 4 times bigger from scaling factor 1 to 2. That isn't near enough granular. I don't think this will work in practice. I know for sure that e.g. Gtk is not set up to do any reasonable non-integer scaling. It will just scale up all drawing by a fractional factor without any rounding anywhere, causing everything to become fuzzy. We will eventually have alternative icons for higher resolutions, but these will be at 2x scale, not at generic fractional factor (that is not really doable without using pure-vector icons with some complex hinting method). Although, I guess that in the case of text the scaling will be ok, so for some usecases it might be OK. So, it's my opinion that supporting fractional scaling is an unnecessary burden on compositors for something that is not very useful in practice. Thats just my opinion though, and the proposal as such can handle fractional scaling fine by just changing the scale factors to fixed type. In mirrored/clone mode only a single wl_output would be presented to clients with a single scale factor, so priorities won't matter in that case. That is not necessarily so. We might very well want to know that there are two displays, with say different RGB subpixel order, etc. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 0/2] Support for high DPI outputs via scaling
On Mon, May 13, 2013 at 2:19 PM, Alexander Larsson al...@redhat.com wrote: On mån, 2013-05-13 at 14:00 +0200, John Kåre Alsaker wrote: Clients can easily scale larger features like icons, padding and fonts and round them to pixel sizes and draw sharp output even with a fractional scaling factor. This allows users to pick a size suitable for them. The difference between a 1 and 2 scaling factor is too huge. Some things can be easily scaled. Like text and photorealistic images. Other things can't necessarily be scaled and still look nice. Like line art or solid line borders (like e.g. the boxes around a button). Sure, you can round everything to nearest int, but that will cause unevenness in the rounding (buttons sometimes get a 1 pixel border, sometimes 2 depending on the fractional part of the button coords, etc). So, I don't think this is every useful in practice. Even if things aren't perfectly even, it will still be much better than the alternative which is round up to the next scaling factor and let the compositor scale the surface down to a suitable size again. This is what you have to do on Mac OS X to get a reasonable workspace on higher DPI displays. Windows gets 4 times bigger from scaling factor 1 to 2. That isn't near enough granular. I don't think this will work in practice. I know for sure that e.g. Gtk is not set up to do any reasonable non-integer scaling. It will just scale up all drawing by a fractional factor without any rounding anywhere, causing everything to become fuzzy. We will eventually have alternative icons for higher resolutions, but these will be at 2x scale, not at generic fractional factor (that is not really doable without using pure-vector icons with some complex hinting method). Although, I guess that in the case of text the scaling will be ok, so for some usecases it might be OK. It will work very well for things designed to be scalable, browsers are an example. GTK could just fall back to integer scaling. 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. 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. 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. ___ 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 Mon, May 13, 2013 at 2:33 AM, David Herrmann dh.herrm...@gmail.com wrote: That is why the kernel provides PHYS and UNIQ fields for every input device (they might be empty if not implemented, but at least they're supposed to be there..). PHYS provides the physical location for the device. UNIQ provides a unique identification. PHYS is potentially useful, but not reliable; there are often several USB ports near each other, and the player may not re-plug the device in the same one, especially if they are on the back of the machine. With wireless setups we can't be sure that PHYS will be identical between connections. Still, it's useful as a hint. UNIQ has been an empty string on every USB input device I've encountered. I need to get bluetooth set up (my PC has no bluetooth hardware, I need to buy a card or something), so i can't say whether wireless devices provide useful UNIQ values. Todd. -- Todd Showalter, President, Electron Jump Games, Inc. ___ 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
Hi, On 12 May 2013 16:54, Kristian Høgsberg k...@bitplanet.net wrote: I think we can change the interface to int open_config_file(const char *), which looks up and opens the config file and returns the fd. We can keep that in weston_compositor instead of the config_file path. The parse function can then fseek on the fd to reset to the beginning of the file. Going forward, we'll do something like this: Totally. I've actually got a patch which looks in $sysconfdir and $datadir as well, enabling global fallback config files to be shipped, which I guess should be combined with this. When I looked at that, my next step was going to be returning an fd, but then I remembered that fds have no fgets() equivalent and totally lost interest in open-coding that. But it would be a much better result, particularly as mine open()s the files to verify they're accessible anyway ... 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 mån, 2013-05-13 at 14:40 +0200, John Kåre Alsaker wrote: I don't think this will work in practice. I know for sure that e.g. Gtk is not set up to do any reasonable non-integer scaling. It will just scale up all drawing by a fractional factor without any rounding anywhere, causing everything to become fuzzy. We will eventually have alternative icons for higher resolutions, but these will be at 2x scale, not at generic fractional factor (that is not really doable without using pure-vector icons with some complex hinting method). Although, I guess that in the case of text the scaling will be ok, so for some usecases it might be OK. It will work very well for things designed to be scalable, browsers are an example. GTK could just fall back to integer scaling. Browsers are not really scalable like that, css page layout is generally based on the CSS Px definition, and per e.g. http://static.zealous-studios.co.uk/projects/web_tests/PPI%20tests.html: For lower-resolution devices [i.e. non-print], and devices with unusual viewing distances, it is recommended instead that the anchor unit be the pixel unit. For such devices it is recommended that the pixel unit refer to the whole number of device pixels that best approximates the reference pixel. I.e. whole number of pixels = scale by integer matches best what CSS wants. So, it's my opinion that supporting fractional scaling is an unnecessary burden on compositors for something that is not very useful in practice. Thats just my opinion though, and the proposal as such can handle fractional scaling fine by just changing the scale factors to fixed type. It is of no burden on compositors at all, only for clients which choose to implement it. It is, as long as clients are allowed to specify a fractional scaling factors compositors need to be able to handle scaling by that (for instance if the window appears partially on a non-highres monitor. In mirrored/clone mode only a single wl_output would be presented to clients with a single scale factor, so priorities won't matter in that case. That is not necessarily so. We might very well want to know that there are two displays, with say different RGB subpixel order, etc. The compositor could unify this information into a single wl_output. And what would it then report for physical width/height, subpixel, make, model, etc? Seems pretty weird. I suggest we send 3 scaling factors to clients. A lower bound where factors lower will be scaled up. The desired scaling factor. A upper bound where factors above will be scaled down. Clients should find the scaling factor in lower bound to upper bound they are able to render at which is closes to the desired factor. Failing that they should find the first factor they are able to render at above the upper bound. When displayed on multiple monitors it could try to remain sharp on as many monitors as possible. I don't quite understand this. Any factor lower than the desired factor has to be scaled up, no? Lets take a concrete example. The macbook pro 15 has a 2880 x 1800 native panel. This is normally driven as 1440 x 900 with a scale factor of 2. On OSX you can also select a 1920x1200 resolution, which is nominally a scale factor of 1.5. However, on OSX what they do is that apps render to a framebuffer at twice the resolution (3840x2400) and its then scaled it down to 2880x1800 to make it look reasonable. On such a setup in wayland the wl_output would be 1920x1200, with a scaling factor of 1.5. For a 800x601 window a hidpi applications could then either pick a buffer of 1600x1202 buffer and set a scaling factor of 2 causing the compositor to downscale it (similar to OSX above), or it could create a buffer at 1200x902 (nearest to the true 901.5) and and set scaling factor to 902/600 (i.e. 1.50333..) and have the compositor not scale it (which is a minor issue due to the 1.5 != 1.50333..). In this case the desired scaling factor would be 1.5. What do you expect the upper and lower bounds to be? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Gamepad focus model (Re: Input and games.)
Hi, On 13 May 2013 07:14, Pekka Paalanen ppaala...@gmail.com wrote: On Mon, 13 May 2013 09:12:03 +1000 Peter Hutterer peter.hutte...@who-t.net wrote: Those were exactly my thoughts in the beginning, however during the way long email thread, I got convinced otherwise for now. There are a few issues that come mind: - how to know, when one seat should follow the keyboard(?) focus of another seat? I wonder when this is necessary. unless I'm misunderstanding something this should only be of concern when both users want to change games (or otherwise between clients)? I would imagine, that two players each with own gamepads is a more common case when playing the same game on split-screen or alike, than playing two different games. Therefore, when the game is started, the display server would ideally somehow know to assing both gamepad foci to the game window. The basic assumption with seats is that each is independent, but the server is of course free to assign foci as it chooses. This is just a server implementation detail. But I guess it does not really matter how it is on the protocol level, there would need to be a focus group configuration in the server anyway; either by protocol allowing several gamepad in one wl_seat, or a purely server detail by focus groups containing wl_seats. I think this is not a protocol question as much as a server implementation consideration, so... *shrug*. 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? If the focus can be changed independently, how does this happen? If the keyboard/pointer seat switches focus to another game, do both seats switch, or does the other stay behind? If both switch - why are we complicating the focus model rather than just adding both to a seat? 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. Cheers, Daniel ___ 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 Sun, May 12, 2013 at 07:33:44PM -0700, Othman, Ossama wrote:
Hi Kristian,
On Sun, May 12, 2013 at 8:54 AM, Kristian Høgsberg k...@bitplanet.netwrote:
I think we can change the interface to int open_config_file(const char
*), which looks up and opens the config file and returns the fd. We
can keep that in weston_compositor instead of the config_file path.
The parse function can then fseek on the fd to reset to the beginning
of the file. Going forward, we'll do something like this:
http://lists.freedesktop.org/archives/wayland-devel/2013-April/008333.html
Nice set of changes!
and store the weston_config object in weston_compositor object. The
config path patch here is somewhat orthogonal to that though.
On Sun, May 12, 2013 at 2:20 AM, Othman, Ossama ossama.oth...@intel.com
wrote:
...
+ info.count = 0;
+ info.paths = malloc(DEFAULT_DIR_COUNT * sizeof(char *));
+ if (info.paths == NULL)
+ return NULL;
I don't think this function should need any mallocs at all.
Agreed. I was a bit too loose with the malloc()s. :)
It's not out of concern of performance or memory pressure, it's that
every malloc is a potential error path and something you have to
remember to free. And in this case, the code becomes simpler so it's
a win-win.
Basically
we should be able to say something like
char path[PATHMAX];
snprintf(path, size, %s%s%s, home_dir, dotconf, name);
fd = open(path);
if (fd = 0)
return fd;
/* same for XDG_CONFIG_DIR */
as for XDG_CONFIG_PATHS, I'd just scan through the string manually
with strchrnul instead of bothering with copying and strtok_r:
for (p = config_dirs, *p; p = next) {
next = strchrnul(p, ':');
snprintf(path, size, %s/weston/%s, p next - p, name);
'sizeof path' here, not just 'size' btw.
fd = open(path);
That is indeed much better. Since your new parser is pending would you
like me to hold off submitting a reworked patch that incorporates your
suggestions?
I think we can move forward with your patch immediately. The reworked
parser will use the same function for looking up the config file, so
we can land that now.
Kristian
___
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 9:54 AM, Alexander Larsson al...@redhat.com wrote: On mån, 2013-05-13 at 14:40 +0200, John Kåre Alsaker wrote: I don't think this will work in practice. I know for sure that e.g. Gtk is not set up to do any reasonable non-integer scaling. It will just scale up all drawing by a fractional factor without any rounding anywhere, causing everything to become fuzzy. We will eventually have alternative icons for higher resolutions, but these will be at 2x scale, not at generic fractional factor (that is not really doable without using pure-vector icons with some complex hinting method). Although, I guess that in the case of text the scaling will be ok, so for some usecases it might be OK. It will work very well for things designed to be scalable, browsers are an example. GTK could just fall back to integer scaling. Browsers are not really scalable like that, css page layout is generally based on the CSS Px definition, and per e.g. http://static.zealous-studios.co.uk/projects/web_tests/PPI%20tests.html: For lower-resolution devices [i.e. non-print], and devices with unusual viewing distances, it is recommended instead that the anchor unit be the pixel unit. For such devices it is recommended that the pixel unit refer to the whole number of device pixels that best approximates the reference pixel. I.e. whole number of pixels = scale by integer matches best what CSS wants. So, it's my opinion that supporting fractional scaling is an unnecessary burden on compositors for something that is not very useful in practice. Thats just my opinion though, and the proposal as such can handle fractional scaling fine by just changing the scale factors to fixed type. It is of no burden on compositors at all, only for clients which choose to implement it. It is, as long as clients are allowed to specify a fractional scaling factors compositors need to be able to handle scaling by that (for instance if the window appears partially on a non-highres monitor. 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. In mirrored/clone mode only a single wl_output would be presented to clients with a single scale factor, so priorities won't matter in that case. That is not necessarily so. We might very well want to know that there are two displays, with say different RGB subpixel order, etc. The compositor could unify this information into a single wl_output. And what would it then report for physical width/height, subpixel, make, model, etc? Seems pretty weird. I suggest we send 3 scaling factors to clients. A lower bound where factors lower will be scaled up. The desired scaling factor. A upper bound where factors above will be scaled down. Clients should find the scaling factor in lower bound to upper bound they are able to render at which is closes to the desired factor. Failing that they should find the first factor they are able to render at above the upper bound. When displayed on multiple monitors it could try to remain sharp on as many monitors as possible. I don't quite understand this. Any factor lower than the desired factor has to be scaled up, no? Lets take a concrete example. The macbook pro 15 has a 2880 x 1800 native panel. This is normally driven as 1440 x 900 with a scale factor of 2. On OSX you can also select a 1920x1200 resolution, which is nominally a scale factor of 1.5. However, on OSX what they do is that apps render to a framebuffer at twice the resolution (3840x2400) and its then scaled it down to 2880x1800 to make it look reasonable. Actually, this seems like a fairly reasonable way for the client to render. It can simply render at a sufficiently high integer multiple of the resolution it wants to look really good on such that it's always downscaling. Or, if it's worried about memory, let the compositor upscale. However, the key here is that the scale factor is an integer multiple of *one* of the monitor scale factors. Whether or not the monitor scale factor is an integer doesn't matter for this. On such a setup in wayland the wl_output would be 1920x1200, with a scaling factor of 1.5. For a 800x601 window a hidpi applications could then either pick a buffer of 1600x1202 buffer and set a scaling factor of 2 causing the compositor to downscale it (similar to OSX above), or it could create a buffer at 1200x902 (nearest to the true 901.5) and and
Re: [PATCH] config-parser: Honor the XDG_CONFIG_DIRS environment variable
On Mon, May 13, 2013 at 10:37 AM, Daniel Stone dan...@fooishbar.org wrote: Hi, On 12 May 2013 16:54, Kristian Høgsberg k...@bitplanet.net wrote: I think we can change the interface to int open_config_file(const char *), which looks up and opens the config file and returns the fd. We can keep that in weston_compositor instead of the config_file path. The parse function can then fseek on the fd to reset to the beginning of the file. Going forward, we'll do something like this: Totally. I've actually got a patch which looks in $sysconfdir and $datadir as well, enabling global fallback config files to be shipped, which I guess should be combined with this. When I looked at that, my next step was going to be returning an fd, but then I remembered that fds have no fgets() equivalent and totally lost interest in open-coding that. We can use fdopen(). But it would be a much better result, particularly as mine open()s the files to verify they're accessible anyway ... Yeah, that was the point of returning an fd - to avoid the classic access()/open() race (though I doubt it's a concern for a config file). Kristian ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
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. Thank you for your support anyway. -- Rafael Antognolli ___ 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 Sun, May 12, 2013 at 10:58:04AM +0200, Quentin Glidic wrote:
From: Quentin Glidic sardemff7+...@sardemff7.net
It's a good idea, but there are a couple of issues with the patch.
Signed-off-by: Quentin Glidic sardemff7+...@sardemff7.net
---
src/shell.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/shell.c b/src/shell.c
index 5da649d..135eaa5 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -2705,6 +2705,15 @@ zoom_axis_binding(struct weston_seat *seat, uint32_t
time, uint32_t axis,
}
static void
+lock_binding(struct weston_seat *seat, uint32_t time, uint32_t key,
+ void *data)
+{
+ struct desktop_shell *shell = data;
+
+ shell_fade(shell, FADE_OUT);
We need to put the compositor into the idle state at this point. The
wake signal only fires on input activity when the compositor is idle.
If you just fade out without setting idle, the compositor won't fire
the wakeup signal until after the idle timeout, and you wont be able
to get out of the black screen until then.
We should add a weston_compositor_idle() to go with the other state
transition functions (weston_compositor_wake/offscreen/sleep), which
just sets state to IDLE and cancels the timer.
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.
Kristian
+}
+
+static void
zoom_key_binding(struct weston_seat *seat, uint32_t time, uint32_t key,
void *data)
{
@@ -4235,6 +4244,8 @@ shell_add_bindings(struct weston_compositor *ec, struct
desktop_shell *shell)
/* configurable bindings */
mod = shell-binding_modifier;
+ weston_compositor_add_key_binding(ec, KEY_L, mod,
+ lock_binding, shell);
weston_compositor_add_key_binding(ec, KEY_PAGEUP, mod,
zoom_key_binding, NULL);
weston_compositor_add_key_binding(ec, KEY_PAGEDOWN, mod,
--
1.8.2.1
___
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: minimized and stick windows
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. --Jason Ekstrand ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] move subsurface-server-protocol.h include out of compositor.h
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])
--
1.7.11.7
___
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 04:31:06PM -0700, Othman, Ossama wrote:
Hi Kristian,
Here's another revision of the patch that attempts to implement your
suggested simplification, as well as address the TOCTOU race in previous
revisions of the patch. The module entry point signature changed slightly
because of the latter. Note that I had to modify the strchrnul() loop
slightly from what you suggested since the next string ended up beginning
with a colon ':' after the first iteration. I'm not exactly happy with my
solution (p =( *next == ':' ? next + 1 : next)). Please let me know what
you think.
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.
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.
Kristian
Thanks!
-Ossama
---
From 528848247242cdf476e05569b5abef029d438f79 Mon Sep 17 00:00:00 2001
From: Ossama Othman ossama.oth...@intel.com
Date: Mon, 13 May 2013 16:12:32 -0700
Subject: [PATCH] config-parser: Honor XDG_CONFIG_DIRS.
This set of changes adds support for searching for a given config file
in the directories listed in $XDG_CONFIG_DIRS if it wasn't found in
$XDG_CONFIG_HOME or ~/.config. This allows packages to install custom
config files in /etc/xdg/weston, for example, thus allowing them to
avoid dealing with home directories.
To avoid a TOCTOU race the config file is actually open()ed during the
search. Its file descriptor is returned and stored in the compositor
for later use when performing subsequent config file parses.
Signed-off-by: Ossama Othman ossama.oth...@intel.com
---
clients/desktop-shell.c |8 ++--
clients/tablet-shell.c|8 ++--
clients/terminal.c|8 ++--
clients/window.c |8 ++--
man/weston.ini.man| 12 +-
shared/config-parser.c| 92
++---
shared/config-parser.h|6 +--
src/cms-static.c |4 +-
src/compositor-drm.c | 10 ++---
src/compositor-fbdev.c|8 ++--
src/compositor-headless.c |8 ++--
src/compositor-rdp.c |4 +-
src/compositor-rpi.c |8 ++--
src/compositor-wayland.c |8 ++--
src/compositor-x11.c | 10 ++---
src/compositor.c | 31 +++
src/compositor.h |8 ++--
src/shell.c |8 ++--
src/tablet-shell.c|2 +-
src/text-backend.c|9 +++--
src/xwayland/launcher.c |2 +-
tests/weston-test.c |2 +-
22 files changed, 154 insertions(+), 110 deletions(-)
diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index 38af6c6..3949975 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -1090,7 +1090,7 @@ add_default_launcher(struct desktop *desktop)
int main(int argc, char *argv[])
{
struct desktop desktop = { 0 };
- char *config_file;
+ int config_fd;
struct output *output;
int ret;
@@ -1122,11 +1122,11 @@ int main(int argc, char *argv[])
grab_surface_create(desktop);
- config_file = config_file_path(weston.ini);
- ret = parse_config_file(config_file,
+ config_fd = open_config_file(weston.ini);
+ ret = parse_config_file(config_fd,
config_sections, ARRAY_LENGTH(config_sections),
desktop);
- free(config_file);
+ close(config_fd);
if (ret 0)
add_default_launcher(desktop);
diff --git a/clients/tablet-shell.c b/clients/tablet-shell.c
index 99d66f2..3d5e79a 100644
--- a/clients/tablet-shell.c
+++ b/clients/tablet-shell.c
@@ -456,7 +456,7 @@ int main(int argc, char *argv[])
{
struct tablet tablet = { 0 };
struct display *display;
- char *config_file;
+ int config_fd;
struct output *output;
display = display_create(argc, argv);
@@ -478,11 +478,11 @@ int main(int argc, char *argv[])
wl_list_init(tablet.homescreen-launcher_list);
- config_file = config_file_path(weston.ini);
- parse_config_file(config_file,
+ config_fd = open_config_file(weston.ini);
+ parse_config_file(config_fd,
config_sections, ARRAY_LENGTH(config_sections),
tablet);
- free(config_file);
+ close(config_fd);
signal(SIGCHLD, sigchild_handler);
diff --git a/clients/terminal.c b/clients/terminal.c
index e80e0e5..f11a6cc 100644
--- a/clients/terminal.c
+++ b/clients/terminal.c
@@ -2671,17 +2671,17 @@ int main(int argc, char *argv[])
{
struct display *d;
struct terminal *terminal;
- char *config_file;
+ int config_fd;
option_shell = getenv(SHELL);
if (!option_shell)
[PATCH weston] tests: add simple installcheck test for the weston sdk
From: U. Artie Eoff ullysses.a.e...@intel.com This test should be executed with 'make installcheck' after running 'make install'. It is a simple, basic test that attempts to compile a trivial (and inherently useless) weston sdk module to ensure the exported SDK can be used by consumers. Any improvements are welcome. Signed-off-by: U. Artie Eoff ullysses.a.e...@intel.com --- tests/Makefile.am | 5 - tests/installcheck-test | 41 + 2 files changed, 45 insertions(+), 1 deletion(-) create mode 100644 tests/installcheck-test diff --git a/tests/Makefile.am b/tests/Makefile.am index 9f711cf..69a3e22 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -115,7 +115,10 @@ if BUILD_SETBACKLIGHT setbacklight = setbacklight endif -EXTRA_DIST = weston-tests-env +installcheck-local: + $(SHELL) ./installcheck-test + +EXTRA_DIST = weston-tests-env installcheck-test BUILT_SOURCES =\ subsurface-protocol.c \ diff --git a/tests/installcheck-test b/tests/installcheck-test new file mode 100644 index 000..f73b91b --- /dev/null +++ b/tests/installcheck-test @@ -0,0 +1,41 @@ +#!/bin/bash +# +# Copyright © 2013 Intel Corporation +# +# 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. +# + +set -x + +TMPFILE=/tmp/weston-sdk-ic$$ +cat EOF $TMPFILE.c +#include weston/compositor.h +WL_EXPORT int +module_init(struct weston_compositor *compositor, + int *argc, char *argv[], const char *config_file); +EOF + +gcc -c `pkg-config pixman-1 weston --cflags` $TMPFILE.c -o $TMPFILE.o +gcc -shared $TMPFILE.o `pkg-config weston --libs` -o $TMPFILE.so + +set RESULT=$? + +rm $TMPFILE.c $TMPFILE.o $TMPFILE.so + +exit $RESULT -- 1.7.11.7 ___ 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
Alexander Larsson wrote: On ons, 2013-05-08 at 12:07 -0700, Bill Spitzak wrote: Output scaling should be merged with the existing buffer_transform (the 8-value enumeration describing 90 degree rotations/reflections). In effect they are parts of the same thing, yeah. I don't know if ABI compat allows us to just change buffer_transform though. I'm not proposing changing the buffer_transform api, but instead somehow making sure that all transforms are together whenever possible so that they can be described as a single transform. I think there has to be an attempt to reduce the number of transformation steps to as few as possible. The transforms themselves can be as complex of a combination of different apis set by the client and compositor as wanted, but every other api that takes an xy location should use xy locations in as few different spaces as possible. If this is not done clients are forced to maintain a messy square array of matrix and inverse matricies to translate positions from one space into another. With the current proposal the only problem I see is that the scaler specifies the source rectangle in the output of buffer_transform space. If more complex transforms are added in the future the meaning of this source rectangle either becomes rather complex or pretty useless, or you are forced to think about two transforms rather than one. My recommendation is that the source rectangle be in the input to buffer_transform space. I'm also worried some about the proposals for hi-res outputs because they look like they may force a third transform, as events are in the input space but some compositor api such as the xy are in the output space. I think things can be reduced to exactly two transforms. There is one transform from buffer space which are where pixels are actually stored in the buffer, to surface space which is where events, surface size, and regions are defined. There is a second transform to output space which are pixels on an output (there is a different one of these transforms per output). The first transform currently consists of the buffer_transform and the scaler. The second one consists of the proposed hi-dpi compensation, the xy translation of outputs, the second transform of any parents for subsurfaces, and any effects like rotation or wavy that the compositor adds. I think there is a possible scheme where there is a single transform, by making buffer space and surface space identical. This is unfortunately incompatible with the long-established buffer_transform api, as well as the scaler api, in that all events and surface size are specified in the input to these rather than the output. 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 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 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). 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
Re: [PATCH weston] shell: Add a lock binding
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? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
