The current 20% is excessive. On the t440s, the button size amounts to ~14mm
from the bottom. On the x220 it amounts to ~9mm, leaving only 31mm as actual
touchpad.
Reduce it to 15% instead, which amounts to 10.5mm on the t440 and 6mm on the
x220. Cap the button height further by making buttons a m
On Tue, 01 Jul 2014 16:05:33 -0700
Bill Spitzak wrote:
> On 07/01/2014 01:58 PM, Jasper St. Pierre wrote:
>
> > So what you want isn't a position hint, but a "preferred output" hint.
> > That's a lot simpler of a problem to solve, and one that we've talked
> > about implementing before. The issu
On Wed, 2 Jul 2014 00:33:39 +0200
Fabrice Rey wrote:
> Pekka I think you misunderstod my point, let me try to be more clear.
> The "circular menu" is actually just a window, that paints some icons on a
> ring. It doesn't have a parent window, and that's the problem.
Why does it not have a parent
On Wed, Jul 02, 2014 at 01:38:19PM +1000, Peter Hutterer wrote:
> On Tue, Jul 01, 2014 at 08:23:23PM +0200, jad...@gmail.com wrote:
> > On Tue, Jul 01, 2014 at 03:56:20PM +1000, Peter Hutterer wrote:
> > > Provide an interface to enable/disable tapping, with a default mapping of
> > > 1/2/3 fingers
On Tue, Jul 01, 2014 at 02:53:18PM +0200, Hans de Goede wrote:
> The old touchpad accel code was clamping touchpad acceleration between
> 0.2 and 0.4, and on the test devices I have the constant_factor ended up
> such that in practice the accel was almost always 0.2, so rather than having
> a veloc
On Tue, Jul 01, 2014 at 02:32:56PM +0200, Hans de Goede wrote:
> Hi,
>
> On 07/01/2014 06:33 AM, Peter Hutterer wrote:
>
>
>
> > The idea is interesting. Indeed on the T440 with a relatively large and
> > square-ish touchpad, this is much better now. On the x220 with a small
> > 16:10 ratio tou
On Tue, Jul 01, 2014 at 08:23:23PM +0200, jad...@gmail.com wrote:
> On Tue, Jul 01, 2014 at 03:56:20PM +1000, Peter Hutterer wrote:
> > Provide an interface to enable/disable tapping, with a default mapping of
> > 1/2/3 fingers mapping to L/R/M button events, respectively.
> >
> > Signed-off-by: P
On 07/01/2014 04:06 PM, Jason Gerecke wrote:
yep, Lyude's latest protocol draft (in the works) does/will have that in it,
to have the built-in/display tablets not use a cursor, the external ones
have a cursor. we haven't really worried about the client-drawing area mode
yet because it'll likely
On Mon, Jun 30, 2014 at 3:46 AM, Peter Hutterer
wrote:
> On 30/06/2014 20:23 , Pekka Paalanen wrote:
>>
>> On Mon, 30 Jun 2014 09:33:15 +0300
>> Pekka Paalanen wrote:
>>
>>> On Mon, 30 Jun 2014 11:08:35 +1000
>>> Peter Hutterer wrote:
>>>
On Sat, Jun 28, 2014 at 12:41:33PM +0300, Pekka Paal
On 07/01/2014 01:58 PM, Jasper St. Pierre wrote:
So what you want isn't a position hint, but a "preferred output" hint.
That's a lot simpler of a problem to solve, and one that we've talked
about implementing before. The issue is then finding the color
correcting monitor, and then putting the vi
On 07/01/2014 03:33 PM, Fabrice Rey wrote:
Pekka I think you misunderstod my point, let me try to be more clear.
The "circular menu" is actually just a window, that paints some icons on
a ring. It doesn't have a parent window, and that's the problem.
How in Wayland will we be able to place this
What I meant was:
If in fact the mouse is pointing at the same surface that receives the
keystroke (and then creates the popup menu) there is no problem, as that
client knows the relative position of the mouse verses that surface and
can therefore use relative positioning to it to place the po
On Tue, Jul 01, 2014 at 08:49:56PM +0200, jad...@gmail.com wrote:
> On Fri, Jun 27, 2014 at 01:02:11PM +1000, Peter Hutterer wrote:
> > Those three are the ones that matter for logging or device identification in
> > callers, so let's provide them.
> >
> > Signed-off-by: Peter Hutterer
>
> Revie
On 07/01/2014 12:35 PM, Jasper St. Pierre wrote:
"A blink in the highlighting"?
Yes. Say the client wants to highlight the button being pressed and it
has popped up a menu, If the mouse is moved from the button to the menu,
the client wants to keep the button highlighted.
If in fact the s
> "When the keyboard and mouse focus are the same surface then relative
coordinates for the popup can be used"
There is no window having focus here. Or maybe there is, but it's not the
surface of the "circular menu", which is hidden, and only appears when
pressing a shortkey (about global shortkey
Pekka I think you misunderstod my point, let me try to be more clear.
The "circular menu" is actually just a window, that paints some icons on a
ring. It doesn't have a parent window, and that's the problem.
How in Wayland will we be able to place this window so that its center is
right on the curs
On Tue, Jul 1, 2014 at 4:05 PM, Bill Spitzak wrote:
>
>
> On 07/01/2014 12:57 PM, Jasper St. Pierre wrote:
>
>> No, you don't.
>>
>> You cannot possibly reuse the saved settings on different OSes with
>> different output layouts.
>>
>
> You are wrong. We use it all the time. These systems are reb
On 07/01/2014 11:10 AM, Fabrice Rey wrote:
> "In particular users expect to be able to copy this information from
one system to another but only for certain clients."
I didn't think of it but indeed, if you save the theme of your desklet
application and restore it on another system, you expect
On 07/01/2014 12:57 PM, Jasper St. Pierre wrote:
No, you don't.
You cannot possibly reuse the saved settings on different OSes with
different output layouts.
You are wrong. We use it all the time. These systems are rebooted,
generally between OS/X (to use Photoshop) and Linux (to use everyt
On 07/01/2014 11:52 AM, Fabrice Rey wrote:
Here is another problem (and sorry for my numerous messages,
I've just though of this one now) :-)
I have an application that pops up a menu when pressing a shortkey.
It's a circular menu (it actually really exists such an application), so
it should
No, you don't.
You cannot possibly reuse the saved settings on different OSes with
different output layouts. On Windows, there's a taskbar at the bottom (yes,
it's technically configurable, I know). On OS X, there's a menu bar at the
top. You have no idea what windows are around you and where they
On 06/30/2014 11:36 PM, Pekka Paalanen wrote:
One idea was that the client can ask the compositor to create a
cookie (a blob) that the client can save, and when restoring the
window, give the cookie back to the compositor to recall the position
and size, subject to the compositor checking if it
On Tue, 1 Jul 2014 20:52:28 +0200
Fabrice Rey wrote:
> Here is another problem (and sorry for my numerous messages,
> I've just though of this one now) :-)
> I have an application that pops up a menu when pressing a shortkey.
> It's a circular menu (it actually really exists such an application)
"A blink in the highlighting"?
On Tue, Jul 1, 2014 at 3:32 PM, Bill Spitzak wrote:
> On 06/30/2014 09:50 PM, Peter Hutterer wrote:
>
> Yes this makes sense. Sorry I was confusing it with the X implementation
>>> where the Enter event replaced a Move event.
>>>
>>
>> it does? it's actually one
On 06/30/2014 09:50 PM, Peter Hutterer wrote:
Yes this makes sense. Sorry I was confusing it with the X implementation
where the Enter event replaced a Move event.
it does? it's actually one of the ambiguous parts of the X protocol.
nothing prevents you from sending motion events for the same
On Tue, Jul 1, 2014 at 10:47 AM, Ping Cheng wrote:
> On Mon, Jun 30, 2014 at 1:03 AM, Dmitry Kazakov wrote:
>> Hi, all!
>>
>> I'd like to add about mapping of the tablet input.
>>
>> In XInput one can assign a matrix transfromation for each tablet device,
>> which is exactly what people need.
>
>
On Tue, 1 Jul 2014 10:47:19 -0700
Ping Cheng wrote:
> On Mon, Jun 30, 2014 at 1:03 AM, Dmitry Kazakov wrote:
> > Hi, all!
> >
> > I'd like to add about mapping of the tablet input.
> >
> > In XInput one can assign a matrix transfromation for each tablet device,
> > which is exactly what people n
Here is another problem (and sorry for my numerous messages,
I've just though of this one now) :-)
I have an application that pops up a menu when pressing a shortkey.
It's a circular menu (it actually really exists such an application), so it
should pop with its center right on the cursor.
So here
On Fri, Jun 27, 2014 at 01:02:11PM +1000, Peter Hutterer wrote:
> Those three are the ones that matter for logging or device identification in
> callers, so let's provide them.
>
> Signed-off-by: Peter Hutterer
Reviewed-by: Jonas Ådahl with a nit below.
Jonas
> ---
> src/evdev.c| 18 +++
On Tue, Jul 01, 2014 at 03:56:19PM +1000, Peter Hutterer wrote:
> Signed-off-by: Peter Hutterer
> ---
> Changes to v1:
> - actually implement libinput_config_status_to_str
> - add a basic test for it
Except for a minor nit, Reviewed-by: Jonas Ådahl
>
> src/libinput.c | 20
On Tue, Jul 01, 2014 at 03:56:20PM +1000, Peter Hutterer wrote:
> Provide an interface to enable/disable tapping, with a default mapping of
> 1/2/3 fingers mapping to L/R/M button events, respectively.
>
> Signed-off-by: Peter Hutterer
> ---
> Changes to v1:
> - change to a simple enabled/disable
> "I think that may be solved by window types/roles more than having one
generic "normal window type" with flags or state for everything."
It could be conceivable for desklets (they are a bit different than the
regular windows, at least they seem to be on Wayland).
However you can expect the casual
> "In particular users expect to be able to copy this information from one
system to another but only for certain clients."
I didn't think of it but indeed, if you save the theme of your desklet
application and restore it on another system, you expect everything ot be
the same, including the positi
On Mon, Jun 30, 2014 at 10:36 PM, Dmitry Kazakov wrote:
>
>> > The situation is getting even worse if you look at the feature which
>> > Windows' Wacom driver has (I'm not sure whether this feature is
>> > available
>> > in X11 Wacom driver, but it is highly requested by the painters). On
>> > Win
On Mon, Jun 30, 2014 at 1:03 AM, Dmitry Kazakov wrote:
> Hi, all!
>
> I'd like to add about mapping of the tablet input.
>
> In XInput one can assign a matrix transfromation for each tablet device,
> which is exactly what people need.
If we support matrix transformation in libinput/Wayland, all "
Thank you all for your help. Time to read more docs and code :-).
Regards,
Ayan
On Mon, Jun 30, 2014 at 11:53 AM, Bill Spitzak wrote:
> It would be a good idea to add a pointer to this info somewhere on the
> wayland web pages.
>
>
> On 06/30/2014 01:01 AM, Ander Conselvan de Oliveira wrote:
>
The old touchpad accel code was clamping touchpad acceleration between
0.2 and 0.4, and on the test devices I have the constant_factor ended up
such that in practice the accel was almost always 0.2, so rather than having
a velocity based acceleration curve, in essence it was just always using an
ac
Hi,
On 07/01/2014 06:33 AM, Peter Hutterer wrote:
> The idea is interesting. Indeed on the T440 with a relatively large and
> square-ish touchpad, this is much better now. On the x220 with a small
> 16:10 ratio touchpad it's better but not yet good. It feels like the pointer
> acceleration kick
Hi,
On 06/30/2014 02:22 AM, Peter Hutterer wrote:
> The current code triggers multi-finger tapping even if the finger released was
> previously held on the touchpad for a while. For an event sequence of:
> 1. first finger down
> 2. first finger move past threshold/wait past timeout
> 3. second fin
Hi,
On 07/01/2014 07:16 AM, Peter Hutterer wrote:
> Motion starting inside the buttons is initially ignored. For pointer motion
> along the negative y axis, the finger usually starts south of the touchpad
> center. The more distance the motion is intended to cover, the closer to the
> bottom edge
40 matches
Mail list logo
