Making Wayland accessible

[Bill Spitzak]

Personally I am very worried about clients doing this.

My main concern is clients acting differently than each other. This will 
happen even if every one of them is using a carefully written toolkit 
that implements all defined wayland behavior because they may be running 
on different hosts with different versions of that toolkit. And unless 
you are living in fantasy land you will know that there will be clients 
that are not using perfect toolkits.

Also it makes it extremely difficult to remote to a host using a 
different window system (rdp) that makes the opposite assumption, 
because you have to "uncook" the events and then rely on the client 
recooking them back to the same thing the use did on that host. Anybody 
using NX will know this is a problem even between two X servers due to 
it attempting to uncook keysyms into the scancodes used by the remote 
server.

A literal interpretation of having the client do it all means you cannot 
add a new type of hardware and have it emulate a mouse for software that 
does not know about this new type of hardware.

In fact I think wayland should fully mark events with all kinds of 
information, like "this is probably a double-click" and "the user has 
dragged the mouse enough that it is not a click" and "the user has been 
holding the mouse still long enough that you should do a hover event", 
and everything else anybody can think of. Slight differences between 
applications in deriving this information is a problem even on Windows.

It should be possible for a client to retrieve the raw events (if they 
really exist at all, they won't in the rdp scenario). This mostly means 
that any input processing cannot eat or delay an event, it must replace 
it with something. And attaching the raw event info to it may be a good 
idea.

Wayland is already "cooking" events, such as doing some of the keyboard 
translation, the input methods, on-screen keyboards, the mapping of 
other devices to the "seat pointer", the entire touch/gesture api, etc. 
So I also see no reason to make repeat a special case.

Rui Tiago Cação Matos wrote:
> Hi,
> 
> just replying to this part:
> 
> On 15 October 2013 22:05, Matthias Clasen <matthias.clasen at gmail.com> wrote:
>> - input tweaks like slow keys or bounce keys or hover-to-click naturally fit
>> in the event dispatching in the compositor
> 
> In the same spirit of having key repeat on the client side, I think
> that slow, bounce and sticky keys should also be implemented by the
> clients. Doing these on the compositor would in particular make things
> more complex for xwayland which (I assume) should continue to provide
> these features for X clients while being a regular wl_keyboard client
> itself.
> 
> MouseKeys though, seems like it can be implemented in the wayland
> compositor and we should probably remove the functionality from
> xwayland. Hover-to-click can be done in the compositor as well.
> 
> Rui
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel