[PATCH weston 2/2] input: Update to-be-restored focus when unfocused

[Jamey Sharp]

For what it's worth, I'm happy to use backported patches. I just hope this
gets addressed upstream eventually.

It's a little more than just cosmetic if you have a graphical application
that can be driven purely by keyboard, and sometimes you don't have a
working pointer input device so you can't get focus back after a VT switch.
I grant that's a somewhat niche use case, but it's the one I'm dealing
with... :-)

I was confused about the state of these patches too, because I didn't see
the original mails. Hopefully next week I can test the combination of
Quentin's revert+fix pair with my patch and make sure it passes the tests I
set up.

On that note, I would offer my test framework upstream, except I set up an
entire qemu image using NixOS to test this, and that seems a little
heavyweight. I can't think of an easier way to test drm-backend stuff
though...

Jamey

On Fri, Aug 24, 2018 at 7:11 AM, Derek Foreman <
derek.foreman.samsung at gmail.com> wrote:

> On 2018-08-16 02:33 AM, Quentin Glidic wrote:
> > On 8/16/18 5:24 AM, Peter Hutterer wrote:
> >> On Fri, Aug 10, 2018 at 12:55:42PM -0500, Derek Foreman wrote:
> >>> On 2018-08-02 03:32 AM, Quentin Glidic wrote:
> >>>> On 8/2/18 10:29 AM, Quentin Glidic wrote:
> >>>>> From: Quentin Glidic <sardemff7+git at sardemff7.net>
> >>>>>
> >>>>> If we start a special (grabbing) client when Weston is unfocused, it
> >>>>> would lose focus when coming back to Weston.
> >>>>>
> >>>>> A first attempt to fix this was
> >>>>> 85d55540cb64bf97a08b40f79dc66843f8295d3b
> >>>>> but it messed with VT switching.
> >>>>>
> >>>>> This fix just updates the saved focus, so when Weston gets focused
> >>>>> back,
> >>>>> it will focus the correct client.
> >>>>>
> >>>>> Signed-off-by: Quentin Glidic <sardemff7+git at sardemff7.net>
> >>>>> ---
> >>>>>
> >>>>> Sorry for the delay, I hoped I could make a Gitlab MR but sadly it
> >>>>> didn’t happen yet. :-)
> >>>>>
> >>>>> I think this patch won’t conflict with VT switching, and it does
> >>>>> fix the
> >>>>> issue I had initially.
> >>>
> >>> I'm a bit confused as to where we're at with this.
> >>>
> >>> How did the reverted patch "mess with" or "conflict with" VT switching?
> >>
> >> it ended up always setting the keyboard focus to NULL on VT switch
> >> (due to
> >> how libinput devices are handled), so on vt switch back you had no
> focus.
> >>
> >>> Is it intended that these two patches be applied, and then Jamey's
> patch
> >>> (marked as "superseded" in patchwork) be applied on top to resolve the
> >>> loss of focus on VT switch away/back?
> >>
> >> AIUI, these two need supersede Jamey's patchl but I'm not 100% sure on
> >> that,
> >> sorry.
> >>
> >> Cheers,
> >>     Peter
> >>
> >>>
> >>> Thought this might be important to land before the release, but it's
> not
> >>> terribly clear what it actually fixes.  I'd assumed it was the VT
> switch
> >>> thing, but that remains unresolved.
> >>>
> >>> Help? :)
> > Sorry for the confusion. This (second) patch is a cleaner fix of the
> > issue that was “fixed” by the reverted commit. Then on top of it, you’ll
> > have to apply Jamey’s patch, which is an independent issue+fix (which
> > the old fix conflicted with). I’m not sure why it was marked
> > superseeded, maybe Patchwork detecting my patch as a reply?
> >
>
> Thanks guys.  Due to hilariously misconfigured inbox filters I didn't
> catch these replies until today.  Sorry.
>
> I think the VT switch problem has been around for at least 1 release
> now, possibly a few more, so I think it's ok to release with the long
> standing (mostly cosmetic) bug, and deal with these fixes shortly after.
>
> Thanks again,
> Derek
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180824/34aa53c1/attachment-0001.html>