Hi Jonas,
On Sun, Jul 27, 2014 at 11:28:28PM +0200, Jonas Ådahl wrote:
> The kernel may send a 'release' event without ever having sent a key
> 'pressed' event in case the key was pressed before libinput was
> initiated. Ignore these events so that we always guarantee a release
> event always come
On 04.07.2014 18:17, Michel Dänzer wrote:
> On 04.07.2014 17:51, Ander Conselvan de Oliveira wrote:
>> On 07/04/2014 04:13 AM, Michel Dänzer wrote:
>>> On 03.07.2014 21:27, Ander Conselvan de Oliveira wrote:
On 06/25/2014 05:09 PM, Alvaro Fernando García wrote:
> Init cursor size to 64x64
When removing a device, its not guaranteed that all button or key
presses have been released, resulting in an invalid seat wide button
count.
Note that kernel devices normally will send release events when being
unplugged, but this won't happen when removing a device from the path
backend.
Signed
Hi,
These 4 patch patches replaces 7 and 8 from the previous series.
This series brings in, as suggested in the review, the bit mask
operations for long's from libevdev, but uses them only for ignoring
initial release events. For auto release a byte array for counting button
presses is used. By c
It's up to a evdev device backend to configure seat capabilities it
supports. Even though it may be possible for a touchpad to have extra
keys, there is currently no support for sending keyboard events from the
touchpad driver, and if that would be implemented, it'd be a detail of
the touchpad driv
Keep track of the number of times a given button or key is pressed on a
device. For regular mouse devices or keyboard devices, such a count will
never exceed 1, but counting button presses could help when button
presses with the same code can originate from different sources. One could
for example
Some tests in test/path.c and test/udev.c are not dependent on
device behaviour but rather managing of device lifetime etc. Run those
tests only once with only one device, resulting more or less the same
code coverage but shorter run time.
Signed-off-by: Jonas Ådahl
---
> hmm, I think instead of
The kernel may send a 'release' event without ever having sent a key
'pressed' event in case the key was pressed before libinput was
initiated. Ignore these events so that we always guarantee a release
event always comes after a pressed event for any given key or button.
Signed-off-by: Jonas Ådahl
Hi Daniel,
thanks, i understood we should add the wl_display_dispatch_pending call in
the application
there is currently no way to avoid this and basically it does not harm.
I only wanted to understand if there is something missing.
2014-07-27 22:41 GMT+02:00 Daniel Stone :
> Hi Eugen,
>
>
> On
Hi,
On 07/24/2014 08:53 AM, Peter Hutterer wrote:
> Provides the bounding box only, with slot 0 always being the upper/left, slot
> 1 being the lower-right touch. This needs to use the touch_down etc. litest
> interfaces, which are now widened to double (leftover from 489630f58) and a
> device-spe
Hi Eugen,
On Sunday, July 27, 2014, Eugen Friedrich wrote:
>
> Our graphics stack creates it's own wayland queue and uses this queue for
> all wayland objects and only this queue will be dispatched. Our graphics
> stack calls also wl_display_sync api and the issue is that the wayland
> library wi
O thanks for the hint about mailing list,
and for clarification on the dispatching logic(I'm not original English
speaker and assume "havok" is like behavior? )
2014-07-27 21:33 GMT+02:00 Giulio Camuffo :
> FIY, You dropped the mailing list in your reply.
>
> 2014-07-27 22:15 GMT+03:00 Eugen Fr
FIY, You dropped the mailing list in your reply.
2014-07-27 22:15 GMT+03:00 Eugen Friedrich :
> The problem is the app never calls wl_display_distpath(_pending)
> it just creates native handles and then uses EGL for rendering and the
> events on the main wayland display queue are never dispatched
2014-07-27 21:14 GMT+03:00 Eugen Friedrich :
> Hi all,
>
> after debugging a memory consumption issue in simple wayland application i
> found a issue in our wayland graphics backend. Then i took a look into the
> mesa implementation and found the quite similar implementation there.
>
> Our graphics
Hi all,
after debugging a memory consumption issue in simple wayland application i
found a issue in our wayland graphics backend. Then i took a look into the
mesa implementation and found the quite similar implementation there.
Our graphics stack creates it's own wayland queue and uses this queue
15 matches
Mail list logo
