,
this may not be wise even if possible.
But even in that case, I’m still idly curious.)
— Chris
On Sat, Feb 29, 2020 at 7:07 PM Chris Murphy wrote:
>
> Hi,
>
> I just came across this and it seems it might be related; but someone
> else will need to evaluate whether it's applicable or adequate.
>
> https://lwn.net/Articles/813254/
> https://www.fsf.org/blogs/sy
Hi,
I just came across this and it seems it might be related; but someone
else will need to evaluate whether it's applicable or adequate.
https://lwn.net/Articles/813254/
https://www.fsf.org/blogs/sysadmin/coming-soon-a-new-site-for-fully-free-collaboration
--
Chris M
peline and compositor. There are
many on Linux. Even multiple wayland compositors. And they're
potentially used in combination on top of each other. I'm thinking of
Qubes OS where each application runs in a VM. What about flatpaks and
snap applications? The idea each net pipeline is different and would
need to be characterized, doesn't sound workable.
--
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
ight have for the rest of the displays that
aren't self-calibrating, is lack of platform support parity for the
various video card LUTs. But for that (important) detail, it should
otherwise be true that an ICC profile describes the display's state
regardless of the display rende
On Thu, Mar 7, 2019 at 3:15 AM Michel Dänzer wrote:
>
> On 2019-03-07 8:05 a.m., Chris Murphy wrote:
> > Of course. It can take 5-30 minutes to do a calibration and
> > characterization. In particular if I have 2, 3 or even 4 displays
> > connected I'd want to cal
SO defined (via
PDF) blending operations.
--
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On Wed, Mar 6, 2019 at 10:02 PM Graeme Gill wrote:
>
> Chris Murphy wrote:
>
> > Hmmm. For a while now we've had display calibration+profiling
> > applications compel full screen mode so they're not really usable
> > alongside anything else. They are in effect
se
drm/kms full screen, and then restore the Wayland session I might be
OK with it. But if I have to log out, not OK.
--
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
The definition of wl_argument in wayland-util.h references wl_object,
so wl_object ought to be defined in wayland-util.h. This resolves
gitlab issue #78.
---
src/wayland-util.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/wayland-util.h b/src/wayland-util.h
index b6cbe0e
on purchase of a
> gpu and/or a monitor).
Weekly or monthly is common once you own such hardware. Display
behavior changes quite a bit, and can be highly variable depending on
the component sourcing for the light source.
About the only device profile good for the life of the device, is a
ca
linear ProPhoto
RGB (same primaries as ROMM RGB, using gamma 1.0 function instead of
1.8).
A possibly important side topic to understand about rendering intent
transforms: it is not intelligent or dynamic.
--
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
ee output class have one A2B table (device to
PCS), which is what applies in the application display use case, with
the rendering intent choices pointing to that table.
--
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
; path.
>
> What is "displayRGB"? Does it essentially mean "write these pixel
> values to any monitor as is"? What if the channel value's data type
> does not match?
Good question. I use 'displayRGB' as generic shorthand for the display
profile, which i
plus tone curve which can be defined as a gamma function or even
parametrically), space class, and abstract class are typically pretty
tiny, they could be created on the fly and fed into lcms2 as virtual
profiles, and let it handle all the transforms with its
On Mon, Mar 4, 2019 at 12:13 AM Graeme Gill wrote:
>
> Chris Murphy wrote:
>
> > A common offender were games. They'd try to access the video card LUT
> > directly for effects, but then not reset it back to what it was,
> > rather reset it to a hardwired assump
On Fri, Mar 1, 2019 at 3:10 AM Pekka Paalanen wrote:
>
> On Thu, 28 Feb 2019 18:28:33 -0700
> Chris Murphy wrote:
>
> > I'm curious how legacy applications including games used to manipulate
> > actual hardware LUT in a video card, if the application asked the
>
wheel and doing it internally.
In the near term do you really expect you need blending beyond
Rec.2020/Rec.2100? Rec.2020/Rec.2100 is not so big that transforms to
Rec.709 will require special gamut mapping consideration. But I'm open
to other ideas.
Blender, DaVinci, Lightworks, GIMP
On Thu, Feb 28, 2019 at 2:35 AM Pekka Paalanen wrote:
>
> On Wed, 27 Feb 2019 13:47:07 -0700
> Chris Murphy wrote:
>
> > On Wed, Feb 27, 2019 at 5:27 AM Pekka Paalanen wrote:
> > >
> > > there is a single, unambiguous answer on Wayland: the compositor owns
&g
er windows would
> remain looking good regardless.
Understood.
--
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On Fri, Feb 22, 2019 at 9:00 AM Pekka Paalanen wrote:
>
> Hi Chris,
>
> that is some interesting background, but I feel like I didn't quite
> catch the point.
>
> If the CRTC color management pipeline (LUT-CTM-LUT + maybe more) is
> programmed according to the monitor
On Fri, Feb 1, 2019 at 3:43 AM Pekka Paalanen wrote:
>
> On Thu, 31 Jan 2019 12:03:25 -0700
> Chris Murphy wrote:
>
> > I'm pretty sure most every desktop environment and distribution have
> > settled on colord as the general purpose service.
> > https://
e're going to have different rendering experiences.
And that is the long version on why 'color image encoding' as a full
encapsulating term of what's really important, is the ball to keep our
eye on, not just color spaces.
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
and definition (summary). And it's also sane to
include all of the listed color image encodings, in this proposal.
http://www.color.org/chardata/rgb/rgb_registry.xalter
--
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
x27;s a variant, which is 'Display P3' from Apple,
which starts out being defined with DCI-P3 D65 but uses a tone
response curve defined by the sRGB curve.
> +
Probably the summary should be 'ITU-R BT.2020 for UHDTV' same for
ome recommended by ICC, like SampleICC, Argyll etc, is there
> something which suits our case better?
You'd want to evaluate the interfaces of Argyll CMS and lcms2; it's
possible you'd use Argyll CMS for profile creation, and lcms2 as the
tr
ceholder bug to point to the Fedora one or
if the Fedora one is sufficient.
Also are XWayland crashers properly assigned to mutter on GNOME? Or XOrg?
Thanks,
--
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lis
Quoting Emil Velikov (2018-03-02 14:52:28)
> Hi Chris,
>
> On 1 March 2018 at 08:28, Chris Wilson wrote:
> > EGL_IMG_context_priority allows the client to request that their
> > rendering be considered high priority. For ourselves, this is important
> > as we are inter
the GPU is being hogged by background
clients.
Signed-off-by: Chris Wilson
Cc: Daniel Stone
Reviewed-by: Daniel Stone
---
The previously mentioned bug affecting i965_dri.so not accepting
CONTEXT_ATTRIB_PRIORITY should now be fixed in the stable release, so
the window of nasty surprises should be
Quoting Pekka Paalanen (2017-09-27 15:25:21)
> On Wed, 27 Sep 2017 15:12:15 +0100
> Chris Wilson wrote:
>
> > Quoting Alexandros Frantzis (2017-09-27 15:01:08)
> > > On Wed, Sep 27, 2017 at 01:18:47PM +0100, Chris Wilson wrote:
> > > > Quoting Alex
Quoting Alexandros Frantzis (2017-09-27 15:01:08)
> On Wed, Sep 27, 2017 at 01:18:47PM +0100, Chris Wilson wrote:
> > Quoting Alexandros Frantzis (2017-09-27 13:09:16)
> > > Use EGL fence sync objects to emit timepoints for the beginning and the
> > > end of rendering o
th the GPU rendering. Each will also force a
flush and submission of the GL pipeline, which seems to me to be very
heavyweight ?
-Chris
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
From: Christopher James Halse Rogers
This *technically* changes the semantics of the return value of the source
callbacks.
Previously you could return a negative number from a source callback and it
would prevent
*other* source callbacks from triggering a subsequent recheck.
Doing that seems l
From: Christopher James Halse Rogers
This *technically* changes the semantics of the return value of the source
callbacks.
Previously you could return a negative number from a source callback and it
would prevent
*other* source callbacks from triggering a subsequent recheck.
Doing that seems l
From: Christopher James Halse Rogers
Signed-off-by: Christopher James Halse Rogers
---
src/wayland-server-core.h | 59 +++
1 file changed, 59 insertions(+)
diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h
index 61da8ab..0a2c689 100
On Tue, Apr 4, 2017 at 6:25 PM, Peter Hutterer wrote:
> On Tue, Apr 04, 2017 at 05:01:53PM -0600, Chris Murphy wrote:
>> On Tue, Apr 4, 2017 at 4:36 PM, Peter Hutterer
>> wrote:
>> > On Tue, Apr 04, 2017 at 12:33:32PM -0600, Chris Murphy wrote:
>> >> Be
On Tue, Apr 4, 2017 at 4:36 PM, Peter Hutterer wrote:
> On Tue, Apr 04, 2017 at 12:33:32PM -0600, Chris Murphy wrote:
>> Before filing a bug...
>>
>> I'm having tap to click annoyances. When typing, the cursor insert
>> point changes somewhere else, and suddenly
enabled
Tap drag lock:disabled
Left-handed: disabled
Nat.scrolling:disabled
Middle emulation: disabled
Calibration: n/a
Scroll methods: *two-finger edge
Click methods:*button-areas clickfinger
Disable-w-typing: enabled
Accel profiles: none
Rotation: n/a
[chris@f26h
This patch updates the documentation for building EFL with wayland
support on the wayland web site.
Signed-off-by: Chris Michael
---
efl.html | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/efl.html b/efl.html
index 024109a..5b179df 100644
--- a/efl.html
it takes two or more
profiles to define a transform, and it's that transform that
(indirectly) moderates the display's behavior; or even the
application's behavior for that matter.
--
Chris Murphy
___
wayland-devel mailing list
wayland-dev
as "much easier to make reliable" sounds like the other pipeline may
not be reliable, but that is the pipeline 99.9% of the colors we care
about are going through, which are the colors from all of our
applications.
So instead of testing one pipeline, we're going to h
oth, noticeable posteriziation); or if the display is such crap
that you just have to suck it up and go with matrix+TRC to get smooth
results that lacks uniform accuracy.
--
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedeskto
r behaved is pretty questionable, and a huge
assumption that we're in fact improving the display performance by
"calibrating" them by depending on video card LUTs in the first place. That
is exactly why the high end display don't use it at all. And for
here will be partial data loss (color fidelity)
As for CIEXYZ, to literally convert pixels into this space, or even as an
exchange space, it will require minimum 16 bits per channel or there will
be noticeable quantization. It's a huge color space. You could maybe get
away with 8 bit per channe
On Wed, Dec 21, 2016 at 5:49 PM, Carsten Haitzler wrote:
> On Wed, 21 Dec 2016 12:24:33 -0700 Chris Murphy
> said:
>
>> So...
>>
>> Do applications (wayland clients) choose what compositor to use? Each
>> application could be using a different compositor?
t everything needs this many bits pushed around, but
if it's an architecture that could suitably replace what color managed
apps already do internally now, then it's needed at least as an option
that they can opt into.
--
Chris Murphy
___
way
jects are explicitly tagged and the
compositor is doing display compensation with the help of e.g. lcms)?
Or am I missing something about compositors?
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedeskto
blets you will have 10 different experiences).
I don't assume that on Linux any of these must be mimicked. But there
are distinct advantages with mimicking: we'll have a good idea where
the bodies are buried, rather than having something completely
different from any other platform.
-
ibration program
came with a helper program that would launch at startup time and apply
the calibration curve to the video card LUT.
--
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On Tue, Dec 20, 2016 at 11:33 AM, Daniel Stone wrote:
> Hi Chris,
>
> On 20 December 2016 at 18:11, Chris Murphy wrote:
>> On Tue, Dec 20, 2016 at 10:02 AM, Daniel Stone wrote:
>>> On 17 December 2016 at 10:16, Graeme Gill wrote:
>>>> As I've explaine
le s that doesn't demand
that the user draw up a list of "don't ever run these programs" while
doing color critical work, then great. Otherwise, there's going to
need to be a way to access the crude calibration lever in the video
card. Even though crude, this use case
When we handle keyboard key events, we already retrieve the key state
at the top of this function, so there is no real need to call the same
libinput function again as we can just reuse the 'key_state' variable
that we have above.
Signed-off-by: Chris Michael
---
src/libinput-de
When we handle keyboard key events, we already retrieve the key state
at the top of this function, so there is no real need to call the same
libinput function again as we can just reuse the 'key_state' variable
that we have above.
Signed-off-by: Chris Michael
---
src/libinput-de
When we handle pointer button events, we already retrieve the button
state at the top of this function, so there is no real need to call
the same function again as we can just reuse the 'button_state'
variable that we have above.
Signed-off-by: Chris Michael
---
src/libinput-device.c
On 12/18/2015 01:20 AM, 박성진 wrote:
Dear all,
I have a query regarding key remap functionality.
As of now, there is no key remap functionality provided by libinput.
Personally, if libinput is going to "handle input" .. then it SHOULD be
handling (or at least providing) API for "users" where
Signed-off-by: Chris Michael
---
clients/simple-damage.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/clients/simple-damage.c b/clients/simple-damage.c
index 37a81f5..24c67cc 100644
--- a/clients/simple-damage.c
+++ b/clients/simple-damage.c
@@ -262,7 +262,8
Patch updated to remove dead lines as suggested by Daniel Stone
Signed-off-by: Chris Michael
---
src/compositor-rdp.c | 1 -
src/vaapi-recorder.c | 2 +-
tests/weston-test.c | 2 +-
xwayland/window-manager.c | 2 --
4 files changed, 2 insertions(+), 5 deletions(-)
diff --git a
Signed-off-by: Chris Michael
---
src/compositor-rdp.c | 2 +-
src/vaapi-recorder.c | 2 +-
tests/weston-test.c | 2 +-
xwayland/window-manager.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
index 1098f01
This function is unused throughout the entire weston source tree, so
remove it. It seems that the "load_backend" function is the one
currently being used
Signed-off-by: Chris Michael
---
src/main.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/src/main.c b/
The function 'weston_surface_to_buffer' is unused by compositor and
clients inside weston, so it should be safe to remove this function
Signed-off-by: Chris Michael
---
src/compositor.c | 13 -
src/compositor.h | 3 ---
2 files changed, 16 deletions(-)
diff -
commit 57388e44e5 accidentally changed the comment in
compositor.c::subsurface_commit_to_cache
Signed-off-by: Chris Michael
---
src/compositor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compositor.c b/src/compositor.c
index 65abb72..d723b64 100644
--- a/src
Signed-off-by: Chris Michael
---
clients/window.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/clients/window.c b/clients/window.c
index bf3c470..5d69116 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -145,7 +145,7 @@ struct window_output {
struct toysurface
Signed-off-by: Chris Michael
---
src/compositor.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/compositor.c b/src/compositor.c
index bbac110..5fa30cb 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -768,7 +768,6 @@ weston_matrix_transform_region(pixman_region32_t *dest
This variable may have been used previously when evdev.c was used
however that functionality seems to have been consumed by libinput, so
there is no need for this variable in the weston_seat structure anymore.
Signed-off-by: Chris Michael
---
src/compositor.h | 1 -
1 file changed, 1 deletion
mmap() function expects to be passed a void pointer as the address
here. In order for the kernel to choose a proper address, we should be
passing NULL instead of 0
Signed-off-by: Chris Michael
---
src/compositor-drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src
Signed-off-by: Chris Michael
---
src/input.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/input.c b/src/input.c
index e230c83..2e5cd04 100644
--- a/src/input.c
+++ b/src/input.c
@@ -1571,7 +1571,7 @@ notify_touch(struct weston_seat *seat, uint32_t time, int
touch_id
Signed-off-by: Chris Michael
---
src/compositor-rdp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
index c221eb9..7272f41 100644
--- a/src/compositor-rdp.c
+++ b/src/compositor-rdp.c
@@ -1241,7 +1241,7 @@ rdp_backend_create
Signed-off-by: Chris Michael
---
src/cms-colord.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/cms-colord.c b/src/cms-colord.c
index 1e61feb..c88eb11 100644
--- a/src/cms-colord.c
+++ b/src/cms-colord.c
@@ -145,7 +145,7 @@ update_device_with_profile_in_idle(struct
Signed-off-by: Chris Michael
---
src/screen-share.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/screen-share.c b/src/screen-share.c
index e5f91ea..d961c89 100644
--- a/src/screen-share.c
+++ b/src/screen-share.c
@@ -438,13 +438,13
Signed-off-by: Chris Michael
---
ivi-shell/hmi-controller.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ivi-shell/hmi-controller.c b/ivi-shell/hmi-controller.c
index c388164..5cc76d3 100644
--- a/ivi-shell/hmi-controller.c
+++ b/ivi-shell/hmi-controller.c
@@ -1780,7
Please find attached patch to fix issue with weston_log message not
ending with a return
From 8de51c0e54d6a60a5c326ec3af1c0134044be5ce Mon Sep 17 00:00:00 2001
From: Chris Michael
Date: Mon, 28 Sep 2015 15:24:18 -0400
Subject: [PATCH] compositor-wayland: Terminate weston_log error message
I did many tests, and the only conclusion I've came to is that a buffer we
> used for the framebuffer
> is slower to render to after.
Did you try just allocating a new cached backbuffer each frame?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
t; is fullscreen and then Weston uses the buffer as scanout buffer, when
> the buffer is
> released and we render again in the buffer, L3 caching is disabled.
It is simple to demonstrate that hypothesis incorrect by marking all
colour buffers as uncached.
-Chirs
--
Chris Wilson, Intel Ope
get xwayland from somwhere and install or compile it?
Can someone give me a pointer to get this working? Nothing I have tried
seems to have helped, even after compiling from source using the
instructions at (http://wayland.freedesktop.org/raspberrypi.html)
Thanks,
Chris
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: <mailto:ch...@
Alex,
Thank you for the patch :) Sadly I cannot take a look at it right now (busy
with some other things), but I will place it in my queue and get to it
probably after Christmas break.
Cheers,
dh
-Original Message-
From: Alex Wu [mailto:zhiwen...@linux.intel.com]
Sent: 17 December 2012
rt() is already verifying that the handle is
suitable for the use case, would it not be wiser to check it return in
case it has to reject the handle for any other reason, or on the off
chance that the scanout can read from any buffer? Not that I'm
advocating remapping user vma like that behind the
Alex,
Would you mind resending these patches as attachments, and not inline in the
message ?
Thanks :)
Dh
-Original Message-
From: zhiwen...@linux.intel.com [mailto:zhiwen...@linux.intel.com]
Sent: 03 August 2012 09:02
To: enlightenment-de...@lists.sourceforge.net
Cc: eduardo.de.barros.l
Thank you Alex for the patches !! :)
I do not think I will have time to get to them today (and I know I have
delayed these patches all week) :( It's just that for something this
"large", it will take time to review, test, etc, etc...and I don't have that
time available today :( However, I will make
Thanks for the patches :) I will try to make time to review them this week.
Much appreciated :)
Cheers,
Dh
-Original Message-
From: zhiwen...@linux.intel.com [mailto:zhiwen...@linux.intel.com]
Sent: 26 July 2012 10:18
To: enlightenment-de...@lists.sourceforge.net
Cc: eduardo.de.barros.
Fixed in EFL svn now, Thanks :)
Dh
> -Original Message-
> From: zhiwen...@linux.intel.com [mailto:zhiwen...@linux.intel.com]
> Sent: 23 May 2012 08:32
> To: enlightenment-de...@lists.sourceforge.net
> Cc: wayland-devel@lists.freedesktop.org
> Subject: [E-devel] [PATCH] Wayland: Fix not a
2012/3/2 Kristian Høgsberg :
> On Fri, Mar 2, 2012 at 9:30 AM, Chris Morgan wrote:
>>> I found that a good testing framework can lower the barrier of writing
>>> useful tests. Nice logging and status reports are important I feel. And
>>> if for example you can easily
> I found that a good testing framework can lower the barrier of writing
> useful tests. Nice logging and status reports are important I feel. And
> if for example you can easily write data driven tests, then testing all
> possible code paths in a critical area becomes straight-forward and the
> te
unately one side-effect of cairo flushing everything
prior to the swap caused the current context to be set to invalid.
Author: Chris Wilson
Date: Mon Dec 12 13:52:27 2011 +
gl: Set the destination for swap buffers, required by EGL at least
EGL mandates that the current context b
the weekend and teach us a thing or
two about the DRM infrastructure and what it might look like in a year
or two as more SoC gradually become mainline?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
wayland-devel mailing list
wayland-d
On Sat, Feb 5, 2011 at 10:33 PM, Chris Morgan wrote:
>
>
Patch ok except for the short style c comments? I was going to
regenerate it but didn't want to spend the time if there was no
interest in the patch. I think the patch makes sense since it provides
that hidden mapping between th
On Fri, Feb 4, 2011 at 11:02 PM, Chris Morgan wrote:
> Darxus' build scripts made getting, building and running wayland very
> easy. It seems useful to provide these to users on the official
> wayland site to lower the barrier to getting started with wayland.
>
> I combined
2011/2/7 Kristian Høgsberg :
> On Sun, Feb 6, 2011 at 11:14 PM, Chris Morgan wrote:
>> clients/window.c | 44 +++-
>> 1 files changed, 35 insertions(+), 9 deletions(-)
>
> Hi Chris,
>
> I was thinking that we could introduce a
clients/window.c | 44 +++-
1 files changed, 35 insertions(+), 9 deletions(-)
From 202d2c7ddd3503fc9bf015375ff7344c89dfadee Mon Sep 17 00:00:00 2001
From: Chris Morgan
Date: Sun, 6 Feb 2011 23:12:45 -0500
Subject: [PATCH] Move window frame surface
.
>
> Maybe you should re-write your email above from a position of humility
> instead of unfounded arrogance.
>
> Dave
His email didn't seem overly arrogant to me. I'd actually be
interested in more info about how the issue and the diffe
On Feb 6, 2011, at 1:22 PM, "Kristian Høgsberg" wrote:
> 2011/2/6 Chris Morgan :
>> On Sunday, February 6, 2011, Kristian Høgsberg wrote:
>>> On Sun, Feb 6, 2011 at 11:57 AM, Chris Morgan wrote:
>>>> Hello.
>>>>
>>>> I ran
rom a mobile, pardon the brevity. ~ C.
EHLLs?
Wouldn't c++ at least force an explcit cast, which is at least
somewhat self documenting since you can see the target type?
Did you happen to see my patch to explicitly map the two enums or was
that not what you meant b
On Sunday, February 6, 2011, Kristian Høgsberg wrote:
> On Sun, Feb 6, 2011 at 11:57 AM, Chris Morgan wrote:
>> Hello.
>>
>> I ran into an issue figuring out how a resize event made it's way from
>> window.c in the client to shell.c on the server. I think I figur
up the API?
Chris
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
On Friday, February 4, 2011, Chris Morgan wrote:
> Darxus' build scripts made getting, building and running wayland very
> easy. It seems useful to provide these to users on the official
> wayland site to lower the barrier to getting started with wayland.
>
> I combined two
From dba11faf766d5abecc84c3d55799db6871ecdd44 Mon Sep 17 00:00:00 2001
From: Chris Morgan
Date: Sat, 5 Feb 2011 22:30:13 -0500
Subject: [PATCH] Map enum window_location to enum wl_shell_resize for the call to wl_shell_resize() to match the type used in shell_resize()
---
clients/window.c
mands to make it easier to update, rebuild etc. I
also added a brief mention to the top of the building.html.
Chris
From 71f876333bc37b164c8e62c3ec4ac9329ba59ffb Mon Sep 17 00:00:00 2001
From: Chris Morgan
Date: Fri, 4 Feb 2011 22:46:51 -0500
Subject: [PATCH] Add the wayland-build.sh scri
e but nothing jumped out and I figured I might
as well just ask someone to pick for me a reasonable sized thing to
work on as a beginner.
Chris
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wa
98 matches
Mail list logo
