Re: Tablet support status (or, hitting jackpot with freeze break requests)

Hi Frederic,

On Wed, Aug 24, 2016 at 9:51 PM, Frederic Peters <fpeters gnome org> wrote:
Hi Carlos,

Thanks for your work on this.

So the summary of freeze requests are:
- Pushing wip/pad-osd in gnome-shell
- Pushing wip/garnacho/wayland-tablet on gnome-control-center
- Disabling/dropping the wacom module from gnome-settings-daemon

I know this implies a lot of late changes: dropping support for an
entire driver, new UI, losing some configurability at places
(temporarily, I hope), ... so I may understand if feels uneasy.

Indeed.  It may be early in the freeze but it's too much and I'm -1 on
this, let's have it for 3.24.

Some "middle ground" options I might think of are:

- Still moving OSD and configuration management to mutter, although
with mixed xf86-input-libinput/wacom driver support to ensure we can
make X11 supported again ASAP.
- Wire mutter to using gsettings from gnome-settings-daemon so
x11/wayland share the same settings, and preserve the wacom plugin in
g-s-d for X11 mostly as-is. It would still be more convenient to have
the OSD in gnome-shell nonetheless.

So, how far would you let me go? :)

I want to avoid all risks of regressions in X11 (this means the second
middle ground option).  The thing is I don't want to get tablet users
in the impossible position of having to pick between working tablet
support in Wayland and whatever feature or application they were using
on X and that for any reason fails on Wayland.

I understand your concerns, I would like to push at least for the
first option though, of the 3 late changes mentioned above, it would
only imply the "new UI" one (there's no dropped driver, nor loss of
configurability, we just shift the "applies configuration" role to
mutter), it allows us to declare tablet support complete and in full
parity in this cycle on both x11/wayland, and makes the remaining
changes for 3.24 mostly an implementation detail (switching from one
driver to another in x11).

Going for the second option will still involve changes in g-s-d, so
regressions aren't entirely impossible, and implies maintaining 2
codebases doing very similar things.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]