On 30.10.2016 23:59, Peter Hutterer wrote: > On Fri, Oct 28, 2016 at 12:32:00PM +0200, Armin Krezović wrote: >> Hi >> >> On 28.10.2016 07:22, 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]. >>> >> >> What infrastructure is toytoolkit missing? > > proper events. right now, the events come from the compositor, are maybe > handled a little bit and passed straight into the client. but it's still > essentially a straight wayland-event to function pointer mapping. for tablet > events, the only sensible thing would be to accumulate them in the tool kit, > then pass them on as opaque event objects to the clients. otherwise, you'll > have handlers for pressure, tilt, distance, axis, etc. in every client and > they all have their own way of accumulating them until the frame event > arrives. >
Can't this be done in the compositor? >> What other compositor features besides the mode switching are missing? > > Automatic and semantic mapping of the tablets to the right monitor. requires > libwacom to check if it's built-in and some heuristics to get the output > correct. e.g. Cintiqs are built into a monitor, but laptop-integrated need > to map to the built-in screen. > > Ratio mapping for external tablets - a 16:10 tablet mapped onto 4:3 monitor > needs to have its area adjusted so that the input data isn't skewed. This > has a couple of other implementation questions - do you just clip > coordinates or do you fake a proximity out in the compositor when you leave > the active area? > > Relative vs absolute mode switching - somewhere we need the decision which > input data to use and how to switch it on the fly. Admittedly, we probably > get by just leaving the mouse in relative mode and everything else in > absolute. > > Once you want to actually use your pen in a serious manner, you need to > handle pressure curves as well. Could be done in the compositor or the > toolkit, jury's still out on that. But the pressure curve essentially means > that you can configure a physical:virtual pressure mapping to make the > tool behave like a pencil or a brush, etc. > >> There's support for mode switching in libweston itself, such as >> weston_output_mode_switch_to_temporary and >> weston_output_mode_switch_to_native >> >> What's wrong with them? Do they need some enhancements (I understand that not >> all backends support this - but I can implement it for X11 backend, and we >> can fake it for the headless one)? > > it's a different type of mode switch. forget about output stuff here, mode > switching for tablets means that one tablet button toggles through (or > directly selects) a mode. That mode then applies to the touch ring/strip and > optionally the buttons. So in mode 0, your ring may be a scroll wheel, in > mode 1 it zooms, in mode 2 it pans and in mode 3 it rotates. Button 1 may be > a left mouse button in mode 0, select the eraser tool in mode 1, etc. > > This is all stuff that's way beyond something called "toytoolkit" :) > > Cheers, > Peter > >> >>> 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 agree with what Daniel has said. It would be nice to have a reference implementation, at least on the server side. And now that there's libweston, it can be utilized by others, too. Thanks, Armin.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
