<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 3, 2013 at 12:00 AM, Daniel Stone <span dir="ltr"><<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<div class="im"><br>
On 3 April 2013 03:09, Kristian Høgsberg <<a href="mailto:hoegsberg@gmail.com">hoegsberg@gmail.com</a>> wrote:<br>
> On Sat, Mar 30, 2013 at 01:31:34AM -0400, Matthias Clasen wrote:<br>
</div><div class="im">>> - It looks like I can't trigger a popup from a key or touch event,<br>
>> because set_popup requires a serial that corresponds to an implicit<br>
>> pointer grab. That is sad, I like the menu key...<br>
><br>
> Yes, it looks like we'll need new protocol for that.  It's also not<br>
> possible to trigger keyboard move or resize of windows.<br>
<br>
</div>Hm, do we really need new protocol for this, or, given that serials<br>
are display-global, can we just bump wl_shell_surface to v2 and note<br>
that v2 and above accept _either_ a key or button press for the serial<br>
argument to set_popup? I don't see any potential for confusion or<br>
getting things wrong, and it saves everyone a lot of really tedious<br>
typing.<br></blockquote><div><br></div><div style>Why should there be a serial at all? What if the client got some input from elsewhere, e.g. popup a warning or sth like that because of a hardware error??</div><div> </div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
>> - The wl_pointer interface seems to be a bit weak wrt to device<br>
>> properties. I would at least expect to learn about the number of<br>
>> buttons and right-handed vs left-handed, etc.<br>
><br>
> Daniel covered this, though I do think that we should be able to<br>
> determine the set of all buttons supported by all mice and communicate<br>
> to the client if there's a case for that.<br>
<br>
</div>Certainly evdev lets you see which buttons are supported by a pointer,<br>
as well as which keys are supported by a keyboard - at least to the<br>
extent that the hardware actually exposes this through HID, which is<br>
even less reliable than EDID.  But it's definitely possible to do, and<br>
AFAICT hardware tends to err on the side of exposing too many<br>
capabilities, rather than too few (i.e. you're not going to get an<br>
event for a mouse button we previously claimed not to have).<br>
<br>
While we're here though, I'd love to clarify what a value of 1.0 in a<br>
wl_pointer::axis event means.  Right now, anything with a wheel will<br>
send 1.0 per wheel click, whereas two-finger scrolling on touchpads<br>
will send 1.0 per pixel.  This makes axis events totally unusable for<br>
when you have a mouse and touchpad both: half your scrolls are going<br>
to be wrong.  Can we settle on, and document, 1.0 as an arbitrary unit<br>
roughly equivalent to one 'click' of a wheel, and scale appropriately<br>
in the touchpad driver?<br>
<br>
And if we're going to stick with evdev BTN_* codes for button events,<br>
we should probably document that one too.<br>
<br>
Cheers,<br>
Daniel<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
</div></div></blockquote></div><br></div></div>