Carsten Haitzler (The Rasterman) wrote:
> what if the display can do different color profiles for different regions? my
> example is yuv colorspace. 601 vs 709 etc. actually can be assigned per hw
> plane... they are different colorspaces ... :)
It isn't a different color space though, just a dif
Jason Gerecke wrote:
> On Mon, Dec 19, 2016 at 7:04 AM, James Feeney wrote:
>> What is the design outline of that Wayland-protocol-free CMS?
>
> I can certainly see where you're coming from, as I too had similar
> thoughts when getting my feet wet with with protocol design for tablet
> input eve
Pekka Paalanen wrote:
> could you keep the CC list intact, please.
Sorry - no. I don't like getting spammed with multiple copies
of the same email, so I don't do it to other people.
>> Since Wayland doesn't currently implement any color management support,
>> I'm not following how it can be a st
On Mon, Dec 05, 2016 at 03:52:19PM +0200, Pekka Paalanen wrote:
> From: Pekka Paalanen
>
> This is a rough intro to what Xwayland is and does, with just one
> implementation detail so far (Window identification).
>
> I paid no attention to formatting details, those can be polished in
> follow-up
If the fingers rest on the touchpad without moving for a timeout, switch to
pinch or swipe based on the finger position. We already did so for two-fingers
switching to scrolling, now we also do so for 3 and 4 finger gestures. This
gives us better reaction to small movements.
Signed-off-by: Peter H
On Mon, Dec 19, 2016 at 12:55:24PM -0500, Adam Goode wrote:
> Compositors currently receive "move", "resize", and "show_window_menu"
> requests from clients whose decorations have been interacted with.
> Clients currently implement key- and mouse-binding policies to
> determine which one of these r
On Mon, Dec 19, 2016 at 11:56:38AM -0500, Mike Blumenkrantz wrote:
> some restrictions must be placed on this or else it becomes legal for
> the compositor to place popups in unexpected locations
>
> Signed-off-by: Mike Blumenkrantz
Could be further specified further that its about window geomet
This requires to expand the blacklisting to be a bit more specific so we don't
initialize dwt config on devices that won't need it.
https://bugs.freedesktop.org/show_bug.cgi?id=99140
Signed-off-by: Peter Hutterer
---
src/evdev-mt-touchpad.c | 13 +-
src/libinput-util.h
Signed-off-by: Peter Hutterer
---
test/device.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/test/device.c b/test/device.c
index f44a988..af39508 100644
--- a/test/device.c
+++ b/test/device.c
@@ -61,6 +61,22 @@ START_TEST(device_sendevents_config_inva
I've never had the log output help me identify a bug during a test run. Now
that we run all tests in the same binary the verbosity just leads to a massive
file that makes it hard to find the actual failure. Turn off LITEST_VERBOSE by
default but leave the parsing in for cases where it may come in h
This should be handled by a udev rule in systemd/hwdb but that rule doesn't
apply to virtual devices.
Signed-off-by: Peter Hutterer
---
test/litest-device-magic-trackpad.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/test/litest-device-magic-trackpad.c
b/test/litest-device-m
Niels Ole Salscheider wrote:
> Yes, exactly. But these are things that do not use the "normal" wayland
> protocols but are initiated by the compositor.
I'm not sure what you mean by that. Why should the compositor launch
applications ? The user should launch applications they want to
use in the
On Mon, 19 Dec 2016 10:07:31 +0100 Niels Ole Salscheider
said:
> On Monday, 19 December 2016, 11:08:31 CET, Carsten Haitzler wrote:
> > On Sat, 19 Nov 2016 17:29:20 +0100 Niels Ole Salscheider
> >
> > said:
> > > Signed-off-by: Niels Ole Salscheider
> > > ---
> > >
> > > Makefile.am
On 12/19/16 2:48 AM, Pekka Paalanen wrote:
> Hmm, indeed, maybe it would be possible if you are imposing your own
> EGL middle-man library between the application and the real EGL library.
>
> That's definitely a idea to look into. I cannot say off-hand why it
> would not work, so maybe it can wor
On Mon, Dec 19, 2016 at 7:04 AM, James Feeney wrote:
> On 12/19/2016 03:04 AM, Pekka Paalanen wrote:
>> We very deliberately avoid defining any "standard" Wayland interfaces
>> for configuring a compositor, because every compositor is different.
>> With X11, you had the one single X server impleme
Hi,
Version 2 of the original patch is here (wayland-protocols):
https://patchwork.freedesktop.org/series/16642/
Weston implementation (in progress):
https://patchwork.freedesktop.org/series/17007/
Comments welcome!
Adam
On Mon, Dec 12, 2016 at 9:11 AM, Adam Goode wrote:
> Hi,
>
> I put t
This is a work in progress, but is good progress along the idea of
xdg-shell communicating low-level decoration interaction events to
the compositor, rather than every client needing to interpret window
manipulation actions and bindings.
It moves logic from clients/window.c and shared/frame.c into
This removes some of the decoration binding logic from clients.
The compositor implements decoration bindings in v7. Clients now
tell the compositor when clicks or touches happen on decorations,
and the compositor decides what to do. Previously, all clients
had to implement bindings for move, resiz
This updated protocol allows compositors to have a richer set of actions
in response to user initiated events, but requires compositors to implement
the bindings for what was previously move, resize, and show_window_menu.
Signed-off-by: Adam Goode
---
COPYING|
There are no changes in this from v6 to v7, that will come next.
Signed-off-by: Adam Goode
---
Makefile.am |1 +
unstable/xdg-shell/xdg-shell-unstable-v7.xml | 1041 ++
2 files changed, 1042 insertions(+)
create mode 100644 unstable/x
Compositors currently receive "move", "resize", and "show_window_menu"
requests from clients whose decorations have been interacted with.
Clients currently implement key- and mouse-binding policies to
determine which one of these requests to send to the compositor in
response to user action.
Deskt
This is a slight change from v1. I updated Makefile.am and changed the value
for "titlebar" to match the enum in weston.
v1 description:
There were many different opinions and suggestions for how to allow
for raise and lower to be bound to mouse clicks in titlebars. This
is one possible way forw
Like clock_gettime(), clock_getres() is in -lrt for glibc < 2.17.
Add a check for it, like is done for clock_gettime().
Fixes:
http://autobuild.buildroot.net/results/bce/bcecdbbce4a99eb1e9bfbf519857bf94d8952037/
Signed-off-by: "Yann E. MORIN"
---
Makefile.am | 1 +
configure.ac | 3 ++-
2
Hi,
On 19 December 2016 at 16:53, Daniel Stone wrote:
> Given that we can have render-only devices, or vgem in a class of its
> own, ignore any non-KMS devices in compositor-drm's device selection.
> For x86 platforms, this is mostly a non-issue since we look at the udev
> boot_vga issue, but oth
some restrictions must be placed on this or else it becomes legal for
the compositor to place popups in unexpected locations
Signed-off-by: Mike Blumenkrantz
---
unstable/xdg-shell/xdg-shell-unstable-v6.xml | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/unstable/xdg-s
Given that we can have render-only devices, or vgem in a class of its
own, ignore any non-KMS devices in compositor-drm's device selection.
For x86 platforms, this is mostly a non-issue since we look at the udev
boot_vga issue, but other architectures which lack this, and have
multiple KMS devices
On 12/19/2016 03:04 AM, Pekka Paalanen wrote:
> We very deliberately avoid defining any "standard" Wayland interfaces
> for configuring a compositor, because every compositor is different.
> With X11, you had the one single X server implementation and no other.
> On Wayland, every compositor is an
Hi
I am having an embedded SoC on which Wayland weston and work are ported.
When I try to play YouTube/TV app on the browser , only audio is coming no
video on the TV. I am using fbdev backend. In my hardware I don't have
support for DRM backend. Please suggest me what could be the issue for this
On Mon, 19 Dec 2016 10:50:22 +0100
Christian Stroetmann wrote:
> On19.Dec.2016 09:48, Pekka Paalanen wrote:
> > Sorry for not realizing the "wrap libEGL.so" approach earlier.
>
> Yeah, and how does this look like when put in context with Waltham?
It has nothing to do with Waltham at all. It is
Hi,
could you keep the CC list intact, please.
On Mon, 19 Dec 2016 12:37:14 +1100
Graeme Gill wrote:
> Pekka Paalanen wrote:
> > On Wed, 14 Dec 2016 18:49:14 +1100
> > Graeme Gill wrote:
>
> >> Please read my earlier posts. No (sane) compositor can implement CMM
> >> capabilities to a color
On19.Dec.2016 09:48, Pekka Paalanen wrote:
On Fri, 16 Dec 2016 11:35:48 -0600
DRC wrote:
On 12/16/16 3:06 AM, Pekka Paalanen wrote:
I should probably tell a little more, because what I explained above is
a simplification due to using a single path for all buffer types.
...
Thanks again. Thi
On19.Dec.2016 09:48, Pekka Paalanen wrote:
On Fri, 16 Dec 2016 11:35:48 -0600
DRC wrote:
On 12/16/16 3:06 AM, Pekka Paalanen wrote:
I should probably tell a little more, because what I explained above is
a simplification due to using a single path for all buffer types.
...
Thanks again. Th
On Monday, 19 December 2016, 11:08:31 CET, Carsten Haitzler wrote:
> On Sat, 19 Nov 2016 17:29:20 +0100 Niels Ole Salscheider
>
> said:
> > Signed-off-by: Niels Ole Salscheider
> > ---
> >
> > Makefile.am| 1 +
> > unstable/color-management/README
On Fri, 16 Dec 2016 11:35:48 -0600
DRC wrote:
> On 12/16/16 3:06 AM, Pekka Paalanen wrote:
> > I should probably tell a little more, because what I explained above is
> > a simplification due to using a single path for all buffer types.
> > ...
>
> Thanks again. This is all very new to me, an
On Monday, 19 December 2016, 13:08:13 CET, Graeme Gill wrote:
> Niels Ole Salscheider wrote:
> > I feel like the discussion drifts off a bit. You (Graeme) obviously know
> > much more about color management than I do. But as Pekka already pointed
> > out there are a few constraints that originate i
On Mon, 19 Dec 2016 17:01:50 +1100 Graeme Gill said:
at this point i'm going to summarize this. this might be more helpful than
continuing point by point rebuttals as i sense that there's something missing
in this conversation:
summary of what i think should be the case (or roughly):
1. i
36 matches
Mail list logo