Re: Race VT+X11 on -current

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 <hps_at_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
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_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