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

[Derek Foreman]

On 2018-08-24 12:23 PM, Jamey Sharp wrote:
> 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... :-)

Sorry if it seemed I was dismissing this work entirely.  This bug has
been annoying me for quite some time and I hadn't looked into it at all
myself. For my use case, I can use the keyboard focus switch shortcut to
focus something, so it hasn't been a showstopper.

I think we're going to do a weston 5.0.1 in a month or so, and this will
be among the fixes it contains. :)

> 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.

That would be great!

> 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...

Would still be interesting to take a look at, I think.

Thanks,
Derek

> Jamey
> 
> On Fri, Aug 24, 2018 at 7:11 AM, Derek Foreman
> <derek.foreman.samsung at gmail.com
> <mailto: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
>     <mailto:sardemff7%2Bgit 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
>     <mailto:sardemff7%2Bgit 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
> 
>