<div dir="ltr"><div>For what it's worth, I'm happy to use backported patches. I just hope this gets addressed upstream eventually.<br></div><div><br></div><div>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... :-)<br></div><div><br></div><div>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.</div><div><br></div><div>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...<br></div><div><br></div><div>Jamey<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 24, 2018 at 7:11 AM, Derek Foreman <span dir="ltr"><<a href="mailto:derek.foreman.samsung@gmail.com" target="_blank">derek.foreman.samsung@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 2018-08-16 02:33 AM, Quentin Glidic wrote:<br>
> On 8/16/18 5:24 AM, Peter Hutterer wrote:<br>
>> On Fri, Aug 10, 2018 at 12:55:42PM -0500, Derek Foreman wrote:<br>
>>> On 2018-08-02 03:32 AM, Quentin Glidic wrote:<br>
>>>> On 8/2/18 10:29 AM, Quentin Glidic wrote:<br>
>>>>> From: Quentin Glidic <<a href="mailto:sardemff7%2Bgit@sardemff7.net">sardemff7+git@sardemff7.net</a>><br>
>>>>><br>
>>>>> If we start a special (grabbing) client when Weston is unfocused, it<br>
>>>>> would lose focus when coming back to Weston.<br>
>>>>><br>
>>>>> A first attempt to fix this was<br>
>>>>> 85d55540cb64bf97a08b40f79dc668<wbr>43f8295d3b<br>
>>>>> but it messed with VT switching.<br>
>>>>><br>
>>>>> This fix just updates the saved focus, so when Weston gets focused<br>
>>>>> back,<br>
>>>>> it will focus the correct client.<br>
>>>>><br>
>>>>> Signed-off-by: Quentin Glidic <<a href="mailto:sardemff7%2Bgit@sardemff7.net">sardemff7+git@sardemff7.net</a>><br>
>>>>> ---<br>
>>>>><br>
>>>>> Sorry for the delay, I hoped I could make a Gitlab MR but sadly it<br>
>>>>> didn’t happen yet. :-)<br>
>>>>><br>
>>>>> I think this patch won’t conflict with VT switching, and it does<br>
>>>>> fix the<br>
>>>>> issue I had initially.<br>
>>><br>
>>> I'm a bit confused as to where we're at with this.<br>
>>><br>
>>> How did the reverted patch "mess with" or "conflict with" VT switching?<br>
>><br>
>> it ended up always setting the keyboard focus to NULL on VT switch<br>
>> (due to<br>
>> how libinput devices are handled), so on vt switch back you had no focus.<br>
>>  <br>
>>> Is it intended that these two patches be applied, and then Jamey's patch<br>
>>> (marked as "superseded" in patchwork) be applied on top to resolve the<br>
>>> loss of focus on VT switch away/back?<br>
>><br>
>> AIUI, these two need supersede Jamey's patchl but I'm not 100% sure on<br>
>> that,<br>
>> sorry.<br>
>><br>
>> Cheers,<br>
>>     Peter<br>
>><br>
>>><br>
>>> Thought this might be important to land before the release, but it's not<br>
>>> terribly clear what it actually fixes.  I'd assumed it was the VT switch<br>
>>> thing, but that remains unresolved.<br>
>>><br>
>>> Help? :)<br>
> Sorry for the confusion. This (second) patch is a cleaner fix of the<br>
> issue that was “fixed” by the reverted commit. Then on top of it, you’ll<br>
> have to apply Jamey’s patch, which is an independent issue+fix (which<br>
> the old fix conflicted with). I’m not sure why it was marked<br>
> superseeded, maybe Patchwork detecting my patch as a reply?<br>
> <br>
<br>
</div></div>Thanks guys.  Due to hilariously misconfigured inbox filters I didn't<br>
catch these replies until today.  Sorry.<br>
<br>
I think the VT switch problem has been around for at least 1 release<br>
now, possibly a few more, so I think it's ok to release with the long<br>
standing (mostly cosmetic) bug, and deal with these fixes shortly after.<br>
<br>
Thanks again,<br>
Derek<br>
</blockquote></div><br></div>