On 19 March 2013 16:58, Scott Moreau <[email protected]> wrote:
> This is a good point. I think the plan here as discussed before is
> that, eventually we'll have a way for clients to request 'raw events'
> which means the compositor will hand events to the client with minimal
> or no processing (including key repeat).
If I'm looking at a current version of wayland.xml, the protocol
already supports three types of key event: down, repeat, up. Clients
that want the repeat can presumably treat it the same as 'up', clients
that don't can ignore it (or mask it? haven't checked how event
masking works in Wayland).
This seems to be a much more tasteful solution than asking the
compositor to concoct fake events (or not to concoct fake events,
depending on the client needs) for repeated keys. Is there a
deficiency in this approach that I'm missing?
<enum name="key_state">
<description summary="physical key state">
Describes the physical state of a key which provoked the key event.
When a key repeats, the sequence is down -> repeat -> repeat -> up.
</description>
<entry name="released" value="0" summary="key is not pressed"/>
<entry name="pressed" value="1" summary="key is pressed"/>
<entry name="repeat" value="2" summary="key is pressed and repeating"/>
</enum>
<event name="key">
<description summary="key event">
A key was pressed or released.
</description>
<arg name="serial" type="uint"/>
<arg name="time" type="uint"/>
<arg name="key" type="uint"/>
<arg name="state" type="uint"/>
</event>
-dan
--
[email protected]
http://ww.telent.net
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
