John Kåre Alsaker wrote:
You might have me confused for Pekka or Alexander. Our proposals should
be identical here. I'm just saying that it will increase the possibly
resolution of input events on higher scaling factors, which reduces
issues with rounding, but doesn't solve it altogether.
Ye
On Wed, Jun 5, 2013 at 3:11 AM, Bill Spitzak wrote:
> John Kåre Alsaker wrote:
>
> This is still a problem without any high-DPI stuff. You could just as
>> easily have an input device with a resolution 3 times higher than the
>> display.
>>
>
> I am worried that most clients will work around the
John Kåre Alsaker wrote:
This is still a problem without any high-DPI stuff. You could just as
easily have an input device with a resolution 3 times higher than the
display.
I am worried that most clients will work around the problem of the scale
proposal by rounding all numbers from 3.5 to
On Tue, Jun 4, 2013 at 10:24 PM, Bill Spitzak wrote:
> John Kåre Alsaker wrote:
>
> And I'm worried that high-resolution pointing devices will be
>> ignored by clients that immediately round to the nearest buffer pixel.
>>
>> Presumably they wouldn't use the high-resolution for anything
John Kåre Alsaker wrote:
And I'm worried that high-resolution pointing devices will be
ignored by clients that immediately round to the nearest buffer pixel.
Presumably they wouldn't use the high-resolution for anything then. I'm
not sure how this relates to the topic either.
A clien
Pekka Paalanen wrote:
Bill Spitzak wrote:
I always figured that the transformation of a subsurface is multiplied
by the transformation of the parent surface. For the scaler proposal
this means the output rectangle is in parent-surface buffer pixels.
You are confusing things.
Sub-surface
On Mon, 03 Jun 2013 18:41:51 -0700
Bill Spitzak wrote:
> Jason Ekstrand wrote:
>
> > I think I'm begining to see what you and John have been suggesting.
> > While I think Alexander's proposal will work well enough for the
> > standard case, I think this also has merit. If I were to sum up, I
On Mon, 3 Jun 2013 16:21:48 +0200
John Kåre Alsaker wrote:
> On Mon, Jun 3, 2013 at 2:22 PM, Pekka Paalanen wrote:
>
> > On Tue, 28 May 2013 19:27:35 +0200
> > John Kåre Alsaker wrote:
> >
> > > + Conceptually simple to implement. Compositors doesn't have to deal with
> > > scaling for subsurf
On Mon, Jun 3, 2013 at 10:21 PM, Bill Spitzak wrote:
> + Clients get input in exact pixels (no rounding errors).
>> + Clients doesn't have to transform input events in order to match the
>> sizes used by buffers.
>
> You said "pels" don't match buffer pixels. Therefore a transformation is
> nee
Jason Ekstrand wrote:
I think I'm begining to see what you and John have been suggesting.
While I think Alexander's proposal will work well enough for the
standard case, I think this also has merit. If I were to sum up, I'd
say I was "cautiously supportive" of the above. It does seem to sol
On Mon, Jun 3, 2013 at 3:21 PM, Bill Spitzak wrote:
> It appears John Alsaker is proposing exactly the same change I have been
> proposing. I think we are having a hard time explaining it however.
>
>
> Pekka Paalanen wrote:
>
>> On Tue, 28 May 2013 19:27:35 +0200
>> John Kåre Alsaker wrote:
>>
It appears John Alsaker is proposing exactly the same change I have been
proposing. I think we are having a hard time explaining it however.
Pekka Paalanen wrote:
On Tue, 28 May 2013 19:27:35 +0200
John Kåre Alsaker wrote:
My proposal is simply to let the compositor tell the client how much
On Mon, Jun 3, 2013 at 2:22 PM, Pekka Paalanen wrote:
> On Tue, 28 May 2013 19:27:35 +0200
> John Kåre Alsaker wrote:
>
> > My proposal is simply to let the compositor tell the client how much
> larger
> > it wants the client to render content. The client can then tell the
> > compositor how muc
On Tue, 28 May 2013 19:27:35 +0200
John Kåre Alsaker wrote:
> My proposal is simply to let the compositor tell the client how much larger
> it wants the client to render content. The client can then tell the
> compositor how much larger it made content in the window. Armed with this
> information
On 05/30/2013 12:42 AM, Alexander Larsson wrote:
The compositor will produce regions that are not integers in surface
space. For instance the damage from an overlapping window atop a surface
who's scale is not an integer will produce a region that is fractional
in that lower surface's space.
D
On ons, 2013-05-29 at 07:55 -0700, Bill Spitzak wrote:
> On 05/29/2013 12:31 AM, Alexander Larsson wrote:
>
> >> I don't think you can avoid non-integer scaling. What happens if a
> >> client says it's scale is 3 and the output has a scale of 2? This is not
> >> just hypothetical, it will certainl
On 05/29/2013 12:31 AM, Alexander Larsson wrote:
I don't think you can avoid non-integer scaling. What happens if a
client says it's scale is 3 and the output has a scale of 2? This is not
just hypothetical, it will certainly happen if there is both a scale 3
and scale 2 output on the device.
On tis, 2013-05-28 at 18:33 -0700, Bill Spitzak wrote:
> On 05/28/2013 06:40 AM, Pekka Paalanen wrote:
>
> > If you really need an output scaling factor like 1.5, then you report it
> > as either 1 or 2, and do a compensating scaling in the compositor to
> > achieve 1.5. That is the best compromiz
On 05/28/2013 06:40 AM, Pekka Paalanen wrote:
If you really need an output scaling factor like 1.5, then you report it
as either 1 or 2, and do a compensating scaling in the compositor to
achieve 1.5. That is the best compromize I can imagine, since to be
honest, 1.5 does not work for the protoc
My proposal is simply to let the compositor tell the client how much larger
it wants the client to render content. The client can then tell the
compositor how much larger it made content in the window. Armed with this
information the compositor can size the window accordingly.
Note that this impli
On Tue, 28 May 2013 17:03:29 +0200
John Kåre Alsaker wrote:
> On Tue, May 28, 2013 at 3:40 PM, Pekka Paalanen wrote:
>
> > On Tue, 28 May 2013 15:10:53 +0200
> > John Kåre Alsaker wrote:
> >
> > > On Thu, May 23, 2013 at 2:57 AM, Kristian Høgsberg > >wrote:
> > >
> > > > I read through the la
On Tue, May 28, 2013 at 3:40 PM, Pekka Paalanen wrote:
> On Tue, 28 May 2013 15:10:53 +0200
> John Kåre Alsaker wrote:
>
> > On Thu, May 23, 2013 at 2:57 AM, Kristian Høgsberg >wrote:
> >
> > > I read through the latest wayland protocol patches and the discussion
> > > around them and didn't se
On Tue, 28 May 2013 15:10:53 +0200
John Kåre Alsaker wrote:
> On Thu, May 23, 2013 at 2:57 AM, Kristian Høgsberg wrote:
>
> > I read through the latest wayland protocol patches and the discussion
> > around them and didn't seen anything I didn't like. I think the
> > approach here is good and a
On Thu, May 23, 2013 at 2:57 AM, Kristian Høgsberg wrote:
> I read through the latest wayland protocol patches and the discussion
> around them and didn't seen anything I didn't like. I think the
> approach here is good and agree with the consensus. This patch series
> looks great too and I like
- Original Message -
> On Thu, 23 May 2013 10:55:08 +0200
> Alexander Larsson wrote:
>
> > On ons, 2013-05-22 at 20:36 -0500, Jason Ekstrand wrote:
> >
> >
> > > I hate to rain on the parade, but it's not going to be that simple. I
> > > already tried adding a field to wl_resource an
On Thu, 23 May 2013 10:55:08 +0200
Alexander Larsson wrote:
> On ons, 2013-05-22 at 20:36 -0500, Jason Ekstrand wrote:
>
>
> > I hate to rain on the parade, but it's not going to be that simple. I
> > already tried adding a field to wl_resource and, as it currently
> > stands, it causes major
On ons, 2013-05-22 at 20:36 -0500, Jason Ekstrand wrote:
> I hate to rain on the parade, but it's not going to be that simple. I
> already tried adding a field to wl_resource and, as it currently
> stands, it causes major issues. As a reminder, this is because
> wl_buffer has a wl_resource fiel
On ons, 2013-05-22 at 20:57 -0400, Kristian Høgsberg wrote:
> * Don't send out new wl_output events to clients that bind with
>version 1. For this I think we want to extend wl_resource with an
>int version; field.
Somewhat related, and I mentioned this earlier in the thread, we have a
p
On Thu, May 23, 2013 at 01:05:43AM +0200, Hardening wrote:
> Le 22/05/2013 14:41, al...@redhat.com a écrit :
> >From: Alexander Larsson
> >
> >This adds support to weston (X11 and DRM backends) for output
> >scale and buffer_scale. It also contains some work on the
> >example clients to make them
On Wed, May 22, 2013 at 7:57 PM, Kristian Høgsberg wrote:
> On Wed, May 22, 2013 at 02:41:24PM +0200, al...@redhat.com wrote:
> > From: Alexander Larsson
> >
> > This adds support to weston (X11 and DRM backends) for output
> > scale and buffer_scale. It also contains some work on the
> > example
On Wed, May 22, 2013 at 02:41:24PM +0200, al...@redhat.com wrote:
> From: Alexander Larsson
>
> This adds support to weston (X11 and DRM backends) for output
> scale and buffer_scale. It also contains some work on the
> example clients to make them support buffer scaling.
>
> I think the support
Le 22/05/2013 14:41, al...@redhat.com a écrit :
From: Alexander Larsson
This adds support to weston (X11 and DRM backends) for output
scale and buffer_scale. It also contains some work on the
example clients to make them support buffer scaling.
I think the support is fairly comprehensive, alth
From: Alexander Larsson
This adds support to weston (X11 and DRM backends) for output
scale and buffer_scale. It also contains some work on the
example clients to make them support buffer scaling.
I think the support is fairly comprehensive, although I'm aware of
a few outstanding issues:
* The
33 matches
Mail list logo
