On Mon, Feb 16, 2015 at 08:13:01AM +0100, Hans de Goede wrote:
> Hi,
>
> On 16-02-15 04:50, Peter Hutterer wrote:
>
>
>
> >ok, I've played around with the ideas in this thread and discussed it with
> >Benjamin this morning. Short summary: I think we should go with the original
> >patch, with an
On the majority of Wacom tablets, the buttons are on the left side, opposite of
the side where the palm is meant to rest. Because of this, it's impossible to
use the tablet with your left hand (comfortably, anyway) unless you flip it
over, in which case the coordinates need to be inverted for it to
---
test/tablet.c | 77 +++
1 file changed, 77 insertions(+)
diff --git a/test/tablet.c b/test/tablet.c
index 8074e4e..bf78e12 100644
--- a/test/tablet.c
+++ b/test/tablet.c
@@ -154,6 +154,82 @@ START_TEST(proximity_out_clear_buttons)
}
EN
TABLET_PROXIMITY events cause many terminals to push every column to the right
by one additional tab, this just increases the space after the event type so
that everything lines up again.
Signed-off-by: Stephen Chandler Paul
---
tools/event-debug.c | 2 +-
1 file changed, 1 insertion(+), 1 delet
This is in reference to an issue I discovered during the GSoC where I found that
there is a grey area with the tablet tool and the tablet itself, where the
tablet will pick up the presence of a tool, but won't get any useful information
from it. When this happens, tablets have a habit of sending di
Signed-off-by: Stephen Chandler Paul
---
test/tablet.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/test/tablet.c b/test/tablet.c
index d67d954..8074e4e 100644
--- a/test/tablet.c
+++ b/test/tablet.c
@@ -376,7 +376,7 @@ START_TEST(motion_event_state)
/* couple
Having a motion event that's sent right after the original proximity event just
to give the values of each axis is somewhat redundant. Since we already include
the values of each axis with each type of event, we may as well use the
proximity event to give the client the starting values for each axi
There isn't much purpose in having proximity in and out as different events,
combining them into one single event is more consistent with the rest of the
API, and means less code for clients to have to work with.
Signed-off-by: Stephen Chandler Paul
---
src/evdev-tablet.c | 18 ++--
We should be able to set the tablet to left-handed mode immediately when it's
connected to the system. Since left-handed mode won't activate until the tool is
out of proximity however, we have to make sure that upon initially connecting
the tablet, we set the tool to be out of proximity (it may as
On Mon, Feb 16, 2015 at 01:19:38PM -0800, Bill Spitzak wrote:
> On 02/16/2015 01:05 PM, Peter Hutterer wrote:
>
> >besides, this doesn't really help, you usually want to know if a device has
> >a specific button well before you get the first event. so the real source
> >to use here would be the ca
Hi,
On 16 February 2015 at 20:46, Bill Spitzak wrote:
> I'm pretty certain there was an old version that looked in the PATH, but
> this has the really unfortunate effect that the build does not work, you
> have to manually create the wayland_scanner and put it in the path, then run
> the build.
>
On 02/16/2015 01:05 PM, Peter Hutterer wrote:
besides, this doesn't really help, you usually want to know if a device has
a specific button well before you get the first event. so the real source
to use here would be the capability. That could make sense, I'll have a look
at this, the API would
I would think the drop target client can figure out what action to
perform, there is no need to communicate it's set of actions to the
compositor or for the compositor to have any of this logic to "determine
the action both parts agree on".
The drop target will have to say what action it did.
On Mon, Feb 16, 2015 at 12:35:13PM -0800, Bill Spitzak wrote:
>
>
> On 02/13/2015 07:06 PM, Peter Hutterer wrote:
> >On 14/02/2015 11:17 , Bill Spitzak wrote:
> >>
> >>
> >>On 02/13/2015 04:46 PM, Peter Hutterer wrote:
> >>>On 14/02/2015 05:00 , Bill Spitzak wrote:
> Actually, more to the poi
On 02/14/2015 01:18 AM, Bryce Harrington wrote:
You can check out this spiffed up documentation at:
http://wayland.freedesktop.org/docs/html/
It looks like these pages have not been updated to the newest output, in
particular apa.html, which does not have the "object" replaced with the
a
I'm pretty certain there was an old version that looked in the PATH, but
this has the really unfortunate effect that the build does not work, you
have to manually create the wayland_scanner and put it in the path, then
run the build.
Would it be possible to search the path, and if not found, s
On 02/13/2015 07:06 PM, Peter Hutterer wrote:
On 14/02/2015 11:17 , Bill Spitzak wrote:
On 02/13/2015 04:46 PM, Peter Hutterer wrote:
On 14/02/2015 05:00 , Bill Spitzak wrote:
Actually, more to the point, it sounds like the client is unable to
distinguish the BTN_LEFT produced by the point
I am trying to run the rdp backend on a proprietary board (arm / zynq).
I am using yocto build system, wayland 1.5.0, freerdp (latest master).
weston crashes just after the connection (using remmina from a Ubuntu PC).
[20:08:40.921] weston 1.5.0
http://wayland.freedesktop.org/
Hey everyone,
I'm bringing again on the table a proposal for DnD actions in the protocol,
this is something I feel missing for complete parity with XDND, at least
seeing the missing bits from the GNOME perspective.
I picked the earlier work from Giulio Camuffo, although perhaps ended up
not being
These 2 requests have been added:
- wl_data_source.notify_actions request: Notifies the compositor of the
available actions on the data source.
- wl_data_offer.notify_actions request: Notifies the compositor of the
available actions on the destination side, plus the preferred action.
Out of t
The policy in weston in order to determine the chosen DnD action is
deliberately simple, and is probably the minimals that any compositor
should be doing here.
Besides honoring the notify_actions requests on both wl_data_source
and wl_data_offer, weston now emits the newly added events notifying
b
And I just want to thank Bill for sticking with it for so long -- good to
see the great list of documentation fixups once his initial rocky hardware
problems were addressed.
It's been a hard road to get this far.
Libinput's almost got the fixin's for using common xbox 360 pads and HID
variants the
On 10/02/15 14:42, Emil Velikov wrote:
> Currently we use the wayland-scanner executable as found with
> AC_PATH_PROG, and after that check the presence of wayland-scanner.pc
>
> Even if the latter is pointing to another wayland-scanner we silently
> ignore it. Rework things to check for the relev
From: Manuel Bachmann
2 things were wrong with the minimization code :
- if the minimized surface was fullscreen, the shell would keep
its fullscreen mode on and only display a black background ;
- keyboard focus was unset, but pointer focus was not.
On the other hand, make sure a fullscreen s
From: Manuel Bachmann
The "set_minimized(surface, 0)" function call was never
used anywhere, and not really respecting naming
conventions.
Signed-off-by: Manuel Bachmann
---
desktop-shell/shell.c | 33 ++---
1 file changed, 10 insertions(+), 23 deletions(-)
diff
On Mon, 16 Feb 2015 11:00:36 +0100
Manuel Bachmann wrote:
> From: Manuel Bachmann
>
> Some of the .png files are specific to ivi-shell. Avoid installing
> them to "$prefix/share/weston" if ivi-shell has explicitly been
> disabled at configure time.
>
> Signed-off-by: Manuel Bachmann
> ---
>
From: Manuel Bachmann
Some of the .png files are specific to ivi-shell. Avoid installing
them to "$prefix/share/weston" if ivi-shell has explicitly been
disabled at configure time.
Signed-off-by: Manuel Bachmann
---
Makefile.am |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
dif
On Sat, 14 Feb 2015 01:18:49 -0800
Bryce Harrington wrote:
> The 1.7 release of Wayland is now available for download. Thanks to
> all who have contributed, and especially to the desktop environments
> and client applications that now converse using Wayland.
Thank you Bryce for the releases!
I
28 matches
Mail list logo
