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, and my laptop decided to die slowly, now it won't charge anymore, and the ~30min left in battery are clearly not enough to finish this.
So, seeing you want quick/painless/seamless, and seeing I cannot provide all 3 (esp. the 1st now). I back off with this proposal, will figure out how to get out of this hole I dug myself in as soon as I can, even if it leads to the least pleasant story wrt how do we share code between x11 and wayland here for 3.22.
Other option is, someone pushes the stuff in my behalf, we satisfy the string freeze, and I use the term before hard code freeze to stabilize (that's what it's for, right?), but I kind of gave up with this option seeing the tight/ad-hoc conditions I got in the original proposal, so I'm assuming "no way" here.
Cheers,
Carlos
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 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.
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)
Fred