<div dir="ltr"><div dir="ltr"><div dir="ltr">It took me longer than I hoped to get back to this, but I have now tested Quentin Glidic's two patches (the revert followed by the revised fix) plus my "Restore keyboard focus after VT switch", applied to Weston 4. With all three patches applied, Weston passes my tests. Hooray!</div><div dir="ltr"> </div><div dir="ltr">And just to be sure, I verified that applying Quentin's patches without mine do _not_ pass my tests. So Quentin's patches don't interfere with mine (good!) but also don't supersede mine, despite how Patchwork apparently got set.</div><div dir="ltr"> </div><div>Thanks everyone for keeping this going and working out the right details!</div><div>Jamey </div></div></div> <div class="gmail_quote"><div dir="ltr">On Fri, Aug 24, 2018 at 10:52 AM Derek Foreman <<a href="mailto:derek.foreman.samsung@gmail.com">derek.foreman.samsung@gmail.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 > <<a href="mailto:derek.foreman.samsung@gmail.com" target="_blank">derek.foreman.samsung@gmail.com</a> > <mailto:<a href="mailto:derek.foreman.samsung@gmail.com" target="_blank">derek.foreman.samsung@gmail.com</a>>> 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 <<a href="mailto:sardemff7%2Bgit@sardemff7.net" target="_blank">sardemff7+git@sardemff7.net</a> > <mailto:<a href="mailto:sardemff7%252Bgit@sardemff7.net" target="_blank">sardemff7%2Bgit@sardemff7.net</a>>> > >>>>> > >>>>> 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 <<a href="mailto:sardemff7%2Bgit@sardemff7.net" target="_blank">sardemff7+git@sardemff7.net</a> > <mailto:<a href="mailto:sardemff7%252Bgit@sardemff7.net" target="_blank">sardemff7%2Bgit@sardemff7.net</a>>> > >>>>> --- > >>>>> > >>>>> 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 > > </blockquote></div>