A couple of useful changes to the VT handling

[bluetech]

They are not dependent so you can pick both or either.

[dvdhrm]

Awesome, thx. I will pull this next week as I don't have much time right now. Anyway, they look mostly good. But I'd like to adjust the changes to test_vt. That kmscon_eloop_dispatch() looks wrong. The idea is right but I'd like to go sure we really catch the SIGUSR here and that it does not dispatch some other event. Also, we should use some timeout to avoid a deadlock if the SIGUSR never arrives (whatever reason may cause this).

Cheers David

[dvdhrm]

Sorry, I have to reject the first patch. I have looked up the kernel-changes and they actually also block VT-switch events from ctrl+alt+FX. Until we have proper input handling and can catch vt-switch events ourself, I don't want this patch. It makes it impossible to switch back to X/other-VT when being on the kmscon-VT. I don't know whether you tested this patch with a 3.1 kernel. But on my 3.1 this shows this odd behaviour.

If we have proper input handling we may reconsider this. I've added it to the TODO list.

[dvdhrm]

I have cherry-picked the other commit. I have changed a few things:

• I removed the "switch" from the two new function names. It seems redundant.
• I have added some log_warning()s and log_debug()s
• I changed the logic in kmscon_vt_leave(). We now return -EINPROGRESS if SIGUSR needs to be handled by the application. We return 0 if no VT switch needs to be made and we return <0 on failure. This allows the test_vt application to call the eloop only if really needed and avoid hangups/delays on termination if SIGUSR never arrives.
• kmscon_vt_leave() will trigger the VT_ACTIVATE ioctl only if our VT is currently active. I now check vts.v_active agains vt->num and not vt->saved_num. This actually makes more sense.
• test_vt calls the eloop dispatcher with a 1second timeout to avoid hangups on termination. And it calls the dispatcher only if -EINPROGRESS is returned.

Thanks for this patch. Just for information if you planned that: I don't want this feature as default behavior in the other test cases as it is quite disturbing for debugging but it seems an important feature for the final application. We will need further investigation for the final eloop_dispatch, though. We should remove all other signals from the eloop first to avoid receiving a SIGINT or fd event before SIGUSR and the eloop terminates without handling the SIGUSR. But we can think about this later.

Cheers David

I close this pull request now but feel free to reopen it if you have objections.

[bluetech]

Hi,

As for the K_OFF, not pulling it now seems reasonable, especially when it's completely optional. For testing, I personally used Alt-Sysrq+r, which resets back to RAW mode. I forgot to mention it in the commit message.

BTW, I spent some time this week writing up some input support, because I wanted to learn about evdev and udev. It's in here since yesterday: https://github.com/bluetech/kmscon/tree/input And I've done a moderate amount of testing. I'm not sure whether to send a pull request, I figure you might want to write it yourself instead of reviewing that.

Thanks.

[dvdhrm]

Yeah, sysrq works but it seems like a hack.

I already looked at the input module. I will add some comments to your tree later. It seems nice but I already found some things I'd change.

Regards David