Re: questions to planned lock-functionality for vts

[simone . weiss]

> 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
>
Hello,

Our approch would be more universal, it wouldn't only work when wayland is
used, but as well on servers and systems that are not going to use
wayland.
And wayland doesn't seem to be ready soon.

Regards
Simone Weiss

--
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/