protocol questions

[Kristian Høgsberg]

On Wed, Apr 3, 2013 at 10:59 AM, Yichao Yu <yyc1992 at gmail.com> wrote:
>
>
>
> 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??

That would just be a regular top-level window or a transient window.
The popup window type is specifically for popup menus or dropdowns,
which activate in response to user action and under X grabs mouse and
keyboard.  Under wayland the grab is internal to the server and tied
to the popup window, but we still an input event serial to make sure
an application can only pop up a grabbing window in response to a user
input.

Kristian

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