Re: questions to planned lock-functionality for vts

[David Herrmann]

Hi

On Mon, Mar 23, 2015 at 2:02 PM,  <simone.weiss@xxxxxx> wrote:
> hello
>
>> By moving these calls into the kernel, you don't make them necessarily
>> fail-safe. This can all be implemented in user-space. By switching to
>> a dedicated VT (say, VT12) and running VT_SETMODE+VT_PROCESS, you lock
>> the machine. You can now implement your screensaver. If you run a
>> spawner-process, you're even safe if your screensaver crashes.
>
> Yes but this would lock the whole machine. Our plan is to make it posible
> to lock a specific set of VTs - owned by the user who wants to lock.
>
> e.g if user A locked all his VTs user B would still be able to switch to
> his VTs.

Correct. But if you want to support locking individual sessions (or
VTs), why not look at what is done with upcoming Wayland compositors,
which implement this in the compositor itself? That is, the session
tracks whether it's locked and shows a lock-screen if so. This can be
done on text-VTs the same as on graphical ones.

I mean, why does the kernel need to know VT state which is inherently
defined the application running on it?

Putting this in the kernel is the easier way out, given the historical
setup of gettys on VTs. But I wonder why it's supposed to be the
better way?

Thanks
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/