2013/8/15 Peter Hutterer <peter.hutte...@who-t.net>: > one of the things that should be done is to figure out _where_ features such > as this are going to be handled. In the compositor, the compositor's input > module, on the client side, ... ? I'm trying to figure out how to handle > this correctly, but don't have much to show here just yet.
> For example, wl_pointer only has a button event, which means that a client > cannot differ between a tap and a button click. no doubt this should be in a > piece of shared code, but right now it's not quite sure what can be > shared where yet. FWIW, I don't have a self-consistent opinion on this, but I have a clickpad that needs my patch or something similar :) It may sound too trivial, but here are the conflicting arguments to consider. 1. Consistency. I find the situation quite similar to that with on-screen keyboards (or maybe input methods). I am saying that separately, because on GUADEC an opinion was expressed by me and confirmed by Keith Packard that on-screen keyboards are not necessarily input methods. Indeed, an on-screen keyboard converts a sequence of touches or pointer clicks into a series of correctly-timed key up/down events that you can (ideally) use to play Quake or enter text, while traditional input methods only produce text. OTOH Caribou with its long-press-to-get-accents mode can't get timings right. And here and now we have a mechanism that converts touchpad touches into a series of pointer events and "button clicks" - i.e. another case of event converter. It would look wrong if these two use cases for event converters have inconsistent designs. 2. Complexity. Maybe off-topic: yesterday in a shop I also saw a bluetooth keyboard with a built-in touchpad (from a local manufacturer, looks quite similar to Rapoo E9080 but has bluetooth), and bought it for use as a remote controller for the media center. The peculiar thing was that the touchpad doubles as a numpad, i.e. has painted markings on it, and a touch-based virtual switch that puts the touchpad either in the touchpad mode or in the numpad mode. This particular device does the necessary interpretation of touches in hardware, i.e. the kernel emits pointer relative events and button presses or key events without any special drivers. But I won't be surprised if new devices with painted markings around virtual keys appear on the market that will also need to be decoded in software. So the software that converts touches on specially-marked surfaces into their device-specific intended meaning will likely get more complex and weird in the future. Just like input methods. 3. Compatibility. There is already a lot of software (e.g. weston-terninal and all gtk+ apps) that expects a pointer-like interface when operated with a touchpad. We can't just break it. 4. The need to show a pointer. There is a notion of the global pointer position that needs to be maintained in the compositor that is used with a touchpad. Due to the need to show this pointer, one can't entirely punt touchpad support to applications. And we can't "punt only gestures and quirks to applications", as on Sony touchpads there is an area where finger movements should be ignored for the purpose of moving the pointer, and the pointer is a thing that belongs to a compositor. 5. Artificial limitations. Like it or not, there will be software in the future that wants to get the exact finger positions and not the interpreted events. E.g. software that is used to configure and calibrate the touchpad, games, or software that wants to implement custom app-specific gestures. That's exactly like games that want raw keypresses and not text constructed by the input method. However, in my opinion, people want their hardware supported now, and will not wait for an architecturally-correct solution (that can be added later). For now, anyway, a touchpad is just something that sends wl_pointer events, and if it continues to be that way, applications won't need to be changed. -- Alexander E. Patrakov _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
