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.sams...@gmail.com > <mailto:derek.foreman.sams...@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+...@sardemff7.net > <mailto:sardemff7%2b...@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+...@sardemff7.net > <mailto:sardemff7%2b...@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 > > _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel