On 30/06/2014 16:33 , Pekka Paalanen wrote:
On Mon, 30 Jun 2014 11:08:35 +1000
Peter Hutterer <[email protected]> wrote:
On Sat, Jun 28, 2014 at 12:41:33PM +0300, Pekka Paalanen wrote:
On Fri, 27 Jun 2014 13:04:59 -0700
Bill Spitzak <[email protected]> wrote:
[...]
- The pen moves the seat's mouse cursor, always. If more than one cursor
is wanted the pen should be in a different seat. The user is not
manipulating more than one device at a time and does not want to see two
cursors.
...and then you said the exact opposite, plus you require the
broken case where the same hardware events map to multiple
completely different protocols (wl_pointer *and* tablet).
that's not necessarily the worst thing, provided it doesn't happen at the
same time. with a "mode toggle" button the compositor could switch between
tablet events and absolute motion on-the-fly.
That I completely agree with, but Bill did write "The pen moves the
seat's mouse cursor, always." Always - implies that you sometimes get
pointer and tablet events for the same action.
This is a change how tablets currently work in Linux but aside from that
it's actually the easiest and cleanest to implement.
It sounds like it would work: just use wl_pointer protocol when the
tablet controls the pointer, and tablet protocol when it is used as
a... tablet, and let the compositor switch between the two modes. Still,
never the both at the same time for same physical user action, right?
That way the tablet protocol could be exclusively for the "whole tablet
maps to the client/window/app-custom region", and you can ignore the
"tablet maps to whole/all outputs" case as that would be handled by the
wl_pointer mode alone. How would that sound?
doable, but I'm equally worried about how this may not actually be
useful :) having the tablet map to a single output by default is
sensible but having to switch between the modes is tricky at best. What
if you want to click a button outside the current client? do you have to
switch mode? or does the compositor automatically switch to wl_pointer
based on the client? These are the questions I'm not sure yet how to
answer. Having the compositor automatically switch mode if the client
requests the tablet manager interface and use wl_pointer otherwise is
doable but awfully close to the pointer emulation we're trying to avoid.
Moving seat's "mouse cursor" means the tablet/pen controls the
wl_pointer and sends wl_pointer events. I don't see any way around
that.
moving the visible cursor doesn't necessarily mean that it must translate
into the wl_pointer protocol. It's probably awkward at first if the pointer
moves and clients don't react to it but if we essentially require the
toolkits to support wl_tablet then this will go away quickly.
I suspect it will be very hairy to make that work. Clients always set
the pointer cursor image when the pointer enters a surface. If you move
the cursor without using wl_pointer protocol, what happens with the
cursor image?
Also, you would have wl_pointer.enter and wl_tablet.pointer_enter or
something which would both mean the pointer cursor is entering, but
controlled by a different device. It just feels... not right, no?
yeah, sorry. I forgot that in wayland a lot more things are
client-controlled than in X.
There's one more idea floating around but it's still just an idea:
extend wl_pointer to wrap the current enter/leave events with additional
tablet-specific ones. so instead of the current enter/motion/leave
sequence you'd get proximity-in/enter/motion/leave/prox-out, with the
prox-in event containing a tablet identifier. That would automatically
allow the tablet to be used as pointer anywhere, and based on the
version you just won't get the extra events. Still, it throws up a whole
bunch of other issues that I'm not happy with, so I suspect this idea
may be DOA.
Cheers,
Peter
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
