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

On Mon, Aug 29, 2016 at 6:18 AM, Carlos Garnacho wrote: > Hi, So, it looks like we unfortunately missed the boat on this one, and now its too late for 3.22.0. Carlos, can we instead aim to land all of this upstream in early 3.23, and backport it for F25 ? I know this is going

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

Hi, long story short, I won't be able to deliver as much/quickly as you want. In the first place, I'm having some brief vacation (back to real life on Fri). Even though, I brought with me laptop and my most inexpensive tablet, with the intention to gather the time to do this. But life sucks,

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

On Wed, Aug 24, 2016 at 08:34:45PM +0200, Carlos Garnacho wrote: > Hi!, > > As you probably know, there's been some work towards making drawing > tablets supported in Wayland. As with other device configurability > done previously to work on wayland too, this implies moving to > libinput-based

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

On Wed, 2016-08-24 at 23:37 +0200, Frederic Peters wrote: > ok then, but 3.21.91 is scheduled for next week, all things need to > be > in place and released for it. > > (this still requires another release team approval) 2/2 ___ release-team@gnome.org

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

Carlos Garnacho wrote: > > 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

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

Hi!, As you probably know, there's been some work towards making drawing tablets supported in Wayland. As with other device configurability done previously to work on wayland too, this implies moving to libinput-based input, also on the x11 side through xf86-input-libinput. But this has supposed