Hi,
maybe I missed it at some point in the discussion (sorry if that is the
case), but what is your use case for the "name?" What are clients
expected to use it for?
The description mentions "similar behaviors", but it is unclear to me
what you are referring to.
Regards,
Philipp
2018-04-10 (火) の
On Tue, 10 Apr 2018 10:27:40 -0400
Drew DeVault wrote:
> Will it address your concerns if I:
>
> 1. Add a statement clarifying that the names are unique across all
>living wl_outputs and may be reused if the corresponding wl_output
>global is removed
> 2. Add a statement clarifying that
On Tue, 10 Apr 2018 20:27:55 -0400
Drew DeVault wrote:
> Signed-off-by: Drew DeVault
> Reviewed-by: Simon Ser
> ---
> This version clarifies the uniqueness constraint, mapping of names to
> wl_outputs, and persistence between sessions.
>
> .../xdg-output/xdg-output-unstable-v1.xml | 19 ++
> Using mesa-18.0.0, Wayland-1.14 and Weston 3.0.0 I get a blank screen on a
> machine with intel
> hd4400 graphics when staring with:
>
> WAYLAND_DEBUG=1 EGL_LOG_LEVEL=debug XDG_RUNTIME_DIR=/run/user/$(id -u)
> weston-launch >weston.log 2>&1
>
> X works fine and, a couple of mesa upgrades ago,
On Wed, 11 Apr 2018 08:35:22 +
John Frankish wrote:
> > Using mesa-18.0.0, Wayland-1.14 and Weston 3.0.0 I get a blank screen on a
> > machine with intel
> > hd4400 graphics when staring with:
> >
> > WAYLAND_DEBUG=1 EGL_LOG_LEVEL=debug XDG_RUNTIME_DIR=/run/user/$(id -u)
> > weston-launch
> > > Using mesa-18.0.0, Wayland-1.14 and Weston 3.0.0 I get a blank
> > > screen on a machine with intel hd4400 graphics when staring with:
> > >
> > > WAYLAND_DEBUG=1 EGL_LOG_LEVEL=debug XDG_RUNTIME_DIR=/run/user/$(id
> > > -u) weston-launch >weston.log 2>&1
> > >
> > > X works fine and, a cou
On Wed, 11 Apr 2018 10:16:46 +1000
Peter Hutterer wrote:
> On Tue, Apr 10, 2018 at 02:01:10PM +0300, Pekka Paalanen wrote:
> > On Mon, 9 Apr 2018 12:54:43 +1000
> > Peter Hutterer wrote:
> >
> > > On Fri, Mar 23, 2018 at 02:01:01PM +0200, Pekka Paalanen wrote:
> > > > From: Pekka Paalanen
On 2018-04-11 9:17 AM, Philipp Kerling wrote:
> maybe I missed it at some point in the discussion (sorry if that is the
> case), but what is your use case for the "name?" What are clients
> expected to use it for?
This is ideally combined with other protocols. Some example use-cases:
- A client
More good questions.
On 2018-04-11 11:02 AM, Pekka Paalanen wrote:
> There is still the corner-case of: can removing wl_output global A
> cause the name for wl_output global B to change, but I suppose that
> falls to common sense to not do so strange things.
I suppose I can add a note about this
This new protocol description is a simplification over v2.
- All pre-edit text styling is gone.
- No events regarding input panel (OSK) state nor covered rectangle.
Compositors are still free to handle situations where the keyboard
focus rectangle is covered by the input panel.
- No set_prefer
Sorry to ask such basic questions, but I was unable to find details on:
When you minimize an application window in Weston, where does it go to? How do
you get it back?
Is it possible to change the date/time format in the top right hand corner of
the display?
___
From: Emmanuele Bassi
Meson is a next generation build system, and various projects in the
larger Linux ecosystem already moved to it — for instance:
- the X11 server
- the X11 protocols repository
- Mesa
- libdrm
The added benefit for adding Meson support is that projects using Meson
a
FWIW, I did something similar, here:
https://lists.freedesktop.org/archives/wayland-devel/2017-October/035399.html
because I wanted to add build tests. IIRC there is some bug that I only
fixed locally.
Jonas
On Wed, Apr 11, 2018 at 05:27:49PM +0100, Emmanuele Bassi wrote:
> From: Emmanuele Bassi
Hi Jonas;
On 11 April 2018 at 17:45, Jonas Ådahl wrote:
> FWIW, I did something similar, here:
> https://lists.freedesktop.org/archives/wayland-devel/2017-
> October/035399.html
> because I wanted to add build tests. IIRC there is some bug that I only
> fixed locally.
>
>
Yes, I was planning to
On Wed, Apr 11, 2018 at 06:04:26PM +0100, Emmanuele Bassi wrote:
> Hi Jonas;
>
> On 11 April 2018 at 17:45, Jonas Ådahl wrote:
>
> > FWIW, I did something similar, here:
> > https://lists.freedesktop.org/archives/wayland-devel/2017-
> > October/035399.html
> > because I wanted to add build tests
On Wed, Apr 11, 2018 at 03:03:58PM +0200, Dorota Czaplejewicz wrote:
> This new protocol description is a simplification over v2.
>
> - All pre-edit text styling is gone.
> - No events regarding input panel (OSK) state nor covered rectangle.
> Compositors are still free to handle situations wher
On Monday, 9 April 2018 07:20:53 PDT Dorota Czaplejewicz wrote:
> On Sun, 11 Mar 2018 20:30:14 +0100
>
> Carlos Garnacho wrote:
> > This new protocol description is a vast simplification over v2, highlights
> > are:
> > - All pre-edit text styling is gone, the protocol doesn't seem the place
> >
On Wed, 11 Apr 2018 11:26:22 -0700
Weng Xuetian wrote:
> On Monday, 9 April 2018 07:20:53 PDT Dorota Czaplejewicz wrote:
> > On Sun, 11 Mar 2018 20:30:14 +0100
> >
> > Carlos Garnacho wrote:
> > > This new protocol description is a vast simplification over v2, highlights
> > > are:
> > > - Al
(forgot to reply to the list)
On Wednesday, 11 April 2018 11:35:58 PDT Dorota Czaplejewicz wrote:
> On Wed, 11 Apr 2018 11:26:22 -0700
>
> Weng Xuetian wrote:
> > On Monday, 9 April 2018 07:20:53 PDT Dorota Czaplejewicz wrote:
> > > On Sun, 11 Mar 2018 20:30:14 +0100
> > >
> > > Carlos Garnacho
On 03/24/2018 08:08 PM, Simon Ser wrote:
> This adds a new protocol to negotiate server-side rendering of window
> decorations for xdg-toplevels. This allows compositors that want to draw
> decorations themselves to send their preference to clients, and clients that
> prefer server-side decoration
Hi!,
Thanks for picking up on this Dorota, and sorry for catching up late,
initial discussion started on days off, and I still have a big pile of
"to go through" email.
On Wed, Apr 11, 2018 at 3:03 PM, Dorota Czaplejewicz
wrote:
> This new protocol description is a simplification over v2.
>
> -
Hi!,
On Wed, Apr 11, 2018 at 8:52 PM, Weng Xuetian wrote:
> (forgot to reply to the list)
>
> On Wednesday, 11 April 2018 11:35:58 PDT Dorota Czaplejewicz wrote:
>> On Wed, 11 Apr 2018 11:26:22 -0700
>>
>> Weng Xuetian wrote:
>> > On Monday, 9 April 2018 07:20:53 PDT Dorota Czaplejewicz wrote:
>
This patch series adds the ability to set a custom pointer acceleration
profile. The profile maps speed (in device units) to an acceleration factor
which is applied to the current delta, i.e. the same that the current accel
curves do. The big difference here is that the user can control the
acceler
This way we can pass them around easier without needing the whole
pointer_accelerator struct (which in theory is device-type specific). The
values relate to the calculation of the delta between trackers anyway, so
logically this is where they belong.
Signed-off-by: Peter Hutterer
---
src/filter-
So the function to calculate the velocity is easier to call from other sites.
Signed-off-by: Peter Hutterer
---
src/filter-private.h | 3 +++
src/filter.c | 11 +--
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/src/filter-private.h b/src/filter-private.h
index a
Signed-off-by: Peter Hutterer
---
meson.build | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/meson.build b/meson.build
index aeb734d8..05a45659 100644
--- a/meson.build
+++ b/meson.build
@@ -161,7 +161,7 @@ dep_libfilter = declare_dependency(link_with : libfilter)
##
Signed-off-by: Peter Hutterer
---
src/filter-private.h | 5 +
src/filter.c | 43 +--
2 files changed, 34 insertions(+), 14 deletions(-)
diff --git a/src/filter-private.h b/src/filter-private.h
index ec87a849..10be823b 100644
--- a/src/filter-p
No functional changes, just refactoring
Signed-off-by: Peter Hutterer
---
src/filter.c | 79 +++-
1 file changed, 46 insertions(+), 33 deletions(-)
diff --git a/src/filter.c b/src/filter.c
index 206695bb..d12b1147 100644
--- a/src/filter.c
Signed-off-by: Peter Hutterer
---
meson.build | 1 +
src/filter-trackpoint.c | 309
src/filter.c| 263 -
3 files changed, 310 insertions(+), 263 deletions(-)
create mode 100644 src/
Prep work for splitting things up better
Signed-off-by: Peter Hutterer
---
src/filter-private.h | 53
src/filter.c | 49 +++-
2 files changed, 56 insertions(+), 46 deletions(-)
diff --git a/
Signed-off-by: Peter Hutterer
---
src/filter-private.h | 17 +
src/filter.c | 17 -
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/src/filter-private.h b/src/filter-private.h
index 10be823b..4779e8f2 100644
--- a/src/filter-private.h
+++ b
Signed-off-by: Peter Hutterer
---
meson.build | 1 +
src/filter-touchpad.c | 332 ++
src/filter.c | 177 ---
3 files changed, 333 insertions(+), 177 deletions(-)
create mode 100644 src/filter-touchpad.c
There's a fair bit of duplication of code from filter.c but it's not worth
disecting this and optimising it. The device is 5 years old now, we don't want
to touch this accel method so duplication is good here.
Signed-off-by: Peter Hutterer
---
meson.build| 1 +
src/filter-touch
Signed-off-by: Peter Hutterer
---
meson.build | 1 +
src/filter-tablet.c | 197
src/filter.c| 146 --
3 files changed, 198 insertions(+), 146 deletions(-)
create mode 100644 src/filter-tabl
This is the standard approach for mice and touchpads to calculate the
acceleration based on the last two deltas, let's make that code shareable.
Signed-off-by: Peter Hutterer
---
src/filter-private.h | 8
src/filter.c | 52 ++--
2
This also fixes a bug with the _noop function, because we casted to the wrong
struct the dpi value was garbage.
Signed-off-by: Peter Hutterer
---
meson.build | 1 +
src/filter-flat.c | 124 ++
src/filter.c | 77 ---
Signed-off-by: Peter Hutterer
---
src/filter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/filter.c b/src/filter.c
index fef2c835..ed90af70 100644
--- a/src/filter.c
+++ b/src/filter.c
@@ -101,7 +101,6 @@ filter_get_type(struct motion_filter *filter)
* Pointer accele
Plenty of duplication there from the normal filter.c, but that also makes it
less likely to break if we adjust the other one.
Signed-off-by: Peter Hutterer
---
meson.build | 1 +
src/filter-low-dpi.c | 253 +++
src/filter.c | 85
Signed-off-by: Peter Hutterer
---
src/filter-touchpad.c | 39 +--
1 file changed, 9 insertions(+), 30 deletions(-)
diff --git a/src/filter-touchpad.c b/src/filter-touchpad.c
index 717b6803..9217137c 100644
--- a/src/filter-touchpad.c
+++ b/src/filter-touchpad.
Yeah, it's duplication. But this way it's also separation and we can't
accidentally use the wrong struct.
Signed-off-by: Peter Hutterer
---
src/filter-low-dpi.c | 49 +
src/filter-mouse.c| 17 +
src/filter-private.h | 17 -
Signed-off-by: Peter Hutterer
---
src/libinput-util.h | 63 +
test/test-misc.c| 53
2 files changed, 116 insertions(+)
diff --git a/src/libinput-util.h b/src/libinput-util.h
index c6d40efc..1f699
Signed-off-by: Peter Hutterer
---
meson.build| 1 +
src/filter-mouse.c | 326 +
src/filter.c | 297 +---
3 files changed, 329 insertions(+), 295 deletions(-)
create mode 100644 src/fil
This adds a third profile to the available profiles to map device-specific
speed to an acceleration factor, fully defined by the caller.
There has been a consistent call for different acceleration profiles in
libinput, but very little specifics in what actually needs to be changed.
"faster horses"
Signed-off-by: Peter Hutterer
---
src/evdev-mt-touchpad.c | 29 -
1 file changed, 4 insertions(+), 25 deletions(-)
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index bdc41a64..5b1ac476 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.
Signed-off-by: Peter Hutterer
---
src/filter-low-dpi.c | 10 +-
src/filter-mouse.c | 10 +-
src/filter-private.h | 12 ++--
src/filter-touchpad-x230.c | 14 +++---
src/filter-touchpad.c | 10 +-
src/filter.c | 30 +
Reduces the duplication, everyone uses the same value anyway
Signed-off-by: Peter Hutterer
---
src/filter-low-dpi.c | 3 +--
src/filter-private.h | 3 +--
src/filter-touchpad-x230.c | 7 +--
src/filter-touchpad.c | 7 +--
src/filter.c | 8
5 files
46 matches
Mail list logo