protocol questions

[Yichao Yu]

On Wed, Apr 3, 2013 at 12:00 AM, Daniel Stone <daniel at fooishbar.org> wrote:

> Hi,
>
> On 3 April 2013 03:09, Kristian Høgsberg <hoegsberg at gmail.com> wrote:
> > On Sat, Mar 30, 2013 at 01:31:34AM -0400, Matthias Clasen wrote:
> >> - It looks like I can't trigger a popup from a key or touch event,
> >> because set_popup requires a serial that corresponds to an implicit
> >> pointer grab. That is sad, I like the menu key...
> >
> > Yes, it looks like we'll need new protocol for that.  It's also not
> > possible to trigger keyboard move or resize of windows.
>
> Hm, do we really need new protocol for this, or, given that serials
> are display-global, can we just bump wl_shell_surface to v2 and note
> that v2 and above accept _either_ a key or button press for the serial
> argument to set_popup? I don't see any potential for confusion or
> getting things wrong, and it saves everyone a lot of really tedious
> typing.
>

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??


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