On Wed, 1 May 2013 17:03:30 -0400
Kristian Høgsberg wrote:
> On Mon, Apr 22, 2013 at 01:30:28PM +0300, Pekka Paalanen wrote:
> > On Fri, 5 Apr 2013 14:23:50 -0500
> > Thomas Daede wrote:
> >
> > > I am not sure that doing the color conversion in the compositor
> > > is the correct place. Some o
On 05/01/2013 02:16 AM, John Kåre Alsaker wrote:
On Tue, Apr 30, 2013 at 10:49 PM, Jason Ekstrand mailto:ja...@jlekstrand.net>> wrote:
On Tue, Apr 30, 2013 at 2:29 PM, Bill Spitzak mailto:spit...@gmail.com>> wrote:
I'm not clear on why Wayland's design requires adding 2 dummy
In the future the CMS plugins will need to read the config file and setup a list
of hardcoded names to ICC profiles.
---
src/compositor-drm.c | 11 ---
src/compositor.c | 1 +
src/compositor.h | 1 +
3 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/src/compositor-dr
On Tue, 30 Apr 2013 09:14:48 -0400
Todd Showalter wrote:
> On Tue, Apr 30, 2013 at 5:29 AM, Pekka Paalanen
> wrote:
>
> > you've provided lots of valuable information already. Unfortunately
> > my input is left as hand-waving, since I cannot dedicate to
> > designing this protocol myself (as in
On Tue, 30 Apr 2013 10:30:33 -0500
Jason Ekstrand wrote:
> On Tue, Apr 30, 2013 at 10:25 AM, Todd Showalter
> wrote:
>
> > On Tue, Apr 30, 2013 at 9:26 AM, Pekka Paalanen
> > wrote:
> >
> > > unfortunately that is not how Wayland works at all. All clients
> > > are isolated from the start, rega
On Tue, 30 Apr 2013 22:35:22 +0800
Zhi An Ng wrote:
> > I'd like to have a better name for it, and you might want the set
>
> I
> checked up the thesaurus and the closest contender was "size", so I
> guess you already have the best name :)
>
>
> > Comments? Is the language clear?
>
> >
On Tue, 30 Apr 2013 17:08:49 -0400
Matthias Clasen wrote:
> On Tue, Apr 30, 2013 at 8:33 AM, Pekka Paalanen
> wrote:
> > Hi all,
> >
> > below is my first draft for a wl_surface scaling and cropping
> > extension. I called it wl_scaler in the lack of a better name. It is
> > designed similarly t
On Tue, 30 Apr 2013 10:54:25 -0500
Jason Ekstrand wrote:
> On Tue, Apr 30, 2013 at 9:06 AM, John Kåre Alsaker <
> john.kare.alsa...@gmail.com> wrote:
>
> > I'd say we should split the cropping and scaling request into two.
> >
>
> How would you suggest doing that? I actually really like the
>
On Tue, 30 Apr 2013 14:21:41 -0700
Bill Spitzak wrote:
> "scalar" is often used to identify a single number in linear algebra.
> A different name would be better. "transform" might work but that
> also would cover the subsurface and surface transforms, perhaps that
> can be moved to this api as w
On Tue, 30 Apr 2013 15:49:16 -0500
Jason Ekstrand wrote:
> On Tue, Apr 30, 2013 at 2:29 PM, Bill Spitzak
> wrote:
>
> > I'm not clear on why Wayland's design requires adding 2 dummy
> > objects to the api (in this case the "wl_scalar" factory and the
> > per-surface "wl_surface_scalar") rather
On Thu, 02 May 2013 10:53:14 +0300
Ander Conselvan de Oliveira wrote:
> The protocol allows us to add new requests to a new version of an
> interface. For instance, the set_buffer_transform request was added
> to version 2 of the wl_surface interface.
>
> I believe the scaled video use case is
I'd suggest that client should use subsurfaces if they want multiple
colorspaces in a window. They might have to do that anyway since they may
want a different pixel format.
On Thu, May 2, 2013 at 8:58 AM, Pekka Paalanen wrote:
> On Wed, 1 May 2013 17:03:30 -0400
> Kristian Høgsberg wrote:
>
>
Am 02.05.13, 10:10 +0100 schrieb Richard Hughes:
In the future the CMS plugins will need to read the config file and setup a list
of hardcoded names to ICC profiles.
Why will come a need for a CMS to read hardcoded names from the config
file?
kind regards
Kai-Uwe
___
On 2 May 2013 13:49, Kai-Uwe Behrmann wrote:
> Why will come a need for a CMS to read hardcoded names from the config file?
Well, colord won't, but not everybody wants/needs colord, e.g. on an
embedded display where a color profile is never likely to change. For
this case I've added a cms-static
ICC profiles can now be specified in weston.ini for each output, or a CMS
implementation can optionally loaded from a pluggable module.
---
configure.ac | 7 ++
src/Makefile.am | 13 +++-
src/cms-static.c | 211 +++
src/cms.c
On Thu, May 2, 2013 at 5:51 AM, Pekka Paalanen wrote:
> On Tue, 30 Apr 2013 10:54:25 -0500
> Jason Ekstrand wrote:
> > On Tue, Apr 30, 2013 at 9:06 AM, John Kåre Alsaker <
> > john.kare.alsa...@gmail.com> wrote:
> > > I'd say we should split the cropping and scaling request into two.
> >
> > How
On Thu, May 2, 2013 at 5:44 AM, Pekka Paalanen wrote:
> On Tue, 30 Apr 2013 09:14:48 -0400
> Todd Showalter wrote:
>
>> I'm getting set up to write code. Someone kindly gave me a bash
>> script to pull down all the components, so once I get things set up
>> properly I'll see if I can get a p
Pekka Paalanen wrote:
So it's really a question whether we can require all compositors to
unconditionally support crop&scale. And that really means *all* Wayland
compositors forever, since wl_surface is core protocol.
I see no reason not to make this a requirement. You already require 90
degr
Hi,
On 2 May 2013 19:06, Bill Spitzak wrote:
> Pekka Paalanen wrote:
>> So it's really a question whether we can require all compositors to
>> unconditionally support crop&scale. And that really means *all* Wayland
>> compositors forever, since wl_surface is core protocol.
>
> I see no reason not
Pekka Paalanen writes:
> Yes, I agree.
>
> Even if BP was not a nesting compositor, making the home button
> minimize the active window would usually get you to the BP right under
> it. The task switcher would be more reliable, though, and also allow to
> get back to the game. It is all mostly a
Hi,
On 2 May 2013 15:42, Jason Ekstrand wrote:
> Ok, I see it now. Sorry, but I missed it on my first read-through. Yes, it
> fixes the problem, but in an extremely confusing way. The reason I say it
> is confusing is because it inherently mixes buffer and surface coordinate
> systems. I reall
Hi,
On 2 May 2013 10:44, Pekka Paalanen wrote:
> On Tue, 30 Apr 2013 09:14:48 -0400
> Todd Showalter wrote:
>> The question is, is a gamepad an object, or is a *set* of gamepads
>> an object?
>
> Both, just like a wl_pointer can be one or more physical mice. Whether a
> wl_pointer is backed
Jason Ekstrand wrote:
Agreed. Sending transform matrices or the like has HUGE rounding
problems. Particularly when we're using wl_fixed which is 24.8. Other
methods would require adding rounding conventions etc.
I was assuming IEEE 32-bit floating point would be in the api for at
least th
Daniel Stone wrote:
I also think all of wl_shell should be a core requirement.
Not all compositors are user sessions. Think about nested compositors
for browsers, or capture, or also very stripped-down usecases where
they really don't want to have to deal with this kind of thing.
For simple
On Thu, May 2, 2013 at 1:22 PM, Daniel Stone wrote:
> Hi,
>
> On 2 May 2013 15:42, Jason Ekstrand wrote:
> > Ok, I see it now. Sorry, but I missed it on my first read-through. Yes,
> it
> > fixes the problem, but in an extremely confusing way. The reason I say
> it
> > is confusing is because
On Tue, Apr 16, 2013 at 06:19:47PM -0700, Bill Spitzak wrote:
> Jan Arne Petersen wrote:
>
> >I completely agree that editing UTF-8 text as UTF-8 is fine.
> >
> >I am just wondering if we should have offsets in "Unicode code points"
> >(with the addition that for invalid byte sequences each byte c
On 05/02/2013 09:56 PM, Kristian Høgsberg wrote:
> On Tue, Apr 16, 2013 at 06:19:47PM -0700, Bill Spitzak wrote:
>> Jan Arne Petersen wrote:
>>
>>> I completely agree that editing UTF-8 text as UTF-8 is fine.
>>>
>>> I am just wondering if we should have offsets in "Unicode code points"
>>> (with t
This code was originally written by Soren Sandmann and was
found here: http://people.gnome.org/~ssp/randr/edid-parse.c
The code has been in use in gnome-settings-daemon for a couple of years now and
is used to generate an Auto-EDID ICC profile if the screen has not been profiled
with a calibratio
On Wed, Apr 10, 2013 at 11:36:24AM +0100, Rob Bradford wrote:
> From: Rob Bradford
>
> Following the addition of the EGL_WIDTH and EGL_HEIGHT this function should
> return EGL_TRUE for those requested attributes too.
> ---
> src/egl/drivers/dri2/egl_dri2.c | 4 ++--
> 1 file changed, 2 insertion
EDID parsing should probably be moved out of compositor-drm since other
backends can provide EDIDs too.
On Thu, May 2, 2013 at 10:38 PM, Richard Hughes wrote:
> This code was originally written by Soren Sandmann
> and was
> found here: http://people.gnome.org/~ssp/randr/edid-parse.c
>
> The co
Just a reminder to all students and mentors planning to work on an
X.Org GSoC project this year, the deadline for applications is
tomorrow (May 3rd, 19:00 UTC). If you are a student planning to
apply, please submit your application by the deadline. If you are
planning to mentor a project and have
edid.[c|h] is actually what I had initially, want me to do something
like that? Something like a:
struct edid_info;
int edid_parse(struct edid_info *info, const uint8_t *data, size_t length);
Richard
On 2 May 2013 21:57, John Kåre Alsaker wrote:
> EDID parsing should probably be moved out of co
That will probably work.
On Thu, May 2, 2013 at 11:07 PM, Richard Hughes wrote:
> edid.[c|h] is actually what I had initially, want me to do something
> like that? Something like a:
>
> struct edid_info;
> int edid_parse(struct edid_info *info, const uint8_t *data, size_t length);
>
> Richard
>
---
src/Makefile.am | 2 +
src/compositor-drm.c | 180 +--
src/compositor.c | 21 ++
src/compositor.h | 5 ++
src/edid.c | 175 +
src/edid.h | 48 +
On Thu, 2 May 2013 18:18:27 + (UTC)
Rick Yorgason wrote:
> Pekka Paalanen writes:
> > Yes, I agree.
> >
> > Even if BP was not a nesting compositor, making the home button
> > minimize the active window would usually get you to the BP right
> > under it. The task switcher would be more reli
35 matches
Mail list logo
