On 10/27/2016 10:22 PM, Peter Hutterer wrote: > Time to discuss graphics tablet support in weston: I had a patchset for some > earlier version of the tablet protocol, since then we've added a few bits > and bobs, including the mode switching support. > > Short story behind this email is: I seriously question the point of having a > tablet implementation in weston. I know it's supposed to be the test bed for > protocols (fwiw, we already have mutter + GTK support for tablets). But in > order to test this particular protocol, a lot of supporting infrastructure > has to be there that libtoytoolkit doesn't have. In addition, there are a > couple of things to be added to the compositor support, especially for mode > switching, that I question the value of having this in weston at all [1]. > > Some or most of this work will likely end up being an unused (and thus > untested) code path, the compositors that care about a niche feature like > graphics tablet support are unlikely to be the ones that use libweston. > > So right now, I'm tending to *not* implementing tablet support for weston. > Any opinions? Yay? Nay? Banana!? > > Cheers, > Peter > > [1] yes, you can attribute some of all this to laziness
I'm sure you can guess that I'm in favor of adding support to Weston and libtoytoolkit, but hopefully I can provide some sound reasons to back up that opinion. While pen input may not be as ubiquitous as the mouse/touchpad or keyboard, it isn't exactly uncommon either. The tablet PC user expects to be able to use their pen anywhere they could use a mouse: opening applications, moving/resizing/closing windows, interacting with dialog boxes and application UI, etc. The pen is just as capable of clicking and dragging as a mouse or finger and is used for those purposes almost as much as for drawing/writing. libtoytoolkit use is niche enough that that perhaps it is acceptable to say that clicking/dragging and other basic UI interactions should be effectively "broken" in the name of simplicity. On the other hand, it would be nice if the toolkit was responsive to at least a minimal degree. I do so much hate having to dig in my drawer for a mouse just because an application doesn't recognize my pen or puck. As for Weston, I have a much harder time accepting that it should go without support. Doing so effectively says that Weston is not suitable for use by artists with applications like GIMP and Krita. Certainly the reference compositor is free to ignore applications and use-cases that it finds irrelevant, but (as I already mentioned), artists and pens aren't exactly uncommon. Further, leaving support out of Weston just leaves the barrier that much higher for developers of other compositors. Developers aren't going to implement from-scratch support for hardware they don't have, and aren't going to be able to justify the expense of buying a tablet when there are more important bugs/features impacting their userbase. Having reference code available is useful and doubly-so to have a working implementation included in the library you're building on (libweston). Tablets currently see use in environments where "niche" compositors (e.g. nested remote desktop or single-application workstations) would likely see use. I also believe that getting support into (lib)Weston would ensure improved quality compared to the alternative since the code would be used by multiple small compositors who would have a reasonably diverse combined userbase. Sure it won't be as large as e.g. Mutter, but it should be sufficient and certainly better than the number of users individual implementations would have. Finally, I should note that adding support for tablets doesn't mean that the support has to be 100% feature-complete. Leaving out support for those parts of the protocol which are more complex and less used (e.g. mode switching; maybe even pads TBH) may be reasonable. Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three, / So you look at the sixty-fours.... _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
