On 2015-05-08 06:07, Hans Petter Selasky wrote: > On 05/08/15 11:56, Garrett Cooper wrote: >> >>> On May 7, 2015, at 21:34, Hans Petter Selasky <h...@selasky.org> wrote: >>> >>> Hi, >>> >>> I have a fix, attached. >>> >>> I'll just throw this in if nobody objects. Seems like a trivial issue: >>> >>> Prevent switching to NULL or own window in the "vt_proc_window_switch" >>> function. This fixes an issue where X11 keyboard input can appear >>> stuck. The cause of the problem is a duplicate TTY device window >>> switch IOCTL during boot, which leaves the "vt_switch_timer" running, >>> because the current window is already selected. While at it factor out >>> some NULL checks. >>> >>> PR: 200032 >>> Reported by: multiple people >>> MFC after: 1 week >> >> Hi Hans, >> Can you please toss that up on phabricator? >> Thanks! >> -NGie > > If it helps getting the stuff committed ... > > https://reviews.freebsd.org/D2480 > > --HPS > _______________________________________________ > email@example.com mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
My experience is a little different. When suspend/resuming my laptop (Lenovo T530 with nVidia gpu) Sometimes when I resume, it seems like the keyboard is frozen. If I alt+f1, then alt+f9, it seems to work fine after that. I'd never though of trying just alt+f9 right away, as I could already see my X session. Not sure if this is related, but it sounds very similar. -- Allan Jude
Description: OpenPGP digital signature