On Tue, Nov 12, 2013 at 10:50:18PM +0100, Jonas Ådahl wrote:
> Hi,
>
> Wayland compositors are expected to deal with input device processing
> themselves providing input events according to the Wayland protocol to
> the clients. So far only weston has had more than basic support for
> processing r
Jasper St. Pierre wrote:
It's because the keyboard is a surprisingly complicated tool with
multiple modes of operating, probably without you ever realizing it, and
clients need all of that power:
If I'm typing text, the *labels* of the keys matter, and input methods
allow us to translate
Hmm, that's quite interesting, I've never thought of keyboard this way,
really. And I think this is because all of that is redundant actually.
Client should provide you with the ability to configure which button and
for what reason you want to press. For example when you install ubuntu it
asks you
It's because the keyboard is a surprisingly complicated tool with multiple
modes of operating, probably without you ever realizing it, and clients
need all of that power:
If I'm typing text, the *labels* of the keys matter, and input methods
allow us to translate sequences of key presses and rel
Thanks! That's strange... I mean... It sounds like there are extra levels
of responsibility. What I would expect is one way flow with 1 component
processing all the input. 1 person will hardly deal with more then 1 output
(though it may use several inputs at a time). That's y the concept of 1
activ
If by libxcbcommon you mean libxkbcommon, no.
libxkbcommon is about the complex ways of interpreting key events, with
client-side key maps, modifiers, accessibility features (latched keys,
sticky keys, etc.). It's meant to be used from both the compositor and the
client.
libinput is about replaci
Is libinput supposed to be sort of replacement for libxcbcommon?
Thanks.
On Thu, Nov 14, 2013 at 4:58 PM, Artsiom Anikeyenka
wrote:
> I like the generalized architecture of any input handling as well. I
> didn't look into the code because I will hardly understand it yet. I also
> don't understa
I like the generalized architecture of any input handling as well. I didn't
look into the code because I will hardly understand it yet. I also don't
understand a lot yet but what I'd do is also some sort of dispatcher of the
input object queue. I.e. when each device is watched by the wrapper which
On Wed, Nov 13, 2013 at 01:22:26PM +0100, Jonas Ådahl wrote:
> On Wed, Nov 13, 2013 at 7:22 AM, Peter Hutterer
> wrote:
> > Hi Jonas,
> >
> > On Tue, Nov 12, 2013 at 10:50:56PM +0100, Jonas Ådahl wrote:
> >> Wayland compositors are expected to deal with input device processing
> >> themselves prov
On Wed, Nov 13, 2013 at 7:22 AM, Peter Hutterer
wrote:
> Hi Jonas,
>
> On Tue, Nov 12, 2013 at 10:50:56PM +0100, Jonas Ådahl wrote:
>> Wayland compositors are expected to deal with input device processing
>> themselves providing input events according to the Wayland protocol to
>> the clients. So
On Wed, Nov 13, 2013 at 4:00 AM, Christopher James Halse Rogers
wrote:
> On Tue, 2013-11-12 at 22:50 +0100, Jonas Ådahl wrote:
>> Hi,
>>
>> Wayland compositors are expected to deal with input device processing
>> themselves providing input events according to the Wayland protocol to
>> the clients
On Wed, Nov 13, 2013 at 1:49 AM, Kristian Høgsberg wrote:
> On Tue, Nov 12, 2013 at 1:50 PM, Jonas Ådahl wrote:
>> Hi,
>>
>> Wayland compositors are expected to deal with input device processing
>> themselves providing input events according to the Wayland protocol to
>> the clients. So far only
Hi Jonas,
On Tue, Nov 12, 2013 at 10:50:56PM +0100, Jonas Ådahl wrote:
> Wayland compositors are expected to deal with input device processing
> themselves providing input events according to the Wayland protocol to
> the clients. So far only weston has had more than basic support for
> processing
On Tue, Nov 12, 2013 at 1:50 PM, Jonas Ådahl wrote:
> Hi,
>
> Wayland compositors are expected to deal with input device processing
> themselves providing input events according to the Wayland protocol to
> the clients. So far only weston has had more than basic support for
> processing raw input
Hi,
Wayland compositors are expected to deal with input device processing
themselves providing input events according to the Wayland protocol to
the clients. So far only weston has had more than basic support for
processing raw input events from evdev.
In order to avoid reimplementing support for
15 matches
Mail list logo