- Jul 20, 2016
-
-
Carlos Garnacho authored
The buttons grabbed by the compositor might have changed in between, so just broadcast the button array again.
-
Carlos Garnacho authored
We must lookup the mode switch serial for the group where the button belongs to. Also, avoid the changes if the client requests setting the feedback for buttons owned by the compositor.
-
Carlos Garnacho authored
-
Carlos Garnacho authored
-
Carlos Garnacho authored
-
Carlos Garnacho authored
We assumed that each group could only have 1 strip and/or ring, because accounting is performed per group, so we could not assume the real index for anything above 1. Get rid of this restriction, now that MetaWaylandTabletPad does its own accounting of rings/strips, alongside groups.
-
Carlos Garnacho authored
This is best for 2 reasons: - It's feels cleaner doing first creation of rings/strips and then the group assignment. The other option is making groups iterate other all rings/strips and selectively skip those not meant for it, which sounds somewhat redundant. - Some minimal accounting of rings/strips without group restrictions is needed for meta_wayland_tablet_pad_get_label(). The rings/strips memory is now owned by MetaWaylandTabletPad instead of groups, which is sort of meaningless since all are meant to go at the same time.
-
Carlos Garnacho authored
-
Carlos Garnacho authored
-
Carlos Garnacho authored
Just call back into meta_display_request_show_osd().
-
Carlos Garnacho authored
When it's active, we want wayland to stop handling (most notably key) events.
-
Carlos Garnacho authored
There may be external/compositor-specific reasons to trigger the pad OSD. Expose this call so the pad OSD can be triggered looking up the right settings, monitor, etc...
-
Carlos Garnacho authored
This is intended to be caught in the gnome-shell code, in order to show the OSD with the pad action mapping.
-
Carlos Garnacho authored
Or NULL if the tablet is mapped to the full desktop size.
-
Carlos Garnacho authored
-
Carlos Garnacho authored
This action remaps the tablet to each of the connected monitors, or to the span of all monitors.
-
Carlos Garnacho authored
This API will be used from the gnome-shell pad OSD implementation, in order to show the actions that currently apply to every button/ring/strip in the tablet.
-
Carlos Garnacho authored
As those are specified by settings.
-
Carlos Garnacho authored
This will be used on lookups to the current action assigned to any element in a tablet pad.
-
Carlos Garnacho authored
Each of the buttons/rings/strips may have one such feedback string, this API makes is meant to make lookups consistent.
-
Carlos Garnacho authored
These are handled by the MetaInputSettings, so hook the events emitted to it.
-
Carlos Garnacho authored
It does nothing at the moment, but can be hooked into MetaWaylandTabletPad now. For X11, we need to trigger these for the pad events we receive from the passive pad button grabs.
-
Carlos Garnacho authored
This will be needed to update internal state of pad groups.
-
Carlos Garnacho authored
-
Carlos Garnacho authored
A bezier curve is created out of the 2 control points in settings, so the pressure is made to follow the stablished curve between 0 and 1.
-
Carlos Garnacho authored
Those just send different BTN_ keycodes.
-
Carlos Garnacho authored
This function will be useful for the wayland implementation, because buttons are mapped at the time of sending those through the wire. As x11/wayland implementations differ here, this function will be useful for the wayland implementation, as the action is handled lat
-
Carlos Garnacho authored
Some settings make no sense on external tablets, and others make no sense in display/system-integrated tablets. Perform those checks so we don't end up with possibly broken configuration.
-
Carlos Garnacho authored
Those settings make no sense there, so should be made ineffective.
-
Carlos Garnacho authored
We can now just set the mapping through clutter_input_device_set_mapping()
-
Carlos Garnacho authored
Depending on clutter_input_device_get_mapping(), or whether the current tool is either cursor or lens (those don't make any sense in absolute mode), relative motions will be reported.
-
Carlos Garnacho authored
This function call only applies to tablets, and thus will error out unless it's called with CLUTTER_TABLET_DEVICEs. This will allow setting absolute/relative mapping on those on the fly, as this is optional.
-
Carlos Garnacho authored
We will need to fetch information from it at certain places. The MetaBackend still takes care of freeing it though.
-
Carlos Garnacho authored
Given that information defines largely how such devices are to be configured, it makes sense to have that information at hand. A getter has been also added for the places where it could be useful, although it will require HAVE_LIBWACOM checks in callers too.
-
Carlos Garnacho authored
Now that we have clutter_input_device_get_device_node(), it is trivial to implement.
-
Carlos Garnacho authored
-
Carlos Garnacho authored
-
Carlos Garnacho authored
This function is meant to return the device node path (eg. /dev/input/...), which will be useful to wire up a few things.
-
Carlos Garnacho authored
At least for wayland, this needs implementing within mutter. So add a function to look this setting up.
-
Carlos Garnacho authored
Instead of as closure data. We will need to store (and query) more per-device info, so access to this struct is necessary.
-