On Wed, Apr 3, 2013 at 12:00 AM, Daniel Stone <dan...@fooishbar.org> wrote:
> Hi, > > On 3 April 2013 03:09, Kristian Høgsberg <hoegsb...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel >
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
