On Mar 7, 2014 1:14 PM, "Bryce W. Harrington" <<a href="mailto:b.harrington@samsung.com">b.harrington@samsung.com</a>> wrote: > > On Fri, Mar 07, 2014 at 11:31:16AM -0600, Jason Ekstrand wrote: > > > > + If the size of the presented surface changes, the resulting output > > > > + is undefined. The compositor may attempt to change the output > > mode > > > > + to compensate. However, there is no guarantee that a suitable > > mode > > > > + will be found and the client has no way to be notified of success > > > > + or failure. > > > > > > Probably a stupid question but could the presented surface be locked to > > > prevent it from changing size? > > > > Not really. The client simply attaches buffers of some size or another and > > the server has to take what the client gives it. That patagraph is > > intended expressly to address this by telling the client "Don't do that!" > > under threat of undefined results. > > Guess I'm thinking more from the user perspective of having downloaded > some random client app off the internet that ignores this advice. > > Presumably at least the damage is limited to the client's window. I > guess that's my main concern - that some random app doesn't leave the > user's system borked up. > > > > > + The framerate parameter specifies the target framerate for the > > > > + output. The compositor is free to ignore this parameter. A value > > > > + of 0 indicates that the client has no preference. > > > > > > This doesn't actually define what the framerate parameter does. Does it > > > do something if the framerate drops too low? Or does it cap it to not > > > go above a certain level? > > > > The output mode is given by three parameters: width, height, and > > framerate. The framerate should be given in mHz (same as in > > wl_output.mode) but maybe I should specify that. If the compositor states > > that the given output supports, for instance 1024x768@60Hz and 1024x768@50Hz, > > this lets the client specify which it would like. In most cases, the > > client won't care which is why I have the 0 option. However, providing a > > framerate option allows the client more-or-less full control over the > > output mode. > > Ah, that's clearer. Think I was confused by the word target; 'desired > framerate' would maybe be clearer. > > So for your examples, if 50Hz was desired, then you'd pass > framerate="50000"? > > > > > + If the surface has a buffer_scale greater than 1, the compositor > > > > + may choose a mode that matches either the buffer size or the > > > > + surface size. In either case, the surface will fill the output. > > > > > > This paragraph is a bit confusing. Is buffer_scale a scaling factor? > > > > Wayland provides an integer scale parameter for each output that tells the > > client that the given output is actually scaled down. This is for HiDPI > > displays where you may want 2 or 3 physical pixels per logical pixel. If > > the output has a scale factor of 3, that means that every surface on that > > output will be scaled up by a factor of 3. The buffer_scale option allows > > the client to compensate in the same way as the buffer_transform option > > allows it to compensate for a rotated output. If a surface has a > > buffer_scale of 3 and a 600x900 buffer, then the size of the surface is > > only 200x300 but it will be pixel-for-pixel exact on the output that's > > scaled by 3. > > > > The problem here is what to do with the buffer_scale factor. In the > > example above, the client is providing a 600x900 buffer but the surface is > > only 200x300. Which size should the compositor make the output? This gets > > even stickier because the output modes provided by wl_output are given in > > physical pixels without any transform or scale. As given, I chose to > > explicitly not solve this problem and let the compositor choose. In > > practice, I expect that most compositors won't provide any scale factor on > > the output and the client just provides the surface size it wants. > > > > Perhaps this isn't the best option. Would it be better defined if we just > > stated that the compositor will try to match the output size to the surface > > size? Then warn clients that the wl_output.scale factor may still get > > applied. This may be a better option since the client will have to handle > > the tramsform in a similar way. > > > > Ultimately, if the client wants to control modesetting it should be either > > a) using the same size and transform as the output or b) providing a > > surface in output-space (after having transformed the mode from the > > compositor) and letting the compositor transform/scale it. I'm not really > > sure what's best to do here honestly. Suggestions are appreciated. I'll > > think on it more. > > Are the use cases here just HiDPI and fullscreen games? If there are > other use cases they might shed light on the scope of the problem. > Would video players use it? > > In particular is there any use case for having 1 physical pixel per N > logical pixels? If there is, then perhaps let buffer_scale just be the > scaling factor, and have a separate parameter for toggling scaling on or > off? Documentation-wise, having two parameters is going to be easier to > explain I think. I think there's some confusion as to the target clientel here. I don't intend for games of other "normal" apps to be running on this protocol. The modesetting part in particular is inteded mainly for running a compositor embedded inside another one. Take another look at the 0'th patch in the series. I cover the use-cases in detail there. Really, the question here isn't about turning scaling on/off, it's about what to do with the wl_surface.buffer_scale that we already have. If wl_surface.buffer_scale == wl_output.scale then it's obvious. If this is not the case, it's not 100% clear what the right thing to do is here. > > > > > + </description> > > > > + <arg name="surface" type="object" interface="wl_surface"/> > > > > + <arg name="output" type="object" interface="wl_output"/> > > > > + <arg name="framerate" type="int"/> > > > > + <arg name="feedback" type="new_id" > > interface="wl_fullscreen_shell_mode_feedback"/> > > > > + </request> > > > > + > > > > + <enum name="error"> > > > > + <description summary="wl_fullscreen_shell error values"> > > > > + These errors can be emitted in response to wl_fullscreen_shell > > requests > > > > + </description> > > > > + <entry name="invalid_method" value="0" summary="present_method > > is not known"/> > > > > + </enum> > > > > + </interface> > > > > + > > > > + <interface name="wl_fullscreen_shell_mode_feedback" version="1"> > > > > + <event name="mode_successful"> > > > > + <description summary="mode switch succeeded"> > > > > + This event indicates that the attempted mode switch operation was > > > > + successful. A surface of the size requested in the mode switch > > > > + will fill the output without scaling. > > > > + > > > > + Upon recieving this event, the client should destroy the > > > receiving > > > > > > > + wl_fullscreen_shell_mode_feedback object. > > > > + </description> > > > > + </event> > > > > + <event name="mode_failed"> > > > > + <description summary="mode switch failed"> > > > > + This event indicates that the attempted mode switch operation > > > > + failed. This may be because the requested output mode is not > > > > + possible or it may mean that the compositor does not want to allow > > > > + mode switches at this time. > > > > > > Would it be worth returning these two failure modes as distinct events? > > > Might help client developers in debugging if nothing else. > > > > > > If lets say a game client wanted to do a mode change, would it make > > > sense for them to do a series of present_surface_for_mode calls and > > > keep trying different modes while they receive mode_failed events? > > > Or is there a way for them to query for allowed modes that they can > > > select from? > > > > Ok, first off games aren't really the intended clientel. I don't think > > this is really an issue. Allow me to elaborate. I expect that the > > compositor will have one of two basic modes of operation. First, is to > > allow you to set any mode at all. This is likely to be the case for > > streaming/recording compositors where there is no physical output. Second > > is that it has some list of modes and allows you to select one. In the > > first case, it should always succeed unless the compositor has some rule > > such as "you can only set this once". > > Right, or invalid modes... -1x-1, 1000000x1000000, etc. > > > In the second case, you can go ahead > > and try to set whatever you want, but it might not work. However, if it's > > an advertised mode and the transform and scale match (see above) you should > > expect it to work. > > Gotcha, yeah so long as there's a list available then we can expect the > client to constrain itself to those. How does the client request this > list? > > > If a client wants to run at some exotic resolution, I expect it to try that > > and, if it fails, pick the best resolution from the advertised modes and > > then try that. > > > > I still want to leave the compositor a bit of a way out if there's a > > problem. Perhaps "does not allow mode switches at this time" is a bad way > > to put it. > > It suggests the client could sleep(N) and try again. If that is an > appropriate way to handle it then the wording's fine. If it's not going > to be allowed for the given client, window, or surface at all, then > perhaps a more definitive wording would help the client. Yeah, I need to reword this. I'll get it patched up. > > Bryce >