Re: [PATCH] protocol: Add buffer_scale to wl_surface and wl_output

[Alexander Larsson]

On tis, 2013-05-14 at 13:43 -0700, Bill Spitzak wrote:
> al...@redhat.com wrote:
> 
> > +  
> > +  
> > +
> > 
> 
> Fixed is not a good idea for scaling factors. You cannot accurately 
> represent values like 2/3 or 1/fixed. For an actual problem with 
> scaling, if the accurate scaling is an odd fixed number, the client 
> cannot specify that their scale is exactly 1/2 that, thus losing the 
> ability to get a 2x scale done by the compositor.
> 
> I would specify the scale as two integers defining a rational fraction.
> 
> This would also allow completely lossless multiplication with the 
> rational numbers used by the scaler proposal.
> 
> You may also want to allow different horizontal and vertical scales, 
> mostly because all plausable implementations can do this with no loss of 
> speed, and the scaler api allows this. You will need to define if this 
> is before or after the buffer transform...

In fact, working on this in weston a bit it seems that in general, scale
is seldom used by itself but rather its used to calculate the buffer and
screen size which are then used, and we want both of these to be
integers. So, it seems to me that we should specify scaling by giving
the width/heigh of the surface, which in combination with the buffer
size gives the exact scaling ratios, plus it guarantees that the scaling
maps integers to integers.


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] protocol: Add buffer_scale to wl_surface and wl_output

[Pekka Paalanen]

On Tue, 14 May 2013 13:43:12 -0700
Bill Spitzak  wrote:

> You may also want to allow different horizontal and vertical scales, 
> mostly because all plausable implementations can do this with no loss of 
> speed, and the scaler api allows this. You will need to define if this 
> is before or after the buffer transform...

Only if there are monitors with non-square pixels that we care about.
Otherwise no.
- pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 2/2] protocol: Add buffer_scale to wl_surface and wl_output

[Pekka Paalanen]

On Tue, 14 May 2013 12:48:39 -0700
Bill Spitzak  wrote:

> Pekka Paalanen wrote:
> 
> > You cannot get an identity by multiplying real-valued transformations
> > together, other than by accident.
> 
> This is why I propose sending the inverse of the matrix, so the identity 
> can be checked accurately. It also happens that the inverse matrix is 
> the same matrix that is needed to tell cairo to draw the image correctly.
> 

A matrix naively multiplied by its inverse matrix is not identity, so
you cannot simply check it.

Also, checking whether two matrices are equal is *hard*. Do not go
there.

This proposal does not belong in this thread. Really.

- 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

[Bill Spitzak]

John Kåre Alsaker wrote:


For example a compositor may want to use a 1-1.2 range with
1.1 as
the desired scaling factor. A clients which are only able to
draw at
integer scaling factor would round that up to 2 and let the
compositor downscale it. When the range for which compositor
won't
scale is send to clients we can avoid this.


I don't think a range is necessary. The client can just claim that
it's window is scaled at 1.1 even though it drew it at 1. Or at 2.2
even though it drew it at 2. Nothing stops the client from doing
this so you might as well make that the way integer scales are done.

Then the user drags the window that claims to be draw at 1.1 over to a 
monitor with scaling factor 1. It will be downscaled even though it's a 
perfect match for the monitor.


That makes sense. I'm still not sold on the range, especially the upper 
end of the range. The only likely scheme I see for choosing a size to 
draw at will ignore the upper range.


What happens in your "scale=1.1, range=1,1.2" scenario if the client 
draws at a size of 2? It looks like it will draw at a scale if 1.1/2, 
but it may be better for it to draw at a size of 1/2.

___
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

[Bill Spitzak]

John Kåre Alsaker wrote:


On Tue, May 14, 2013 at 9:16 PM, Bill Spitzak > wrote:


John Kåre Alsaker wrote:

The size of a window should always be in pixels at the protocol
level.


Note that this is in direct contradiction to the proposed scaler
api. In it the size of the window is in transformed pixels.

I think now the scaler proposal should be changed.

I was referring to surface pixels here, which is what you get after the 
transformation of the scaler extension. 


But the output of the scaler is not pixels. It certainly is not the 
pixels in the buffer, and if this hi-dpi scaling or arbitrary transforms 
done by the shell is done, it is not pixels on the output either.


Integers in the input space, however, always correspond to real physical 
pixels in the buffer.


If coordinates are always in buffer space, the compositor can multiply 
all the transforms together and not have to think about the partial 
transforms.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 0/2] Support for high DPI outputs via scaling

[John Kåre Alsaker]

On Tue, May 14, 2013 at 9:46 PM, Bill Spitzak  wrote:

>
>
> John Kåre Alsaker wrote:
>
>>
>> I expect a compositor to render deviations of the desired scaling
>> factor without scaling windows. The range when this is allowed is
>> reported to clients so they can try to render at a size which will
>> avoid scaling.
>>
>> For example a compositor may want to use a 1-1.2 range with 1.1 as
>> the desired scaling factor. A clients which are only able to draw at
>> integer scaling factor would round that up to 2 and let the
>> compositor downscale it. When the range for which compositor won't
>> scale is send to clients we can avoid this.
>>
>
> I don't think a range is necessary. The client can just claim that it's
> window is scaled at 1.1 even though it drew it at 1. Or at 2.2 even though
> it drew it at 2. Nothing stops the client from doing this so you might as
> well make that the way integer scales are done.
>
Then the user drags the window that claims to be draw at 1.1 over to a
monitor with scaling factor 1. It will be downscaled even though it's a
perfect match for the monitor.


>
> With the range, what happens to a surface with a scale of 1.3? Is it
> scaled by 1.3? Or should it be 1.3/1.2 times larger than the one scaled at
> 1.2, which is actually 1.191666? For this reason I think any scale wanted
> by the client should be obeyed literally.

It will be scaled by client_scaling_factor/output_scaling_factor, which is
1.3/1.1.


>
>  We may also allow scaling factors below 1.
>>
>
> I think scaling factors less than 1 are going to be a requirement.
> Otherwise the "units" have to be for the lowest-resolution device, which
> seems silly if you have a huge hi-res screen and a small lcd low-res
> display on your keyboard.
>
Perhaps, but I'd expect clients to do a lot of rounded up making the
scaling not very linear.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 0/2] Support for high DPI outputs via scaling

[John Kåre Alsaker]

On Tue, May 14, 2013 at 9:16 PM, Bill Spitzak  wrote:

> John Kåre Alsaker wrote:
>
>  The size of a window should always be in pixels at the protocol level.
>>
>
> Note that this is in direct contradiction to the proposed scaler api. In
> it the size of the window is in transformed pixels.
>
> I think now the scaler proposal should be changed.
>
I was referring to surface pixels here, which is what you get after the
transformation of the scaler extension.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Gamepad focus model (Re: Input and games.)

[Rick Yorgason]

Hi Bill,

In reply to everything below, I don't think there's anything in any of 
the proposals that prevents compositors from implementing pointer 
emulation for gamepads, or from suspending that emulation when a game 
has the gamepad's focus.


-Rick-

On 2013-05-14 15:08, Bill Spitzak wrote:

I feel the underlying function should be this:

1. The game can enumerate all the gamepads.

2. The game can "grab the focus" for any gamepads it wants.

Once it is grabbed, the pointer motion makes NO difference, removing a
lot of the questions people are asking here. If the device was moving
the pointer, it stops moving the pointer. If another device like a mouse
moves the pointer, it continues to do so, but it does not matter if the
mouse is moved outside the game and clicked elsewhere: the mouse works
like normal sending clicks to that other client, and the gamepad events
continue going to the game.

The only complexity is to prevent clients from grabbing the gamepad when
they should not. For this the "grab the focus" does not work unless the
shell allows it to.

As I see it the gamepad is "attached" to at most one "pointer". The
gamepad can be grabbed if the client has that pointer's focus. The
gamepad can also be "attached" to any number of other devices. It can
also be grabbed if the event that triggered the grab request is a
focus-in or event for a related device (this is so keyboard keys can
cause a gamepad grab).

Specifying this attachement is where the seat and hierarchy comes in.

I very much agree that the seat==user idea is best. Otherwise it seems
like seats are pretty useless, and users would have to be added to
wayland anyway, making it more complex for no good reason. To get the
"one seat per gamepad but they all share the same pointer" the
parent-seat proposal seems like as easy fit. I am having a hard time
coming up with a plausible setup that this would not cover. Grabbing a
gamepad does not change this parenting in any way.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Gamepad focus model (Re: Input and games.)

[Rick Yorgason]

On 2013-05-14 11:18, Daniel Stone wrote:

1) Some compositors may put every gamepad in one seat, and some compositors
may assign one gamepad per seat. The game programmer has to support both
code paths. And unfortunately, when game programmers inevitably neglect to
do that, the gamers are going to blame the compositors rather than the
games. Wayland will get a reputation as a display server where you have to
configure your gamepads differently for different games.


Compositors can implement maximise badly too, or multi-display
support.  But it's not an argument to push the complexity out.  It's
an argument for not running broken compositors.


But is it really broken?

The *only* way to do a split screeen FPS where both players are using a 
keyboard/mouse combo is to use multiple seats. That alone should be an 
argument for putting the player ID in the seat rather than the gamepad.



2) Gamepads aren't the only scenario where you want to have one focus for
multiple players.

Here's a couple scenarios that are complicated by breaking the seat == user
model:


It's not seat == user, it's seat == focus.


Well, right now we have user == seat == focus. We're debating which side 
of the equation should be decoupled.



A) You're playing split-screen Halo. Two users have a mouse/keyboard, and
two users have gamepads.

In the seat == user world, we know how this is set up: seat 1 has a
mouse/keyboard, seat 2 has a mouse/keyboard, seat 3 has a gamepad, and seat
4 has a gamepad.


We know how it's set up, but we don't know how it works.  How does the
compositor know to focus 3 and 4 at Halo, rather than at the browser
or whatever else is running at the time? You can't have the keyboard
and mouse tell you, because they're different seats.  So it's just
manual then? Or the compositor making random guesses?


Are the details of how focus slaving should work the only thing holding 
us back from this model?


I've given some examples of how I think a compositor should implement 
that in earlier emails, but I can work on explaining it better if it's 
the only problem.



In the many-gamepads-per-seat model, I don't know how to set this up. The
first two players would have to have their own seats, but since the player
ID is in the gamepad, where do we get their player numbers from? And what
about players 3 and 4? Where do their gamepads go? They can go in seat 1,
but then how do you distinguish player 1 from players 3 and 4? And why does
player 2 have to manually focus the game?


The gamepads go to whichever seat it is that's directing their focus.
If their focus is entirely manually set, then they go in their own
seat.  Simple, no? Or am I totally missing something, and do gamepads
under Wayland typically not follow keyboard/mouse focii? (I don't mean
in really contrived theoretical cases, I mean in the overwhelming
majority of situations.)


Okay, so in this scenario, seat 1 has a mouse, a keyboard, and two 
gamepads, and those devices are split across players 1, 3, and 4.


The gamepad object we discussed earlier had a player ID associated with 
it, so you could tell which gamepad belongs to player 1, player 2, etc. 
If the gamepad has player indicator LEDs, it's expected to display this 
information.


But in this case, player 1 has the mouse and keyboard, and there's no 
way to represent that. Instead, the compositor would probably assign the 
gamepads to players 1 and 2, but since they're *actually* players 3 and 
4, the LEDs on their gamepads would be wrong.


I *do* believe that gamepads in Wayland would typically follow the 
keyboard focus, but I think that can be accomplished with focus slaving, 
without any changes to the protocol.



(I don't believe this scenario is inherently exotic. Lemmings, Settlers, and
Hired Guns all did this back in the DOS and Amiga days, before OSs made it
harder to distinguish mice from each other.)


Yes, that's the tradeoff you get for multitasking, and having the OS
know where your mice are, rather than having to tell every single game
where every single mouse is.


Yep, it's a tradeoff, but only because display servers haven't been 
designed with multiple simultaneous users in mind. This is one of the 
many areas Wayland innovates in.



B) Imagine that, with the current trend of adding touchpads to gamepads,
Fruit Ninja releases a multi-player version. All players play on the same
"field", but it tracks their scores independently; whomever slashes the
fruit first gets the points. Let's imagine we have player 1 with a separate
touchpad, and players 2 and 3 with gamepads that have touchpads built in.

In the seat == user model, it's obvious how this should be set up: seat 1
gets a touchpad, seat 2 gets a gamepad with the associated touchpad, and so
does seat 3.

In the many-gamepads-per-seat model, the question rises again of where you
put the gamepads. Do they go in the same seat as the touchpad they're
attached to? Or do they all end up in seat 1? If they're all in seat 1, 

Re: [PATCH] config-parser: Honor the XDG_CONFIG_DIRS environment variable

[Othman, Ossama]

Hi Kristian,

On Tue, May 14, 2013 at 1:57 PM, Kristian Høgsberg wrote:

> On Tue, May 14, 2013 at 09:55:19AM -0700, Othman, Ossama wrote:
> > I've attached the patch since the patch I sent through git send-mail was
> > sent through an e-mail account that isn't subscribed to this list
> (waiting
> > for moderator approval), and to make sure the spacing isn't munged again.
> >  This patch was generated against weston master as of this morning.
>
> Cool, looks good now, committed.  I did catch a corner case in the
> spec that we could handle better.  As far as I can see,
> XDG_CONFIG_HOME, if set, overrides ~/.config.  That means if it's set
> and we don't find a config file there, we shouldn't fall back and try
> ~/.config/weston.ini.


Good catch!


>  Similarly, only if XDG_CONFIG_DIRS is not set
> do we fall back to /etc/xdg, but we do handle correctly with your
> patch.  Also the spec says "not set or empty", so we should be
> checking !config_dirs || *config_dirs == '\0'.
>
> Finally, I didn't see a reason for adding weston/ to the path when
> iterating the XDG_CONFIG_DIRS?  I guess many applications put their
> config file in a subdirectory of the config dir, but at least for
> ~/.config/weston.ini we don't do that.
>

The part of the XDG base spec that discusses XDG_CONFIG_DIRS wasn't very
clear to me.  I was thrown by the mention of "subdirs" on the web page at
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html#referencing.
 Unfortunately "subdirs" doesn't appear to be defined. It states:

   Specifications may reference this specification by specifying the
location of a configuration file as $XDG_CONFIG_DIRS/subdir/filename. This
implies that:

   -

   Default configuration files should be installed to
$sysconfdir/xdg/subdir/filename
   with $sysconfdir defaulting to /etc.
   -

   A user specific version of the configuration file may be created in
   $XDG_CONFIG_HOME/subdir/filename, taking into account the default value
   for $XDG_CONFIG_HOME if $XDG_CONFIG_HOME is not set.
   -

   Lookups of the configuration file should search for ./subdir/filename
   relative to all base directories indicated by $XDG_CONFIG_HOME and
   $XDG_CONFIG_DIRS . If an environment variable is either not set or
   empty, its default value as defined by this specification should be used
   instead.

I interpreted "subdir" as "weston" in our case.  My Linux box (Ubuntu
12.10) also puts config files under various subdirectories in /etc/xdg;
although there are some config file placed directly in /etc/xdg as well.  I
don't know which is right so I'm happy with whatever you decide.  :)


> I committed a small patch to fix up these issues - let me know if you
> see a problem.
>

Will do!

Thanks Kristian!
-Ossama
___
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

[Kristian Høgsberg]

On Tue, May 14, 2013 at 09:55:19AM -0700, Othman, Ossama wrote:
> Hi Kristian,
> 
> I've attached the patch since the patch I sent through git send-mail was
> sent through an e-mail account that isn't subscribed to this list (waiting
> for moderator approval), and to make sure the spacing isn't munged again.
>  This patch was generated against weston master as of this morning.

Cool, looks good now, committed.  I did catch a corner case in the
spec that we could handle better.  As far as I can see,
XDG_CONFIG_HOME, if set, overrides ~/.config.  That means if it's set
and we don't find a config file there, we shouldn't fall back and try
~/.config/weston.ini.  Similarly, only if XDG_CONFIG_DIRS is not set
do we fall back to /etc/xdg, but we do handle correctly with your
patch.  Also the spec says "not set or empty", so we should be
checking !config_dirs || *config_dirs == '\0'.

Finally, I didn't see a reason for adding weston/ to the path when
iterating the XDG_CONFIG_DIRS?  I guess many applications put their
config file in a subdirectory of the config dir, but at least for
~/.config/weston.ini we don't do that.

I committed a small patch to fix up these issues - let me know if you
see a problem.

> Sorry for the churn.

No that's fine, we usually go through a couple of revisions of review
before committing the patch.  

Thanks,
Kristian

> 
> 
> 
> On Tue, May 14, 2013 at 7:05 AM, Kristian Høgsberg wrote:
> 
> > On Mon, May 13, 2013 at 11:41 PM, Othman, Ossama
> >  wrote:
> > > Hi Kristian,
> > >
> > >> I think it's good to go - however, inlining the patch messed up the
> > >> whitespace.  Ideally, send patches using git send-email, which can be
> > >> configured to use smtp servers, and you can pass --annotate if you
> > >> want to add a message or comment to the patch (put it after the ---
> > >> that indicates the end of the commit message).  Or as a last resort,
> > >> attach the patch.
> > >
> > >
> > > I forgot to attach the patch this last time around.  Sorry about that.
> >  I'll
> > > just resend the patch with git send-email, as you suggest.
> > >
> > >>
> > >> As for the next thing, good catch.  I'd do something like
> > >>
> > >> for (p = config_dirs; p != NULL; p = next) {
> > >> next = strchrnul(p, ':');
> > >> if (*next == ':')
> > >> next++;
> > >>
> > >> ...
> > >>
> > >> to keep the for (...) more readable.
> > >
> > >
> > > Changing the loop termination to "p != NULL" causes an infinite loop
> > since
> > > strchnul() returns a pointer to the null character '\0', not the NULL
> >
> > Yeah, sorry for the confusion, for a second while writing the email I
> > was thinking that we could just use strchr instead and test for p !=
> > NULL, but that doesn't work for getting the end of the last path
> > element.
> >
> > > pointer.  Also, the moving the next pointer past the colon must be done
> > > after path construction, other the colon ends up at the end of the path.
> > > How's this instead:
> > >
> > > for (p = config_dirs; *p != '\0'; p = next) {
> > > next = strchrnul(p, ':');
> > > snprintf(path, sizeof path,
> > > "%.*s/weston/%s", (int)(next - p), p, name);
> > > fd = open(path, O_RDONLY | O_CLOEXEC);
> > > if (fd >= 0)
> > > return fd;
> > >
> > > if (*next == ':')
> > > next++;
> > > }
> > >
> > > Note that I also had to cast "next - p" in the snprintf() call to int
> > since
> > > the format specifier "%*.s" wants an int but the pointer difference on
> > my 64
> > > bit Ubuntu box is a long int, at least according to the format specifier
> > > warning I get:
> > >
> > > foo.c: In function ‘open_config_file’:
> > > foo.c:53:5: warning: field precision specifier ‘.*’ expects argument of
> > type
> > > ‘int’, but argument 4 has type ‘long int’ [-Wformat]
> > >
> > > foo.c in this case is a simple test program I wrote.  I assume the cast
> > is
> > > safe since "next - p" should always fall within the range of type int.
> > >
> > > Anyway, I'll resend the patch with the above changes with git send-email.
> >
> > Yup, that all sounds good.
> >
> > thanks,
> > Kristian
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] protocol: Add buffer_scale to wl_surface and wl_output

[Bill Spitzak]

al...@redhat.com wrote:


+  
+  
+



Fixed is not a good idea for scaling factors. You cannot accurately 
represent values like 2/3 or 1/fixed. For an actual problem with 
scaling, if the accurate scaling is an odd fixed number, the client 
cannot specify that their scale is exactly 1/2 that, thus losing the 
ability to get a 2x scale done by the compositor.


I would specify the scale as two integers defining a rational fraction.

This would also allow completely lossless multiplication with the 
rational numbers used by the scaler proposal.


You may also want to allow different horizontal and vertical scales, 
mostly because all plausable implementations can do this with no loss of 
speed, and the scaler api allows this. You will need to define if this 
is before or after the buffer transform...

___
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

[Bill Spitzak]

Alexander Larsson wrote:


In this case our proposals differs. The compositor knows it's not
resizing the window so it simply passes 2000x2000 along to the
configure arguments.


How can the compositor know its not resizing the window? Only the app
knows if it can render at a different scaling factor, as it is the app
that allocates and draws to the buffer.


Huh? OBVIOUSLY the compositor knows it is not resizing the window. 
Otherwise it *would* resize it and the display would have the window at 
the wrong size!

___
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

[Bill Spitzak]

John Kåre Alsaker wrote:

I might have been unclear. Users may want to disable resizing of buffer 
pixels in the compositor. However clients which able to draw at the 
correct scaling factor should still do so and appear pixel perfect.


Clients that don't want scaling can simply "lie" and claim their buffer 
is at the same scaling factor as the output.

___
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

[Bill Spitzak]

Kristian Høgsberg wrote:

On Mon, May 13, 2013 at 11:49 PM, Bill Spitzak  wrote:

Kristian Høgsberg wrote:


The problem then is that the key release of the binding will now count
as activity and undo the lock.  I think we'll need a custom grab (see
weston_compositor_run_key_binding()) that triggers the lock on release
of the last key in the binding.  Or maybe add a "virtual modifier",
say MODIFIER_RELEASE, to make the binding code trigger the binding on
release instead.


Could you just have all release events not count as "activity"?


Hmm, maybe... they way it works now is that pressing and holding a key
(or button) inhibits the idle timer and when you then release we reset
it.  I think the expected behavior is that if you hold down a button
long enough for the idle time to expire, releasing the button doesn't
immediately trigger the screensaver.  That's arguably a corner case of
course, but I think that behavior is worth preserving.


That does sound better, but now I am confused as to what the problem is? 
It seems like it is already solved. Have exactly the same stuff that 
inhibits the idle timer also not "count as activity".

___
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

[Bill Spitzak]

Alexander Larsson wrote:


Now, a non-naive client will get the same maximize reply of 1000x1000,
but in this case we want it to create a buffer of 2000x2000 (with scale
2) since it knows the window is on a high-dpi monitor. So, there is a
natural separation of the surface size (1000x1000) and the buffer size
(2000x2000).

We can't have the configure event say 2000x2000, because then old
clients will not be auto-upscaled as we want.


The compositor can use the scaling factor of the surface to send all 
events to in, including maximize. So it can send 2000x2000 to the hi-res 
client and 1000x1000 to the client that did not set the scaling factor.


In fact this is going to be necessary if you want to support maximize 
sizes that are not a multiple of the scale.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] protocol: Add buffer_scale to wl_surface and wl_output

[Bill Spitzak]

John Kåre Alsaker wrote:
On Tue, May 14, 2013 at 2:51 PM, Alexander Larsson > wrote:


On tis, 2013-05-14 at 13:44 +0200, John Kåre Alsaker wrote:
 > I'd only accept a proposal which makes the clients tell the
compositor
 > how much they increased the size of their window. If the compositor
 > wants to resize anything it should resize the entire window and not
 > individual surfaces/buffers. This also avoids having to position
 > subsurfaces and have configure requests at fractional surface pixels.

I don't quite understand what you mean by this (like, how is "window"
different from "surface"). Can you give an example of how the API would
look for what you mean.

A window can have multiple surfaces (see the subsurface extension).


I don't see any problem at all. Any scale being applied to a surface to 
be applied to it's subsurfaces as well. And subsurface position is in 
pre-scaled coordinates so if you want a subsurface to align with some 
pixels in the main surface's buffer, the position is still in integers.


Yes the subsurface's destination rectangle is going to be scaled to 
non-integers. I think you have to realize you are not going to avoid 
this problem by your attempt to link the clipping rectangle to the 
scaling factor. Clients should deal with it by rendering images such 
that the result is not objectionable, mostly by forcing the edges to be 
replicated on buffers, and filling the invisible areas with non-clashing 
pixel values.


I now do very much believe that the scaler extension should be altered 
so that surface size and events are reported in pre-scaled (ie in buffer 
pixels) coordinates. This makes the transformation be done at the same 
step as this scaler, reducing the number of different coordinate spaces. 
You cannot do it the other way because that *does* require surface sizes 
to be non-integers.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Extremly interesting career opportunity for Wayland Project Committers/Contributors

[Chris Bower]

Hi,

 

I'm a Head-hunter dedicated to the European Mobile and Consumer Technology
space and representing a hugely impressive mobile & consumer technology
innovator to help them create an exciting new open source lab to ensure that
their business is positioned at the forefront of leading edge open source
software engineering.

 

The lab (split across various European locations) is to be made up of
software engineers that will continue to be focused on and contribute to
external open source community projects (70-80% of the team's work will be
external/community focused).  Wayland is one of the priority projects for
the lab alongside other projects including LLVM, Linux Kernel & Web
technologies (groups include Webkit, Chromium & node.js).  This is an
exciting new group being invested in and there are no limits to how
significant and influential these team roles will be both within the global
business as well as externally. As well as the chance to be one of the
founding members of an exciting new team set for real expansion, on offer
for every position is fantastic career potential & extremely attractive
salaries & benefits packages. 

 

Whilst the teams are being grown from specific European locations, there is
also scope for flexible/remote or home working for highly capable
individuals with regular Wayland project contributions/commits.

 

If you could be interested in a Wayland focused position within this new
open source team, I would be delighted to share further information with
you. Any approach and subsequent dialogue will of course be treated 100%
confidentially by me.

 

My contact details are:

 

Phone:+44 845 605 1785

Email:   ch...@bigpondsolutions.com 

My company's website is www.bigpondsolutions.com 

 

If you are still reading at this stage, thank you for your time and I hope
to hear from you soon.

 

Yours faithfully,

 

Chris

Chris Bower

Director - Executive Search 

 

Tel:  +44 (0) 845 605 1785 (DD)

FAX: +44 (0) 845 605 1781 

Skype: 'chrisbower'

Email:   ch...@bigpondsolutions.com 

Web: www.bigpondsolutions.com 

 

Description: Description: cid:image001.jpg@01C8956D.D869B7C0

 

Big Pond Solutions is a leading Search & Selection Consultancy within the
Wireless and Consumer Technology marketplace covering Europe, North America
and the Asia-Pacific region. Since 2001 we have delivered tailored
recruitment solutions across both Commercial and Technical disciplines,
partnering with innovative companies from emerging and rapid-growth
start-ups to established multi-nationals.

  _  

Big Pond Solutions  operate both as an employment business and an employment
agency. All personal details received by the Company in relation to the
conduct of these businesses are treated as strictly private and
confidential. Personal data regarding qualifications, work experience and
history is supplied, as necessary, to clients for temporary or permanent
placements, and generally as provided in the Company's registration under
the Data Protection Act. All personal data supplied to the Company will be
dealt with fairly and in accordance with the requirements of the Data
Protection Act.  

 

 

 

<>___
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

[Bill Spitzak]

Pekka Paalanen wrote:


You cannot get an identity by multiplying real-valued transformations
together, other than by accident.


This is why I propose sending the inverse of the matrix, so the identity 
can be checked accurately. It also happens that the inverse matrix is 
the same matrix that is needed to tell cairo to draw the image correctly.


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 0/2] Support for high DPI outputs via scaling

[Bill Spitzak]

John Kåre Alsaker wrote:


I expect a compositor to render deviations of the desired scaling
factor without scaling windows. The range when this is allowed is
reported to clients so they can try to render at a size which will
avoid scaling.

For example a compositor may want to use a 1-1.2 range with 1.1 as
the desired scaling factor. A clients which are only able to draw at
integer scaling factor would round that up to 2 and let the
compositor downscale it. When the range for which compositor won't
scale is send to clients we can avoid this.


I don't think a range is necessary. The client can just claim that it's 
window is scaled at 1.1 even though it drew it at 1. Or at 2.2 even 
though it drew it at 2. Nothing stops the client from doing this so you 
might as well make that the way integer scales are done.


With the range, what happens to a surface with a scale of 1.3? Is it 
scaled by 1.3? Or should it be 1.3/1.2 times larger than the one scaled 
at 1.2, which is actually 1.191666? For this reason I think any scale 
wanted by the client should be obeyed literally.



We may also allow scaling factors below 1.


I think scaling factors less than 1 are going to be a requirement. 
Otherwise the "units" have to be for the lowest-resolution device, which 
seems silly if you have a huge hi-res screen and a small lcd low-res 
display on your keyboard.


___
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

[Bill Spitzak]

John Kåre Alsaker wrote:


The size of a window should always be in pixels at the protocol level.


Note that this is in direct contradiction to the proposed scaler api. In 
it the size of the window is in transformed pixels.


I think now the scaler proposal should be changed.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Gamepad focus model (Re: Input and games.)

[Bill Spitzak]

Rick Yorgason wrote:


When you have multiplayer games, you just want to be able to launch the game
and have everybody automatically in it. You don't want your extra players to
have to think about focusing the app or anything like that.

That's the crux of the problem: how do you have one focus for multiple
players?


I feel the underlying function should be this:

1. The game can enumerate all the gamepads.

2. The game can "grab the focus" for any gamepads it wants.

Once it is grabbed, the pointer motion makes NO difference, removing a 
lot of the questions people are asking here. If the device was moving 
the pointer, it stops moving the pointer. If another device like a mouse 
moves the pointer, it continues to do so, but it does not matter if the 
mouse is moved outside the game and clicked elsewhere: the mouse works 
like normal sending clicks to that other client, and the gamepad events 
continue going to the game.


The only complexity is to prevent clients from grabbing the gamepad when 
they should not. For this the "grab the focus" does not work unless the 
shell allows it to.


As I see it the gamepad is "attached" to at most one "pointer". The 
gamepad can be grabbed if the client has that pointer's focus. The 
gamepad can also be "attached" to any number of other devices. It can 
also be grabbed if the event that triggered the grab request is a 
focus-in or event for a related device (this is so keyboard keys can 
cause a gamepad grab).


Specifying this attachement is where the seat and hierarchy comes in.

I very much agree that the seat==user idea is best. Otherwise it seems 
like seats are pretty useless, and users would have to be added to 
wayland anyway, making it more complex for no good reason. To get the 
"one seat per gamepad but they all share the same pointer" the 
parent-seat proposal seems like as easy fit. I am having a hard time 
coming up with a plausible setup that this would not cover. Grabbing a 
gamepad does not change this parenting in any way.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2] text: Respawn input method process if it exits

[Kristian Høgsberg]

On Tue, May 14, 2013 at 01:09:31PM -0300, Eduardo Lima (Etrunko) wrote:
> From: "Eduardo Lima (Etrunko)" 
> 
> Just the same as it is done in shell.c, if the input method process exits
> for any reason, we relaunch it automatically, as it is not possible to
> launch a standalone application outside of the weston process.
> 
> In v2:
>  - Proper error message when giving up.

That looks good, thanks Eduardo.

Kristian

> Signed-off-by: Eduardo Lima (Etrunko) 
> ---
>  src/text-backend.c | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/src/text-backend.c b/src/text-backend.c
> index d7ce31c..5be4a67 100644
> --- a/src/text-backend.c
> +++ b/src/text-backend.c
> @@ -23,6 +23,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #include "compositor.h"
>  #include "text-server-protocol.h"
> @@ -91,6 +92,9 @@ struct text_backend {
>   struct wl_resource *binding;
>   struct weston_process process;
>   struct wl_client *client;
> +
> + unsigned deathcount;
> + uint32_t deathstamp;
>   } input_method;
>  
>   struct wl_listener seat_created_listener;
> @@ -819,14 +823,33 @@ input_method_init_seat(struct weston_seat *seat)
>   seat->input_method->focus_listener_initialized = 1;
>  }
>  
> +static void launch_input_method(struct text_backend *text_backend);
> +
>  static void
>  handle_input_method_sigchld(struct weston_process *process, int status)
>  {
> + uint32_t time;
>   struct text_backend *text_backend =
>   container_of(process, struct text_backend, 
> input_method.process);
>  
>   text_backend->input_method.process.pid = 0;
>   text_backend->input_method.client = NULL;
> +
> + /* if input_method dies more than 5 times in 10 seconds, give up */
> + time = weston_compositor_get_time();
> + if (time - text_backend->input_method.deathstamp > 1) {
> + text_backend->input_method.deathstamp = time;
> + text_backend->input_method.deathcount = 0;
> + }
> +
> + text_backend->input_method.deathcount++;
> + if (text_backend->input_method.deathcount > 5) {
> + weston_log("input_method died, giving up.\n");
> + return;
> + }
> +
> + weston_log("input_method died, respawning...\n");
> + launch_input_method(text_backend);
>  }
>  
>  static void
> -- 
> 1.8.1.4
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] config-parser: Honor the XDG_CONFIG_DIRS environment variable

[Othman, Ossama]

Hi Kristian,

I've attached the patch since the patch I sent through git send-mail was
sent through an e-mail account that isn't subscribed to this list (waiting
for moderator approval), and to make sure the spacing isn't munged again.
 This patch was generated against weston master as of this morning.

Sorry for the churn.
-Ossama



On Tue, May 14, 2013 at 7:05 AM, Kristian Høgsberg wrote:

> On Mon, May 13, 2013 at 11:41 PM, Othman, Ossama
>  wrote:
> > Hi Kristian,
> >
> >> I think it's good to go - however, inlining the patch messed up the
> >> whitespace.  Ideally, send patches using git send-email, which can be
> >> configured to use smtp servers, and you can pass --annotate if you
> >> want to add a message or comment to the patch (put it after the ---
> >> that indicates the end of the commit message).  Or as a last resort,
> >> attach the patch.
> >
> >
> > I forgot to attach the patch this last time around.  Sorry about that.
>  I'll
> > just resend the patch with git send-email, as you suggest.
> >
> >>
> >> As for the next thing, good catch.  I'd do something like
> >>
> >> for (p = config_dirs; p != NULL; p = next) {
> >> next = strchrnul(p, ':');
> >> if (*next == ':')
> >> next++;
> >>
> >> ...
> >>
> >> to keep the for (...) more readable.
> >
> >
> > Changing the loop termination to "p != NULL" causes an infinite loop
> since
> > strchnul() returns a pointer to the null character '\0', not the NULL
>
> Yeah, sorry for the confusion, for a second while writing the email I
> was thinking that we could just use strchr instead and test for p !=
> NULL, but that doesn't work for getting the end of the last path
> element.
>
> > pointer.  Also, the moving the next pointer past the colon must be done
> > after path construction, other the colon ends up at the end of the path.
> > How's this instead:
> >
> > for (p = config_dirs; *p != '\0'; p = next) {
> > next = strchrnul(p, ':');
> > snprintf(path, sizeof path,
> > "%.*s/weston/%s", (int)(next - p), p, name);
> > fd = open(path, O_RDONLY | O_CLOEXEC);
> > if (fd >= 0)
> > return fd;
> >
> > if (*next == ':')
> > next++;
> > }
> >
> > Note that I also had to cast "next - p" in the snprintf() call to int
> since
> > the format specifier "%*.s" wants an int but the pointer difference on
> my 64
> > bit Ubuntu box is a long int, at least according to the format specifier
> > warning I get:
> >
> > foo.c: In function ‘open_config_file’:
> > foo.c:53:5: warning: field precision specifier ‘.*’ expects argument of
> type
> > ‘int’, but argument 4 has type ‘long int’ [-Wformat]
> >
> > foo.c in this case is a simple test program I wrote.  I assume the cast
> is
> > safe since "next - p" should always fall within the range of type int.
> >
> > Anyway, I'll resend the patch with the above changes with git send-email.
>
> Yup, that all sounds good.
>
> thanks,
> Kristian
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>


0001-config-parser-Honor-XDG_CONFIG_DIRS.patch
Description: Binary data
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Gamepad focus model (Re: Input and games.)

[Jason Ekstrand]

On Tue, May 14, 2013 at 10:18 AM, Daniel Stone  wrote:

> Hi,
>
> On 14 May 2013 05:49, Rick Yorgason  wrote:
> > Okay, so the most common configuration would be one seat with a mouse,
> > keyboard, and gamepad. If you only ever play single player games, this is
> > all you would see.
> >
> > When you have multiplayer games, you just want to be able to launch the
> game
> > and have everybody automatically in it. You don't want your extra
> players to
> > have to think about focusing the app or anything like that.
>
> Yes, 100%.
>
> > That's the crux of the problem: how do you have one focus for multiple
> > players? The many-gamepads-per-seat model solves this, but it has a
> couple
> > problems:
> >
> > 1) Some compositors may put every gamepad in one seat, and some
> compositors
> > may assign one gamepad per seat. The game programmer has to support both
> > code paths. And unfortunately, when game programmers inevitably neglect
> to
> > do that, the gamers are going to blame the compositors rather than the
> > games. Wayland will get a reputation as a display server where you have
> to
> > configure your gamepads differently for different games.
>
> Compositors can implement maximise badly too, or multi-display
> support.  But it's not an argument to push the complexity out.  It's
> an argument for not running broken compositors.
>
> > 2) Gamepads aren't the only scenario where you want to have one focus for
> > multiple players.
> >
> > Here's a couple scenarios that are complicated by breaking the seat ==
> user
> > model:
>
> It's not seat == user, it's seat == focus.
>
> > A) You're playing split-screen Halo. Two users have a mouse/keyboard, and
> > two users have gamepads.
> >
> > In the seat == user world, we know how this is set up: seat 1 has a
> > mouse/keyboard, seat 2 has a mouse/keyboard, seat 3 has a gamepad, and
> seat
> > 4 has a gamepad.
>
> We know how it's set up, but we don't know how it works.  How does the
> compositor know to focus 3 and 4 at Halo, rather than at the browser
> or whatever else is running at the time? You can't have the keyboard
> and mouse tell you, because they're different seats.  So it's just
> manual then? Or the compositor making random guesses?
>
> > In the many-gamepads-per-seat model, I don't know how to set this up. The
> > first two players would have to have their own seats, but since the
> player
> > ID is in the gamepad, where do we get their player numbers from? And what
> > about players 3 and 4? Where do their gamepads go? They can go in seat 1,
> > but then how do you distinguish player 1 from players 3 and 4? And why
> does
> > player 2 have to manually focus the game?
>
> The gamepads go to whichever seat it is that's directing their focus.
> If their focus is entirely manually set, then they go in their own
> seat.  Simple, no? Or am I totally missing something, and do gamepads
> under Wayland typically not follow keyboard/mouse focii? (I don't mean
> in really contrived theoretical cases, I mean in the overwhelming
> majority of situations.)
>
> > (I don't believe this scenario is inherently exotic. Lemmings, Settlers,
> and
> > Hired Guns all did this back in the DOS and Amiga days, before OSs made
> it
> > harder to distinguish mice from each other.)
>
> Yes, that's the tradeoff you get for multitasking, and having the OS
> know where your mice are, rather than having to tell every single game
> where every single mouse is.
>
> > B) Imagine that, with the current trend of adding touchpads to gamepads,
> > Fruit Ninja releases a multi-player version. All players play on the same
> > "field", but it tracks their scores independently; whomever slashes the
> > fruit first gets the points. Let's imagine we have player 1 with a
> separate
> > touchpad, and players 2 and 3 with gamepads that have touchpads built in.
> >
> > In the seat == user model, it's obvious how this should be set up: seat 1
> > gets a touchpad, seat 2 gets a gamepad with the associated touchpad, and
> so
> > does seat 3.
> >
> > In the many-gamepads-per-seat model, the question rises again of where
> you
> > put the gamepads. Do they go in the same seat as the touchpad they're
> > attached to? Or do they all end up in seat 1? If they're all in seat 1,
> does
> > the player indicator on their controller match up with their actual
> player
> > number? And again, they all have to individually focus the game.
>
> Again, how does the focus get changed? Where are the gamepads deriving
> their focus from? Put them in that seat, and add a wl_touch object for
> every gamepad.
>
> >> If the focus can be changed independently, how does this happen?
> >
> > Focus can only be changed independently for "collaborative" seats.
> > "Collaborative mode" means "I want to interact with the desktop
> > independently." When collaborative mode is turned off, your focus is
> derived
> > from a seat which *is* in collaborative mode.
>
> OK, so what's the downside from having the gamepad embedded insi

[PATCH v2] text: Respawn input method process if it exits

[Eduardo Lima (Etrunko)]

From: "Eduardo Lima (Etrunko)" 

Just the same as it is done in shell.c, if the input method process exits
for any reason, we relaunch it automatically, as it is not possible to
launch a standalone application outside of the weston process.

In v2:
 - Proper error message when giving up.

Signed-off-by: Eduardo Lima (Etrunko) 
---
 src/text-backend.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/src/text-backend.c b/src/text-backend.c
index d7ce31c..5be4a67 100644
--- a/src/text-backend.c
+++ b/src/text-backend.c
@@ -23,6 +23,7 @@
 
 #include 
 #include 
+#include 
 
 #include "compositor.h"
 #include "text-server-protocol.h"
@@ -91,6 +92,9 @@ struct text_backend {
struct wl_resource *binding;
struct weston_process process;
struct wl_client *client;
+
+   unsigned deathcount;
+   uint32_t deathstamp;
} input_method;
 
struct wl_listener seat_created_listener;
@@ -819,14 +823,33 @@ input_method_init_seat(struct weston_seat *seat)
seat->input_method->focus_listener_initialized = 1;
 }
 
+static void launch_input_method(struct text_backend *text_backend);
+
 static void
 handle_input_method_sigchld(struct weston_process *process, int status)
 {
+   uint32_t time;
struct text_backend *text_backend =
container_of(process, struct text_backend, 
input_method.process);
 
text_backend->input_method.process.pid = 0;
text_backend->input_method.client = NULL;
+
+   /* if input_method dies more than 5 times in 10 seconds, give up */
+   time = weston_compositor_get_time();
+   if (time - text_backend->input_method.deathstamp > 1) {
+   text_backend->input_method.deathstamp = time;
+   text_backend->input_method.deathcount = 0;
+   }
+
+   text_backend->input_method.deathcount++;
+   if (text_backend->input_method.deathcount > 5) {
+   weston_log("input_method died, giving up.\n");
+   return;
+   }
+
+   weston_log("input_method died, respawning...\n");
+   launch_input_method(text_backend);
 }
 
 static void
-- 
1.8.1.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] text: Respawn input method process if it exits

[Eduardo Lima (Etrunko)]

On 05/14/2013 12:47 PM, Michael Hasselmann wrote:
> On Tue, 2013-05-14 at 12:16 -0300, Eduardo Lima (Etrunko) wrote:
>> +static void launch_input_method(struct text_backend *text_backend);
>> +
>>  static void
>>  handle_input_method_sigchld(struct weston_process *process, int status)
>>  {
>> +uint32_t time;
>>  struct text_backend *text_backend =
>>  container_of(process, struct text_backend, 
>> input_method.process);
>>  
>>  text_backend->input_method.process.pid = 0;
>>  text_backend->input_method.client = NULL;
>> +
>> +/* if input_method dies more than 5 times in 10 seconds, give up */
>> +time = weston_compositor_get_time();
>> +if (time - text_backend->input_method.deathstamp > 1) {
>> +text_backend->input_method.deathstamp = time;
>> +text_backend->input_method.deathcount = 0;
>> +}
>> +
>> +text_backend->input_method.deathcount++;
>> +if (text_backend->input_method.deathcount > 5) {
>> +weston_log("weston-desktop-shell died, giving up.\n");
> 
> Wrong log message, should be "input_method died, giving up.\n"
>  

Ah the wonders of copy and paste, thanks for the spot. :) I am sending
the patch with the proper message again.

>> +return;
>> +}
>> +
>> +weston_log("input_method died, respawning...\n");
>> +launch_input_method(text_backend);
> 
> I am not smart enough to figure out whether this could be abused to
> launch a (possibly untrusted) 3rd party input method at runtime, say by
> manipulating some cached config and then triggering a crash in the input
> method.
> 

Yes, this is something that should concern not only the input method,
but also other plugins, such as the desktop shell itself.

Regards, Etrunko

-- 
Eduardo de Barros Lima (Etrunko)
Software Engineer, Open Source Technology Center
Intel Corporation
São Paulo, Brazil
eduardo.l...@linux.intel.com
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 0/2] Support for high DPI outputs via scaling

[John Kåre Alsaker]

On Tue, May 14, 2013 at 5:49 PM, Alexander Larsson  wrote:

> On tis, 2013-05-14 at 17:00 +0200, John Kåre Alsaker wrote:
>
>
> > Obviously they are defined as such right now, since there is
> > no scaling.
> >  But, the patch I proposed changes this,
> >
> > because otherwise we can't
> > cleanly handle backwards compatibility (and also it makes
> > sense).
> > Backwards compatibility with what?
>
> With existing wayland clients that don't do sbupixel accuracy. Did you
> ever try a current wayland app on a 240 dpi display?
>
I thought you were referring to something else since there's still won't be
any scaling from buffer to surface coordinates in the legacy client case.


> > How would you handle subsurfaces with different scaling factors? What
> > coordinates would the subsurface's position be in?
>
> All positions are in the global compositor coordinate space. The one
> that e.g. different outputs are positioned in, etc.
>
That won't work. Currently a subsurface's position is relative to the
parent surface in the parent's surface coordinates.


> > We can't have the configure event say 2000x2000, because then
> > old
> > clients will not be auto-upscaled as we want.
> > In this case our proposals differs. The compositor knows it's not
> > resizing the window so it simply passes 2000x2000 along to the
> > configure arguments.
>
> How can the compositor know its not resizing the window? Only the app
> knows if it can render at a different scaling factor, as it is the app
> that allocates and draws to the buffer.
>
The compositor knows if it's drawing pixels at a 1:1 rate or if it's doing
resizing.


> Anyway, its pretty obvious that you're talking about a different design.
> I'm growing tired of this discussion, I will just shut up and implement
> my design in weston. If you want to implement a competing desing, feel
> free.
>
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] text: Respawn input method process if it exits

[Michael Hasselmann]

On Tue, 2013-05-14 at 12:16 -0300, Eduardo Lima (Etrunko) wrote:
> +static void launch_input_method(struct text_backend *text_backend);
> +
>  static void
>  handle_input_method_sigchld(struct weston_process *process, int status)
>  {
> + uint32_t time;
>   struct text_backend *text_backend =
>   container_of(process, struct text_backend, 
> input_method.process);
>  
>   text_backend->input_method.process.pid = 0;
>   text_backend->input_method.client = NULL;
> +
> + /* if input_method dies more than 5 times in 10 seconds, give up */
> + time = weston_compositor_get_time();
> + if (time - text_backend->input_method.deathstamp > 1) {
> + text_backend->input_method.deathstamp = time;
> + text_backend->input_method.deathcount = 0;
> + }
> +
> + text_backend->input_method.deathcount++;
> + if (text_backend->input_method.deathcount > 5) {
> + weston_log("weston-desktop-shell died, giving up.\n");

Wrong log message, should be "input_method died, giving up.\n"

> + return;
> + }
> +
> + weston_log("input_method died, respawning...\n");
> + launch_input_method(text_backend);

I am not smart enough to figure out whether this could be abused to
launch a (possibly untrusted) 3rd party input method at runtime, say by
manipulating some cached config and then triggering a crash in the input
method.

ciao Michael

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 0/2] Support for high DPI outputs via scaling

[Alexander Larsson]

On tis, 2013-05-14 at 17:00 +0200, John Kåre Alsaker wrote:


> Obviously they are defined as such right now, since there is
> no scaling.
>  But, the patch I proposed changes this,
>  
> because otherwise we can't
> cleanly handle backwards compatibility (and also it makes
> sense).
> Backwards compatibility with what?

With existing wayland clients that don't do sbupixel accuracy. Did you
ever try a current wayland app on a 240 dpi display?

> How would you handle subsurfaces with different scaling factors? What
> coordinates would the subsurface's position be in?

All positions are in the global compositor coordinate space. The one
that e.g. different outputs are positioned in, etc.

> We can't have the configure event say 2000x2000, because then
> old
> clients will not be auto-upscaled as we want.
> In this case our proposals differs. The compositor knows it's not
> resizing the window so it simply passes 2000x2000 along to the
> configure arguments.

How can the compositor know its not resizing the window? Only the app
knows if it can render at a different scaling factor, as it is the app
that allocates and draws to the buffer.

Anyway, its pretty obvious that you're talking about a different design.
I'm growing tired of this discussion, I will just shut up and implement
my design in weston. If you want to implement a competing desing, feel
free.


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Gamepad focus model (Re: Input and games.)

[Daniel Stone]

Hi,

On 14 May 2013 05:49, Rick Yorgason  wrote:
> Okay, so the most common configuration would be one seat with a mouse,
> keyboard, and gamepad. If you only ever play single player games, this is
> all you would see.
>
> When you have multiplayer games, you just want to be able to launch the game
> and have everybody automatically in it. You don't want your extra players to
> have to think about focusing the app or anything like that.

Yes, 100%.

> That's the crux of the problem: how do you have one focus for multiple
> players? The many-gamepads-per-seat model solves this, but it has a couple
> problems:
>
> 1) Some compositors may put every gamepad in one seat, and some compositors
> may assign one gamepad per seat. The game programmer has to support both
> code paths. And unfortunately, when game programmers inevitably neglect to
> do that, the gamers are going to blame the compositors rather than the
> games. Wayland will get a reputation as a display server where you have to
> configure your gamepads differently for different games.

Compositors can implement maximise badly too, or multi-display
support.  But it's not an argument to push the complexity out.  It's
an argument for not running broken compositors.

> 2) Gamepads aren't the only scenario where you want to have one focus for
> multiple players.
>
> Here's a couple scenarios that are complicated by breaking the seat == user
> model:

It's not seat == user, it's seat == focus.

> A) You're playing split-screen Halo. Two users have a mouse/keyboard, and
> two users have gamepads.
>
> In the seat == user world, we know how this is set up: seat 1 has a
> mouse/keyboard, seat 2 has a mouse/keyboard, seat 3 has a gamepad, and seat
> 4 has a gamepad.

We know how it's set up, but we don't know how it works.  How does the
compositor know to focus 3 and 4 at Halo, rather than at the browser
or whatever else is running at the time? You can't have the keyboard
and mouse tell you, because they're different seats.  So it's just
manual then? Or the compositor making random guesses?

> In the many-gamepads-per-seat model, I don't know how to set this up. The
> first two players would have to have their own seats, but since the player
> ID is in the gamepad, where do we get their player numbers from? And what
> about players 3 and 4? Where do their gamepads go? They can go in seat 1,
> but then how do you distinguish player 1 from players 3 and 4? And why does
> player 2 have to manually focus the game?

The gamepads go to whichever seat it is that's directing their focus.
If their focus is entirely manually set, then they go in their own
seat.  Simple, no? Or am I totally missing something, and do gamepads
under Wayland typically not follow keyboard/mouse focii? (I don't mean
in really contrived theoretical cases, I mean in the overwhelming
majority of situations.)

> (I don't believe this scenario is inherently exotic. Lemmings, Settlers, and
> Hired Guns all did this back in the DOS and Amiga days, before OSs made it
> harder to distinguish mice from each other.)

Yes, that's the tradeoff you get for multitasking, and having the OS
know where your mice are, rather than having to tell every single game
where every single mouse is.

> B) Imagine that, with the current trend of adding touchpads to gamepads,
> Fruit Ninja releases a multi-player version. All players play on the same
> "field", but it tracks their scores independently; whomever slashes the
> fruit first gets the points. Let's imagine we have player 1 with a separate
> touchpad, and players 2 and 3 with gamepads that have touchpads built in.
>
> In the seat == user model, it's obvious how this should be set up: seat 1
> gets a touchpad, seat 2 gets a gamepad with the associated touchpad, and so
> does seat 3.
>
> In the many-gamepads-per-seat model, the question rises again of where you
> put the gamepads. Do they go in the same seat as the touchpad they're
> attached to? Or do they all end up in seat 1? If they're all in seat 1, does
> the player indicator on their controller match up with their actual player
> number? And again, they all have to individually focus the game.

Again, how does the focus get changed? Where are the gamepads deriving
their focus from? Put them in that seat, and add a wl_touch object for
every gamepad.

>> If the focus can be changed independently, how does this happen?
>
> Focus can only be changed independently for "collaborative" seats.
> "Collaborative mode" means "I want to interact with the desktop
> independently." When collaborative mode is turned off, your focus is derived
> from a seat which *is* in collaborative mode.

OK, so what's the downside from having the gamepad embedded inside the
seat it derives its focus from?

>> If
>> the keyboard/pointer seat switches focus to another game, do both
>> seats switch, or does the other stay behind?
>
> Assuming seat 2 is following seat 1, they both switch.
>
>> If both switch - why are
>> we complicating the

[PATCH] text: Respawn input method process if it exits

[Eduardo Lima (Etrunko)]

From: "Eduardo Lima (Etrunko)" 

Just the same as it is done in shell.c, if the input method process exits
for any reason, we relaunch it automatically, as it is not possible to
launch a standalone application outside of the weston process.

Signed-off-by: Eduardo Lima (Etrunko) 
---
 src/text-backend.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/src/text-backend.c b/src/text-backend.c
index d7ce31c..52c0814 100644
--- a/src/text-backend.c
+++ b/src/text-backend.c
@@ -23,6 +23,7 @@
 
 #include 
 #include 
+#include 
 
 #include "compositor.h"
 #include "text-server-protocol.h"
@@ -91,6 +92,9 @@ struct text_backend {
struct wl_resource *binding;
struct weston_process process;
struct wl_client *client;
+
+   unsigned deathcount;
+   uint32_t deathstamp;
} input_method;
 
struct wl_listener seat_created_listener;
@@ -819,14 +823,33 @@ input_method_init_seat(struct weston_seat *seat)
seat->input_method->focus_listener_initialized = 1;
 }
 
+static void launch_input_method(struct text_backend *text_backend);
+
 static void
 handle_input_method_sigchld(struct weston_process *process, int status)
 {
+   uint32_t time;
struct text_backend *text_backend =
container_of(process, struct text_backend, 
input_method.process);
 
text_backend->input_method.process.pid = 0;
text_backend->input_method.client = NULL;
+
+   /* if input_method dies more than 5 times in 10 seconds, give up */
+   time = weston_compositor_get_time();
+   if (time - text_backend->input_method.deathstamp > 1) {
+   text_backend->input_method.deathstamp = time;
+   text_backend->input_method.deathcount = 0;
+   }
+
+   text_backend->input_method.deathcount++;
+   if (text_backend->input_method.deathcount > 5) {
+   weston_log("weston-desktop-shell died, giving up.\n");
+   return;
+   }
+
+   weston_log("input_method died, respawning...\n");
+   launch_input_method(text_backend);
 }
 
 static void
-- 
1.8.1.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 0/2] Support for high DPI outputs via scaling

[John Kåre Alsaker]

On Tue, May 14, 2013 at 3:19 PM, Alexander Larsson  wrote:

> On tis, 2013-05-14 at 13:19 +0200, John Kåre Alsaker wrote:
> > On Tue, May 14, 2013 at 11:25 AM, Alexander Larsson
> > 
> >
> > I don't think it should really be allowed to not apply the
> > scaling.
> > Users may want to disable scaling as it's not very good looking. I
> > don't think we should enforce a policy about that.
>
> What do you mean? Scaling is done by the compositor. The user is who
> tells the compositor to use scaling (by setting a scale on the
> wl_outputs), just like he sets the resolution.
>
I might have been unclear. Users may want to disable resizing of buffer
pixels in the compositor. However clients which able to draw at the correct
scaling factor should still do so and appear pixel perfect.


> > Right now buffer sizes define surface sizes, and that makes
> > surface
> >  sizes not really well defined.
> > They're defined as the same as buffer sizes (ignoring the trivial
> > transformations). They should still be the same if the scaling factor
> > is not 1.0. Clients should scale both buffers and surfaces. The only
> > thing that should decouple these sizes more are the scaling extension.
>
> Obviously they are defined as such right now, since there is no scaling.
>  But, the patch I proposed changes this,



> because otherwise we can't
> cleanly handle backwards compatibility (and also it makes sense).
>
Backwards compatibility with what?

How would you handle subsurfaces with different scaling factors? What
coordinates would the subsurface's position be in?


> In the canonical example of 2x scaling you have some lcd panel at say
> 2000x2000, and we want naive apps to be automatically upscaled as if it
> was a 1000x1000 monitor. If a window in the naive app is maximized this
> means it must get a configure reply from maximize that says 1000x1000,
> which cause it to attach a buffer of 1000x1000 (with scale factor 1) to
> it. This is how existing wayland clients work.
>
In my proposal the compositor will scale down configure arguments by the
same amount it resizes the window up.


> Now, a non-naive client will get the same maximize reply of 1000x1000,
> but in this case we want it to create a buffer of 2000x2000 (with scale
> 2) since it knows the window is on a high-dpi monitor. So, there is a
> natural separation of the surface size (1000x1000) and the buffer size
> (2000x2000).
>
> We can't have the configure event say 2000x2000, because then old
> clients will not be auto-upscaled as we want.
>
In this case our proposals differs. The compositor knows it's not resizing
the window so it simply passes 2000x2000 along to the configure arguments.

It's also worth considering the edge cases when pixels doesn't scale down
so easily. Say we have a workspace of 2000x1901 and we have a scaling
factor of 2 and we want to maximize the client.
With a scale factor unaware legacy client we'd have to send 1000x950.5
which would have to be rounded to 1000x951. We could compensate by cropping
or stretching to fill the workspace.
With a client using a scaling factor of 2 I'd send 2000x1901 which the
client might be able to fill exactly or it might just pretend it's
2000x1902 and crop the result. In your proposal this would still have to be
rounded to 1000x951 and clients able to fill 2000x1901 exactly would render
at 2000x1902 instead.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Gamepad focus model (Re: Input and games.)

[Daniel Stone]

(Still digesting the rest of the thread.)

On 14 May 2013 08:11, Peter Hutterer  wrote:
> the other thing that made me thing about your approach:
> with the gamepad_manager, you've got an extra layer in the tree for gamepads
> that pointers/keyboards don't have. that's not a bad thing and focus
> handling is easier this way, but now you could also look at pointers and
> keyboards and see if that extra layer is useful for those two. And I think
> it would be - e.g. wacom devices share their focus with the pointer, but
> also have their device-specific stuff that clients may need.

The reason that's there is because Wayland is heavily object-driven.
Rather than firing out event selections, you mostly register for
events by binding to interfaces which send them.  So, you need
wl_gamepad_manager to support more than one gamepad per seat; you
could have the seat send out new gamepad events directly, but then you
don't have any way to unregister for those events - so we use
wl_gamepad_manager, and when it's destroyed, you don't get new events
from it.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Add a colord implementation of a CMS plugin for weston

[Kristian Høgsberg]

On Sat, May 11, 2013 at 09:48:22AM +0100, Richard Hughes wrote:
> This allows users to change the assigned display profile in GNOME (using
> gnome-control-center) or KDE (using colord-kde) and also allows the profiling
> tools to correctly inhibit the calibration state whilst measuring the native
> screen response.
> ---
>  configure.ac |  10 +
>  src/Makefile.am  |  11 ++
>  src/cms-colord.c | 550 
> +++
>  weston.ini   |   2 +-
>  4 files changed, 572 insertions(+), 1 deletion(-)
>  create mode 100644 src/cms-colord.c

Looks good, committed.  Only briefly reviewed this time, but the
interaction with core weston looks good and we don't even have to
touch the core API.

Kristian

> diff --git a/configure.ac b/configure.ac
> index b71038d..109afee 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -277,6 +277,16 @@ AC_ARG_ENABLE(tablet-shell,
>  AM_CONDITIONAL(ENABLE_TABLET_SHELL,
>  test "x$enable_tablet_shell" = "xyes")
>  
> +# CMS modules
> +AC_ARG_ENABLE(colord,
> +  AS_HELP_STRING([--disable-colord],
> + [do not build colord CMS support]),,
> +   enable_colord=yes)
> +AM_CONDITIONAL(ENABLE_COLORD,
> +test "x$enable_colord" = "xyes")
> +if test x$enable_colord = xyes; then
> +  PKG_CHECK_MODULES(COLORD, colord >= 0.1.8)
> +fi
>  
>  AC_ARG_ENABLE(wcap-tools, [  --disable-wcap-tools],, enable_wcap_tools=yes)
>  AM_CONDITIONAL(BUILD_WCAP_TOOLS, test x$enable_wcap_tools = xyes)
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 92d9e38..2d71e48 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -95,6 +95,7 @@ module_LTLIBRARIES =\
>   $(desktop_shell)\
>   $(tablet_shell) \
>   $(cms_static)   \
> + $(cms_colord)   \
>   $(x11_backend)  \
>   $(drm_backend)  \
>   $(wayland_backend)  \
> @@ -261,6 +262,16 @@ cms_static_la_SOURCES =  \
>   cms-static.c\
>   cms-helper.c\
>   cms-helper.h
> +if ENABLE_COLORD
> +cms_colord = cms-colord.la
> +cms_colord_la_LDFLAGS = -module -avoid-version
> +cms_colord_la_LIBADD = $(COMPOSITOR_LIBS) $(COLORD_LIBS)
> +cms_colord_la_CFLAGS = $(GCC_CFLAGS) $(COMPOSITOR_CFLAGS) $(COLORD_CFLAGS)
> +cms_colord_la_SOURCES =  \
> + cms-colord.c\
> + cms-helper.c\
> + cms-helper.h
> +endif
>  endif
>  
>  BUILT_SOURCES =  \
> diff --git a/src/cms-colord.c b/src/cms-colord.c
> new file mode 100644
> index 000..33f23b2
> --- /dev/null
> +++ b/src/cms-colord.c
> @@ -0,0 +1,550 @@
> +/*
> + * Copyright © 2013 Richard Hughes
> + *
> + * Permission to use, copy, modify, distribute, and sell this software and
> + * its documentation for any purpose is hereby granted without fee, provided
> + * that the above copyright notice appear in all copies and that both that
> + * copyright notice and this permission notice appear in supporting
> + * documentation, and that the name of the copyright holders not be used in
> + * advertising or publicity pertaining to distribution of the software
> + * without specific, written prior permission.  The copyright holders make
> + * no representations about the suitability of this software for any
> + * purpose.  It is provided "as is" without express or implied warranty.
> + *
> + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
> + * SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
> + * FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
> + * SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
> + * RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
> + * CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
> + * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include 
> +#endif
> +
> +#define _GNU_SOURCE
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "compositor.h"
> +#include "cms-helper.h"
> +
> +struct cms_colord {
> + struct weston_compositor*ec;
> + CdClient*client;
> + GHashTable  *devices; /* key = device-id, value = 
> cms_output */
> + GHashTable  *pnp_ids; /* key = pnp-id, value = 
> vendor */
> + gchar   *pnp_ids_data;
> + GMainLoop   *loop;
> + GThread *thread;
> + GList   *pending;
> + GMutex   pending_mutex;
> + struct wl_event_sourc

Re: [PATCH weston] move subsurface-server-protocol.h include out of compositor.h

[Kristian Høgsberg]

On Mon, May 13, 2013 at 03:55:47PM -0700, U. Artie Eoff wrote:
> From: "U. Artie Eoff" 
> 
> The subsurface-server-protocol.h header should not be included
> by any headers that are part of the SDK since it is not exported.
> Otherwise, SDK consumers will break during compilation.
> 
> Move this include from compositor.h to compositor.c.
> 
> Fixes https://bugs.freedesktop.org/show_bug.cgi?id=64537

Thanks Artie, that's good.

Kristian

> Signed-off-by: U. Artie Eoff 
> ---
>  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 
>  #include "compositor.h"
> +#include "subsurface-server-protocol.h"
>  #include "../shared/os-compatibility.h"
>  #include "git-version.h"
>  #include "version.h"
> diff --git a/src/compositor.h b/src/compositor.h
> index d7aa005..99468a1 100644
> --- a/src/compositor.h
> +++ b/src/compositor.h
> @@ -35,7 +35,6 @@ extern "C" {
>  #include "version.h"
>  #include "matrix.h"
>  #include "config-parser.h"
> -#include "subsurface-server-protocol.h"
>  
>  #define ARRAY_LENGTH(a) (sizeof (a) / sizeof (a)[0])
>  
> -- 
> 1.7.11.7
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] config-parser: Honor the XDG_CONFIG_DIRS environment variable

[Kristian Høgsberg]

On Mon, May 13, 2013 at 11:41 PM, Othman, Ossama
 wrote:
> Hi Kristian,
>
>> I think it's good to go - however, inlining the patch messed up the
>> whitespace.  Ideally, send patches using git send-email, which can be
>> configured to use smtp servers, and you can pass --annotate if you
>> want to add a message or comment to the patch (put it after the ---
>> that indicates the end of the commit message).  Or as a last resort,
>> attach the patch.
>
>
> I forgot to attach the patch this last time around.  Sorry about that.  I'll
> just resend the patch with git send-email, as you suggest.
>
>>
>> As for the next thing, good catch.  I'd do something like
>>
>> for (p = config_dirs; p != NULL; p = next) {
>> next = strchrnul(p, ':');
>> if (*next == ':')
>> next++;
>>
>> ...
>>
>> to keep the for (...) more readable.
>
>
> Changing the loop termination to "p != NULL" causes an infinite loop since
> strchnul() returns a pointer to the null character '\0', not the NULL

Yeah, sorry for the confusion, for a second while writing the email I
was thinking that we could just use strchr instead and test for p !=
NULL, but that doesn't work for getting the end of the last path
element.

> pointer.  Also, the moving the next pointer past the colon must be done
> after path construction, other the colon ends up at the end of the path.
> How's this instead:
>
> for (p = config_dirs; *p != '\0'; p = next) {
> next = strchrnul(p, ':');
> snprintf(path, sizeof path,
> "%.*s/weston/%s", (int)(next - p), p, name);
> fd = open(path, O_RDONLY | O_CLOEXEC);
> if (fd >= 0)
> return fd;
>
> if (*next == ':')
> next++;
> }
>
> Note that I also had to cast "next - p" in the snprintf() call to int since
> the format specifier "%*.s" wants an int but the pointer difference on my 64
> bit Ubuntu box is a long int, at least according to the format specifier
> warning I get:
>
> foo.c: In function ‘open_config_file’:
> foo.c:53:5: warning: field precision specifier ‘.*’ expects argument of type
> ‘int’, but argument 4 has type ‘long int’ [-Wformat]
>
> foo.c in this case is a simple test program I wrote.  I assume the cast is
> safe since "next - p" should always fall within the range of type int.
>
> Anyway, I'll resend the patch with the above changes with git send-email.

Yup, that all sounds good.

thanks,
Kristian
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] shell: Add a lock binding

[Kristian Høgsberg]

On Mon, May 13, 2013 at 11:49 PM, Bill Spitzak  wrote:
> Kristian Høgsberg wrote:
>
>> The problem then is that the key release of the binding will now count
>> as activity and undo the lock.  I think we'll need a custom grab (see
>> weston_compositor_run_key_binding()) that triggers the lock on release
>> of the last key in the binding.  Or maybe add a "virtual modifier",
>> say MODIFIER_RELEASE, to make the binding code trigger the binding on
>> release instead.
>
>
> Could you just have all release events not count as "activity"?

Hmm, maybe... they way it works now is that pressing and holding a key
(or button) inhibits the idle timer and when you then release we reset
it.  I think the expected behavior is that if you hold down a button
long enough for the idle time to expire, releasing the button doesn't
immediately trigger the screensaver.  That's arguably a corner case of
course, but I think that behavior is worth preserving.

Kristian
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: minimized and stick windows

[Kristian Høgsberg]

On Tue, May 14, 2013 at 2:30 AM, Pekka Paalanen  wrote:
> On Mon, 13 May 2013 17:26:28 -0500
> Jason Ekstrand  wrote:
>
>> On Mon, May 13, 2013 at 4:14 PM, Rafael Antognolli 
>> wrote:
>>
>> > Hi Jason,
>> >
>> > On Wed, May 8, 2013 at 9:26 PM, Jason Ekstrand 
>> > wrote:
>> > > Hi Rafael,
>> > >
>> > >
>> > > On Wed, May 8, 2013 at 6:04 PM, Rafael Antognolli 
>> > > wrote:
>> > >>
>> > >> Hello,
>> > >>
>> > >> I've been looking the Weston code relative to maximized windows, and
>> > >> it seems that the respective code for minimized windows wouldn't be
>> > >> hard to implement.
>> > >>
>> > >> The questions are: are there any plans to add it? Is there someone
>> > >> already working on it? If not, would it be OK if I start submitting
>> > >> patches to try to add support for this?
>> > >
>> > >
>> > > A month or two ago, Scott Morreau was working on it.  However, his work
>> > > never made into weston for a variety of reasons.  Personally, I'm glad to
>> > > see someone interested in working on it again because it's something that
>> > > wayland will need eventually.
>> > >
>> > > The place to start on it is probably with the following e-mail and the
>> > long
>> > > string of replies:
>> > >
>> > >
>> > http://lists.freedesktop.org/archives/wayland-devel/2013-March/007814.html
>> > >
>> > > There was quite a bit of discussion about how to handle it from a
>> > protocol
>> > > level, but Scott never made an actual version 2.  I'd suggest you start
>> > by
>> > > reading the chain of e-mails (it goes into April, not just March).  There
>> > > were quite a few suggestions in there that could be incorporated.
>> > > Hopefully, you can pick through the e-mail discussion and figure out what
>> > > the consensus was.  It'd be good to have a pair of fresh eyes look at it.
>> >
>> > Thanks for pointing that out. I just went through the chain of
>> > e-mails, but I don't think there was a consensus there.
>> >
>> > It also seems that the minimize implementation is a little more
>> > complex than just hiding surfaces and marking some flags. Which makes
>> > me not so comfortable doing an implementation without a consensus
>> > about what should be implemented, and with some orientation.
>> >
>> > That said, I'm not sure I'm really going to take this task.
>> >
>>
>> I didn't intend to scare you off.  Honestly, I don't know for 100% certain
>> how much weston machinery is needed to implement it.  It would require some
>> sort of set of flags to keep the compositor and shell plugin in sync.  That
>> said, I don't know if its quite as difficult as Scott made it sound.
>>
>> As far as direction goes, the first thing is to think through use-cases and
>> settle on a protocol.  Unfortunately, the discussion I linked you to seemed
>> to go nowhere.  However, a lot of that was Scott saying, "This is the way I
>> want to do it and I'm not going to change."  If you look at the other
>> comments, I think there was some consensus in there (at least in a general
>> direction).  Feel free to throw some XML together and we can re-start the
>> discussion.  For that matter, if you can come up with a way to do it as a
>> weston extension for now (with the hopes of putting it in wayland core
>> later), things can be a lot more flexible and we can play around with
>> protocol concepts as we go.
>>
>> Once a basic protocol is in place, then the client-side needs to be
>> implemented in tinytk (window.c) and the server-side needs to be
>> implemented in weston.
>>
>> I'm sorry "I want to add X feature" isn't simpler.  Basically every new
>> major protocol piece goes through a long mailing list discussion and a lot
>> of revision.
>
> Also worth noting, that there are actually two different pieces of
> protocol involved with minimized windows:
>
> - the public protocol, likely part of wl_shell_surface, which all
>   applications use to communicate with the server. This is the
>   important part that will go under strict review, but it is probably
>   also the simpler of the two. You could also check what DE
>   projects have done on this (Gnome/gtk, KDE/Qt, EFL, ...).
>
> - the private protocol between Weston and weston-desktop-shell
>   specifically. As we have chosen to let weston-desktop-shell client do
>   all the GUI drawing, and minimized windows will need some GUI (a task
>   bar button, a menu list of windows) to be able to get them back, we
>   need protocol to inform weston-desktop-shell about the windows so it
>   can draw the GUI.
>
> But these should not be complicated, once you understand how the basics
> of a Wayland protocol work. And you don't need to have any complex
> foreign surface passing protocol to get window thumbnails by hovering
> the pointer over a taskbar button. Thumbnails can be added later, as it
> does not concern the public protocol at all.

We don't need even need to pull that complexity in in the first step.
We can simply allow mod-tab to select minimized windows and unminiized
if they're selected.

K

Re: [PATCH 0/2] Support for high DPI outputs via scaling

[Alexander Larsson]

On tis, 2013-05-14 at 13:19 +0200, John Kåre Alsaker wrote:
> On Tue, May 14, 2013 at 11:25 AM, Alexander Larsson
>  
> 
> I don't think it should really be allowed to not apply the
> scaling.
> Users may want to disable scaling as it's not very good looking. I
> don't think we should enforce a policy about that.

What do you mean? Scaling is done by the compositor. The user is who
tells the compositor to use scaling (by setting a scale on the
wl_outputs), just like he sets the resolution.

> Right now buffer sizes define surface sizes, and that makes
> surface
>  sizes not really well defined.
> They're defined as the same as buffer sizes (ignoring the trivial
> transformations). They should still be the same if the scaling factor
> is not 1.0. Clients should scale both buffers and surfaces. The only
> thing that should decouple these sizes more are the scaling extension.

Obviously they are defined as such right now, since there is no scaling.
But, the patch I proposed changes this, because otherwise we can't
cleanly handle backwards compatibility (and also it makes sense). 

In the canonical example of 2x scaling you have some lcd panel at say
2000x2000, and we want naive apps to be automatically upscaled as if it
was a 1000x1000 monitor. If a window in the naive app is maximized this
means it must get a configure reply from maximize that says 1000x1000,
which cause it to attach a buffer of 1000x1000 (with scale factor 1) to
it. This is how existing wayland clients work. 

Now, a non-naive client will get the same maximize reply of 1000x1000,
but in this case we want it to create a buffer of 2000x2000 (with scale
2) since it knows the window is on a high-dpi monitor. So, there is a
natural separation of the surface size (1000x1000) and the buffer size
(2000x2000).

We can't have the configure event say 2000x2000, because then old
clients will not be auto-upscaled as we want.


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] protocol: Add buffer_scale to wl_surface and wl_output

[John Kåre Alsaker]

On Tue, May 14, 2013 at 2:51 PM, Alexander Larsson  wrote:

> On tis, 2013-05-14 at 13:44 +0200, John Kåre Alsaker wrote:
> > I'd only accept a proposal which makes the clients tell the compositor
> > how much they increased the size of their window. If the compositor
> > wants to resize anything it should resize the entire window and not
> > individual surfaces/buffers. This also avoids having to position
> > subsurfaces and have configure requests at fractional surface pixels.
>
> I don't quite understand what you mean by this (like, how is "window"
> different from "surface"). Can you give an example of how the API would
> look for what you mean.
>
A window can have multiple surfaces (see the subsurface extension).

The API would be the same, the documentation different.


>
> > set_buffer_scale should be renamed to set_scaling_factor. Otherwise it
> > could be easily confused with the scaling extension which just scales
> > up buffers. My suggestion also renders it unrelated to buffers. The
> > geometry2 event should be named scaling_factor. A done event should
> > also be added. I'd also like a lower and upper bound for the scaling
> > factor as argument to that.
>
> I think a done event is silly, as it is not needed and complicates
> clients (since the done event is not always sent for older servers), but
> sure I can add one.
>
Clients can easily require a compositor which implements the done event,
although they may also support older versions. It's just the compositor
that has to take care not sending done (and geometry2) to the old clients.

If you add one, it should be in a separate commit as it's unrelated to this
work.


> > On Tue, May 14, 2013 at 12:26 PM,   wrote:
> >
> > From: Alexander Larsson 
> >
> > This adds wl_surface_set_buffer_scale() to set the buffer
> > scale of a
> > surface.
> >
> > It is similar to set_buffer_transform that the buffer is
> > stored in a
> > way that has been transformed (in this case scaled). This
> > means that
> > if an output is scaled we can directly use the pre-scaled
> > buffer with
> > additional data, rather than having to scale it.
> >
> > It also adds a geometry2 event with a scale member to
> > wl_output that
> > specifies the scaling of an output.
> >
> > This is meant to be used for outputs with a very high DPI to
> > tell the
> > client that this particular output has subpixel precision.
> > Coordinates
> > in other parts of the protocol, like input events, relative
> > window
> > positioning and output positioning are still in the compositor
> > space
> > rather than the scaled space. However, input has subpixel
> > precision
> > so you can still get input at full resolution.
> >
> > This setup means global properties like mouse
> > acceleration/speed,
> > pointer size, monitor geometry, etc can be specified in a
> > "mostly
> > similar" resolution even on a multimonitor setup where some
> > monitors
> > are low dpi and some are e.g. retina-class outputs.
> > ---
> >  protocol/wayland.xml | 41
> > +++--
> >  1 file changed, 39 insertions(+), 2 deletions(-)
> >
> > diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> > index 3bce022..e5744c7 100644
> > --- a/protocol/wayland.xml
> > +++ b/protocol/wayland.xml
> > @@ -876,7 +876,7 @@
> >  
> >
> >
> > -  
> > +  
> >  
> >A surface is a rectangular area that is displayed on
> > the screen.
> >It has a location, size and pixel contents.
> > @@ -1110,6 +1110,30 @@
> >
> >
> >  
> > +
> > +
> > +
> > +
> > +  
> > +   This request sets an optional scaling factor on how
> > the compositor
> > +   interprets the contents of the buffer attached to the
> > surface. A
> > +   value larger than 1, like e.g. 2 means that the buffer
> > is 2 times the
> > +   size of the surface.
> > +
> > +   Buffer scale is double-buffered state, see
> > wl_surface.commit.
> > +
> > +   A newly created surface has its buffer scale set to 1.
> > +
> > +   The purpose of this request is to allow clients to
> > supply higher resolution
> > +   buffer data for use on high-resolution outputs where
> > the output itself
> > +   has a scaling factor set. For instance, a laptop with
> > a high DPI
> > +   internal screen and an low DPI external screen would
> > have two 

Re: [PATCH] protocol: Add buffer_scale to wl_surface and wl_output

[Alexander Larsson]

On tis, 2013-05-14 at 13:44 +0200, John Kåre Alsaker wrote:
> I'd only accept a proposal which makes the clients tell the compositor
> how much they increased the size of their window. If the compositor
> wants to resize anything it should resize the entire window and not
> individual surfaces/buffers. This also avoids having to position
> subsurfaces and have configure requests at fractional surface pixels.

I don't quite understand what you mean by this (like, how is "window"
different from "surface"). Can you give an example of how the API would
look for what you mean.

> set_buffer_scale should be renamed to set_scaling_factor. Otherwise it
> could be easily confused with the scaling extension which just scales
> up buffers. My suggestion also renders it unrelated to buffers. The
> geometry2 event should be named scaling_factor. A done event should
> also be added. I'd also like a lower and upper bound for the scaling
> factor as argument to that.

I think a done event is silly, as it is not needed and complicates
clients (since the done event is not always sent for older servers), but
sure I can add one.

> On Tue, May 14, 2013 at 12:26 PM,   wrote:
> 
> From: Alexander Larsson 
> 
> This adds wl_surface_set_buffer_scale() to set the buffer
> scale of a
> surface.
> 
> It is similar to set_buffer_transform that the buffer is
> stored in a
> way that has been transformed (in this case scaled). This
> means that
> if an output is scaled we can directly use the pre-scaled
> buffer with
> additional data, rather than having to scale it.
> 
> It also adds a geometry2 event with a scale member to
> wl_output that
> specifies the scaling of an output.
> 
> This is meant to be used for outputs with a very high DPI to
> tell the
> client that this particular output has subpixel precision.
> Coordinates
> in other parts of the protocol, like input events, relative
> window
> positioning and output positioning are still in the compositor
> space
> rather than the scaled space. However, input has subpixel
> precision
> so you can still get input at full resolution.
> 
> This setup means global properties like mouse
> acceleration/speed,
> pointer size, monitor geometry, etc can be specified in a
> "mostly
> similar" resolution even on a multimonitor setup where some
> monitors
> are low dpi and some are e.g. retina-class outputs.
> ---
>  protocol/wayland.xml | 41
> +++--
>  1 file changed, 39 insertions(+), 2 deletions(-)
> 
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index 3bce022..e5744c7 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -876,7 +876,7 @@
>  
>
> 
> -  
> +  
>  
>A surface is a rectangular area that is displayed on
> the screen.
>It has a location, size and pixel contents.
> @@ -1110,6 +1110,30 @@
>
>
>  
> +
> +
> +
> +
> +  
> +   This request sets an optional scaling factor on how
> the compositor
> +   interprets the contents of the buffer attached to the
> surface. A
> +   value larger than 1, like e.g. 2 means that the buffer
> is 2 times the
> +   size of the surface.
> +
> +   Buffer scale is double-buffered state, see
> wl_surface.commit.
> +
> +   A newly created surface has its buffer scale set to 1.
> +
> +   The purpose of this request is to allow clients to
> supply higher resolution
> +   buffer data for use on high-resolution outputs where
> the output itself
> +   has a scaling factor set. For instance, a laptop with
> a high DPI
> +   internal screen and an low DPI external screen would
> have two outputs
> +   with different scaling, and a wl_surface rendered on
> the scaled output
> +   would normally be scaled up. To avoid this upscaling
> the app can supply
> +   a pre-scaled version with more detail by using
> set_buffer_scale.
> +  
> +  
> +
> 
> 
>
> @@ -1467,7 +1491,7 @@
>  
>
> 
> -  
> +  
>  
>An output describes part of the compositor geometry.
>  The
>compositor works in the 'compositor

Re: [PATCH] protocol: Add buffer_scale to wl_surface and wl_output

[John Kåre Alsaker]

I'd only accept a proposal which makes the clients tell the compositor how
much they increased the size of their window. If the compositor wants to
resize anything it should resize the entire window and not individual
surfaces/buffers. This also avoids having to position subsurfaces and have
configure requests at fractional surface pixels.

set_buffer_scale should be renamed to set_scaling_factor. Otherwise it
could be easily confused with the scaling extension which just scales up
buffers. My suggestion also renders it unrelated to buffers. The geometry2
event should be named scaling_factor. A done event should also be added.
I'd also like a lower and upper bound for the scaling factor as argument to
that.

On Tue, May 14, 2013 at 12:26 PM,   wrote:

> From: Alexander Larsson 
>
> This adds wl_surface_set_buffer_scale() to set the buffer scale of a
> surface.
>
> It is similar to set_buffer_transform that the buffer is stored in a
> way that has been transformed (in this case scaled). This means that
> if an output is scaled we can directly use the pre-scaled buffer with
> additional data, rather than having to scale it.
>
> It also adds a geometry2 event with a scale member to wl_output that
> specifies the scaling of an output.
>
> This is meant to be used for outputs with a very high DPI to tell the
> client that this particular output has subpixel precision. Coordinates
> in other parts of the protocol, like input events, relative window
> positioning and output positioning are still in the compositor space
> rather than the scaled space. However, input has subpixel precision
> so you can still get input at full resolution.
>
> This setup means global properties like mouse acceleration/speed,
> pointer size, monitor geometry, etc can be specified in a "mostly
> similar" resolution even on a multimonitor setup where some monitors
> are low dpi and some are e.g. retina-class outputs.
> ---
>  protocol/wayland.xml | 41 +++--
>  1 file changed, 39 insertions(+), 2 deletions(-)
>
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index 3bce022..e5744c7 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -876,7 +876,7 @@
>  
>
>
> -  
> +  
>  
>A surface is a rectangular area that is displayed on the screen.
>It has a location, size and pixel contents.
> @@ -1110,6 +1110,30 @@
>
>
>  
> +
> +
> +
> +
> +  
> +   This request sets an optional scaling factor on how the compositor
> +   interprets the contents of the buffer attached to the surface. A
> +   value larger than 1, like e.g. 2 means that the buffer is 2 times
> the
> +   size of the surface.
> +
> +   Buffer scale is double-buffered state, see wl_surface.commit.
> +
> +   A newly created surface has its buffer scale set to 1.
> +
> +   The purpose of this request is to allow clients to supply higher
> resolution
> +   buffer data for use on high-resolution outputs where the output
> itself
> +   has a scaling factor set. For instance, a laptop with a high DPI
> +   internal screen and an low DPI external screen would have two
> outputs
> +   with different scaling, and a wl_surface rendered on the scaled
> output
> +   would normally be scaled up. To avoid this upscaling the app can
> supply
> +   a pre-scaled version with more detail by using set_buffer_scale.
> +  
> +  
> +
> 
>
>
> @@ -1467,7 +1491,7 @@
>  
>
>
> -  
> +  
>  
>An output describes part of the compositor geometry.  The
>compositor works in the 'compositor coordinate system' and an
> @@ -1520,6 +1544,8 @@
> The geometry event describes geometric properties of the output.
> The event is sent when binding to the output object and whenever
> any of the properties change.
> +
> +Some additional properties were later added, see
> wl_output.geometry2.
>
>summary="x position within the global compositor space"/>
> @@ -1565,6 +1591,17 @@
>
>
>  
> +
> +
> +  
> +   This event contains additional geometric information
> +that are not in the geometry event. Whenever it is sent
> +it will be followed by a geometry event. This way you can
> +tell by the time the geometry event is recieved whether a
> +geometry2 event will be seen or not.
> +  
> +  
> +
>
>
>
> --
> 1.8.1.4
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 0/2] Support for high DPI outputs via scaling

[John Kåre Alsaker]

On Tue, May 14, 2013 at 11:25 AM, Alexander Larsson wrote:

> On tis, 2013-05-14 at 07:11 +0200, John Kåre Alsaker wrote:
>
> >
> > While this isn't a huge problem on GL-based compositors it
> > will cause a problem for software compositors.  Any scaling
> > for that matter is a potential problem there.  However, a
> > factor of two or something shouldn't be too bad in software.
> >
> > Compositors do not have to scale anything at all. Even with fractional
> > scaling factors a compositor could limit itself to just scaling with
> > integer factors. I don't think software compositor is a case worth
> > considering either. Nobody wants to have those, especially with
> > high-DPI displays.
>
> I don't think it should really be allowed to not apply the scaling.
>
Users may want to disable scaling as it's not very good looking. I don't
think we should enforce a policy about that.


> Right now buffer sizes define surface sizes, and that makes surface
>  sizes not really well defined.

They're defined as the same as buffer sizes (ignoring the trivial
transformations). They should still be the same if the scaling factor is
not 1.0. Clients should scale both buffers and surfaces. The only thing
that should decouple these sizes more are the scaling extension.


> For instance, if you maximize a surface,
> or resize it you will get a configure request with a surface size
> specified. You then want to make your surface that size, so you create a
>  buffer with that size, scaled by the factor you pick.

You can't scale the input from configure. You are required to create a
surface of that size in surface pixels in order for it to match the screen.
Clients should still scale content based on the scaling factor even if it
isn't in control of the surface size.


> If the compositor
> chooses not the given factor but rather a somewhat smaller one then your
> surface will be larger than expected, and extend outsize of the monitor
> in the maximized case, or not hit the pointer in the drag resize case.
>
> Also, it makes surfaces different sizes on different monitors. If an
> output has some specified size/scale factor (1400x900@1.5x say) and you
> move a 1400x900 surface from that monitor (fully or partially) to
> another with a different scale (1400x900@1x) you want the window to be
> the same size, so the scaling factor shouldn't affect surface sizes.
>
It is much much more important that the input remains sharp than exactly
the same size. When the client is moved to another output it can resize
itself to better suit the scaling factor of it, if it's able to.

>> The size of a window should always be in pixels at the protocol level.
>

> What do you mean by window and pixel here. There are multiple pixels and
> sizes here:
>
> compositor pixels:
> The 'compositor coordinate system' is an global space where the
> wl_outputs are laid out.
> framebuffer pixels:
> These correspond to the native LCD panel pixel.
> buffer pixels:
> These are the individual pixels the clients rendered
> surface pixels:
> These are "pixels" in what the protocol calls "surface local
> coordinates".
>
Most things in the protocol uses surface pixels which is what I usually
mean by pixels.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] protocol: Add buffer_scale to wl_surface and wl_output

[alexl]

From: Alexander Larsson 

This adds wl_surface_set_buffer_scale() to set the buffer scale of a
surface.

It is similar to set_buffer_transform that the buffer is stored in a
way that has been transformed (in this case scaled). This means that
if an output is scaled we can directly use the pre-scaled buffer with
additional data, rather than having to scale it.

It also adds a geometry2 event with a scale member to wl_output that
specifies the scaling of an output.

This is meant to be used for outputs with a very high DPI to tell the
client that this particular output has subpixel precision. Coordinates
in other parts of the protocol, like input events, relative window
positioning and output positioning are still in the compositor space
rather than the scaled space. However, input has subpixel precision
so you can still get input at full resolution.

This setup means global properties like mouse acceleration/speed,
pointer size, monitor geometry, etc can be specified in a "mostly
similar" resolution even on a multimonitor setup where some monitors
are low dpi and some are e.g. retina-class outputs.
---
 protocol/wayland.xml | 41 +++--
 1 file changed, 39 insertions(+), 2 deletions(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 3bce022..e5744c7 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -876,7 +876,7 @@
 
   
 
-  
+  
 
   A surface is a rectangular area that is displayed on the screen.
   It has a location, size and pixel contents.
@@ -1110,6 +1110,30 @@
   
   
 
+
+
+
+
+  
+   This request sets an optional scaling factor on how the compositor
+   interprets the contents of the buffer attached to the surface. A
+   value larger than 1, like e.g. 2 means that the buffer is 2 times the
+   size of the surface.
+
+   Buffer scale is double-buffered state, see wl_surface.commit.
+
+   A newly created surface has its buffer scale set to 1.
+
+   The purpose of this request is to allow clients to supply higher 
resolution
+   buffer data for use on high-resolution outputs where the output itself
+   has a scaling factor set. For instance, a laptop with a high DPI
+   internal screen and an low DPI external screen would have two outputs
+   with different scaling, and a wl_surface rendered on the scaled output
+   would normally be scaled up. To avoid this upscaling the app can supply
+   a pre-scaled version with more detail by using set_buffer_scale.
+  
+  
+

 
   
@@ -1467,7 +1491,7 @@
 
   
 
-  
+  
 
   An output describes part of the compositor geometry.  The
   compositor works in the 'compositor coordinate system' and an
@@ -1520,6 +1544,8 @@
The geometry event describes geometric properties of the output.
The event is sent when binding to the output object and whenever
any of the properties change.
+
+Some additional properties were later added, see wl_output.geometry2.
   
   
@@ -1565,6 +1591,17 @@
   
   
 
+
+
+  
+   This event contains additional geometric information
+that are not in the geometry event. Whenever it is sent
+it will be followed by a geometry event. This way you can
+tell by the time the geometry event is recieved whether a
+geometry2 event will be seen or not.
+  
+  
+
   
 
   
-- 
1.8.1.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 0/2] Support for high DPI outputs via scaling

[Alexander Larsson]

On tis, 2013-05-14 at 07:22 +0200, John Kåre Alsaker wrote:


> We may also allow scaling factors below 1. When 0 clients should draw
> using the smallest amount of pixels possible while still being
> understandable. I doubt that will be very useful and clients could
> just have 1 as a lower bound.

Scaling < 1 could make sense for the case of windows that are (atm) only
visible as some form of thumbnail. However, I can't think of a way for
the compositor to tell the client of this.



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 0/2] Support for high DPI outputs via scaling

[Alexander Larsson]

On tis, 2013-05-14 at 07:11 +0200, John Kåre Alsaker wrote:

> 
> While this isn't a huge problem on GL-based compositors it
> will cause a problem for software compositors.  Any scaling
> for that matter is a potential problem there.  However, a
> factor of two or something shouldn't be too bad in software.
> 
> Compositors do not have to scale anything at all. Even with fractional
> scaling factors a compositor could limit itself to just scaling with
> integer factors. I don't think software compositor is a case worth
> considering either. Nobody wants to have those, especially with
> high-DPI displays.

I don't think it should really be allowed to not apply the scaling.
Right now buffer sizes define surface sizes, and that makes surface
sizes not really well defined. For instance, if you maximize a surface,
or resize it you will get a configure request with a surface size
specified. You then want to make your surface that size, so you create a
buffer with that size, scaled by the factor you pick. If the compositor
chooses not the given factor but rather a somewhat smaller one then your
surface will be larger than expected, and extend outsize of the monitor
in the maximized case, or not hit the pointer in the drag resize case.

Also, it makes surfaces different sizes on different monitors. If an
output has some specified size/scale factor (1400x900@1.5x say) and you
move a 1400x900 surface from that monitor (fully or partially) to
another with a different scale (1400x900@1x) you want the window to be
the same size, so the scaling factor shouldn't affect surface sizes.

> And what would it then report for physical
> width/height, subpixel, make,
> model, etc? Seems pretty weird.
> Even if two wl_outputs would be presented, they would have the same
> resolution and scaling factor so priorities still won't matter.

You mean the compositor could "lie" about the scaling factor on one of
the outputs? I guess that is one possibility.

> I don't quite understand this. Any factor lower than
> the "desired"
> factor has to be scaled up, no?
> I expect a compositor to render deviations of the desired scaling
> factor without scaling windows. The range when this is allowed is
> reported to clients so they can try to render at a size which will
> avoid scaling.

I don't think this is really a good idea, as per the above.

> Lets take a concrete example. The macbook pro 15" has
> a 2880 x 1800
> native panel. This is "normally" driven as 1440 x 900
> with a scale
> factor of 2. On OSX you can also select a 1920x1200
> resolution, which is
> nominally a scale factor of 1.5. However, on OSX what
> they do is that
> apps render to a framebuffer at twice the resolution
> (3840x2400) and its
> then scaled it down to 2880x1800 to make it look
> reasonable.
> Rendering at 3840x2400 then scaling down to 2880x1800 is bad for
> performance and makes the result unsharp. It is much preferable that
> clients render into 2880x1800 directly with a 1.5 scaling factor (for
> clients that are capable of doing that).

Well, which is best should be up to the app, but i guess we want to
allow a fractional scaling factor to allow apps to scale by 1.5
themselves if they can.


> We can't really downscale with integer multipliers, just upscale. If
> we downscale, rendering at a (much) higher resolution doesn't really
> help much. We want to avoid upscaling though.

Upscaling is important for backwards compat with apps not supporting
scaling. For instance, we likely need it for old X clients. But yeah,
generally we want to avoid that.

> I don't know if the upper/lower limits is the solution, but
> this is certainly an issue.  In a case like that, I would say
> that the application simply works in the coordinates of the
> "prefered" output.  This includes input events etc.  This may
> mean that the size of the window in points isn't an integer.
> If the toolkit doesn't want to deal with that, they can come
> up with a solution (maybe just require a multiple of 2 for the
> size in this case).
> 
> The size of a window should always be in pixels at the protocol level.

What do you mean by window and pixel here. There are multiple pixels and
sizes here:

compositor pixels: 
The 'compositor coordinate system' is an global space where the
wl_outputs are laid out.
framebuffer pixels: 
These correspond to the native LCD panel pixel. 
buffer pixels: 
These are the individual pixels the clients rendered
surface pixels:  
These are "pixels" in what the protocol calls "surface local
coordinates". 

Note th

Re: Gamepad focus model (Re: Input and games.)

[Peter Hutterer]

On Mon, May 13, 2013 at 09:14:25AM +0300, Pekka Paalanen wrote:
> On Mon, 13 May 2013 09:12:03 +1000
> Peter Hutterer  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  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?

yes. but whether or not the device is actually associated with a fixed
player is likely client-specific (as in: only few clients will make use of
that I suspect)

> 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 th